# Reviewing AI-written code before you ship it: 4 gates > Reviewing AI-written code isn't "read every line" or "trust the model". These are the 4 gates I use with a team of Claude Code agents before anything ships. *2026-10-20T10:25:30Z* # Reviewing AI-written code before you ship it: 4 gates There's an Ask HN thread getting a lot of attention today: ["How to deal with shipping AI-written code you don't understand?"](https://news.ycombinator.com/item?id=50151036). It has passed 500 comments, and the answers split two ways. Some say "don't ship what you don't understand." Others say "whoever deploys it owns it, so lean on tests and monitoring." I run a team of Claude Code agents every day, coordinated with Orchestra MCP, with the work tracked in GitHub Issues through [Claude GitHub PMS](https://gh-pms.fadymondy.com/en/blog/github-issues-project-management-claude-code). So for me this question isn't theoretical. My answer isn't "read every line" and it isn't "trust the model." It's that reviewing AI-written code is a system of gates, and each gate has an owner. ## Gate 1: the author agent never approves its own PR This is the simplest rule and the most important one. The agent that wrote a change carries the same assumptions that made it write the change that way. Ask it to review itself and it will usually find the code fine, because it's looking with the same eyes. In my setup the author agent opens the PR and writes the evidence: what changed, in which files, and how it was checked. That's where its job ends. Approval isn't its call. ## Gate 2: a separate reviewer agent, plus a QA agent with real tests Review is done by a different agent, with different instructions, whose job is to look for problems, not to finish the work. Next to it, a QA agent runs real tests against the behavior: it runs the test suite, tries the edge cases, and checks that the thing actually works, not just that it reads well. The same idea comes up again and again in the HN thread: separate the writer from the checker, and rely on tests and automated verification instead of your feeling about the code. ## Gate 3: a human reads every diff that touches money, auth or data Not every line needs human eyes. But some areas are expensive to get wrong and hard to undo: - **Money:** payments, invoices, prices, discounts. - **Auth:** login, permissions, tokens, who can see what. - **Data:** migrations, deletes, any change to the shape of real data. Any diff that touches one of these, I read myself before merge, however green the tests are. A test tells you the code does what the test expects. It doesn't tell you the expectation was right. ## Gate 4: small PRs. If it can't be read in 10 minutes, split it Gate 3 is impossible on a 2,000-line PR. AI writes a lot of code fast, and that's exactly what turns review into a rubber stamp. So my rule: if a PR can't be read and understood in 10 minutes, it gets split into smaller PRs before anyone reviews it. A small PR is also easier to roll back if something turns up after you ship. ## How the gates actually get enforced Rules on their own get forgotten. That's why I built [Claude GitHub PMS](https://gh-pms.fadymondy.com/en/blog/github-issues-project-management-claude-code) (gh-pms), an open-source Claude Code plugin that makes "done" cost something: - An issue can't advance until the required evidence is in a comment, with file paths where they matter. - There's an optional AI reviewer on the review gate, and only a human can pass the final gate. - One in-progress issue per assignee, and no feature work on `main`. Know its limits: the gate checks that evidence exists and has the right shape. It can't prove the tests passed, which is why Gate 3 stays with a person. I told the full story in [Why I built Claude GitHub PMS](/en/blog/why-i-built-claude-github-pms), and the plugin [launched on Product Hunt today](https://www.producthunt.com/products/claude-github-pms). ## The takeaway You don't have to understand every line the AI wrote. You do have to understand the system the code went through: who wrote it, who reviewed it, what was tested, and what a human read with their own eyes. If you have a clear answer to those four, you can ship with confidence. ## FAQ **Do I have to read every line AI writes?** No. Read anything that touches money, auth or data yourself, and leave the rest to a separate reviewer and real tests. **Can the same agent review the code it wrote?** Better not. The reviewer should be separate, with different instructions, so it doesn't repeat the author's assumptions. **How big should a PR be?** Small enough to read and understand in about 10 minutes. If it's bigger, split it. ## Next steps - Try [Claude GitHub PMS](https://gh-pms.fadymondy.com/en/blog/github-issues-project-management-claude-code); the source is on [GitHub](https://github.com/fadymondy/gh-pms). - Want someone to review your codebase or how your team works with AI? See [AI & codebase audits](/en/services/codebase-audits). --- Source: https://fadymondy.com/en/blog/review-ai-written-code-before-shipping