reviewing AI code one task at a time isn't enough

AI writes more code in a day than any team was built to review. the natural reflex is to review each change as it lands — is this diff correct, does it do what the task asked. that gate is mandatory. it is also, on its own, not enough.

task-level review is table stakes

every change should pass a per-diff review before it merges: does the code match the plan, is it correct, does it introduce an obvious defect. defract runs this as a stage in the lifecycle — story → design → implementation → review → ship — and the change doesn't advance until the review gate clears. keep this, always. it's how each individual change stays honest.

but notice what it is scoped to: one diff, in isolation, right now.

the holes open up between the tasks

the failure that actually bites you usually isn't inside any single change. it's what forty individually-approved changes do to the codebase together. none of these fails a diff review:

• two tasks add the same helper in two different places. neither diff is wrong. now you maintain both, and they drift.
• every task adds one more auth check. no single task owns whether the auth model still holds across all of them.
• performance dies by a thousand cuts — each change adds one query, and no per-diff review is positioned to see the cumulative N+1.
• an architectural boundary erodes one reasonable-looking pull request at a time until the layering is gone.

every one of those passes review. every one of them ships. this is the gap the 2026 Faros engineering report measured from the outside:

teams shipped ~66% more per developer — while incidents per pull request rose ~243% and code churn ~861%.

the changes were fine. the system wasn't. and it isn't a flaw in per-diff review — it's a scope limit. you can't see a system-level problem through a single-change-sized window.

codebase-level review is a different job

so you need a second layer, and it has to look at a different thing: the whole codebase, across every task, release, and area — not one diff. that's what we're building into defract as continuous review. it maps your codebase into areas — the real regions of your system, not folders — and reviews each area through a set of lenses. the result is a coverage view: which areas have been reviewed, through which lens, how recently, and where the open risk sits. it turns "is the codebase healthy?" from a feeling into something you can look at.

the lenses, and why they're adversarial

a single "looks good to me" pass is the weakest form of review — it is searching for reasons to approve. adversarial review inverts that: independent passes, each trying to break the code from one specific angle. defract's codebase review runs four lenses:

• security — hunts for the vulnerability, not the happy path.
• performance — looks for what gets slow at scale, not what works on your laptop.
• architecture — looks for coupling, drift, and boundaries quietly eroding.
• refactor — looks for the duplication and rot that make the next change harder.

splitting them buys specialization and independence. a security reviewer and a performance reviewer surface different things, and running them separately keeps either from dissolving into a vague, useless "quality score." they run independently, then get reconciled: what multiple lenses surface on their own rises to the top; a lone, low-confidence flag drops down. that consensus step is what stops adversarial review from burying you in false positives — the noise that kills every review tool that just lists everything it can find.

and every finding carries its blast radius — the files it actually affects across the codebase, not just the line it lives on. you triage by system impact, not by locality.

findings are a ledger, not a moment

a codebase review isn't a gate you clear once and forget. each finding has a life: you resolve it, or you dismiss it with a reason that sticks. dismiss something, and if the same issue resurfaces later it stays settled — it doesn't nag you again. promote a finding to a task and it flows back into the same lifecycle that built the code in the first place. your codebase's risk posture becomes something you track over time, area by area, instead of rediscovering it in an incident.

two layers, both mandatory

task review keeps each change honest. codebase review keeps the whole thing honest. one without the other is a trap: skip the diff gate and every individual change is a risk; skip the codebase layer and you accumulate holes that no single review was ever positioned to catch.

if you're shipping AI-written code fast — and everyone now is — you need both. that's the bet defract is built on: the tools that only run more agents make the first problem worse and the second one invisible. running the process is what closes both.