The new asymmetry between writing code and reviewing it

AI coding agents broke that balance. The implementation step now runs in minutes while review still runs at human speed, and the tools we use to review code haven't caught up. This manifest is about what that means for the software development life cycle (SDLC), and where we think review needs to go.

How the loop used to work

1. Requirements / tickets. Users or the product owner describe what they want in human language. This goes into a tracker like Jira or Linear.
2. Implementation. A developer picks up the ticket and writes the code. This takes anywhere from a few hours to several days.
3. Testing. The developer tests the changes and adjusts until the behavior matches the description.
4. PR creation. The developer opens a pull request. Continuous integration runs automatically on the diff, catching formatting issues, failing tests, and basic violations before any human looks at it.
5. Review. The tech lead and other developers read the diff. They check whether the implementation actually solves the ticket, follows conventions, is understandable, and is tested. When something needs changing, they leave comments and the developer goes back to step 2. Developers typically spent 4 to 6 hours per week reviewing code, and senior engineers carried the bulk of it.
6. Merge. Once approved, the code is merged into the codebase and ships to production.
7. Feedback. Production usage generates new reports and requests, and the cycle starts again.

What AI changed

Some steps are the same. Some are profoundly changed:

1. Requirements. Same as before.
2. Formalization. The developer takes the ticket and writes a spec, plan, or prompt that gives the AI enough context to work from.
3. Implementation. The AI reads the codebase, the company context, and the prompt, then generates code. This currently takes a few minutes for thousands of lines of code.
4. Testing. The developer reviews the output, tests it, and re-prompts or edits manually to correct anything off.
5. PR creation. Same as before.
6. Review. Same as before.
7. Merge. Same as before.
8. Feedback. Same as before.

Steps 1 and 5 through 8 are unchanged. Steps 2 through 4 are completely different.

The shift in step 3 is the one that breaks the process' balance. Code generation went from work measured in hours and days to work measured in minutes, while review still happens at the speed of a human reading.

The asymmetry

Volume. The implementation step went from days to minutes. A single developer can now produce a week's worth of code before lunch. PR reviewers are now being asked to review thousands of lines per day, and the practical outcome is either shallower reviews or a slower pipeline. Most teams are quietly choosing shallower reviews, accumulating "comprehension debt".

Abstraction. When developers wrote every line themselves, reviewing the diff made sense. Every change was a conscious decision, and feedback on the diff was feedback on the developer's reasoning.

That is no longer true. Developers now work in prompt space. The reasoning, the constraints, the back-and-forth that shaped the implementation all happen there, not in the diff. Tech leads end up commenting on code nobody on the team wrote, about reasoning they must deduce.

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. The real risks are in the decisions behind the code, and the clean-looking output forces reviewers to reverse-engineer the thinking behind it instead of reviewing that thinking directly.

Why existing tools do not solve this

Current PR review tools like GitHub and GitLab were designed for the old loop. 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 can catch things classic CI cannot, and that is genuinely useful. But it stops there. The harder problem is that humans need to understand what is being merged into the codebase they are responsible for, and another AI in the loop does not solve that. The issue is not the lack of automation. It is that the artifact being reviewed — the diff — no longer reflects where the work actually happened.

Our vision for code review

Code review is not going away. But it needs to operate at a different level of abstraction than it does today.

For most of the code an AI agent generates, the right thing to review is not the diff. It is the conversation that produced it: the intent, the constraints, the reasoning the developer brought to the problem. That is where judgment lives now, and that is where most feedback should land.

The diff still matters, but not uniformly. Security code, core business logic, and database migrations carry more risk than the rest of the codebase, because problems there have a larger blast radius. Reviewers should spend their attention there, not spread evenly across every changed line.

Beyond individual PRs, there is something bigger at stake. Every AI coding session a team runs is a signal: how developers frame problems, what context they give agents, where they course-correct, where the AI struggles. Right now that signal disappears. It never gets captured, never gets shared, never compounds into anything a team can learn from. The same inefficiencies get made in isolation, by every developer, on every project.

We believe that over time, the teams that ship the best software will be the ones that treat prompting as a team skill, not a solo one. That means building the infrastructure to observe it, discuss it, and improve it collectively — the same way teams built style guides and CI pipelines to improve how they write code.

That is what Hervé is working toward.