The brief is the job

147. Lesson identity

Module

1.ai-partner — Directing the AI Partner

Lesson

The brief is the job

Academic type

Workflow

Lesson type

Mixed

Order

1

Estimated time

25–35 minutes, including practice

This lesson establishes a working agreement with an AI partner: the task is defined by its boundaries, not by how confidently or enthusiastically the request is phrased.

148. Learning objective

After this lesson, you can write one task brief that states a specific goal, supplies the essential context, defines the allowed scope, and names the project surfaces the AI must not touch.

149. Why this matters

A vague request leaves many decisions unstated. In a game project, a request such as “make this feel better” could be interpreted as permission to alter behavior, timing, visuals, interface elements, level structure, or unrelated files.

A bounded brief reduces those interpretations. It gives the AI a defined assignment and gives you a stable reference for clarifying the assignment before any implementation begins.

150. Prior knowledge

You should have completed 1.checkpoints L2 — Checkpoint, change, revert. That lesson established the value of a known return point when a project will be modified. No project modification is required here, so this lesson concentrates on the brief itself.

No programming language or engine-specific knowledge is required.

151. Core concept

A task brief defines one bounded assignment. It answers four questions:

1. Goal: What specific result is wanted?
2. Context: What facts are necessary to interpret that result?
3. Allowed scope: What may be examined, discussed, or changed for this task?
4. Do not touch: What must remain outside the task?

A brief is not a chat-shaped wish such as:

Make the game feel better.

It is a constrained assignment such as:

Clarify the pause before an enemy reverses direction. Consider only the patrol pause timing. Do not change the route, movement speed, detection, damage, animation, interface, or level layout.

A useful brief is small enough to restate without adding assumptions. If it contains unrelated goals, divide those goals into separate briefs.

152. Mental model: the boundary box

Treat the brief as a box with four sides:

A missing side creates room for assumptions. For example, “improve the patrol” names a topic but does not identify one result, and “change the pause” does not say which related behaviors must remain outside the assignment.

153. The drafting loop

Use a scoped loop for this lesson:

DRAFT → RESTATE → COMPARE → REVISE

1. Draft: Write the four parts of the brief.
2. Restate: Ask the AI to reproduce those four parts without proposing an implementation.
3. Compare: Check whether the restatement adds a goal, assumes permission, omits a restriction, or exposes ambiguous wording.
4. Revise: Correct the wording of the brief and repeat the loop if needed.

The revision of the brief is the change performed in this lesson. The project itself remains unchanged. Later workflows can use the broader direction loop when an implementation decision is possible.

154. Concrete example

155. Chat-shaped wish

Make the guard behavior less boring and improve the level.

This request combines multiple possible outcomes and gives no boundary. It could refer to patrol routes, detection distance, movement speed, damage, animation timing, level geometry, or interface feedback.

156. Bounded task brief

Goal: Make the guard's pause before reversing direction easier to notice.
Context: The guard already follows an established route. The task concerns the clarity of the existing pause, not a new behavior system.
Allowed scope: Examine the patrol pause description and the timing value associated with that pause. Describe one possible timing adjustment, without implementing it.
Do not touch: Do not alter or redesign the route, detection distance, movement speed, damage, animations, interface, level geometry, or unrelated files.

157. Scope traceability

For this lesson, the AI should restate the four parts and identify wording that admits more than one reasonable interpretation. That restatement provides scope traceability: it shows how the AI interpreted the assignment.

An explanation that other behavior would be preserved is not evidence that preservation actually occurred. Behavioral preservation can be evaluated only after an implementation exists and is checked through inspection, play, or relevant rules. That work belongs to a later lesson.

158. AI-native workflow

Use the AI as a clarification partner rather than an automatic editor.

1. Make the task decision yourself: choose one intended result.
2. Draft the goal, essential context, allowed scope, and do-not-touch list.
3. Ask the AI only for a structured restatement and ambiguity check.
4. Compare the restatement with the original brief.
5. Revise phrases that permitted an unintended interpretation.
6. Repeat until the restatement faithfully reflects all four parts.

