Treat AI output as a proposed change that earns trust through review and evidence.
Generated code can look complete while missing a business rule, using a nonexistent API or weakening an access boundary. That is why the engineering workflow matters more than the tool used to draft a change. GitHub’s guidance on reviewing AI-generated code calls for functional checks, architecture review, dependency scrutiny and human judgement.
Define the intended behaviour first
Give the work a clear scope: user outcome, acceptance criteria, interfaces, data boundaries and known failure modes. For a feature that creates an invoice, specify who may create one, which fields are mandatory, how duplicates are handled and what happens when the payment service times out. Without these constraints, a plausible implementation can solve the wrong problem.
Keep architectural decisions with engineers. AI can propose options, but a person should select the design, identify trade-offs and decide what will be maintained. Give the tool only the repository context and data it is approved to use.
Work in changes a reviewer can understand
Prefer a focused change over a large rewrite generated in one pass. Inspect the diff, trace unfamiliar logic and verify every new dependency and API. Ask whether the change follows the project’s patterns and whether a simpler implementation exists. Generated tests deserve the same review as generated code: a test that repeats the implementation’s mistake is not evidence.
Can someone explain what changed, why it is correct, what could fail, and how the change will be operated six months from now?
Verify behaviour at several levels
Run static checks and unit tests, then test the user path and integration boundaries. Include negative cases: missing permission, malformed input, duplicate submission, unavailable dependency and unexpected model output. For AI features, use representative evaluation cases as well as conventional software tests. Review data handling and security-sensitive code with appropriate specialists.
GitHub’s review guide specifically warns about hallucinated APIs, skipped tests and suspicious dependencies. These are practical review prompts, not a guarantee that a passing test suite proves safety.
Keep permissions and secrets outside the suggestion
Do not paste credentials or sensitive customer data into a tool unless the organisation has approved that use. Scope tool access to the task, verify what the generated code can read or modify and review logging for unintended disclosure. If an AI component consumes untrusted documents or pages, test prompt injection and limit the actions it can take. OWASP’s guidance describes the risk of untrusted content being treated as instructions.
Own the release and what follows
Record the change, its tests, reviewer and deployment plan. Release through normal approval and rollback paths. Watch errors and user feedback after deployment; a clean pull request is only one checkpoint. When the team finds a defect, add a regression case and update the guidance used in future work.
| Before merging | Evidence |
|---|---|
| Intent | Acceptance criteria and reviewed design |
| Correctness | Relevant tests, including failure cases |
| Safety | Access, data and dependency review |
| Operations | Deployment, monitoring and rollback plan |
A practical team standard
Make the same quality bar apply whether code was typed by a person or suggested by a model. Require a comprehensible diff, passing checks, a named reviewer and evidence that the intended user behaviour works. AI can help produce the work; accountability stays with the people who approve and operate it.
Sources & further reading
External guidance informs this article; the examples and recommendations above are AI Dive’s interpretation for practical planning.