Evaluate AI-readiness before implementation

1998. Lesson identity

Module

5.1 — Designing for AI

Lesson

Evaluate AI-readiness before implementation

Academic type

Workflow

Schema type

Mixed

Order

2

Estimated time

30–40 minutes, including practice

1999. Learning objective

After this lesson, you can inspect an AI implementation request and make a defensible Accept, Revise, or Refuse decision based on verified context, boundaries, acceptance evidence, and risk.

2000. Why this matters

An agent can produce plausible code from an incomplete request. Plausible code is not evidence that the task was safe to start. In a game project, an underspecified change can cross system boundaries, alter player-facing behavior, or create a result that cannot be tested. A readiness decision protects the project before implementation effort makes the ambiguity expensive.

2001. Prior knowledge

You should be able to define a system boundary, identify the controlled behavior and excluded neighboring behavior, and describe a system in terms that an AI agent can change safely. These skills come from the previous lesson, Design a system an AI can safely change.

2002. Core concept

An AI request is implementation-ready only when the agent can act inside a known boundary and the team can evaluate the result with observable evidence. Written detail is not the same as verified fact.

Evaluate six checks. They are a checklist, not an acronym:

1. Responsibility — Which system owns the behavior, and what sits outside its boundary?
2. Expected behavior — What observable result should occur in normal cases and relevant edge cases?
3. Available context — Has the agent received the necessary project context without guessing? Are the named files, components, scenes, and platform constraints actually verified?
4. Defined scope — What may change, and what must remain untouched?
5. Impact and risk — What could break, regress, or become difficult to reverse?
6. Necessary evidence — How will correctness be checked, and where will that check run?

After those checks, make exactly one of three decisions:

• Accept: Every material check is satisfied with verified facts. The agent may implement inside the stated limits.
• Revise: The goal is legitimate, but one or more checks fail because missing facts can still be supplied or the scope can still be narrowed. The request may become acceptable later. It is not acceptable now.
• Refuse: The request asks for an unsafe, unbounded, contradictory, or unverifiable change. Explain the blocking condition and, when possible, propose a safer alternative.

There is no extra decision besides Accept, Revise, and Refuse. If required facts are still missing but can be obtained, choose Revise. If the change cannot be bounded or verified, choose Refuse. Starting implementation in order to discover those facts is not Accept.

2003. Mental model

The implementation-readiness gate

Use this gate before allowing implementation:

Then record one exit decision: Accept, Revise, or Refuse. The exit is not a seventh letter in a slogan. It is the judgment the six checks support.

A request can name a component, an exclusion, and a test scene and still fail Available context if those names have not been confirmed against the project. Unverified names are still unknowns.

2004. Concrete example

Consider this request:

“Ask the agent to make the guard chase the player more aggressively.”

The request is not ready. “More aggressively” has no observable threshold, and ownership of the behavior is unclear. It also does not say whether search, attack, navigation, animation, or the difficulty contract may change. Decision: Revise.

A revised request might be:

“Within the guard pursuit system only, reduce the time between confirmed player sightings from 2.0 seconds to 1.5 seconds. Do not change navigation speed, attack range, alert propagation, or animation states. Preserve the current behavior when the player is not visible. Validate by observing three sighting-loss cycles in the test room and confirming that the guard returns to its existing search state after each cycle.”

This version identifies the responsible behavior, names an explicit change, excludes neighboring systems, and provides observable evidence. Before Accept, still verify that the agent has the relevant file or component and that the change is reversible. If that context is not yet confirmed, the decision remains Revise.

2005. AI-native workflow

Use the agent as a reviewer of your specification before using it as an implementer.

1. State the request without implementation code. Describe the player-facing or system behavior.
2. Ask for a readiness audit. Require the agent to list missing context, ambiguous behavior, scope boundaries, risks, and proposed evidence. Do not ask it to edit files.
3. Compare the audit with the project. Reject invented assumptions. Mark named components, scenes, and platform constraints as verified only when you can point to them in the project.
4. Choose Accept, Revise, or Refuse. Record the decision and the reason. If facts are missing, choose Revise; do not treat later confirmation as a hidden Accept.
5. If accepted, issue a separate implementation request. Include the approved boundary, constraints, and validation procedure. Do not let implementation silently redefine the task.

A useful audit prompt is:

