KeelenAnswer — trust and control
How do I review code that an AI wrote if I cannot read code?
Updated 21 August 2026
You review the evidence rather than the syntax. Four things tell you most of what a code reviewer would learn. Ask for a test that failed before the change and passes after it, which proves the test measures the new behaviour instead of nothing. Ask for a review by a model that did not write the code, because an author reviewing itself agrees with itself. Require a green continuous integration run on a clean checkout, which proves the change works somewhere other than the machine that made it. Then use the feature yourself and confirm it does what you asked. Keep your own approval on anything touching money, customer data, or access control, where a wrong answer is expensive and a passing test can still miss it.
None of this makes you a reviewer of the code itself, and it is not meant to. It makes you the person who decides whether the evidence is good enough, which is a job you can actually do.
What to do, in order
Test the behaviour yourself, first
Open the change and use it the way a customer would. This is the one check that needs no technical skill and catches the most embarrassing class of failure: code that runs correctly and does the wrong thing.
Demand a test that failed before the change
A test written alongside a feature can pass because it asserts nothing. A test applied without the implementation must fail, and then pass once the implementation lands. That order is the proof. Ask for it, because a test born green is theatre.
Get a second opinion that shares no context
Ask a different model, in a fresh session, to review the change and argue against it. An author that reviews its own work carries its own assumptions into the review, so the useful review is the one with no memory of writing the code.
Require a green build on a clean checkout
Continuous integration runs the whole test suite on a fresh copy of the repository. It answers a question you cannot answer by reading: does this still work when nothing else from the author's machine is present.
Keep the risky changes on your own desk
Payments, login, permissions, personal data, and anything that deletes or migrates records. Require your approval on those regardless of how well the other four layers performed, and get a qualified human to look when the stakes justify it.
What each layer proves, and what it does not
A failing-first test proves the test measures the change. It does not prove the change is a good idea. An independent review catches reasoning errors and missing cases, and it can still miss what nobody thought to look for. A green build proves the change works in a clean environment, not that the suite covers the thing you care about. Your own use of the feature proves the behaviour is right, and tells you nothing about the code paths you did not touch. The layers are useful because they fail differently.
Why the second opinion has to be independent
A model that reviews its own output tends to agree with it, in the same way an author proofreading their own writing reads what they meant instead of what is on the page. A reviewer that has never seen the reasoning has to work from the diff alone, which is the position a human reviewer is in and the reason the review is worth anything.
How Keelen runs these layers for you
Five gates stand between the loop and your main branch. New tests are applied without the implementation first and must fail, so tests born green are rejected. An independent reviewer that shares no context with the run that wrote the code reviews the diff. Your own test suite runs on a clean checkout. Nothing merges over a red required CI check. And a review window stands before gated auto-merge, which you can replace with plan-review sign-off, manual merge, or branch-only mode.
What happens when the checks cannot be satisfied
Failed runs are classified into 30 kinds. Infrastructure blips and provider limits retry on a budget and never count against your work. A real dead end becomes one plain-English card in your Needs-you queue with a recommended action, and the project pauses rather than burning quota.
When Keelen is not the answer
- You can read the code. Ordinary review practice is better than this checklist, and you should use it.
- You are shipping regulated, safety-critical, or life-affecting software. That needs a qualified human audit, and no arrangement of automated checks substitutes for one.
- You want a guarantee. This raises the floor a long way and removes the most common failures. It is not a proof of correctness, and anything that claims to be one is overselling.
Hand the work to a loop
Connect a repository, write what you want in plain language, and review the tested pull requests that come back.
FAQ
How do I know if AI-written code is safe to merge?
Check the evidence around it rather than the code itself: a test that failed before the change and passes after it, a review from a model that did not write it, a green build on a clean checkout, and your own use of the feature. Keep personal approval on anything touching money, customer data, or access control.
Can AI reliably review code that another AI wrote?
It catches a useful share of real problems, especially missing cases and reasoning errors, as long as the reviewer is a separate session that did not write the code. It is not equivalent to a qualified human on high-risk changes, and treating it as one is the mistake to avoid.
What should I never let an AI merge without a human looking?
Anything involving payments, authentication, permissions, personal data, or a database migration that deletes or rewrites records. These are the changes where the damage is hard to reverse and a passing test suite can still be silent.
Do I need to learn to code to run a product this way?
No, but you do need to be able to say precisely what you want and to judge whether the result matches. That is a product skill rather than a programming one. Learning to read a diff eventually helps, and it is not the entry requirement.