Most teams adopt AI code generation the same way: someone tries it, likes it, and the practice spreads informally. That works until two engineers solve the same problem in incompatible ways, a generated function ships with a security hole nobody reviewed, and a junior developer starts pasting whole files into a chat window without a second thought. At that point you need more than enthusiasm. You need an operating manual.
A playbook turns a loose habit into a system. It names the specific situations where AI helps, defines what to do in each one, says who is responsible, and orders the steps so the safe path is also the easy path. This article lays out that operating manual as a set of plays you can adopt directly or adapt to your stack.
Think of each play as a trigger paired with a response. When a certain situation appears, you run a known sequence rather than improvising. The value is consistency: the tenth person to hit a situation behaves like the first, and the team gets predictable results instead of a lottery.
Play One: The Scaffold
Trigger: A new module, component, or service needs to be stood up from nothing.
The scaffold play uses AI to produce the skeleton fast so engineers spend their attention on the parts that matter. The risk is that scaffolds carry conventions, and a wrong convention propagates through everything built on top.
How to run it
- Provide the model with one existing module as a reference for structure and naming.
- Ask for the skeleton only: file layout, types, function signatures, and stubs.
- Review the structure before any logic is generated.
- Owner: the engineer who will own the module long-term, never a drive-by helper.
The scaffold is the cheapest place to catch a structural mistake. Spending five minutes here saves hours of reconciliation later.
Play Two: The Translation
Trigger: Working code exists in one language or framework version and must move to another.
AI is unusually good at translation because the logic is already settled. You are not asking for invention, only for re-expression in a different idiom.
How to run it
- Supply the source code and a short note on the target's conventions.
- Generate the translation in chunks that map to logical units, not the whole file at once.
- Compile or type-check immediately, since invented API calls are the main failure mode.
- Owner: whoever understands the source behavior, so they can confirm equivalence.
Translation is one of the highest-yield plays because the correctness bar is well defined: the output should behave like the input. Our real-world examples and use cases include several translation walkthroughs worth studying.
Play Three: The Test Backfill
Trigger: A piece of code lacks tests and you want coverage before refactoring it.
This play is powerful and dangerous in equal measure. AI can write a lot of tests quickly, but it will write tests that lock in current behavior, bugs included.
How to run it
- Generate tests in a separate pass from any code changes.
- Read every assertion and ask whether it describes desired behavior or merely current behavior.
- Delete or rewrite assertions that encode bugs.
- Owner: a reviewer who knows the intended behavior, not just the existing code.
The discipline of reading each assertion is non-negotiable. A test suite that certifies your bugs as features is worse than no suite at all. The risks here connect directly to the failure patterns in our common mistakes article.
Play Four: The Refactor Pass
Trigger: A function or file works but has grown tangled and needs cleanup.
How to run it
- Provide the code plus a clear statement of the goal: reduce nesting, extract a helper, remove duplication.
- Constrain the model to behavior-preserving changes only.
- Run the existing tests against the refactored output before reading it.
- Owner: the engineer most familiar with the code's edge cases.
Refactoring without tests is reckless whether a human or a model does the work. The test gate makes this play safe; without it, skip the play entirely.
Sequencing: The Order That Keeps You Safe
Individual plays are useful, but the order in which you run them is what prevents compounding errors. The principle is simple: confirm structure before logic, and confirm behavior before trusting output.
The standard sequence
- Establish or confirm types and interfaces first.
- Generate logic against those confirmed types.
- Add error handling and edge cases as a distinct pass.
- Generate or backfill tests against the settled behavior.
- Review the whole result as a unit before merging.
This ordering means every later step builds on something you have already verified. It is the same incremental rhythm we lay out in our step-by-step approach, applied at the level of a whole feature rather than a single function.
Ownership: Who Holds the Pen
A playbook without clear ownership becomes a free-for-all. The governing rule is that the person who will maintain the code owns every prompt that produces it.
Ownership rules that prevent drift
- The future maintainer reviews and approves all generated code, even if someone else prompted it.
- Security-sensitive code requires a second reviewer regardless of who generated it.
- No engineer merges generated code they cannot explain line by line.
- Prompts that produce shared infrastructure are reviewed like any other architectural decision.
These rules do not slow good teams down. They prevent the slow accumulation of code that nobody understands, which is the failure mode that eventually grinds a codebase to a halt.
Putting the Plays Into Daily Work
A playbook only matters if people use it. The way to make that happen is to lower the friction of doing the right thing.
Adoption tactics
- Keep the plays in a short, scannable document your team can reference in seconds.
- Pair each play with a reusable prompt template so engineers do not start from scratch.
- Review the playbook quarterly and retire plays that stopped earning their place.
- Capture new plays when a recurring situation appears that none of the existing plays cover.
The best playbook is a living one. As your tools and codebase evolve, so should the plays. To structure that evolution deliberately, see our framework for prompting for code generation, which gives the underlying model these plays are built on.
Frequently Asked Questions
How is a playbook different from just writing good prompts?
A prompt solves one problem once. A playbook captures which situations recur, what to do in each, who is responsible, and in what order. It turns individual skill into team capability, so results stay consistent even as people come and go.
Do small teams really need this much structure?
Small teams need less ceremony but the same principles. You may keep the playbook to a single page and skip formal sign-offs, but you still benefit from naming your common situations and agreeing on how to handle them. Structure prevents the divergence that gets expensive as you grow.
What is the single most important play to adopt first?
The sequencing discipline: confirm structure before logic, and behavior before trust. More than any individual play, getting the order right prevents the compounding errors that make AI-assisted development feel unreliable.
How do we keep the playbook from going stale?
Treat it like code. Review it on a schedule, retire plays that no longer fit your tools, and add new ones when a recurring situation appears. A playbook that nobody updates becomes a document nobody reads.
Who should own the playbook itself?
A senior engineer or tech lead should own the document, gather feedback, and shepherd changes. Ownership of the playbook is separate from ownership of any given piece of code, but both matter for keeping the practice coherent.
Key Takeaways
- A playbook converts informal AI use into a consistent system of triggers, responses, and owners.
- Core plays include scaffolding, translation, test backfill, and behavior-preserving refactors.
- Sequence work so structure is confirmed before logic and behavior is confirmed before trust.
- The future maintainer of any code owns the prompts that generate it, full stop.
- Security-sensitive and shared-infrastructure code always gets a second reviewer.
- Keep the playbook short, paired with templates, and reviewed on a schedule so it stays alive.