Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Code review should not mean having a person—or an AI system—skim every changed line for its own sake. Automate repeatable checks, but keep human review for decisions, context, and shared understanding. That is the argument Ankit Jain makes in his September 30, 2026 article, “Kill the code review theater, keep the review,” published by The New Stack. The piece is sponsored by Aviator, whose cofounder and CEO is Jain.
What code review is for
Finding defects is one reason developers review code, but it is not the whole purpose. Jain’s article argues that review also helps teammates understand why a change exists, share knowledge about the system, and maintain a common picture of how it works. A review conversation can expose assumptions or trade-offs that are invisible in the diff itself.
That distinction matters as AI tools make it easier to produce code. If the review process becomes a fast scan for comments or a loop of automated approvals, a team may check more lines without learning more about the change. Jain calls that pattern “review theater”: the appearance of scrutiny without the judgment and understanding that make review useful.
What the numbers do—and don’t—say
Jain reports that a 2013 Microsoft study by Alberto Bacchelli and Christian Bird found 44% of developers ranked finding defects as their top reason for code review. He also says the researchers classified 570 review comments, of which 14% concerned defects. These are different measures: one describes developers’ stated reasons, while the other describes the distribution of observed comments. The figures are reported here as Jain presents them; the underlying study was not independently verified for this article.
Jain also cites a 2026 Faros AI analysis of 22,000 developers across more than 4,000 teams. As summarized in his article, it found incidents per pull request up 242.7%, bugs per developer up 54%, work restarts up 13.8%, and pull requests merged without human or agentic review up 31.3%. Those figures are claims attributed through Jain’s account, not independently checked results here; the article does not provide the conditions or comparison details needed to interpret them as universal effects of AI adoption.
#1 Best Overall
Jain further summarizes DORA’s 2025 report as finding that AI adoption can increase delivery throughput and delivery instability at the same time, without giving a specific figure in the article. Taken together, the cited metrics support a question worth asking—whether faster code production is being matched by sufficient understanding and control—but do not prove that AI itself caused any one team’s outcomes.
A five-layer alternative to review theater
Jain proposes a workflow called Argue, Capture, Codify, Debate, and Own. It is a suggested practice, not a validated standard or a controlled comparison of tools. Its central division of labor is practical: let machines apply consistent rules, and reserve human attention for context-dependent choices.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall1. Argue before opening the pull request
Compare possible approaches before implementation hardens into a diff. Jain suggests using separate agents to surface disagreements, then recording the proposed and rejected decisions. Agreement among models should not be treated as a final verdict; the point is to reveal alternatives and assumptions early. His examples of tools that can support parts of this step include PR-Agent, Aider architect mode, AutoGen, and CrewAI.
2. Capture intent and decisions
Attach the reason for the change, its acceptance criteria, and decisions made during implementation to the pull request. A reviewer then has more than code to inspect: they can assess whether the change addresses the intended problem and whether it meets the agreed behavior. Record unresolved questions too, so they remain visible rather than disappearing into informal discussion.
3. Codify recurring, objective corrections
When the same review comment keeps appearing, decide whether it expresses an invariant that can be checked automatically. Jain’s examples include requiring a Money type for currency and using structured logging. These are candidates for consistent enforcement because a rule can be made explicit and checked repeatedly. Questions involving competing goals or contextual judgment should remain human decisions rather than being forced into a brittle rule.
4. Debate what remains unsettled
Use the human review conversation to discuss alternatives and decisions that cannot be resolved from the diff and recorded context alone. This is where reviewers can question whether the approach is appropriate, whether an assumption holds, or whether a trade-off is acceptable. The goal is not to make humans reread every line mechanically; it is to focus their time on consequential uncertainty.
5. Own the rules and system understanding
Name who maintains the invariants and who is responsible for the team’s understanding of the system. Automation does not remove that responsibility. Without ownership, checks can become outdated, exceptions can accumulate, and no one may be accountable for whether a change fits the system’s intent.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to apply the idea to a team’s process
The five layers can be used as a diagnostic rather than a wholesale process replacement. Start with recent reviews and identify where time goes: repeated corrections, missing intent, unresolved design choices, or changes that merge without meaningful human discussion. Then make the smallest adjustment that addresses the recurring failure.
Best Value
- If comments repeat: determine whether they express an objective invariant, then make that rule checkable.
- If reviewers lack context: require a concise statement of intent, acceptance criteria, and important implementation decisions in the pull request.
- If implementation begins before alternatives are considered: discuss options and record disagreements before the pull request is opened.
- If review is mostly line-by-line scanning: use automation for deterministic checks and direct human attention to open questions and system-level consequences.
- If no one maintains the checks: assign an owner for each rule or rule set and make responsibility explicit.
This approach depends on keeping the boundary clear. A machine can apply a rule consistently when the rule and relevant inputs are explicit. It cannot, on the basis of a diff alone, establish the team’s full intent or decide which trade-off is right. That is Jain’s argument about the limits of automated review, not a universal finding about every AI system.
What to take from Jain’s proposal
The useful challenge is not whether to automate review, but what kind of work should be automated. Repeated, objective checks are good candidates for deterministic enforcement. Understanding why a change is being made, weighing alternatives, and deciding whether the team accepts a trade-off still require context and ownership. Jain’s formulation is: “Build tools for what AI does well, and protect what it can’t do.” The article’s sponsorship is relevant context for readers evaluating its recommendations; the proposed workflow should be assessed as Jain’s argument, not as independently demonstrated product evidence.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
