Code review
Also known as: peer code review, code reviews, code inspection
Code review is the practice of having one or more developers examine code changes before they're added to a project, usually through a pull request.
Reviewers look for bugs, security problems, unclear logic, and whether the change actually meets its goal. It also spreads knowledge across the team and keeps code consistent. While code review improves quality, slow or nitpicky reviews can frustrate developers and delay releases.
Code review, explained at three levels
At home
Code review is like having a friend proofread your essay. A fresh pair of eyes spots mistakes you missed.
At work
Code review catches problems before software reaches customers and helps teams share knowledge.
At home
When contributing to open source, maintainers review your code. Their comments are a great free way to learn better practices.
At work
Effective reviews focus on correctness, security, and clarity. Automated tools handle formatting and style so humans can focus on logic and design.
At home
Feedback can feel personal, but it's about the code. In my opinion, learning to receive reviews gracefully is a key professional skill.
At work
Keep changes small, set expected review times, use checklists for security-sensitive code, require reviews from code owners, and treat AI review as a supplement, never a replacement.
Real-world examples
At home
Carlos submitted his first open-source contribution. The maintainer's review suggested a simpler approach, and Carlos learned a new technique.
At work
Sophie leads a Kitchener fintech team. Her rule that every change gets a human review caught a security flaw an AI assistant had introduced.
Common confusions
- Code review is mainly about finding bugs. — It also spreads knowledge, improves readability, and keeps designs consistent. Tests are better at catching many bugs.
- AI code review makes human review unnecessary. — AI catches some issues quickly, but humans still judge whether the change makes sense and is safe.
For analysts
I'd encourage reviewers to check changes against the original requirement. Code can be well written and still solve the wrong problem.
History & origin
Michael Fagan formalized software inspections at IBM in 1976, using meetings where teams reviewed printed code line by line. Open-source projects reviewed changes over email mailing lists, and Google built internal tools for lightweight review in the 2000s. GitHub's pull requests from 2008 made online review standard across the industry. Research, including studies at Microsoft and Google, found that review's biggest benefits included knowledge sharing and maintainability, not just catching bugs. By 2025, AI tools commonly performed a first pass on reviews, though human judgment remained essential. In my view, code review is as much about teaching as it is about checking.