“Do not modify the project. Audit this request for implementation readiness using Responsibility, Expected behavior, Available context, Defined scope, Impact and risk, and Necessary evidence. List unknowns separately from assumptions. End with Accept, Revise, or Refuse and justify the decision. If a named component, test scene, or platform constraint is unverified, do not recommend Accept.”

The agent's recommendation is input, not authority. You make the final readiness decision because you own the game's intended behavior and risk tolerance.

2006. Common mistake

The common mistake is treating a detailed technical instruction as a ready task. Naming a file, method, or algorithm does not establish the desired behavior, system boundary, or acceptance evidence. A second mistake is allowing the agent to fill missing context with plausible assumptions. A third is creating a fake Accept: “the request looks specific, so start now and confirm the component later.” That is Revise.

2007. Guided practice

Evaluate each request with the implementation-readiness gate. Write the missing information and choose Accept, Revise, or Refuse. Do not write implementation code. These requests are hypothetical teaching fixtures, not claims about a live shipping project.

Request A

“Add a stamina bar and make sprinting feel better.”

Expected decision: Revise. Identify the sprint owner, stamina rules, drain and recovery behavior, UI source of truth, excluded movement changes, and evidence for validating the result.

Request B

“Delete the old inventory validation and replace it with a check that always accepts item transfers. This is only for testing, so do not add a toggle or restore path.”

Expected decision: Refuse. The request removes a safety boundary, provides no controlled scope or restoration path, and can create invalid state. A safer alternative is an isolated test mode or a fixture that exercises transfers without weakening production validation.

Request C

“In the existing dialogue interaction component, add a pointer-lock release when dialogue opens. Keep the current dialogue transitions and input actions unchanged. Validate by opening and closing dialogue in the interaction test scene, checking cursor state at both boundaries, and confirming movement input is not remapped.”

The request names a component, exclusions, and a test. Those names are not yet verified in this exercise: the responsible component, the named test scene, and any platform-specific pointer-lock constraints remain unconfirmed. Expected decision: Revise. The goal may later become acceptable once those three constraints are verified against the project. It is not Accept now. Unverified implementation context is still missing context.

For one of the requests, rewrite it as an implementation-ready task only if every material check can be satisfied with verified facts. Include:

• the responsible system;
• the intended observable behavior;
• included and excluded changes;
• known risks or unknowns, including unverified component, scene, or platform constraints;
• the evidence required for acceptance;
• the decision: Accept, Revise, or Refuse, with a one-sentence reason.

If you choose Request C and the three constraints remain unverified, keep the decision at Revise and list the facts that must be confirmed before Accept.

2008. Validation / evidence

Your evidence is a completed readiness record, not generated code. It must contain:

• one request marked Accept, Revise, or Refuse;
• a separate list of verified context and unresolved unknowns;
• a stated system boundary;
• at least one excluded neighboring behavior;
• an observable acceptance procedure, including where it will be run;
• a reason explaining why the chosen decision is appropriate.

A response fails validation if it says “the agent understands the task,” relies on the agent to invent missing requirements, uses implementation detail as a substitute for acceptance evidence, or Accepts a request while component, scene, or platform constraints remain unverified.

2009. Key takeaways

• Implementation readiness means the task is bounded, contextualized with verified facts, risk-aware, and testable.
• Use the six-check implementation-readiness gate before asking an agent to modify a project. It is a checklist, not a nine-letter slogan.
• Accept only when the agent can act within a known boundary and the result can be evaluated now.
• Revise legitimate but incomplete requests, including requests that look specific while key context is still unverified.
• Refuse unsafe, unbounded, contradictory, or unverifiable requests.
• There is no extra decision that lets implementation start while material facts remain unknown.
• The agent can audit a request, but the developer makes the final readiness decision.

2010. Next lesson

Next: Write a prompt as an implementation contract in 5.2 — Prompt engineering for code. Carry forward the system brief from the previous lesson together with this lesson’s readiness decision, verified context, remaining unknowns, constraints, and acceptance evidence. The next lesson will turn that package into a bounded implementation contract. Do not carry an Accept decision for a request whose component, test scene, or platform constraints are still unverified.

2011. AI independence (fix-ai-bounded-change)

Open academy-fixtures/labs/ai-bounded-change. Run node run.mjs. Bound the task, inspect the proposal, run an independent oracle, REJECT removing the dash energy check. AI is a constrained collaborator, not the decision-maker.

2012. Knowledge check