Why code review matters more than ever — keeping team understanding when AI writes code

Introduction

Code review has always done more than catch syntax mistakes. It is a sociotechnical practice: a place where people exchange context, rationale and trade‑offs so that the team as a whole understands the system. Today, with AI increasingly in the loop, that social channel is under pressure. If the submitting developer cannot explain the code an AI produced, the usual conversational conveyance of knowledge can fail — and that failure shows up as slower incident response, brittle maintenance and more stressful on‑call shifts.

Code review as knowledge transfer, not just defect detection

Traditional descriptions of code review focus on bugs, style and standards, and for good reason: a second pair of eyes finds edge cases and security issues that an author misses. GitLab, for instance, highlights reviews as a second opinion that helps find logic problems and security flaws and, crucially, helps share knowledge across teams and languages.

Beyond defect detection, reviewers are learners. They absorb the design rationale behind a change, the constraints the author considered, and the trade‑offs settled on. This aligns with the long history of inspections as a social practice going back to early methods like Fagan inspections (noted in reviews of code review history), where the review meeting was as much about shared understanding as it was about defects.

The AI wrinkle: opacity and the risk to team resilience

When a developer uses an AI assistant to generate code, two things can happen that make review harder. First, the developer may not fully understand why the suggested implementation works the way it does. Second, the AI may encode assumptions or workarounds that are invisible in the commit message. Addy Osmani and others have observed that if a submitting developer cannot explain an AI‑generated change, the review process — and therefore team resilience — breaks down. Practically, that shows up as longer mean time to resolve incidents and more stressful on‑call shifts: debugging at 02:00 is far harder if no one can explain why the system behaves a certain way.

Practical guidance to preserve knowledge during AI‑assisted development

• Require an explanation from the author. A pull request should include a short, human‑written rationale: why this change, what alternatives were considered, and why they were rejected. This forces the author to internalise the code they're submitting.
• Record provenance. If an AI tool was used, note which tool, the prompt, and any post‑processing. That provenance often short‑circuits repeated debugging: reviewers can reproduce the generation step if necessary.
• Use a reviewer checklist focused on understanding. Beyond lint and tests, add items like: "Can the author explain the key algorithmic choices?" and "Are assumptions and failure modes documented?" Checklists make tacit knowledge explicit.
• Insist on tests that document behaviour. Unit and integration tests are executable documentation. They make intent explicit and provide a safety net when the human mental model is weak.
• Pair or mob on AI‑produced changes. Treat AI outputs like code written by a junior engineer: pair review helps share understanding and distributes responsibility before the change lands.
• Update runbooks and on‑call notes. If a change affects operational behaviour, update runbooks as part of the PR. That reduces late‑night firefighting by making expected behaviour discoverable.
• Limit direct merges of AI‑only contributions. Policy can require at least one reviewer who can explain the change in plain language before merge. That preserves the social contract of review.
• Encourage explanatory comments, not just code. Short inline comments that state "why" rather than "what" help later readers who did not participate in the original review conversation.

Process tweaks that help reviewers do their job

Implement lightweight process changes that make the knowledge transfer explicit. Short review templates, a requirement for a human rationale, and automated checks that verify tests and documentation have been updated can be integrated into CI. These steps preserve the collaborative role of review even when AI produces the first draft of code. As practical proof of the benefits of review, industry posts and documentation emphasise that code reviews aid quality, security and team collaboration — outcomes your team should preserve as tools change.

How to know if it’s working

Measure the sociotechnical outcomes, not just lines changed. Useful signals include reduced time to resolve incidents, fewer surprises in post‑mortems, fewer follow‑up PRs to explain behaviour, and improved test coverage for areas with AI‑assisted changes. Qualitative feedback from on‑call engineers about their confidence in the codebase is equally valuable.

Conclusion

AI can make writing code faster, but it does not automatically make the team understand the system. Code review remains the primary channel for transferring that understanding. By shifting review practices to emphasise author explanation, provenance, tests and documentation, teams can keep the sociotechnical fabric intact: code that is not just correct today, but maintainable and debuggable when the pager rings at 02:00.

Sources

GitLab — What is a code review?
3Pillar Global — The Importance of Code Reviews
AppIt — How Code Reviews Can Improve Your Development Process
Hypersense — Why Code Reviews Are Essential

Expanded from

This post expands on a point from Sociotechnical systems in software and AI: Code review in the age of AI‑generated code — harder or easier?.