/
The traditional code review model was designed for a world where humans wrote every line and a reviewer could reasonably trace the author’s reasoning by reading the diff. That model breaks when an AI agent generates hundreds of lines in response to a short prompt.
AI coding assistants have changed the math of software development. Engineers using AI coding tools merge up to 60% more pull requests than those who don’t, and tasks that once took a full day can wrap up in an hour. But that acceleration has exposed a structural problem most teams didn’t see coming: code review hasn’t kept up. Meanwhile, 31% more PRs are merging with no human review at all, and main branch success rates have dropped to 70.8%.
AI-generated code is often described as “almost right, but not quite,” and that’s exactly what makes it hard to review. It passes a casual read while hiding subtle mismatches between what was intended and what was built.
The fix isn’t to review harder, it’s to review differently. When AI writes the code, the reviewer’s job shifts from “Does this logic look correct?” to “Does this match what we intended to build, and can we prove it?” That’s a fundamentally different question, and it calls for a different workflow.
AI code reviewers are useful, but they’re only sampling the code without knowing intent. They can’t verify that the implementation matches what you meant to build.
The most effective teams are moving toward an intent-verification model.
How intent-driven verification works
Aviator Verify replaces the traditional “write code, open PR, wait for review” cycle with a four-stage workflow that captures intent up front and verifies it automatically before a reviewer ever looks at the change.
Stage 1: Build with your preferred agent. Developers keep using whatever AI coding tools they already have — Cursor, Claude Code, Copilot, or anything else. No new editor, no behavior change.
Stage 2: Submit intent via CLI. When the implementation is ready, the developer runs /verify-submit through the Aviator CLI. This captures two things: the intent (a concise statement of what the change does and why, including non-obvious constraints) and a set of acceptance criteria: independent, verifiable assertions with clear pass/fail outcomes.
Stage 3: Verify end-to-end. The system routes each criterion through the appropriate verification path and produces a verdict with supporting evidence. This stage runs automatically — no human in the loop until it finishes.
Stage 4: Review behavior, not just code. Reviewers see intent, verdicts per criterion, and supporting evidence. The diff is still accessible, but it’s no longer the primary review surface. Reviewers can approve, waive a criterion with justification, or request alternative scenarios. Every decision is recorded.
The verification pipeline: code-scan and runtime
Not all criteria need the same kind of verification. Aviator Verify classifies each criterion and routes it to the right verifier automatically.
Code-scan verification handles structural assertions — things you can prove by analyzing the code itself. Does the file exist in the right location? Are the function signatures correct? Were new dependencies added to the right package? Are return types consistent? The verifier parses the diff and AST and produces snippets that demonstrate the assertion holds. These checks are fully deterministic: the same code always produces the same verdict.
Runtime verification handles behavioral assertions — things you can only prove by running the code. Does the endpoint return the right response? Does the error handling work as specified? Does the UI render correctly? The verifier exercises the change in a preview environment, capturing screenshots, console logs, DOM snapshots, and API responses as evidence. Runtime verification requires a preview environment and a skill set that defines the base URL, test users, and fixtures.
Typical verification runs complete in 30 to 120 seconds. Code-scan criteria resolve almost instantly; runtime criteria and preview cold-starts take the bulk of the time. The system caches evidence per criterion and change set, so unchanged criteria don’t re-execute.
Three layers of requirements
One of the biggest challenges in code review — especially with AI-generated code — is that reviewers have to hold the full context of what matters in their heads. What are the security rules? What patterns does this team avoid? What’s specific to this change?
Aviator Verify organizes these into three layers that stack hierarchically:
Org invariants are organization-wide rules that always apply. These are the things your senior engineers flag in every review: authentication required on new endpoints, no hardcoded secrets, external input must be validated, SQL queries must be parameterized, error responses must include correlation IDs. Without invariants, you’d need to add “requires authentication” to every spec. Instead, they’re configured once by admins and automatically checked on every change.
Domain contracts are rules scoped to specific parts of the codebase. The billing module shouldn’t directly modify user records. The payment domain should use Money types. User data reads should route through the UserRepository. These are tied to file path patterns (like src/billing/**) and apply automatically when a change touches those paths.
Acceptance criteria are specific to the individual change — the endpoint path, the required response fields, the expected return values. These come from the developer’s submission and are unique to every PR.
During verification, all applicable layers are checked simultaneously. Higher-layer rules can be overridden by lower layers when the spec intent explains why and the override is explicit — and that override is recorded in the audit trail.
Invariants: encoding your team’s review patterns
Invariants deserve special attention because they solve one of the most persistent problems in code review: the patterns your experienced reviewers catch over and over, review after review.
Every team has these. The senior engineer who always flags missing input validation. The security-conscious reviewer who catches hardcoded credentials. The architect who spots direct database access that should go through a repository pattern. These patterns live in people’s heads, and when those people are out, the patterns don’t get applied.
Aviator Verify captures these patterns as reusable, automated checks. Invariants flow through four phases:
Catalog phase. Invariants are sourced through PR-comment mining, documentation extraction, or repo-signal synthesis. They’re stored account-wide but start in a staging state, waiting for admin review and promotion.
Selection phase. When a verification run starts, an LLM selector determines which invariants apply to the current change based on eligibility conditions and change context. Not every invariant applies to every PR.
Materialization phase. Selected invariants become acceptance criteria tagged with source: baseline_invariant and flow through the same verification pipeline as developer-authored criteria.
Review phase. If an invariant flags a violation, reviewers can waive it with a categorized justification: false positive, doesn’t apply, accepted risk, or fix in followup. The waiver is recorded in the audit trail.
This means the patterns your best reviewers catch don’t depend on those reviewers being available — they’re encoded into the system and applied automatically, every time.
What reviewers actually see
The review document in Aviator Verify is structured around three sections, not a diff:
Intent — the agreed-upon objective. What is this change supposed to accomplish, and why? This is what the developer submitted, and it’s what the reviewer validates first. If the intent is wrong, the code doesn’t matter.
Evidence — verdicts and proof per criterion. Each acceptance criterion shows a pass/fail verdict and the supporting evidence: AST snippets for code-scan checks, screenshots and API responses for runtime checks. Reviewers can drill into the evidence or scan the summary.
Decisions — what the reviewer does next. Approve, request changes, waive a specific criterion with justification, request a scenario rerun, or access the preview environment directly. Every decision is timestamped and attributed.
The diff is still one click away for reviewers who want to inspect the code directly. But the primary review surface is intent and evidence, not lines of code. This is what makes the model scale: a reviewer can validate a 500-line AI-generated change in minutes by checking whether each criterion passed, rather than reading every line.
Audit trail and compliance
Every step in the Aviator Verify workflow is recorded as an immutable event: who submitted the intent, what criteria were generated, what verdicts came back, what evidence was captured, what decisions were made, and what exceptions were granted. The spec approval, implementation, and verification are separate actors, giving you segregation of duties by default.
This matters for compliance. SOC 2, ISO 27001, and similar frameworks require traceability from business intent to production code. Aviator Verify produces that traceability as a natural byproduct of the workflow — not as a separate documentation exercise. Teams can export compliance packages that link every production change to its approved intent, verification results, and business justification.