When AI drafts code, the question is not whether it looks right. AI-generated code almost always looks right. The question is whether it does the right thing, handles the unusual cases, keeps data safe and fits the rest of the system. That is what review is for.
This guide describes the process we use on client projects. It is not the only good process, but it shows the kind of checks any team using AI should be able to describe. It complements what is AI-accelerated development.
Principles
- The reviewer is responsible. Whoever approves a change owns it, however it was written.
- Small changes. A change should do one thing and be reviewable in one sitting.
- No blind merges. If the reviewer does not understand the code, it does not go in.
- Automate the routine. Formatting, linting, type checks and tests run automatically, so review time goes to judgment.
Before review: the author's checks
The engineer who used AI to draft a change is its first reviewer. Before asking anyone else to look, they read every line, run the tests, try the feature by hand and remove anything they would not have written themselves. AI often adds extra code, unused helpers or overly general solutions. Trimming those is part of the job.
The change description explains what it does and why, links to the requirement and notes anything the reviewer should look at closely.
1. Does it do what was intended?
The reviewer starts from the requirement, not the code. What should this change achieve for the user or the business? Then they check that the code does exactly that, no more and no less. AI sometimes solves a slightly different problem than the one asked, or adds features nobody requested.
2. Is it correct, including the edge cases?
Reviewers walk through the logic with realistic and unusual inputs: empty values, very large numbers, duplicate records, missing permissions, time zones and concurrent edits. Business rules get special attention, because AI can implement a rule that is almost right in a way that passes simple tests.
3. Is it properly tested?
Every change that adds or modifies logic comes with tests. Reviewers check that tests fail when the logic is broken, cover the edge cases identified above and are readable enough to serve as documentation. For user-facing changes, the reviewer also checks that the feature has been tried in a browser or on a device.
4. Is it secure?
Reviewers check the usual risks: input validation, injection, access control on every request, safe handling of files and secrets kept out of code. AI sometimes checks permissions in the interface but not on the server, or trusts data it should not. For authentication, permissions, payments and personal data, a senior engineer does a second review. See the AI development security checklist.
5. Does it handle data safely?
Changes that touch the database get extra care. Migrations must be reversible or safe to run twice. Queries must respect tenant boundaries in multi-tenant products. Deletes and bulk updates need clear safeguards. Personal data must be stored and logged appropriately.
6. Will it perform well?
Reviewers look for common performance traps: queries inside loops, missing indexes, loading far more data than needed and slow external calls in the request path. AI-generated code often works fine on small test data and struggles on real volumes.
7. Can the next person understand it?
Code is read far more often than it is written. Reviewers check naming, structure and comments where the reason for something is not obvious. AI can produce verbose or overly clever code. Simpler is almost always better, and it keeps technical debt down.
8. Does it fit the system?
Finally, reviewers check that the change follows the project's conventions and architecture: existing helpers are reused rather than duplicated, patterns are consistent and the change does not quietly introduce a new way of doing something the project already does. Consistency is what keeps a codebase maintainable as it grows.
What automation catches
Automated checks run on every change before a person looks at it:
- Formatting and style.
- Static analysis and type checks.
- The full test suite.
- Dependency and secret scanning.
- Build and deployment to a preview environment where possible.
If any check fails, the change goes back to its author before review.
Using AI to help review
AI can also help reviewers, for example by summarizing a large change, suggesting edge cases to test or pointing out possible issues. We treat these as prompts for human attention, not as approvals. The decision to merge is always a person's.
What clients see
All of this happens in your repositories. You can see every change, its description, the review comments and the test results. The history is yours, which also makes handovers easier if you ever move the work to another team. See security and IP ownership.
Questions to ask any team
- Who reviews AI-generated code, and how experienced are they?
- What automated checks run on every change?
- How are security-sensitive changes handled?
- Can we see an example of a recent review?
- What happens when a reviewer rejects a change?
For more on choosing a team, read how to choose a development partner and where AI helps in development, and where it does not.
Review as a habit, not a gate
The best review cultures treat review as collaboration rather than inspection. Reviewers explain their comments, authors welcome them, and patterns found in review become new automated checks or shared conventions. Over time, that makes both the people and the AI output better, because the codebase itself teaches good habits.
It also keeps knowledge spread across the team. When at least two people have understood every change, no part of the system depends on one person's memory.
An example review
Consider a change that adds a discount code field to a checkout. The AI drafted the form, the validation, the database change and tests. In review, the engineer notices three things. The discount is applied in the browser, but the server does not check it again, so a user could change the amount. The tests cover a valid code and an invalid one, but not an expired code or a code used twice. And the database change adds a column without a default, which would fail on existing rows.
None of these would show up in a quick demo. All of them would cause real problems in production. The reviewer asks for the fixes, the author makes them with help from the AI, and the change is approved on the second pass. That is a normal review, and it is why review time is part of every estimate.