Direct, review, and validate the implementation

2444. Lesson identity

Module

5.16 — Capstone

Lesson

Direct, review, and validate the implementation

Academic type

Guided Build

Schema type

practical

Order

2 of the module

Estimated time

90–120 minutes, including implementation, review, testing, and play validation

2445. Learning objective

After this lesson, you can direct a bounded AI-assisted implementation, review its changes against the approved brief, and produce evidence for each required capstone gate.

2446. Why this matters

A capstone is not complete because an AI tool generated code or because the game launches once. The implementation must satisfy the approved scope, preserve existing behavior, and withstand both technical checks and play validation. A disciplined review turns a vague claim of completion into evidence that another person can inspect. This is also where you practice the central studio skill: directing work without surrendering judgment to the tool.

2447. Prior knowledge

You should have completed 5.16 — Scope and brief the capstone, including one explicitly selected bounded implementation criterion, its acceptance criteria, non-goals, definition of done, and list of required evidence. That criterion is the controlling handoff for this lesson; do not substitute a broader feature request. You should also be able to use the project’s established AI workflow, make a small change in the repository, run the project, and perform the relevant tests or checks taught earlier in the course.

2448. Core concept

The core concept is controlled implementation passes. Do not ask AI to “finish the capstone” in one unrestricted operation. Direct one bounded pass at a time, inspect the result, validate it, and only then proceed. The implementation is accepted only when the approved behavior, code change, regression checks, and play evidence agree.

A useful pass has four parts:

1. Context: provide the brief, relevant files, constraints, and current state.
2. Directive: request one specific change with explicit boundaries.
3. Review: inspect the diff and compare the behavior with the acceptance criteria.
4. Validation: run the appropriate checks and play the relevant path.

2449. Mental model

Use the GATE loop for every approved requirement:

The gate is not passed when one row is missing. A successful run without a reviewed diff is incomplete; a clean diff without play validation is also incomplete when the criterion is player-facing.

2450. Concrete example

Suppose the approved brief requires one player-facing interaction with a visible success state, a failure state, and a restart path. Direct the work in separate passes:

1. Ask AI to identify the relevant scene, script, and existing state transitions without editing anything.
2. Review that context and request only the interaction rule and its associated state change.
3. Inspect the diff. Reject unrelated formatting, renamed files, speculative features, or changes outside the brief.
4. Run the project and verify the success path.
5. Reset the state and verify the failure path.
6. Restart the encounter and verify that the interaction can be attempted again.
7. Record the exact steps and result for each acceptance criterion.

The example is intentionally small. If the requested change cannot be explained as a bounded sequence of observable checks, the scope needs to be clarified before implementation continues.

2451. AI-native workflow

Use AI as a context-sensitive implementation partner, not as the owner of the capstone.

Pass 1: Prepare context

Give the tool only the information needed for the current pass:

• the relevant acceptance criterion;
• the approved behavior and explicit non-goals;
• the relevant files or symbols;
• constraints from the existing project;
• the validation you will perform afterward.

Ask the tool to state its proposed files and risks before it edits. If the response assumes a file, system, or behavior that does not exist, stop and correct the context.

Pass 2: Direct one change

Use a directive such as:

Implement only criterion C-02 from the approved brief. Modify the identified interaction logic and its presentation. Do not add new features, restructure unrelated code, or change public behavior outside this criterion. Before editing, state the files you will change and how the result will be validated.

A good directive specifies boundaries and validation. “Make this better” does neither.

Pass 3: Review the result

Read the diff yourself. Ask AI to explain the changed logic only after you have formed your own initial assessment. Compare its explanation with the actual code. Check for:

• behavior that matches the brief;
• duplicated or unreachable logic;
• state that is not reset correctly;
• null, missing-reference, or timing assumptions;
• accidental changes to unrelated systems;
• debug code, temporary bypasses, or unrequested assets.

AI explanations are review input, not proof.

Pass 4: Validate and record

Run the relevant automated or project checks, then play the exact path a player would use. If a check fails, report the observed failure, expected result, relevant evidence, and the smallest next correction. Do not ask AI to conceal a failing check or rewrite the acceptance criterion.

2452. Git workflow

Use the repository history as a safety boundary and create a reviewable checkpoint for the bounded change:

1. Confirm the branch, current revision, and repository status before editing.
2. Review and record any existing uncommitted work. Do not silently include it in the capstone change; if it prevents a clean baseline, stop and resolve or document the boundary.
3. Establish the baseline by recording the starting revision, status, and the relevant existing behavior before implementation.
4. Make one coherent implementation pass for the approved criterion.
5. Inspect the diff and status; remove unrelated changes.
6. Run checks and play validation before treating the pass as complete.
7. Create or preserve a reviewable checkpoint according to the project workflow, such as a focused commit or clearly identified revision. Record its identifier and connect it to the approved criterion and evidence record.

