10 resources for reviewing AI-generated code

01

1. OWASP Secure Coding with AI

OWASP's guide identifies risks to review when an AI coding tool can edit files, install dependencies and run commands. Its advice on unexpected changes and weakened tests is a useful starting point when the agent's summary looks complete but the change touches more than the requested feature.

The guide is a set of practices, not a certificate that a particular application is safe. Choose the relevant checks for your environment and give a person responsibility for the final decision.

02

2. Git diff

Git diff shows changes between versions or between working files and a recorded version. Use it to inspect the actual files the agent changed, including configuration and tests, before deciding whether the change belongs in the release.

Ask the developer to include staged and unstaged changes, proposed commits and new files not yet tracked by Git. Git status helps identify untracked files; a single diff view does not necessarily show all of them. A diff shows what changed, not whether the resulting behaviour is correct. It also takes some familiarity with the code to judge why a change matters. Ask the agent to explain unfamiliar changes, then verify the explanation against the files.

03

3. GitHub pull request reviews

GitHub's pull request review lets reviewers comment on changes and submit a review. It provides a place for a developer to ask about a particular line and record whether changes are needed before the proposed work is merged.

The value comes from the questions and the reviewer, not the approval button. Check that the reviewer can assess the affected parts of the system and has seen the full set of changes.

04

4. pytest

pytest runs Python tests and reports which assertions fail. For a Python application, it can check a rule at its boundaries: for example, whether a calculation rejects an invalid amount as well as accepting a valid one.

A test only checks what it asserts. Review tests the agent adds or removes, and make sure they describe the intended behaviour rather than merely repeating the implementation.

05

5. Playwright

Playwright can run tests through a real browser. It is useful when the question involves what a person can do on a page: whether a form reports a failed submission, for example, rather than quietly displaying success.

The test environment and its data need to be appropriate for the action being exercised. A browser test can show the observed flow; check the resulting server or external record separately when the task changes one.

06

6. Semgrep

Semgrep scans code against rules that flag patterns for review. It can help a team look for known risky constructions across a change when reading every line alone would be difficult.

Results depend on the rules, languages and configuration used. A finding needs investigation, and an empty report is not proof that the code has no security problem. Check how the selected scan handles the code and data before using a hosted service.

07

7. Gitleaks

Gitleaks looks for secrets such as credentials in code and Git history. Run an appropriate check when an agent has created configuration files or examples that may accidentally contain real access information.

The project maintainer says Gitleaks is feature complete and future releases will contain security patches only, with development focus moving to Betterleaks. Detection has limits: a secret can escape a pattern, and some matches are harmless. If a real credential has been exposed, removing it from the latest file alone does not make it safe; follow the relevant provider's revocation or rotation process.

08

8. OSV-Scanner

OSV-Scanner checks supported dependency information against vulnerability records. It is useful after a coding agent adds packages: the owner can see whether a declared dependency is associated with a known vulnerability.

The result depends on the information available to the scanner and the vulnerability database. No alert does not establish that a package is trustworthy, necessary or free of unknown problems. Review why each new dependency was added as well.

09

9. ZAP

ZAP helps inspect and test web applications, including requests and responses. A team can use it in an authorised test environment to investigate how an application behaves when it receives unexpected input.

Some active tests send potentially disruptive requests. Use them only on systems you are authorised to test, with suitable test data and boundaries. A scan is not a replacement for reviewing access rules or the business consequences of a failure.

10

10. OpenSSF Scorecard

OpenSSF Scorecard checks security practices around open-source projects. It can help a team investigate a new dependency before relying on it, including signals about how the project is maintained and secured.

A score is a prompt for questions, not a guarantee about an individual release or maintainer. Read the underlying checks, review the dependency's role in your application and decide what evidence is sufficient for your use.

Start with one change and the consequence it is supposed to produce. Then inspect the changed files, test the relevant behaviour and examine the dependencies and permissions involved. If the agent changed a customer system or published a site, read the result back in that system as well: a clean code review cannot establish what an external action actually did. The distinction is explored in checking an AI agent's work.

If you lead a company and need to choose where AI belongs in your work, AI consulting for leadership teams can help frame the decision and the responsibilities that follow.