Loose collections of tips are hard to remember and harder to teach. A framework solves that by giving the practice a shape—a named structure you can hold in your head, apply consistently, and hand to someone else. This article presents one such model for prompting code generation, organized around three stages that map to how a code request actually moves from idea to verified result.
The model has three stages: Intent, Context, and Verify. Each has distinct components, and each applies at a specific moment in the work. The value of naming them is not the names themselves but the discipline they impose—when you know the framework has three stages, you notice when you have skipped one, which is exactly when prompts go wrong.
Use this as a scaffold. Once it is internalized, you will run all three stages without thinking about them, the same way an experienced writer no longer consciously thinks about structure. Until then, the explicit model keeps you honest.
Stage One: Intent
Intent is what you settle before you write a single word of the prompt. It answers the question of what you are actually trying to build.
Behavior Over Implementation
The first component of Intent is stating the desired behavior, not the implementation. "Return the median of a list of numbers" is behavior. "Sort the list and pick the middle" is implementation. Leading with behavior keeps you from over-specifying before you understand the problem, and it lets the model contribute a better approach than the one you had in mind.
Inputs, Outputs, and Edge Cases
The second component is naming exactly what goes in, what comes out, and which edge cases matter. This is where ambiguity hides—does the input list allow duplicates, what happens on an empty list, is the output an integer or a float. Settling these in the Intent stage means they do not surface as bugs later. The step-by-step process treats this as its opening move for the same reason.
Stage Two: Context
Context is everything the model cannot infer about your situation. It is the highest-leverage stage and the one most often skipped.
The Environment Layer
The first component of Context is the environment: language version, framework, dependencies, and any libraries the model must use or avoid. Versions matter because APIs change; an unstated version invites code that no longer runs. This layer is cheap to supply and expensive to omit.
The Example Layer
The second component is showing real code from your project. One representative function teaches the model your naming, structure, and error handling all at once—far more effectively than describing those conventions in prose. The model pattern-matches on examples, so showing beats telling. This is the principle the examples article demonstrates across multiple scenarios.
Trimming to Signal
The third component is curation. More context is not better past a point; an entire file pasted in to show one function buries the signal. Include what the new code will touch and nothing else. The discipline of Context is as much about exclusion as inclusion.
Stage Three: Verify
Verify is everything that happens after the model responds. Generation produces a claim; this stage turns it into something you can trust.
Read Before Run
The first component is reading every line before executing it. This is non-negotiable. Polish creates false confidence, and reading is what catches the subtle errors—nonexistent calls, security gaps, mishandled edges—that the model is prone to. It also keeps you the author of your codebase rather than a passenger. The best practices guide treats this as the foundational discipline.
Test Against Reality
The second component is running the code against real and edge-case inputs, and requesting tests you then review critically. A test that asserts the wrong behavior is a trap, so the tests get the same scrutiny as the code. Execution without errors is not proof of correctness.
Iterate With Precision
The third component is correction. When output misses, feed back the exact error message—a stack trace pinpoints the divergence—and restart cleanly when a thread anchors on a wrong assumption. Iteration is part of Verify, not a separate activity.
When to Apply Each Stage
The framework flexes with the stakes of the task. Knowing when to compress it is part of using it well.
Full Model for Production Code
For code that will live in your codebase, run all three stages in full. Intent prevents ambiguity, Context aligns the output, and Verify secures quality. The minutes spent are repaid in errors prevented and iterations avoided. This is the default for anything that matters. The three stages are not equally expensive: Intent and Verify are mostly thinking and reading, while Context is the one that takes real effort to assemble. That asymmetry is exactly why Context is the stage people cut, and exactly why cutting it produces the most mismatched output. When you feel tempted to skip a stage to save time, it is almost always Context, and that is the one to protect.
Compressed Model for Quick Work
For a throwaway script, compress to a light Intent (a clear one-line ask) and a light Verify (read the result), skipping the Context stage entirely when there is no project to fit into. The framework scales down without breaking, because each stage is independent. Matching rigor to stakes is itself a discipline, one the case study shows a team learning the hard way.
Diagnosing a Failed Prompt
The framework earns its keep most clearly when a prompt fails and you do not know why. Walk the three stages in reverse. Did Verify catch a real error, or did you skip it and ship a guess? Was the Context stage complete, or did the model invent an environment because you described instead of showed? Was the Intent clear, or did you hand the model an ambiguous behavior with undefined edge cases? Almost every disappointing result traces to a specific stage you compressed too far. Naming the stage turns a vague frustration—"the model is bad at this"—into a concrete fix you can apply on the next attempt. That diagnostic power is the practical payoff of having a named structure rather than a loose set of tips.
Frequently Asked Questions
Why these three stages and not more?
Because they map cleanly to the three things that actually go wrong: unclear intent, missing context, and unverified output. Adding stages would add ceremony without addressing a distinct failure mode. Three is the smallest number that covers the real risks.
Which stage do people skip most?
Context, by a wide margin. It is invisible work—the model seems to understand without it because it produces something plausible—so people omit it and then rewrite the mismatched output. Naming Context as a required stage is the framework's main contribution to most people's practice.
Can I teach this to a junior developer?
Yes, that is part of the point. A named three-stage model is far easier to teach and check than a loose list of tips. You can review someone's prompt by asking which stage they skipped, which turns vague feedback into specific coaching.
Does the framework change as models improve?
The stages are durable because they concern the gap between what you want and what the model knows—a gap better models narrow but never close. What changes is how much Context the tools gather automatically. Intent and Verify remain entirely your responsibility regardless of model capability.
Key Takeaways
- The model has three stages—Intent, Context, Verify—mapping to the three things that go wrong with code prompts.
- Intent settles behavior, inputs, outputs, and edge cases before you write a word of the prompt.
- Context supplies the environment and real example code the model cannot infer, trimmed to the signal.
- Verify covers reading every line, testing against reality, and iterating with precise feedback.
- Run the full model for production code and compress it for throwaway work—the stages are independent.
- Naming the stages makes the practice teachable and lets you diagnose a weak prompt by which stage it skipped.