Do not mix unrelated cleanup, dependency updates, asset experiments, or broad refactors into the capstone change. If the repository workflow requires a commit, its message should describe the bounded change rather than claim overall completion.

2453. Common mistake

The most common mistake is accepting AI output because it compiles, launches, or looks plausible. Compilation proves only that a limited class of technical errors was avoided. It does not prove that the approved behavior works, that failure and reset paths are correct, or that unrelated behavior was preserved. Review the change and exercise the player-facing path separately. A second mistake is validating from an unclear Git baseline, which makes it difficult to distinguish the approved change from pre-existing work.

2454. Guided practice

Complete the following supervised implementation session using the approved capstone brief.

1. Set the baseline — 10 minutes

Write down the criterion you will implement, its non-goals, the files or systems likely involved, and the validation evidence required. Confirm the branch, starting revision, and repository status. Review any existing uncommitted work and record whether it is outside the lesson scope. Start the project from a known state and confirm the existing behavior relevant to the criterion. If the baseline is already broken, record that fact before making changes.

2. Direct the context pass — 10 minutes

Ask AI to inspect the relevant project context and return:

• the files and symbols it believes are involved;
• the current behavior it infers;
• the smallest proposed change;
• risks and an intended validation sequence.

Do not allow an edit during this pass. Compare the response with the brief and correct any false assumptions.

3. Implement one bounded change — 20–30 minutes

Approve a narrowly worded directive for the first implementation pass. Require the tool to stay within the named files and behavior unless it identifies a concrete dependency. If a dependency appears, pause and decide whether it belongs in scope or requires a brief revision.

4. Review before repairing — 15–20 minutes

Inspect the diff line by line. Mark each changed section as one of:

• required by the criterion;
• necessary support for the criterion;
• unrelated or unsupported.

Remove or reject the third category. For the first two categories, write one sentence explaining why the change is safe. Then ask AI for a review focused on edge cases and compare its findings with your own. Record the reviewed revision or checkpoint identifier so another person can inspect the same change.

5. Validate technically — 10–15 minutes

Run the relevant checks from the project workflow. Record the command or action, result, and any warning that needs follow-up. A passing result is not enough if a warning affects the criterion.

6. Validate through play — 15–20 minutes

Play the exact path described by the acceptance criteria. Test the primary path and each required alternate condition, including failure or reset behavior when specified. Use a short evidence record:

Criterion:
Starting context and baseline revision:
Directive used:
Safety checkpoint or history identifier:
Files changed and diff review:
Starting state:
Player actions:
Observed result:
Expected result:
Technical check:
Pass / needs correction:
Evidence location or note:

7. Correct and recheck — 10–15 minutes

If any gate fails, describe the mismatch precisely and direct the smallest corrective pass. Reinspect the new diff, update the reviewable checkpoint or history record, and repeat every validation affected by the correction. Do not mark the criterion complete based on the first successful path alone.

The required decision is this: choose whether the change is ready for acceptance, needs a bounded correction, or must return to scope review. Justify the decision with the brief, the directive, the safety checkpoint or repository history, the diff, and the evidence record.

2455. Validation / evidence

At the end of the lesson, produce a capstone validation record containing:

• the approved criterion, relevant project context, and its non-goals;
• the starting branch, revision, repository status, and any pre-existing work identified at the baseline;
• the implementation pass or passes used and the directive for each pass;
• the safety checkpoint or repository-history identifier that makes the change reviewable;
• the files changed and a line-by-line or section-by-section review of the diff;
• technical checks performed, commands or actions used, results, and relevant warnings;
• play-validation steps and observed results for every required condition;
• known limitations, failures, or deferred work;
• a final decision: accepted, correction required, or scope review required.

You have met the lesson objective when another reviewer can trace the selected bounded implementation criterion and each acceptance criterion from its context and directive through the safety checkpoint, history and diff review, technical checks, and observable play validation. The evidence must include an actual AI-assisted capstone implementation change; an AI-only review or proposal fallback cannot replace that change. If the evidence is incomplete, the correct result is not “done”; it is an explicit gap that must be resolved or accepted through the project’s defined review process.

2456. Key takeaways

• Direct AI through bounded passes instead of one unrestricted completion request.
• Establish and record a Git baseline before editing, then preserve a reviewable checkpoint.
• Review the actual diff; an AI explanation is not evidence of correctness.
• Combine technical checks with player-facing validation.
• Accept a capstone criterion only when its context, directive, safety history, diff review, technical checks, and play evidence are traceable and complete.

2457. Next lesson

Next: 5.16 L3 — Defend the decision and document the work.

2458. Knowledge check