When agents produce more code than people can comfortably read, the obvious response is to let another model read it. AI code review tools do this well enough to be useful: they spot missed edge cases, inconsistent error handling, duplicated logic, risky patterns and places where the code and the specification disagree. They do it in minutes, on every change, without getting tired.
The risk is not that these tools are bad. It is that they are good enough to be trusted for something they cannot do. A pull request with a clean AI review looks finished. A tired human reviewer, facing a long queue, can let that clean review stand in for their own judgement. At that point the organisation has moved accountability to a component that cannot hold it.
Our position: AI code review is first-pass evidence, not a sign-off. It belongs in the filter chain before human review, it should reduce and sharpen what humans see, and it must never be the last control on a change that matters.
Seapoint Payments is fictional, and its systems and figures are illustrative. By this point Seapoint's onboarding squad is producing around forty agent-built changes a week, which is more than the four engineers can review line by line.
Review as a series of filters
The harness in Part 4 ordered controls from cheapest to most expensive. Review follows the same logic.
In a typical week at Seapoint, forty changes arrive. Nine fail deterministic checks (tests, types, linters, dependency rules, secret scanning) and go straight back to the agent, which repairs most of them within its retry limit. Thirty-one reach AI review. The AI reviewer flags findings on nine and passes twenty-two clean. All thirty-one still reach a person. The findings are attached as notes, so the reviewer starts with a list of questions instead of a blank diff.
What changed was not the number of human reviews. It was what those reviews were about. Before the filter chain, Seapoint's engineers spent much of their review time on things a linter or an AI reviewer could have caught. After it, most human comments concerned intent, architecture and trade-offs.
What AI review is good at, and what it is not
AI review produces findings. It is good at local reasoning over the code in front of it: "this branch does not handle an empty list", "this function duplicates one in the shared library", "the specification says payouts are held on a partial match, but this path releases them". That last kind of finding, checking code against a specification it has been given, is one of the most valuable things an AI reviewer can do, and it depends entirely on the living specification from Part 3 being available to it.
AI review does not produce decisions. It cannot know whether this was the right change to make, whether it fits where the architecture is heading, whether a trade-off is acceptable to the business, or who carries the risk if it is wrong. Those questions need context the reviewer model does not have and accountability it cannot hold.
There are also predictable weaknesses on the findings side:
- False positives. Every flagged non-problem costs reviewer attention and trains people to skim findings.
- False negatives that look like assurance. No findings does not mean no problems. It means no problems this reviewer noticed.
- Shared blind spots. If the same class of model wrote the code and reviewed it, they may share misunderstandings. Part 4 lists AI reviewing AI without an independent control as a harness failure mode.
- Drift. Reviewer behaviour changes when the underlying model changes, often without notice.
Rules for using AI review well
Put deterministic checks first. Anything a linter, type checker or structural rule can catch should never reach the AI reviewer. It is slower, costs more and is less reliable on those problems.
Give the reviewer the specification. A reviewer that can see the acceptance criteria and architecture rules finds intent mismatches. A reviewer that sees only the diff finds style.
Feed findings back to the agent first. Many findings can be fixed by the agent before a human looks. The human then sees what remained and why.
Never let "no findings" approve anything above low risk. The acceptance authority from Part 5 decides. A clean AI review is one input to that decision.
Measure the reviewer. Track how many findings were accepted as real, how many were dismissed, and how many defects escaped to production that the reviewer saw and missed. A reviewer with a high dismissal rate is creating work, not saving it.
Use a different model or a different prompt for independence where it matters. For high-risk paths, a reviewer that differs from the generator reduces shared blind spots. It does not remove the need for a person.
A word about volume
The deeper problem is not review technique. It is volume. If agents generate more change than people can responsibly accept, adding AI review only delays the queue. The real fixes are upstream:
- Smaller changes, each tied to a specification section and an acceptance criterion.
- Fewer unnecessary changes, because agents are pointed at real work, not at refactors nobody asked for.
- Better evidence, so a reviewer can accept a change by reading criteria and results rather than every line.
Seapoint capped agent changes at a size its reviewers could read in about fifteen minutes, and split larger work into reviewable steps. Total throughput barely fell. Review quality rose noticeably.
How AI review fits the delivery loop
| Stage | Who or what | Output |
|---|---|---|
| Deterministic checks | Pipeline | Pass or fail, with a clear message to the agent |
| AI review | Reviewer model with specification access | Findings, sent first to the agent, then to the human |
| Human review | Engineer, plus specialists by risk tier | A decision on code fit, architecture and trade-offs |
| Acceptance | Named authority from Part 5 | Accept, reject, or accept with conditions |
For a practical checklist on taking AI-built software to production, see From prototype to production: the trust checklist. For the broader point that AI makes software easier to create but not easier to trust, see the opening of our Citizens, Agents, Experts series.
Next: Part 7, Production is part of the prompt. All parts are on the series page.
How CloudNala can help
We help teams place AI code review correctly in their delivery pipeline: moving checks that belong in deterministic tooling out of the AI step, giving reviewers access to specifications and architecture rules, setting up measures for reviewer usefulness, and making sure no clean AI review acts as approval on work that needs a human decision.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Delivery Pilot or write to us at consult@cloudnala.co.za