the new bottleneckVibe coding moved the bottleneck from writing to reviewing.
Generating software by describing it to an AI — vibe coding — is genuinely fast. But in a real company the speed just relocates the jam. Code volume jumps, pull requests balloon past 20 files and 1,000 lines, and review latency climbs quarter over quarter until, on the biggest diffs, reviewers stop meaningfully engaging at all. They approve. That's the failure mode: not uniformly bad code, but diminished scrutiny. AI reduced the effort to produce code; it did not reduce the responsibility to make sure it's correct. Review is where that bill comes due.
- AI made very large PRs trivial to produce; human attention stayed bounded.
- On the largest diffs, review time plateaus — the signal that nobody is really reading.
- The real bottleneck isn't generation speed, it's trust: can this ship without a human fully understanding it?
what AI gets wrongKnow the failure modes before you open the diff.
AI code fails in predictable, reviewable ways — and knowing them tells you exactly what to look for. Models solve the literal problem and ignore the practical one: a query that fetches all users with no pagination, no limit, no filter. They write the happy path beautifully and treat error handling as an afterthought. They invent abstractions that look plausible and duplicate logic that already exists. And the slow poison is comprehension debt: as generated code accumulates, the team understands less of its own codebase, until one study found experienced developers were 19% slower with AI tools, not faster. You cannot out-read this. You have to structure against it.
- Happy-path bias: beautiful success cases, missing error and edge handling.
- Literal-but-impractical: correct for the prompt, wrong for production (no limits, no pagination).
- Reuse blindness: re-implements what already exists instead of calling it.
- Comprehension debt: accumulated AI code the team no longer understands.
the core moveDeterministic gates first. Human eyes last.
The single most effective change is to stop using humans as the first line of defense. Most of what goes wrong in AI code is mechanical — and machines catch mechanical problems perfectly, every time, for zero attention. So you layer the review: linters and formatters, a type checker, the existing test suite, security and secrets scanning, dependency and lock-file drift checks all run before any diff reaches a person. Green or it doesn't move. This is the 'vibe, then verify' workflow done right: the AI vibes, the gates verify, and a reviewer only ever sees code that has already survived every check a computer can run. Their bounded attention gets spent on the one thing gates can't judge — whether the change is the right change.
- Lint + format: style and obvious defects, deterministically, no human cost.
- Types: whole classes of integration bugs caught before review.
- Tests + security + secrets + lock-file drift: every change, every time.
- A person reviews only what's already green — never raw, unverified output.
what humans should doReview intent and blast radius, not syntax.
Once the gates are green, syntax correctness is a solved problem — and a misleading one, because 95% syntactic correctness breeds false confidence. The human's job is the part no checker can do: is this the right thing, built the right way, safe to fail? Keep the original requirement open — you cannot judge whether code matches intent if you're only looking at the code. Then ask the questions that matter: What is the intent? Why is this correct? What can fail? What's the blast radius? How is failure detected, and how do we roll back? And bound the inputs: cap PR size (≈200 lines as a target, 400 as a ceiling) so every review fits inside a human's actual attention budget. Reviewing intent scales. Reviewing syntax does not.
- Always review against the requirement, not the diff in isolation.
- Ask: intent, correctness, failure modes, blast radius, rollback.
- Cap PR size so the diff fits inside real human attention.
- Mechanical checks are local signals — humans own architecture, design, and safe failure.
the method, made realAgentation is the software that enforces this.
A review method only works if something applies it on every change — discipline doesn't scale, structure does. That's Agentation, built on the Méthode Digital Native. A Product Owner describes the intent on the live product. A Tech Lead encodes the rules once — architecture, conventions, security, the maintainability bar — and every agent boots inside them. Then the deterministic gates run before anything reaches production: lint, types, tests, security, all of it, green-or-it-doesn't-land. Everything ships through your own GitHub, on your existing AI plan. So 'nobody read it' becomes 'a structure checked it, every single time' — which is stronger than a tired human reading it sometimes.
- Tech Lead encodes your standards once; agents can't ship outside them.
- Gates run on every change before prod — the human review surface shrinks to intent.
- Ships through your GitHub, on your plan — we never store your code.
cocoricoA French team, sovereign on the tooling.
Agentation is built by a French team. You're probably not going to be sovereign on the models — Claude, GPT and the rest are American — and that's fine, because with just a model you don't do much. The leverage is in the tooling that orchestrates those models: the review structure, the gates, where the code lives, where the data sits. That layer can absolutely be European, and it's a huge part of the value. So we make it so: hosting in the EU (Hetzner, Germany), data in the EU (Supabase), your code staying inside your own GitHub, GDPR by construction. Sovereign where it actually counts — the part you control.
- French team, EU hosting (Hetzner, Germany), EU data (Supabase).
- Your code never leaves your GitHub; we don't store it.
- Sovereignty on the orchestration layer — the part that's actually yours to own.
FAQHow do you review AI-generated code at scale without burning out reviewers?
You stop making humans the first line of defense. Run deterministic gates — lint, type checks, tests, security and secrets scanning, lock-file drift — automatically before any diff reaches a person. Those catch the mechanical failures for zero human attention. A reviewer then only sees code that's already green, and spends their bounded attention on intent and architecture, not syntax. That's how review scales when generation is effectively free.
What should a human actually look at when reviewing AI code?
Intent and blast radius. Keep the original requirement open and judge whether the change does the right thing the right way: What's the intent? Why is it correct? What can fail? What's the blast radius and rollback plan? Syntax and style are the gates' job — once they're green, the human's job is everything a checker can't decide: is this the correct change, and is it safe to fail?
What are the most common ways AI-generated code fails review?
Four recurring patterns: happy-path bias (beautiful success cases, missing error handling), literal-but-impractical solutions (correct for the prompt but no pagination/limits for production), reuse blindness (re-implementing code that already exists), and comprehension debt (accumulated AI code the team no longer understands). Knowing them tells you what to gate against and what to scrutinize by hand.
Isn't 'I never read the AI's code' exactly how software becomes unmaintainable?
It is — if nothing is watching. The difference is structure. With Agentation, a Tech Lead encodes your conventions and maintainability bar once, agents work inside them, and deterministic gates verify every change before production. So 'nobody read it' becomes 'a structure checked it, every time' — which beats a tired human reading it sometimes. What accumulates is governed code, not unreviewable sprawl.
How big should an AI-generated pull request be?
Small enough to fit inside real human attention. A practical rule is ~200 lines as a target and ~400 as a hard ceiling, with a documented exception for mechanical refactors. Agents make giant PRs trivial to produce, but on the largest diffs reviewers stop genuinely engaging — they just approve. Bounding size keeps the human review meaningful instead of theatrical.
Does Agentation see or store my code?
No. Everything ships through your own GitHub on your existing AI plan; we don't store your source. Hosting is in the EU (Hetzner, Germany), data in the EU (Supabase), GDPR by construction. We're a French team and the sovereignty is on the orchestration layer — the gates, the review structure, where your code and data live — which is the part you can actually own.