We talked to 100+ dev teams about how they use AI. Here are some things we learned.

We spent four months talking to more than 100 tech leads, architects, and senior engineers about how their teams actually use AI. Review time is a real constraint. But the one they kept circling back to was harder to name: control.

The dominant story about AI and code review is a throughput story: agents write faster than any human can read, the PR queue backs up, and the fix is to review faster with better bots, more QA, more automation. Everyone we spoke to feels that pressure. But ask them whether humans are still needed and the answer is a firm yes: people still own the moments that decide quality, setting up how the agents work, writing the spec, and reviewing what ships. It is that last one, review, where the deepest worry sits.

Humans didn't leave the loop. They moved to its edges.

That yes has gotten more specific over the last six months. The fever that peaked after the late-2025 model releases (also known as the Saaspocalypse era) has cooled into a hangover: a few months of uncoordinated AI use that produced years of tech debt. Three moments came back again and again as irreducibly human.

The agentic software factory. Before a line is generated, someone sets up the system the agents work inside: CLAUDE.md and AGENTS.md, the conventions, the rules, the specs format, the skills that standardize the workflows, the CI checks. Someone also keeps auditing the architecture and the codebase as the agents reshape it. It is the same job the tech lead always had, now aimed at agents instead of people. One finding was consistent: teams that let the agents run that structuring themselves backed off. Code files ballooned to thousands of lines, the layout scattered, and past a certain size the agents lost the thread of their own code. Keeping the system legible stayed a human job.

Writing the specification. It is easy for an LLM to produce industry-standard code, such as a boilerplate integration or reading a CSV in Python. As LLMs commoditize, that kind of software commoditizes with them. That pushes the value into the business-specific details, where the prompter's domain expertise is what makes the software non-standard.

Reviewing and validating. Early on we met a few believers, convinced they could get away without ever reading their code again. Almost no one we spoke to still believes they can hand off ownership of the codebase: roughly 80% still keep a human reviewing what ships. AI is a tool, and a fast one. Speed without a gate has one destination: a Ferrari is a very fast way to get into a wall. Someone has to hold a model of what the codebase is becoming, because that is the person you will need the day it breaks.

"You get systems that look right but aren't, and when one thing goes wrong, you have no idea what happened."

— a founding engineer

The clean exception is the early-stage startup, where nothing matters except finding the market before the runway ends. Fair. But we heard the same bill come due later, once they scaled: the codebase turned unmaintainable, new hires could not ramp, and more than one team told us they paused growth to clean up or rebuild. The debt is fine to take. It just belongs in the plan.

Time is the real constraint. Control is the deeper worry.

The review bottleneck is almost always framed as a time problem, and it genuinely is one. Addy Osmani's Code Review in the Age of AI frames it that way, and so did our own manifesto. Agents outproduce reviewers, the queue grows, reviewers go underwater. About 2/3 of the teams we spoke with named review as their bottleneck.

But that is not what surprised us. Sitting next to tech leads while they reviewed, the concern underneath was not time. It was control: being able to say, with confidence, what a change does to the system they answer for. Around 40% named that loss of grip outright; more circled it without quite having a word for it.

A senior dev carries a mental model of the codebase that lets them review a PR extremely fast: check the data-model changes, check the APIs, check the business logic, skim the rest. Done. That single act signs off the change and keeps the mental model current. That model is what makes them the right person to fix the thing at 2am when it breaks.

That is the pass agents break. For as long as people wrote the code, review had a safety net: the author was a teammate you knew, and you could ask what they were thinking, which edge cases they weighed, why they went this way instead of the obvious one. Now the author is effectively a stranger who has already left the building. The reasoning that produced the change lives in the agent's session, not in the diff, so all the reviewer has is the code. Instead of skimming against a model they already hold, they read every change and try to infer, from the code alone, why it was made.

"Now I have a 14,000-line PR. How the hell am I going to understand what happened? Can I trust it?"

Review bots do not close the gap either. They flag individual lines, one more stream to read, while the question that actually matters goes unanswered: what is this change doing to the system? Push it far enough and the code is written by one model and reviewed by another, until people quietly learn to stop looking at that signal.

"In the end, it's just AI talking to AI."

— a team lead

The binding constraint moved from writing code to understanding it.

New tools for writing code do not change what a software process is for. Thirty years of practice still holds. What changed is where the constraint binds: writing is cheap now, and reading a change, understanding it, and answering for it is the step that limits everything. That step still runs on an interface built for a diff a human could hold in their head. Watching reviewers work, we saw five things they used to do cheaply get expensive.

The reviewer's job	Before	Under agentic development
Hold the spec in your head	PR description and a linked ticket; a whiteboard for the hard ones	More spec than ever, in prompts, tickets, PRDs, ADRs, and repo docs, but none of it is easily accessible when you review the diff
Find the poorly-built parts	Scan a small diff; lean on conventions, tests, and CI	Everything looks fine and well tested at a glance, across too many files. It takes GitHub, the IDE, and an agent to review a single PR: three interfaces for one review
Confirm nothing exceeded scope	Obvious on a scroll, if you know the codebase	Buried in the hundreds of files changed, and "out of scope" barely means anything now: agents scope-creep by default, so it mostly slips through
See how the team actually works	PR reviews, peer coding, lints, CI, conventions, DORA metrics	You just see an LLM's output, with lints and CI enforced on it. No way to know which model was used, how the dev prompted, or which skills they used, and no obvious way to level the team or break the silos that leave it behaving like a pack of solo devs
See every change	Read every PR, top to bottom	Impossible at volume; you have to focus on what matters, not the boilerplate

Humans are necessary. They just don't have the right tools.

None of this makes the reviewer's job automatable, and that is the point. Not because an LLM cannot summarize a change; increasingly it can. Because someone human still has to own the result and answer for it: to the on-call rotation, to the customer, to whoever asks why it broke. And owning a decision means understanding it. A better reading interface does not decide whether a change is right; it gives back the context to decide faster. It will not rescue a team that never wrote the spec down, and it will not turn a 300-file PR into a good idea.

Humans are nowhere close to leaving the software development process. Their role is moving: from typing the code to owning the judgment about it, and to protecting the one asset agents erode fastest, a live model of what the system is becoming. We think the binding constraints of the SDLC have changed, and the tooling has to be rebuilt to adapt to them.

That is the interface we are building Hervé to be: a review surface that hands the reviewer the intent alongside the diff, so they can rebuild their mental model instead of reverse-engineering it from the diff.

Do these observations resonate with you? What about you, how do you keep control over your codebase?