Review of AI-generated code

What it does

It holds generated code to the standard of written code and makes sure the volume an assistant produces does not outrun the checks. It also protects the review step itself, which is the control most at risk when output rises faster than the number of reviewers. The head of engineering is accountable; reviewers and automated pipeline checks apply it to every change before merge.

How to implement it

• State in policy that the author of a change is responsible for all of it, whatever produced it.
• Require human review of every change, sized so that review is meaningful.
• Run static analysis, secret scanning and dependency scanning in the pipeline.
• Allow new dependencies only from an approved list or after review, and verify that each exists and is the intended package.
• Check generated code for licence obligations.
• Monitor review time and defect rates as assistant use grows.

Evidence it operates

Design: an engineering policy on assistant use and the pipeline configuration enforcing the checks. Operation: merge records showing a reviewer and passing scans for each change; dependency approval records; trend data on security findings.

Where it fits

Operates in the delivery pipeline at each merge. It is the primary control for insecure AI-generated code.

Limits

Reviewers tire and skim, more so when code arrives quickly and looks competent. Scanners find known patterns and miss flaws of logic. The control depends on review capacity keeping pace with output. Using a second AI tool to review generated code can help find defects and does not replace an accountable human reviewer.