Your team reviews code after it's written. The data suggests you should flip that around.
What Changed
Code review started around 2006 when Google formalized internal practices. For nearly two decades, the process stayed the same: write code, submit a pull request (PR), wait for review, address comments, merge. AI code generation is changing this model. When developers use tools like Copilot to generate 60% of their code, reviewing becomes a verification exercise, not a knowledge-sharing one.
The shift: review the intent before the code is written. Capture what you're trying to accomplish, align on the approach, then let AI or humans write the implementation. Aviator's tooling demonstrates this in practice. Their Verify system spins up servers, sends real traffic, and drives UI interactions to check that code matches the stated intent. The review happens at the intent layer, not the syntax layer.
Key Findings
Intent review cuts review time by focusing human attention where it matters. When you review a 500-line PR, you're checking syntax, logic, edge cases, and trying to understand the author's intent. When you review a 50-word intent statement first, you're validating the approach before implementation starts. One requires deep code reading; the other requires architectural judgment.
Trunk-based development with continuous review eliminates the PR bottleneck. Thoughtworks uses pair programming and trunk-based development where review happens continuously as code is written. No PRs. No review queues. The trade-off: higher coordination cost, but zero merge conflicts and instant feedback loops. This works when your team maintains constant communication.
AI verification handles the mechanical checks humans used to do. Does the code match the requirements? Do the tests cover the happy path and error cases? Does it handle the edge cases listed in the intent? These are verification tasks, not review tasks. Automated systems can run integration tests against staging environments and report back whether the implementation matches the specification. Your senior engineers shouldn't spend time checking if a function handles null inputs correctly.
Intent artifacts create better documentation than code comments. Six months from now, when someone asks why you made a particular architectural choice, a PR with 47 comments and three rounds of revisions doesn't tell the story. An intent document that says "we're moving from synchronous to async processing because webhook delivery was timing out at 30 seconds under load" does. The intent becomes the permanent record.
The review gate moves but doesn't disappear. You still need human judgment. The question shifts from "is this code correct?" to "is this the right thing to build?" and "does the implementation match what we agreed to build?" The first question requires product and architecture knowledge. The second requires verification tooling.
What This Means for Your Team
You're probably running PRs the way Google did in 2006: developer writes code, submits PR, waits for review, addresses comments, merges. Your median PR age is probably 2-3 days. Your developers context-switch between writing new code and addressing review comments on old code.
If your team uses AI code generation, you're reviewing AI output. That's a waste of senior engineer time. The AI doesn't make architectural decisions or understand business context. It generates syntactically correct code based on prompts. Your reviewers should validate the prompts (the intent), not the generated code.
If you're subject to SOC 2 Type II or PCI DSS v4.0.1 Requirement 6.3.2 (code review before production), intent review satisfies the control. The requirement says "code changes are reviewed" but doesn't specify when. Reviewing intent before implementation and verifying implementation against intent gives you better control than reviewing 500 lines of code after the fact.
Action Items by Priority
Start with one team running intent-first experiments. Pick a team that's already using AI code generation heavily. Have them write a one-paragraph intent statement before starting implementation. Review and approve the intent. Then write the code. Track time-to-merge and number of review rounds. Compare against your current baseline. Run this for two weeks.
Build an intent template that captures what reviewers actually need to know. Your template should answer: What problem does this solve? What's the proposed approach? What are the alternatives you considered? What are the risks? What verification steps will confirm it works? This becomes your new PR template. The code diff becomes supporting evidence, not the primary artifact.
Identify which verification tasks can be automated. List everything your reviewers check: tests pass, code coverage threshold met, no new security vulnerabilities, performance benchmarks within range, documentation updated. Anything on this list that's mechanical should move to automation. Your CI pipeline should fail the build if verification fails, not rely on human reviewers to catch it.
Establish clear escalation for intent disagreements. When reviewers disagree with the approach, you need a decision-making process. Who makes the call? What's the timeline? How do you document the decision? Intent review surfaces these disagreements before implementation starts, which is better than discovering them after 500 lines of code are written. But you need a process to resolve them quickly.
Track review metrics that matter for intent-driven workflows. Stop measuring "time to first review comment." Start measuring "time from intent approval to merge" and "number of implementation iterations after intent approval." If you're doing intent review right, the second number should approach zero. The code should match the approved intent on first submission.
