How should Engineering teams review AI-generated code?

AI can increase the volume and breadth of proposed code. If review capacity and practice remain unchanged, teams may create a new bottleneck or accept larger changes with less understanding. The answer is not a ceremonial “human in the loop”, but a review process that produces relevant evidence and a clear decision.

The same engineering standards apply to all code. AI involvement changes where teams should expect failure and how deliberately they preserve understanding and independence.

Require a clear and understandable change

The pull request should state the problem, intended behaviour, scope, important design choices, risks and evidence. The engineer submitting it should be able to explain how the change works and why it fits the system. A transcript is not a substitute for that explanation.

Keep changes focused. Large generated diffs hide subtle behaviour, increase reviewer load and make rollback harder. Separate mechanical transformations from functional changes where possible, and identify generated dependencies or configuration.

Reject unexplained code even when it appears polished. Ownership begins before merge and continues through operation and maintenance.

Review product and system consequences

Check that the change addresses the intended need and does not introduce unrequested behaviour. Examine architecture, interfaces, data handling, error paths, concurrency, performance, accessibility, observability and recovery according to context.

Look for common generation risks: invented APIs, outdated library use, inconsistent patterns, excessive complexity, insecure defaults and code copied into the wrong abstraction. Confirm licences and provenance where required by policy. NCSC guidance treats security, supply chain, documentation and technical debt as lifecycle concerns for AI systems; ordinary secure software practice remains relevant to AI-assisted development.

Bring specialist reviewers into high-impact decisions early. A security or architecture approval at the end cannot repair a poorly framed approach cheaply.

Build independent verification

Run the normal automated build, tests, static analysis, dependency and security checks. Review whether those controls cover the material behaviour. Add targeted evidence for high-risk paths, including integration, operational or manual checks where needed.

If the same model generated the code, tests and explanatory summary from the same context, apparent agreement may repeat one misunderstanding. Seek independence through human-designed acceptance examples, existing contracts, alternative analysis or separate test reasoning. Deliberately break critical behaviour to see whether tests detect it.

AI code review can identify issues and provide fast feedback. GitHub advises using it to supplement rather than replace human review. Its comments must themselves be checked; silence is not assurance.

Adapt controls and learn from review evidence

Review depth should reflect task impact, novelty, reversibility, permissions and agent autonomy. An editor suggestion reviewed line by line differs from an agent that modifies multiple components and runs commands. Require stronger containment, audit and approval as the potential consequence grows.

Capture why generated changes are rejected or heavily reworked. Patterns may indicate missing repository context, unsuitable tasks, weak tests or a tool that performs poorly in the relevant technology. Use that evidence to improve instructions, controls and work selection.

Measure review time, findings, rework, escaped defects and maintainability, not approval speed alone. Preserve human review capacity; increasing generation while starving verification is not increased delivery capacity. The goal is a change the team can responsibly own, regardless of who or what drafted it.

Example

An agent produces a broad dependency upgrade with passing unit tests. The pull request is split into mechanical and behavioural changes. Reviewers discover that one generated adapter bypasses an existing authorisation check and that the tests mock the component responsible for enforcing it.

The team restores the approved boundary, adds an integration test derived from the security requirement and records the pattern in repository guidance. It also narrows future agent tasks so dependency upgrades cannot silently redesign access paths.

FAQs

• Should AI-generated code always receive human review?

  Human accountability and proportionate verification are always required, but the form can vary. Low-impact suggestions may be reviewed directly by the engineer accepting them; consequential agent changes may require independent peers and specialists.

• Can one AI system review code produced by another?

  It can provide an additional signal, especially with different context or instructions, but model agreement is not proof. Retain independent tests, authoritative requirements and human judgement appropriate to the risk.

• Should reviewers inspect the AI conversation?

  The conversation may help diagnose assumptions, but the pull request should stand on a concise rationale and evidence. Requiring reviewers to reconstruct a long interaction adds friction and does not guarantee understanding.