How we keep AI drafts out of production without slowing down
A review model for generated code and copy that catches quiet errors without turning every draft into a committee meeting.
Generated code and generated text fail in different ways. Code fails loudly: it does not compile, the test goes red, the page breaks. Text fails quietly: it reads fine and says something that is not true.
So the review is different for each, and the rule that holds for both is simple — nothing reaches a client without a person who can explain every claim in it.
Give the draft a boundary
Before generation starts, we define what the draft may decide and what must come from a person or a source. Tone and structure can be drafted. Client results, legal statements and product behaviour cannot be guessed.
For code, the boundary is the acceptance criteria and the existing architecture. A generated implementation still has to use the project conventions, preserve data rules and handle failure paths.
Review claims before style
A polished sentence can hide an unsupported promise. We check names, numbers, dates, capabilities and comparisons before editing rhythm or word choice.
Each factual claim must point to a source the reviewer can inspect. If the source does not exist, the sentence becomes a question for the owner or leaves the draft.
Make code prove its behaviour
Generated code is reviewed in the same layers as handwritten code: types, tests, security boundaries, accessibility and behaviour in the interface.
A passing build is only the first check. The reviewer follows the main path, an empty state and at least one failure path. Code that works only with the ideal input is still a draft.
Keep the prompt out of the final decision
The prompt explains how the first version was produced. It does not prove that the result is correct. Reviewers work from the output, the source material and the acceptance criteria.
This also keeps the process tool-independent. Models change. The evidence needed to approve a claim or a release should not.
Use a small approval surface
A draft moves faster when one person owns the final decision. Other people can supply facts or specialist review, but the owner decides whether the result meets the brief.
For higher-risk work, approval is split by domain. A developer owns runtime behaviour, a content owner owns claims and a responsible stakeholder signs off on legal or financial language.
AI can produce the first version. Accountability cannot be delegated with it.
The practical release gate
Before release, we ask four questions. Can we trace the important claims? Can someone explain the code path? Have we checked the non-ideal states? Is there a clear owner if the result is wrong?
If one answer is no, the work stays in review. That gate is short enough to use under deadline and strict enough to keep a fluent draft from pretending to be finished work.