Use this prompt:

Restate this task under four headings: goal, context, allowed scope, and do not touch. Do not propose code, edits, files, or implementation steps. Then identify any phrase that has more than one reasonable interpretation.

The AI may identify ambiguity, but it should not silently decide how to resolve it. You remain responsible for choosing and writing the intended boundary.

159. Common mistakes

160. Naming a topic instead of a result

“Work on the checkpoint feedback” names an area but not an observable outcome. A result would be “make checkpoint activation easier to notice.”

161. Treating the whole system as allowed scope

“Improve the checkpoint system” permits changes to activation, progression, rewards, respawning, interface elements, and other connected behavior. Narrow the scope to the part needed for the single goal.

162. Assuming everything else is obviously forbidden

“Improve the jump” could be interpreted as changing height, gravity, acceleration, animation, camera behavior, collision, or level design. State which of those surfaces are outside the task.

163. Asking the AI to fill in missing decisions

If the brief does not specify whether the desired signal is visual, audible, or both, the AI can identify that ambiguity. It should not choose the design direction on your behalf unless choosing it is explicitly part of the assignment.

164. Claiming behavior has been preserved before implementation

A restatement can show that a restriction was understood. It cannot prove that project behavior was preserved because this lesson makes no project change.

165. Guided practice

Use this situation:

A player can reach and activate a checkpoint, but the activation is difficult to notice.

Your task is to produce a brief for one clearer activation signal. Do not ask for code, file edits, implementation, or a proposed redesign.

166. Step 1: Draft the brief

Write four labeled sections:

• Goal: Name one observable activation-feedback result.
• Context: State only the facts needed to understand that result.
• Allowed scope: Limit the assignment to one feedback channel or one clearly defined feedback element.
• Do not touch: Protect checkpoint reachability, activation conditions, progression meaning, rewards, respawn behavior, level layout, and unrelated interface elements.

If you have not decided which feedback channel is in scope, make that decision before sending the brief. Do not use “visual and audio feedback” when the exercise calls for one channel.

167. Step 2: Request a restatement

Send the brief with the provided restatement prompt. The response should contain only:

• the stated goal;
• the essential context;
• the allowed scope;
• the do-not-touch boundaries;
• any ambiguous phrase it detected.

168. Step 3: Compare

Place the original brief and the restatement side by side. Answer these questions:

• Did the restatement preserve the single goal?
• Did it add context that was not supplied?
• Did it broaden the allowed scope?
• Did it omit any do-not-touch boundary?
• Did it identify wording that genuinely supports multiple interpretations?

This is a clarity comparison, not a decision about a proposed project change.

169. Step 4: Revise

Rewrite any ambiguous or overbroad phrase. For example:

• Replace “improve checkpoint feedback” with “make the existing visual activation signal easier to notice.”
• Replace “inspect the checkpoint system” with “consider only the visual element displayed at activation.”
• Replace “do not change gameplay” with a concrete list of protected behaviors.

Request one final restatement after revising the brief.

170. Capability assessment

Submit:

1. the first draft of the brief;
2. the first AI restatement;
3. a short list of wording problems found during comparison;
4. the revised brief;
5. the final four-part restatement.

The submitted brief—not the quiz—is the capability assessment.

Use this rubric:

Revision is required if any criterion is missing. The exercise is complete when the revised brief and final restatement meet all six criteria.

171. Key takeaways

• A bounded brief defines one goal, essential context, allowed scope, and explicit do-not-touch boundaries.
• A restatement reveals how the assignment was interpreted; it does not prove that project behavior was preserved.
• In this lesson, the working loop is DRAFT → RESTATE → COMPARE → REVISE.
• Revising the brief is the change. No project implementation is needed.
• The completed artifact is a bounded brief with a faithful four-part restatement.

172. Next lesson

Continue to 1.ai-partner L2 — Inspect, then decide, which introduces inspection of an actual proposed change and the learner's decision about whether that change stays within the brief.

173. Knowledge check