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

Because an incident needs judgment under time pressure more than code reading. The owning team has to know what normal traffic and normal errors look like for that service well before anything breaks, and that knowledge only comes from working with the service over time, which typing its code does not give you.

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 slows everything down the moment they are on leave or asleep, while a small team with a clear rotation keeps the same accountability without depending on one person.

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 is released. 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 release software with AI tools?

No, it changes which step takes time. Generating the change gets faster with AI tools, and the decision about whether to release it and who answers for it afterward still needs a person, so ownership belongs to the review and incident stages and does not delay drafting the code itself.

How is this different from the approval process on a pull request?

Approval 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 makes the risk larger 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 is released. 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. We say this as praise: it is the entire pitch of building with AI. The draft used to be the slowest step, 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 responds to the alert? 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.

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 is released. 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 growing 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, release a fix, or wait. That is a judgment call made by a person who already understands how that particular service works, rather than a check going through 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 worked on most of the codebase at some point. That claim stops being true the moment generation speed is faster than reading speed, and it does not become true again just because the tests pass.

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 treat the two as one.

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 dependent system starts to fail first when this one slows down. An owner knows which error messages can be ignored 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 comes from working 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 starts

The most costly outage 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. Put it in the same list the alerting system uses, where people look during an incident.

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 matters more once a service can be generated faster than a person can understand it, because the gap between "code exists" and "someone understands this system" is exactly where an incident with no owner slows down.

Give ownership to a team, and keep it separate from authorship

The first idea is often to make the owner the person, or the model, that produced the code. Both are wrong choices.

One named individual as the accountability mechanism means everything depends on one person: they are on leave, asleep, or simply do not answer, and the incident waits for that person instead of being fixed. 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 receive an alert and respond. It cannot study 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 comes after 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 receives the alerts.

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 something that makes an organization's existing strengths and weaknesses larger. Read plainly: teams with clear ownership get faster at releasing safely. Teams without it get faster at producing incidents nobody is ready to resolve quickly. The org chart decides which one you get, more than the code volume.

What this means for how we scope a build

When we scope a build, ownership is part of the architecture conversation, instead of something added 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 increases the effect 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.

Why code ownership still matters when agents write it