CTO commentary by Ilya Ilin
A script that drafts a report from synthetic data and a patch that changes customer billing deserve different checks. An AI tool can produce either quickly. The review decision starts with the data, permissions and behaviour the change can reach.
That is the useful question in Boris Cherny’s post about throwaway prototypes: how far can a mistake travel? A prototype with production credentials can affect real customers. Its name does not make that risk smaller.
For a founder or an enterprise engineering leader, a useful outcome is a short release policy that the team can apply to its next change. Here is how I would structure it.
Describe the failure you want to prevent
Before reviewing the diff, ask what happens if it is wrong. Could someone receive the wrong invoice, see another account’s data or lose work? Can the team restore the previous behaviour without repairing stored data? Those answers help determine the evidence needed for release.
Start with three working categories. Use them to decide which questions a reviewer must answer. A one-line permission change can belong in the most demanding category. A large experiment can remain low risk when both its environment and data are isolated.
- Isolated experiment: synthetic or disposable data, no production credentials and no writes to shared systems. An incorrect result can be discarded.
- Product change: real users or dependencies can be affected. Name an owner, test the important workflow and define how to limit or reverse the rollout.
- Sensitive operation: money, access rights or hard-to-reverse writes are involved. Add review by someone who understands the domain, evidence for failure cases and a plan to reconcile any incorrect state.
Keep the patch small enough to challenge
Suppose an agent is asked to fix an invoice calculation and also reorganises the billing module. The reviewer now has to separate the intended behaviour change from the refactor. Splitting those changes makes it easier to inspect the calculation, identify a regression and decide what to undo.
The human owner should be able to explain the important decision without repeating the agent’s summary. Which customer behaviour changes? Which assumptions remain? What was deliberately left alone? If answering requires another large investigation, the patch needs clearer boundaries or a reviewer with the relevant knowledge. Generating more code will add to that queue.
Ask for a test that would catch the mistake
For a billing handler, a useful test might deliver the same event twice and check the persisted result. It could also interrupt processing after a write, then retry. Checking that a function was called once provides less evidence about whether a customer could be charged twice. The test should observe the consequence the team cares about.
Use an end-to-end check for the workflow that crosses the changed boundary: for example, a restricted user opening the account page after a permissions change. Keep the expected behaviour explicit. An agent can write tests that agree perfectly with its own mistaken implementation, so a person who understands the product still needs to choose what must remain true.
Put the rule in the release path
Write down which changes need which checks, who approves them and what counts as an exception. Then enforce the parts that the delivery system can enforce. Required reviews and status checks are mechanisms available in repository platforms; GitHub’s branch-protection documentation gives a concrete example. A reminder in an agent prompt provides no equivalent enforcement.
A release check is useful when it examines the candidate that will actually run. Test the built site or packaged service, retain its results and release that same revision. If a check is unstable, identify why and repair it. Repeatedly rerunning until a green result appears makes the release decision depend on chance. The exception process should identify the owner and the missing evidence.
Decide how to notice and contain a bad release
Before rollout, choose a signal that would make the team stop. For a checkout change, that could include failed purchases or incorrect order state. A limited rollout can expose a problem before the whole customer base receives the change. Google’s SRE guidance describes this canary approach and the evaluation needed before expanding it.
Be precise about recovery. Reverting a binary can restore its previous behaviour, but it does not automatically repair a record already changed or retract a message already sent. A sensitive write may need a way to stop new work, identify affected records and reconcile them. Put that work and its owner in the release plan before approving the change.
Budget for the work after code generation
A team can generate patches faster while spending longer waiting for review or repairing releases. Look at time from proposed change to a verified release, the age of the review queue and the work required after deployment. These measures help a founder decide whether the next investment belongs in implementation, clearer task boundaries or better verification.
Keep the policy proportionate. A small team can begin with one page covering an owner, the possible failure, the evidence and the recovery plan. An enterprise may already have domain owners and approval controls to connect. In either case, give low-impact experiments room to move, and reserve deeper review for changes whose consequences justify it.