Writing code got faster. Reading it didn't.

AI coding agents broke that balance. The implementation step now runs in minutes, while review still runs at human speed.

And this is not a niche problem. AI coding went from experiment to default in barely two years: more than 80% of developers now use AI tools. Nearly every software team on earth has inherited the same broken arithmetic: code arriving faster than anyone can read it. The way we write software changed overnight; the way we review it did not.

This manifesto is about what that means for the software development life cycle (SDLC): where review needs to go, and what a team could learn along the way.

How the process used to work

The steps were a ticket, a few days of implementation, a round of review, a merge. Review was a bounded cost: 4 to 6 hours a week, most of it carried by senior engineers.

What AI changed

The process keeps its shape, but its middle does not. Three steps, one of them new:

1. Formalization. The developer turns the ticket into a spec, plan, or prompt with enough context for the AI to work from.
2. Implementation. The AI reads the codebase, the context, and the prompt, then generates code, a few minutes for thousands of lines.
3. Testing. The developer reviews the output, tests it, and re-prompts or edits to fix what is off.

Implementation is where it broke. Code generation went from hours and days to minutes, while review still happens at the speed of a human reading.

That reshapes the day of senior engineers, among the best-paid people on earth, whose attention is the most expensive resource a team has. Writing used to fill most of the week. Now most of it goes to reviewing AI-generated code, and review time has nearly doubled. The people who used to write the hardest code now mostly read it.

The asymmetry

Volume. A single developer can now produce a week's worth of code before lunch, and reviewers are asked to read thousands of generated lines a day. Something has to give: review as carefully as before and become the bottleneck, or review faster and let quality slip: the control-versus-speed trade-off this shift forces. Most teams quietly pick speed. Review fatigue does the rest, and the codebase accumulates "comprehension debt".

Abstraction. When developers wrote every line, the diff was the reasoning: each change a conscious decision. Not anymore. The work now happens in prompt space, and the reasoning that shaped the code lives there, not in the diff. Tech leads end up commenting on code nobody wrote, about decisions they can only guess at.

Worse, AI-generated code is hard to review precisely because it looks good. Naming is consistent. Structure is clean. Tests pass. Reviewers have nothing obvious to catch, so attention slides off. And a new class of risk hides there: the decisions behind the code, which the clean output gives no sign of.

Why existing tools do not solve this

Current PR review tools like GitHub and GitLab were designed for the old process. They surface diffs, run CI checks, and thread comments on line numbers. The artifact under review is still the diff, and the prompt that produced the code is nowhere in the picture.

A newer wave of AI code reviewers like CodeRabbit and Aikido catch real issues classic CI misses. Useful, but only some, never all, and never the biggest gap. Like every tool before them, they read the diff and guess at the intent behind it. The deeper problem is that someone still has to understand what is going into the codebase they are accountable for, and that understanding takes the intent that produced the change: the constraints, the rejected paths, the decision the developer actually made. All of it is thrown away the moment they push. Take that away, and what is the engineer even there for?

How Hervé changes review

Think of every team as sitting on one curve. One axis is how much control you keep over what ships; the other is how fast you move. Read every line and you keep control but move slow. Ship on faith and you move fast but blind. For years that curve was short. Writing code by hand was slow either way.

AI stretched it. Generation became almost free, the fast end raced ahead while review stayed at human speed, and the gap between reading everything and shipping on faith blew wide open. But a curve is only as good as the tools that draw it. A better review tool draws a new one, and that is what Hervé is built to do: not find a nicer point on today's curve, but draw a new one, where you move fast and keep control.

Hervé redraws it with two things the diff never carried: the intent that produced the change, captured for the first time, and a read on what is critical in your codebase. It weighs the code against what was actually asked, and against where a mistake would do the most damage, so review stops being a top-to-bottom crawl. It starts with the questions that matter: where did the AI do more, or less, than the intent asked for, and did it touch what you cannot afford to get wrong?

The loud version makes headlines: in April 2026, a Cursor agent deleted a startup's production database and every backup in nine seconds while "fixing" a staging error nobody asked it to touch. But most drift is quiet: a loosened check, an unvetted dependency, a stray read of a .env, one file touched that should have been left alone, buried in a 200-file pull request. Some of it never shows in the diff; the rest is lost in the noise, with nothing to flag it as unasked for. The tests pass. Only by comparing the intent to the diff can you see where the code and the instruction parted ways.

This does not mean reading more. It means the opposite: Hervé surfaces the handful of places that deserve a human's attention, the spots where the code drifted from the ask or touched something critical, instead of leaving you to crawl the whole diff. And unlike a review bot, it does not try to make the call for you. It keeps you in the driving seat, where the judgment belongs. You read less, understand more, and keep control at speed.

And it does not stop at the single PR. Reviewing this way captures the intent behind every change, and across a whole team, that captured signal holds answers a tech lead is not able to see: whether the team's own skills are actually being used, and when. Which parts of the codebase burn the most tokens to change. Today those answers are scattered across a hundred private sessions and lost. Hervé surfaces them, so a team's hard-won practice stops dying on one laptop, the way individual style once became style guides and manual checks became CI. A team that can see how it builds with AI, and get better at it together, becomes more than the sum of its engineers.

Hervé reads your code and its intent, never stores your code, and goes to work on your next pull request.