Write a prompt as an implementation contract

2013. Lesson identity

Module

5.2 — Prompt engineering for code

Lesson

Write a prompt as an implementation contract

Academic type

Workflow

Schema type

mixed

Order

1

Estimated time

30–40 minutes

This lesson treats a code prompt as an operational contract between the developer and an AI coding partner. The prompt must make the intended change, its boundaries, and its evidence of completion inspectable.

2014. Learning objective

After this lesson, you can author a complete code prompt for one bounded game-development change by specifying its context, scope, constraints, acceptance criteria, and required output format.

2015. Why this matters

An AI coding partner can produce plausible code from an incomplete request, but plausibility is not evidence that the requested change is correct. A structured prompt reduces ambiguity before implementation begins. It also gives you a basis for evaluating the response instead of judging it by confidence or length. In a game project, this keeps a small mechanic change from silently becoming an architecture change.

2016. Prior knowledge

You should be able to evaluate whether a task is ready for AI implementation, as practiced in 5.1 L2 — Evaluate AI-readiness before implementation. In particular, you should already be able to identify a bounded task and define observable evidence that would show the task is complete. You should also be familiar with the relevant project terminology, files, systems, and gameplay behavior for the change you are requesting.

2017. Core concept

A useful implementation prompt contains five operational parts:

1. Context: What system, behavior, file, scene, or gameplay situation is involved?
2. Scope: What exact change should be made, and what is explicitly outside the task?
3. Constraints: What existing behavior, interfaces, style, dependencies, or technical limits must remain intact?
4. Acceptance criteria: What observable checks determine whether the change is correct?
5. Output format: What should the AI return so that the work can be reviewed efficiently?

These parts are not decorative prompt sections. Together, they define the implementation boundary and the review contract.

2018. Mental model

Use the C-S-C-A-O contract:

A prompt is ready when another developer could distinguish an in-scope implementation from a technically impressive but incorrect expansion of the task.

2019. Concrete example

Suppose the bounded change is: add a visual indicator when the player can interact with a nearby object.

A weak request is:

Make the interaction system better and add a prompt for interactable objects.

This leaves the target behavior, affected system, constraints, and evidence undefined.

A contract-style request is:

Context: The player controller already identifies the current interactable target. The UI has an existing text label that can be shown or hidden.

Scope: Update the interaction presentation so the label displays the current target name while a valid target exists. Hide the label when there is no valid target.

Constraints: Do not change target detection, interaction distance, input bindings, interaction execution, or the existing UI layout. Reuse the current label rather than creating a new UI system.

Acceptance criteria:

1. A valid nearby target causes the label to become visible.
2. The label displays the target name.
3. No valid target causes the label to hide.
4. Interaction behavior remains unchanged.

Output format: First state the files and symbols you expect to inspect. Then provide a short implementation plan. After implementation, list changed files, explain how each acceptance criterion was checked, and identify any unresolved assumption.

The second prompt does not tell the AI to “be smart.” It defines the work and the evidence needed to review it.

2020. AI-native workflow

Use the following sequence when preparing a prompt:

1. Choose one bounded change. If the request contains several independent outcomes, split it before prompting.
2. Write the five contract parts. Do this before asking the AI for code.
3. Create a Git checkpoint. Confirm the repository is on the intended branch, inspect the working tree, and save or commit the current state before requesting an implementation change. Record the checkpoint so you can identify what belongs to this task.
4. Ask the AI to restate the boundary first. Compare its restatement with your intended scope.
5. Resolve mismatches before implementation. Do not let the agent infer a changed requirement from context.
6. Preserve system separation. State which responsibilities, files, interfaces, and systems must remain separate. Do not allow a bounded change to merge unrelated logic into the target system or replace an existing separation merely because a single-file solution appears easier.
7. Request reviewable output. Require changed files, assumptions, verification steps, and any omitted work.
8. Evaluate against the acceptance criteria. Treat the response as a proposal until the evidence supports the change. Compare the resulting diff with the Git checkpoint before accepting it.

The AI may help expose missing context or ambiguous terms, but you remain responsible for deciding the boundary and determining whether the evidence is sufficient. The Git checkpoint is a recovery and comparison point, not proof that the implementation is correct.

2021. Common mistake

The common mistake is to describe the desired outcome without defining what must remain unchanged. For example, “make interaction clearer” may lead the AI to alter detection, input handling, UI layout, and feedback all at once. A prompt is not complete merely because it names the feature. It must also protect unrelated behavior, preserve the separation between existing responsibilities, and state how completion will be checked.

2022. Guided practice

Draft a contract-style prompt for this bounded change:

When the player enters the detection range of a locked container, show a “Locked” status message. The existing interaction behavior must remain unchanged.

Complete these five fields:

1. Context: Identify the systems or existing behavior the AI must inspect.
2. Scope: State exactly what the new presentation should do.
3. Constraints: List at least three things the AI must not modify. Include one guardrail that preserves the separation between detection, interaction execution, and presentation.
4. Acceptance criteria: Write at least three observable checks. Include both the positive case and the case where the message should not appear.
5. Output format: Specify what the AI must report before and after implementation.

Before asking for implementation, inspect the Git working tree and create a checkpoint for the current state. After the exercise, describe how you would compare the proposed change with that checkpoint and how you would recover if unrelated files or responsibilities were modified.

Make one deliberate decision about ambiguity: choose whether the message should appear for every locked container or only for the currently selected interaction target. State that decision in the prompt rather than leaving it for the AI to infer.

2023. Validation / evidence

Your prompt passes this lesson's check when it:

• describes one bounded change rather than a broad improvement;
• identifies enough context for the AI to locate the relevant behavior;
• names at least three constraints that protect unrelated systems;
• explicitly preserves the separation between detection, interaction execution, and presentation;
• includes observable acceptance criteria for success and non-appearance or non-change where relevant;
• requires an output that exposes files, assumptions, implementation summary, and verification;
• includes a Git checkpoint before implementation and a diff comparison after implementation;
• makes an explicit decision about the locked-container message's target scope.

A reviewer should be able to read your prompt and answer: “What is being changed, what is protected, how will we compare the change with the prior state, and how will we know it worked?” without asking you to supply a missing requirement.

2024. Key takeaways

• A code prompt is an implementation contract, not a general feature wish.
• Context, scope, constraints, acceptance criteria, and output format serve different purposes.
• Explicit non-goals and separation guardrails prevent a bounded change from expanding into unrelated work.
• A Git checkpoint makes the change set inspectable and provides a recovery reference.
• Acceptance criteria must describe observable evidence, not confidence or intent.
• The AI can expose ambiguity, but the developer decides the boundary and validates the result.

2025. Next lesson

Continue to 5.2 L2 — Diagnose a prompt that invites unsafe code.

2026. Knowledge check