Today’s AI‑assisted code review tools often let a model read every line of a pull request, produce a verdict, and leave a human to skim the output before approving. Aviator Verify flips that model: verification is handled by deterministic agents, while intent, decisions, and final approval stay with people. The change replaces pure line‑by‑line AI judgment with a structured, seven‑part workflow that captures standards, intent, and evidence before a human signs off.
Invariants: Codified Team Rules
Every change is first checked against a set of invariants – the explicit, written rules that embody a team’s engineering standards. In the past, these rules lived in senior engineers’ heads and appeared sporadically as review comments (e.g., “use the Money type for currency”). Verify extracts recurring patterns from PR comments, CONTRIBUTING.md, and explicit @aviator invariant tags, then drafts them as machine‑readable rules. A rule only becomes active after the owning team approves it, ensuring ownership, clear outcome‑focused wording, and appropriate scope.
Intent and Acceptance Criteria: Capturing Why the Change Exists
Instead of a static spec written before implementation, Aviator Verify records intent and acceptance criteria directly from the coding session. Whenever the AI agent asks a question and the engineer answers, those exchanges are harvested, presented for review, and corrected before the PR is submitted. This preserves the real‑time rationale behind a change, eliminating drift between a spec and the actual implementation.
Core Decisions: Making the Implicit Explicit
Many architectural choices never appear in a diff – for example, where state is stored or how a failure path is handled. Verify logs each decision point, labeling whether it originated from a human or an AI agent. This audit trail lets reviewers see who made which call and provides a concrete target for discussion, rather than guessing from code alone.
Test Plan, Evidence, and Human Review
At submit time, Verify assembles a test plan that combines the captured acceptance criteria with the relevant invariants, turning them into concrete test scenarios. It also gathers evidence from a running environment – logs, metrics, or other artefacts – that demonstrate the change meets those scenarios. A human reviewer then examines intent, decisions, and evidence, approving or pushing back as needed. The final step refreshes invariants: any waivers or recurring comments are turned into updated rules for future checks.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Adopting an intent‑driven review workflow shifts the burden of rule enforcement to deterministic agents, reducing missed violations caused by undocumented standards. Engineers must invest effort upfront to define clear invariants and ensure the capture hooks are correctly integrated into their CI pipeline. Security and compliance teams gain a traceable record of decisions and evidence, simplifying audits. Operationally, the process adds a verification stage before PR creation, which may increase cycle time but improves confidence that changes align with both policy and purpose. Teams should start by extracting recurring review comments into provisional invariants, pilot the intent capture in a low‑risk repository, and iterate on the decision‑logging format to match their existing documentation practices.
