Review AI generated code the way you review a new contractor's first pull request: it looks competent, but you need to check intent, dependencies, access control, secrets handling and tests, because the author cannot explain choices they did not make. Make the human who opens the pull request accountable for every line.
What is different about this code?
AI assistants produce fluent, consistent code, which lowers a reviewer's guard. They can invent a function or package that does not exist, copy an outdated pattern, skip validation or add a dependency without comment. The NIST Secure Software Development Framework (SP 800-218) still applies: it describes practices for reviewing and analysing code and for managing third party components. NIST also finalised SP 800-218A, a community profile for generative AI model development, which focuses on building models rather than reviewing their output.
What should the author do before requesting review?
- Read the generated diff fully and be able to explain it.
- Run the tests, linters and scanners locally.
- State in the description what was AI assisted and which prompts or specs drove it.
- Keep the pull request small, since large generated diffs hide problems.
Checklist: intent and logic
- Does the change do what the ticket says and nothing more?
- Are edge cases handled: empty input, large input, concurrent calls, failure paths?
- Is anything duplicated that an existing helper already does?
- Are comments accurate, or confident but wrong?
Checklist: dependencies
- Does every new import exist in the registry under that exact name, from the expected publisher? A hallucinated or lookalike package name can be a supply chain trap.
- Is the version pinned, maintained and free of known vulnerabilities?
- Was a heavy library added for a few lines of code?
- Did the lockfile change in ways unrelated to the task?
OWASP's component analysis guidance notes that an accurate inventory of third party components is pivotal to identifying risk, so confirm the lockfile and inventory reflect the change.
Checklist: security behaviour
- Authentication and authorisation: is the check on the server, for every route and object?
- Input handling: validation, parameterised queries, output encoding.
- Secrets: no keys, tokens or sample credentials in code, tests or logs.
- Cryptography: standard libraries, no homemade schemes, no weak defaults.
- Logging: no personal data or tokens written out.
- Error handling: no stack traces or internals returned to users.
Checklist: tests
- Do tests assert behaviour, or just run the code to hit coverage?
- Is there a test for the failure and deny paths?
- Were tests also generated, so they mirror the code's mistakes? Spot check one by hand.
A constructed example
A generated endpoint "GET /invoices/:id" returns the invoice and passes its test. The reviewer asks whether the code verifies that the invoice belongs to the caller. It does not, so any logged in user can read any invoice by changing the ID. The test only used the owner's account. The fix is a one line ownership check and a second test with another user.
How do automated checks help?
Let machines handle the repeatable parts: dependency scanning, secret detection, static analysis and policy gates in CI, so reviewers spend time on logic and design. Safeguard can scan dependencies, flag reachable vulnerabilities and gate pull requests, which fits the "known issues" part of this list. It does not replace a reviewer judging whether the change is right.
What to do
- Require authors to disclose AI assistance and own the diff.
- Keep pull requests small and ask for a plain statement of intent.
- Verify every new dependency by name, publisher, version and necessity.
- Review authorisation and input handling first, not style.
- Check that tests would fail if the logic were wrong.
- Run scanners and secret checks as required status checks.
- Track escaped defects from AI assisted changes and tune the checklist.
Quick check
Should AI generated code get a stricter review?
It should get the same standard as any code, with extra attention to dependencies, authorisation and tests, because fluent output can hide errors.
Who is responsible for AI written code?
The person who submits the pull request and the team that merges it. The tool is not accountable, so the author must be able to explain every line.
Sources
Last reviewed: 18 October 2026.
