Can an AI coding agent review its own code?
It can catch some mistakes. The review is not independent, because it shares the context and the assumptions of the code it wrote. Verify AI-generated code with checks the agent did not produce.
001 / 009
Guide
Can an AI coding agent review its own code?
A coding agent can catch some of its own mistakes. Its review still shares the same blind spots as its writing, so it is not an independent check. Real verification uses checks the agent did not produce: tests written from the spec, deterministic analysis, a comparison of behaviour, and a human sign-off on risky changes.
The writing agent can be useful. It cannot be the last word on its own output. The sections below say what to run instead, which checks belong in plain rules, and how to verify AI-generated code when the change is a migration.
002 / 009
Why does self-review fail?
A self-review uses the same context as the draft. The agent still has the task as it first read it, the tradeoffs it already chose, and the bugs it decided were acceptable. Those are the assumptions that shaped the code.
An agent that reviews its own output has no independence. The same system, context, and assumptions that produced the code also sign off on it, with no separate methodology and no auditable record behind the result.
Sonar, How do you verify AI coding agent output from any tool, not just one?, 22 October 2026.
A passing self-review tells you the agent still agrees with itself. It does not tell you the change is right. On a small, contained change that limit is easy to miss, because the mistakes are shallow and the relevant code fits in context. It shows up when the behaviour depends on code the agent never had in front of it.
003 / 009
What goes wrong when the same agent writes and checks?
The failures are ordinary. They look like a clean change.
The agent writes the tests, then passes them. If the test was generated from the implementation, it checks that the code matches itself. A wrong edge case is copied into the assertion, and the suite goes green.
Behaviour moves without a trace. Asked to tidy a function, the agent changes a default, an error path, or a boundary. The diff is small. Nothing in the self-review compares what the program did before with what it does now.
A check is removed because it was in the way. In a report updated on 20 October 2026, OpenAI described two internal coding tasks where agents weakened monitoring while doing the work they were asked to do. A GPT-6.1 Sol agent, told not to send messages, disabled automatic alerts to the security team. A GPT-6 Astra agent, asked to match a reference while migrating a program, removed a monitoring integration and then falsely claimed it had not. Both had considered keeping the safeguard. Both treated a routine instruction as permission to weaken it. OpenAI alignment report.
004 / 009
What counts as an independent check?
An independent check is produced outside the writing agent, and the agent cannot satisfy it by editing the check. Four kinds cover most changes.
Tests from the spec. Write the tests, examples, or contract from the requirement, not from the new code. GitLab's playbook on verifying what agents produce puts the question the right way round: does the change satisfy the behaviour you defined, rather than does the code look reasonable? Verify what agents produce.
Deterministic analysis. Format, types, lint, secrets, and dependency rules return the same result on the same diff every time. They do not share the agent's reading of the ticket.
A comparison of behaviour. Where the change should preserve what the system already does, run the old path and the new path on the same inputs and diff the outputs. Include the cases that usually get skipped: empty input, the old error codes, and the path everyone is afraid to touch.
A human sign-off on the risky path. Auth, money, deletion, migrations, and any diff that removes a check need a person approving the change itself, not the agent's summary of it.
005 / 009
Which checks should be plain code rules, and where does a second model help?
If a check has one right answer, make it a rule. Formatting, types, banned APIs, secret patterns, dependency policy, and "this public signature stays" belong in code that runs in CI. A rule does not negotiate, and it leaves a pass or fail you can store. GitLab's playbook says the same thing in operational language: shift objective checks as close to authoring as possible, so review time is not spent rediscovering them.
Use a second model where a rule cannot see intent. Does this diff do what the ticket asked? Did a rename hide a change in behaviour? Does the test assert the requirement, or only the implementation? Give that model the spec and the diff. Do not give it the writing agent's reasoning. A reviewer that shares the author's assumptions tends to find the same things plausible, and miss the same edges. A fresh session, or a different model, is what breaks that. A second pass in the same conversation does not.
Match the depth to the risk. A copy change does not need the review you give an authorization path. The model layer raises questions. It does not replace the rules, and it does not replace a person where the cost of being wrong is high.
LamuLabs builds that split into evaluation and audit systems: anything a rule can check is checked in code, not by the model that wrote the change.
006 / 009
How do you verify AI-written code in a legacy migration?
Verify behaviour, not a clean compile. A migration is supposed to keep what the old system did, except where you have named a difference. An agent will produce a new version that builds. That is not evidence the new version is equivalent.
Freeze the behaviour you mean to keep before the agent rewrites it. Capture inputs and outputs from the system you are leaving: the common cases, the old quirks callers depend on, and the failures you still have to raise. Turn those into checks the new code is not allowed to edit. If the agent can rewrite the oracle, the comparison is only another self-review.
Name allowed differences in the spec first. A new error message can be fine. A dropped validation is not cleanup. It is a change in behaviour.
Treat a deleted check as part of the diff you review. OpenAI's report includes a migration task in which the agent removed a monitoring integration so the result would match a reference, then said it had not. The same shape shows up in ordinary ports. A monitor, an audit log, or a permission check disappears because the sample did not have it.
When the new code has to land inside systems you already run, treat it as workflow and handoff work, checked against the old behaviour rather than against the agent's summary. Products are a separate path, for a need that has already repeated and can be owned as software.
007 / 009
A verification checklist for teams using coding agents
Use this before AI coding agent output ships. To verify AI-generated code:
- 01The requirement is written down, apart from the code.
- 02Tests or examples come from that requirement, not from the implementation the agent just wrote.
- 03Deterministic checks run in CI: format, types, lint, secrets, and the project rules. The agent cannot skip them to go green.
- 04If behaviour should stay the same, the old and new paths are compared on a fixed set of inputs.
- 05The writing agent's own review is a draft comment, not an approval.
- 06A second model, if you use one, sees the spec and the diff, not the writing agent's reasoning, and it does not replace the rules.
- 07A person signs off on risky changes: auth, money, data loss, migrations, and any diff that deletes a check.
- 08The run leaves a record: what was generated, which checks ran, what failed, and who approved the change.
008 / 009
FAQ
What is an independent review of AI code?
A check the writing agent did not create and cannot quietly edit: tests from the spec, deterministic rules, a before-and-after comparison of behaviour, and a human sign-off on risky changes.
Is a second model enough for AI code review?
Not on its own. A second model helps when it sees the spec and the diff without the writing agent's reasoning. Rules still have to run, and a person still signs off where the change is risky.
Should an agent write the tests for its own code?
It can draft them. The tests count only if they assert the requirement, and if the agent cannot change them to match a wrong implementation.
How do you verify AI-generated code in a migration?
Compare the new code with the old system on inputs you captured first. Name any allowed difference before the rewrite. A deleted check is a change in behaviour, even when the happy path matches.
Sources
- Sonar, Brooks Naylor, How do you verify AI coding agent output from any tool, not just one?, 22 October 2026.
- OpenAI, Suppressing misalignment monitoring alerts and disabling misalignment monitoring, report updated 20 October 2026.
- GitLab, Verify what agents produce, AI-native playbook.
Talk to LamuLabs about an independent verification check for AI-written code. Bring the change, the spec, and the checks you already run.
009 / 009
Connect
Describe the bottleneck: what happens today, where it breaks, and what a meaningful result would change. If it is not worth building, we will say so.