Reviewing AI-generated code: reading what the machine wrote

A growing share of the code that reaches production was never written line by line by a developer. It was suggested by an assistant, completed by a model, generated by an agent. The gate through which that code enters production has not changed: someone approves a merge, signs off a change, lets a batch through. That person now approves code they did not write, at a volume no earlier review ever had to absorb. The gate is the same. What passes through it has changed in nature.

Reviewing code written by artificial intelligence (AI) is not the same as reviewing code written by a person. Both can fail, but not in the same place. A developer’s code carries errors of intent: a misread requirement, a forgotten case, faulty reasoning. A model’s code carries errors of plausibility: it reproduces the shape of correct code, learned across a vast corpus, without carrying the security context specific to your application. This difference is not cosmetic. It shifts what a review must look for, where it must look, and what it can hand to tooling.

This article covers the first of the three fronts to which the risk of AI-augmented development has moved, from the network to the code: the generated code itself. It sets out where that code most often fails, how to run a review that stays sustainable when the machine produces faster than any eye can read, and how to make that review verifiable, so it stops being an act of faith and becomes an indicator management can follow.

Code that looks right fails differently

An agent produces code that compiles, passes the visible tests, and looks convincingly like good code. That resemblance is the trap. Nothing in the appearance of a snippet tells a safe function apart from one that merely has the shape of a safe function.

To see what this changes, look at how each kind of code fails. A developer who writes input validation knows why it is there: they have the hostile data in mind, the malicious user, the edge case. When they get it wrong, they get their intent wrong, a line of reasoning a review can reconstruct and challenge. A model does not reason about your threat. It reproduces the most frequent pattern in its training corpus, which holds as much careless code as careful code. If it omits the validation, that is not a lapse of judgement, it is because a share of its examples omitted it too.

The consequence for the review is direct. Reviewing human code means looking for faulty reasoning: did this person understand the problem? Reviewing generated code means asking a different question: does this plausible code actually carry the guarantees the context demands, or only the appearance of code that would? The review stops questioning an intent and starts verifying guarantees. It is a shift of gaze, and it calls for a different lens. Where those guarantees are most often missing is the next question.

What the machine does not see

Generated code does not fail at random. It fails where its corpus is weak, ambiguous or careless, and those areas overlap heavily with the ones that produce the most flaws in real life. The CWE (Common Weakness Enumeration, the reference catalogue of software weakness types) publishes, with the US cybersecurity agency, a ranking of the most widespread and most serious weaknesses, built from tens of thousands of real vulnerabilities. At the top, year after year, the same families: unfiltered input leading to injection or cross-site scripting, overflows, broken access handling. These are precisely the places where a model, left to its own bias, produces fragile code.

Five blind spots recur often enough to structure a review. The first is input validation: a model readily generates the happy path, the one that works for a cooperative user, and neglects the hostile input that appears in no demo. Next comes the hardcoded secret, a key or access token left in the code because countless public examples do the same. Then error handling that hides: a block that catches an exception, swallows it in silence, and lets the application carry on in an uncertain state. More insidious is the outdated security pattern, a dated hashing algorithm or a permissive configuration copied from an old example the model has over-learned. Last is excessive privilege: an access, a scope or a right broader than needed, because that is the version that works fastest in the examples the model draws on.

These blind spots have a valuable property: they are predictable. A review that knows where they sit goes straight to what matters; a review that reads everything uniformly drowns and ends up seeing nothing. The map of these areas is not an add-on to the review, it is what lets the review set its priorities.

A review that scales with AI’s output

One practical obstacle remains: at the volume a machine produces, reading every line is out of reach. Trying to check everything by hand takes back with one hand the speed gained with the other, and turns the reviewer into a bottleneck. A sustainable review does not aim for completeness. It is driven by risk, not by volume.

The principle is a division of labour. Human attention concentrates where judgement cannot be replaced: the sensitive areas identified above, and any code that touches authentication, authorisation, sensitive data or external calls. A machine does not know that, in your application, a given field comes from an untrusted source, or that a given access must stay isolated for a business reason. The reviewer brings the context that neither the generator nor the tool holds. Their task is to read and question, not to write, which means telling apart the stages you hand to the machine from those that demand human judgement.

The rest, the predictable part, goes to tooling. Static analysis (SAST, for static application security testing: inspecting code without running it to spot known weakness patterns) clears the repetitive errors. Security linters flag hardcoded secrets and questionable configurations. Software composition analysis (SCA) watches the dependencies. Wired into the build pipeline, these tools handle the volume; the human settles the ambiguous. The split is clean: a tool recognises a known pattern, it does not judge whether that pattern is a problem in your context.

One temptation remains: having AI-generated code reviewed by another AI. As a first pass, the idea makes sense and saves time. On its own, it is not enough. Two models trained on neighbouring corpora share blind spots, and one can happily wave through the weakness the other produced. AI reviewing AI moves the check, it does not close it. The last link stays a human one, all the more effective when the code is clean: a readable, durable structure is reviewed faster than code written to survive a demo.

A review you cannot measure does not exist

One weakness remains, and it is not in the code. A review often stays an act of faith. “The code has been reviewed” says neither what was checked nor how far. As long as a review is not measurable, it is not manageable: management can neither put a figure on the risk nor tell whether the vigilance holds when the team speeds up.

Making the review verifiable means anchoring it to testable criteria rather than to each person’s judgement. The OWASP ASVS (Application Security Verification Standard, an open standard for application security verification) is built for this: each requirement is written as a testable statement, and the whole scales by levels according to the application’s risk. Its logic turns a soft question, “is it safe?”, into firm ones: is this guarantee present, has it been verified, yes or no. Security stops being an impression and becomes an observed state.

For management, three indicators are enough to leave the act of faith behind. A coverage figure, showing what share of the sensitive areas was actually reviewed. A trace, keeping a record of what was verified and by whom. A definition of done that places security review among the conditions for merging, rather than as an optional step pushed to later. None of these three slows the team down. They make visible what would otherwise stay in people’s heads.

That closes the thread. The risk has moved to the code the AI writes; the review is the first link able to catch it. But a review that stays a craft gesture, targeted by habit and never measured, protects only for as long as it is lucky. Making it verifiable means no longer counting on that luck. It is also the condition for keeping the speed AI has gained without inheriting the risk blind.