If an agent wrote most of a service, why does it still need a human owner?

Because an incident is not a code-reading problem, it is a judgment problem under time pressure. The owning team has to know what normal traffic and normal errors look like for that service well before anything breaks, and that context only builds by living with the service, not by having typed its code.

Is the owner one named engineer or a team?

A team, named in the same place the on-call rotation lives, not one individual. A single named owner creates a bottleneck the moment they are on leave or asleep, while a small team with a clear rotation keeps the same accountability without a single point of failure.

What does the eval suite catch that ownership does not, and the reverse?

The eval suite catches the failure modes someone already wrote a check for, before the change ships. Ownership catches everything that happens after deployment that nobody wrote a check for, because the person or team who knows the service can read a graph, judge whether it is safe to roll back, and decide fast.

Does code ownership slow down how fast a team can ship with AI tools?

No, it changes what slows down. Generating the change gets faster with AI tools, and the decision about whether to ship it and who answers for it afterward still needs a person, so ownership sits at the review and incident stage, not in the way of drafting the code itself.

How is this different from the sign-off process on a pull request?

Sign-off happens once, at merge time, and answers whether a specific change was correct. Ownership is ongoing and answers a different question during an incident: who already understands this service well enough to diagnose it fast, independent of which change caused the problem.

What happens when an agent writes code for a service with no clear owner?

The first hour of any incident in that service goes to figuring out who understands it, instead of fixing it. That is true whether the code was agent-written or hand-written, but agent-written code raises the stakes because more of it can exist before anyone has read all of it closely.

Can an eval suite replace an on-call engineer?

No. An eval suite is a fixed set of checks written from a specification, and it runs before code ships. An incident is a live, unplanned event with symptoms nobody wrote a test for, and resolving it needs a person who can reason about a system they know, not a script that reruns a fixed list of assertions.

How does Reveneau assign ownership on a project it builds?

Every module or service gets an owning team from the point it exists, recorded alongside the on-call schedule rather than in a document nobody opens during an incident. That team is accountable for the service through production and after release, whether the original change came from an agent or a person.

Why code ownership still matters when agents write it: Reveneau

We have watched an agent generate a working service faster than any engineer could read the resulting code end to end. That is not a complaint. It is the entire pitch of building with AI: the draft used to be the bottleneck, and now it isn't.

But speed at generation time creates a new question that has nothing to do with how the code got written. When that service breaks at two in the morning, who answers the page? Here is what we have learned scoping and running these builds: the harder the code gets to review line by line, the more the answer to that question matters, not less.

The eval suite proves the code is correct. It does not know who to call.

An eval suite is a set of checks written from the specification, run before a change ships. It tells you whether the code does what you said it should do. That is real and it is valuable, and it is also a fixed, finished thing: a list of assertions someone wrote in advance.

An incident is the opposite of a fixed, finished thing. It is a live system doing something nobody specified for, discovered after the fact, usually under time pressure. A suite that passed yesterday says nothing about why a queue is backing up right now. Somebody has to look at a dashboard, recognize what is unusual about it, and decide whether the safe move is to roll back, patch forward, or wait. That is a judgment call made by a person who already understands the shape of that particular service, not a check running down a list.

This is the same argument we made about code review generally in who signs off on AI-written code: a check can only enforce a rule somebody already thought of. An incident, by definition, is the rule nobody thought of yet.

The gap gets wider once an agent is the one writing most of the code, for a plain reason: the volume goes up while the number of people who have carefully read every line goes down. A team could once claim, with some honesty, that everyone on it had touched most of the codebase at some point. That claim stops being true the moment generation speed outpaces reading speed, and it does not come back just because the tests are green.

The context a reviewer builds is not the same as the context an owner needs

There is a difference worth naming between reviewing a change and owning a service, and it is easy to collapse the two.

A reviewer reads a diff and judges whether that specific change is correct, well-scoped, and safe to merge. That work is real, and we have written about what it should look like when the code arrives already passing automated checks. But reviewing thirty changes over three months does not automatically add up to understanding a service the way its owner does. An owner knows what the traffic pattern looks like on a normal Tuesday. An owner knows which downstream system gets fragile first when this one slows down. An owner knows which error messages are noise and which ones mean something is actually wrong. None of that shows up in a diff, and none of it can be inferred from reading code quickly, however carefully. It gets built by living with the service over time, which is exactly the kind of context an agent, however good at generating the code, cannot hold.

Ownership has to exist before the incident, not get assigned during it

The costly version of an outage is not the one where the fix takes an hour. It is the one where the first forty minutes go to figuring out who understands the service well enough to even start.

That cost is avoidable, and avoiding it is mostly a matter of doing the boring part in advance: every module or service gets one owning team, named in the same place the on-call rotation lives, from the day the service exists. Not a document nobody opens during an incident. The same list the pager checks.

The team Google's Site Reliability Engineering group built its incident management practice around makes a version of this point directly: incidents get resolved faster when a clear point of contact exists before things go wrong, because assembling the right people is itself a source of delay if it has to happen live. That finding predates AI-written code by years. It gets more relevant, not less, once a service can be generated faster than a person can build a mental model of it, because the gap between "code exists" and "someone understands this system" is exactly where an unowned incident gets slow.

A team, not one name, and not the person who wrote it

The instinct is to make the owner the person, or the model, that produced the code. Resist it on both counts.

One named individual as the accountability mechanism creates a single point of failure: they are on leave, asleep, or simply do not answer, and the incident stalls on a person instead of getting worked. A small team with a real rotation keeps the same accountability, decisions get made by someone answerable for the outcome, without depending on one person being reachable at the wrong hour.

And the fact that an agent wrote most of a service does not make it the owner. An agent cannot be paged. It cannot sit with a graph and decide whether traffic is climbing for a good reason or a bad one. It cannot be asked afterward why a warning sign got missed, and that question, asked of a real team, is what changes how carefully the next change into that service gets reviewed. Ownership is a human commitment to understand a system over time. Authorship is just where the first draft came from.

What changes, and what does not

None of this slows down how fast a change gets written. Generating code got faster with AI tools, and it should stay that way. What ownership adds sits downstream of that: at merge time, someone with real context on the service is the one deciding whether to approve it, and after release, that same team is who a page-out finds.

The 2025 DORA report, drawn from responses across nearly 5,000 technology professionals, found that AI adoption raises delivery throughput while it lowers delivery stability, and describes AI as an amplifier of whatever an organization already is. Read plainly: teams with clear ownership get faster at shipping safely. Teams without it get faster at producing incidents nobody is positioned to resolve quickly. The code volume does not decide which one you get. The org chart does.

What this means for how we scope a build

When we scope a build, ownership is part of the architecture conversation, not an afterthought bolted on after launch. Every service gets a team attached to it from the start, and that team is accountable for it through production and after release, regardless of whether the first version came out of an agent's draft or a person's. The eval suite is how we prove the code does what the specification said. The owning team is who answers for the system doing something the specification never anticipated.

Agents changed how fast a service gets built. They did not change who has to be ready to answer for it once it is live, and no version of this technology is going to change that next.

Sources

DORA 2025 report, via Google Cloud Blog: AI adoption raises delivery throughput while lowering delivery stability, and acts as an amplifier of an organization's existing practices, based on responses from nearly 5,000 technology professionals.
Google SRE book, Managing Incidents: incident response is faster when a clear point of contact and ownership structure exist before an incident starts, rather than being assembled during one.