In a code review, someone else looks at a change before it becomes part of the software. The principle is known from other fields as the four-eyes principle. In practice, the review usually takes place through a pull request or merge request on platforms such as GitHub, GitLab, or Azure DevOps. There, the change is compared with the previous state, commented on, and merged only after approval. The NIST Secure Software Development Framework explicitly recommends reviewing or analyzing human-readable code as a practice for finding vulnerabilities.
How a code review works
- Prepare a small change: A manageable change with a clear purpose can be reviewed thoroughly.
- Provide context: The description explains what changes, why, and how it was tested.
- Automation first: The CI/CD pipeline checks tests, formatting, and known vulnerabilities before people invest time.
- Review and comment: The reviewer reads the change, asks questions, and suggests improvements.
- Revise: The author adjusts the change or explains the decision.
- Approve and merge: Protected branches technically ensure that nothing reaches the main branch without approval.
What a review looks for
Google's publicly available Engineering Practices list these checkpoints, among others:
- Design: Does the change fit into the existing system?
- Functionality: Does the code do what it should, including in edge cases and under concurrent access?
- Complexity: Could it be solved more simply? Is something being built that nobody needs?
- Tests: Are they correct and meaningful, and would they fail if the code breaks?
- Naming and comments: Are names clear, and do comments explain the why?
- Style, consistency, and documentation: Does the code follow the guidelines, and is the documentation updated?
For security, additional questions come in, as described in the OWASP Code Review Guide: Is input validated and output encoded correctly? Are permissions enforced on the server side? Are credentials in the code? Are new dependencies introduced, for example via Composer?
The right standard
Google formulates a pragmatic standard: reviewers should approve a change once it clearly improves the overall code health of the system, even if it is not perfect. Minor points are marked as optional comments. This keeps the review a tool for better software rather than a bottleneck.
AI in code review
AI tools such as Claude Code can automatically pre-review pull requests and point out possible bugs or security issues. This saves time but does not replace human accountability. Two rules matter: AI-generated code goes through the same review as any other code. And company code belongs only in approved tools with clarified data processing, not in private accounts, see shadow AI.
Typical mistakes
- Very large changes that nobody can seriously review
- Approvals without real reading, just to avoid holding up the process
- Long discussions about formatting that an automated tool could resolve
- A personal, disparaging tone instead of objective comments on the code
- Reviews only shortly before the delivery date
Tips for small teams
Even in teams of two or three people, a review is worthwhile, at least for security-relevant changes such as sign-in, permissions, payments, and data exports. Where nobody can review internally, an external review at fixed intervals helps. Documented approvals also make it easier to provide evidence to clients.
How it differs
Tests check whether code behaves as expected. The review also checks clarity, structure, and intent. Static analysis tools find certain classes of errors automatically. A penetration test attacks the running application from the outside. The methods complement each other and together feed into vulnerability management.