You have read about the monsters. You have recognized a few in your own organization.
Now what?
The diagnosis is the easy part. The intervention is where it gets uncomfortable.
A useful diagnostic field reference is a lookup table: observable symptom, likely pattern. Pull requests ship without meaningful review. Bugs reappear in areas that were supposedly fixed. Sprint goals shift because the AI had "better" ideas. The backlog grows faster than the team can work through it.
Those symptoms are not proof of one specific cause, but they give you somewhere to look. The point is to identify what is happening in the work, not to assign a dramatic name to it.
The interventions are deliberately unglamorous. There is no framework to install, no tool to buy, and no consultant required. The counter-moves are practices that put judgment back into the path from generated code to shipped code.
The "Explain It" rule
Before AI-generated code is approved, the submitting developer explains what it does and why it belongs in the change.
If they cannot explain it, the pull request goes back.
This rule attacks several problems at once. It catches the Phantom Intern, where generated work arrives with no real owner. It challenges unquestioning trust in output that looks polished. It interrupts the review loop in which people approve code because it is syntactically clean and the diff is large.
The rule does not require the developer to know every implementation detail by memory. It does require them to understand the behavior, the assumptions, the failure modes, and the reason for the chosen approach.
That is not bureaucracy. It is the minimum needed to own the code.
Use a review checklist built for AI output
A normal code review checklist still applies. AI output needs a few explicit checks because it often passes the visual sniff test.
Ask where the code came from. Check for phantom dependencies. Look for speculative abstractions that solve a future problem nobody has. Confirm that tests were written independently rather than generated as decoration for the implementation. Read the error handling. Does it deal with the failure that matters, or does it only make the compiler happy?
Check naming against the conventions already used in the project. Ask whether the complexity is justified. Look for duplicated logic, unbounded retries, unsafe defaults, and code that quietly changes behavior outside the stated task.
None of these checks is radical. Making them visible matters because reviewers are good at recognizing familiar shapes, and AI output is good at producing familiar shapes that do not always carry the expected meaning.
Stage acceptance
Use explicit gates:
Generate. Review. Test. Integrate.
The sequence is old. It matters more now because the cost of skipping it has fallen close to zero. A developer can generate a large change before anyone has agreed that the change belongs in the system. A team can produce more proposed work than it can understand.
Staged acceptance keeps proposal separate from commitment.
A generated change is not an accepted change. A passing test is not proof that the design is sound. Integration is a decision, not the final click after the code happens to compile.
Make each gate visible. If a stage is skipped, record why. The goal is not perfect ritual. The goal is to stop speed from quietly removing judgment.
Audit the diff
Track what percentage of merged code is AI-generated and compare that with defect rates, rework, review time, or other measures the team already trusts.
The exact metric will vary. The important thing is to make the accumulation visible.
AI-generated code is hard to see when it is syntactically clean. A diff can look ordinary even when nobody on the team understands the design. Without some record of provenance, the organization cannot tell whether a growing defect pattern is connected to how the code was produced.
This is not an argument for banning AI code. It is an argument for knowing what you are shipping.
Run the rewrite test
For critical paths involving money, security, or safety, delete the AI version and write the code by hand. Then compare the two versions.
The exercise is uncomfortable and slow. That is part of its value.
The rewrite test recalibrates your sense of what the AI actually contributed. Maybe the generated version is clearer. Maybe the hand-written version exposes assumptions the first version hid. Maybe both are acceptable. You will not know by admiring the first diff.
Do not apply this to every line of ordinary code. Use it where the cost of misunderstanding is high.
Choose fewer controls
You do not need every intervention at once. Pick one or two that match the symptoms you can see. Give them a sprint to settle. Watch what changes.
If reviews are shallow, start with the explanation rule. If nobody knows how much generated code is entering the system, start with provenance and diff audits. If critical logic is being accepted because tests pass, use the rewrite test.
Aim for sustainable discipline, not a compliance checklist. The anti-patterns will keep surfacing. Your counter-moves should become more precise as you learn where the work actually breaks.