We’ve reached a strange junction in software engineering. More and more of the pull requests landing in my review queue were written entirely by an AI agent, and the engineer who opened them has little or no insight into the problem being solved.

A recent example: a PR that added a surprising amount of complexity around error handling in Google Tag Manager. Layers of it. I suspect the underlying issue was something far simpler, and that this was a massive over-complication of a small fix. But to prove that, I’d need to spend a day unpicking what the agent did and why, and I’m not going to do that.

So the PR sits there, and I’m left with an uncomfortable question. Who owns this code? Nobody wrote it, in the sense that matters. Nobody will take ownership of it going forward, and in six months nobody will know what it does or whether it’s safe to delete.

The review problem

Generating code is now nearly free. Reviewing it is not. A good review was never really about reading every line. It’s about the solution: is this the right approach, is it the simplest thing that works, does it fit the rest of the system, and is it even solving the right problem? Answering those questions takes real understanding, and that cost hasn’t gone down at all. If anything it has gone up, because agents are very good at producing a confident, thorough-looking solution to a slightly different problem from the one that actually exists.

When the author doesn’t understand the change either, the whole burden of understanding lands on the reviewer. That isn’t a review any more. It’s the reviewer doing the original work, after the fact, without the context.

The logical endpoint is that I get my agents to review your agents, and no human understands any of it. It seems like, as an industry, we’re drifting towards being fine with that. I’m not.

Flip it around

I use these tools every day, and they make me far more productive. The problem isn’t the AI. It’s where the human sits in the loop.

Right now the flow often looks like this: the agent finds a problem, the agent writes the fix, and a human is asked to approve it. The human is a rubber stamp at the end.

I’d much rather flip it. Let the agent find the problem and write the ticket: what’s broken, where, and what it thinks is going on. Then a developer picks up that ticket and works through the fix with the agent. The agent can still do most of the typing, but a person is steering, questioning the approach, and pushing back when the solution is more complicated than the problem.

That one change makes a big difference:

  • Someone owns the code. A developer made the decisions, so there’s a person who can explain it, maintain it, and be asked about it later.
  • Someone understands the problem. Working through the fix means actually learning what was wrong, which is how engineers build knowledge of the system.
  • The solutions get simpler. A human who understands the problem is much more likely to say “hang on, can’t we just do this?” than an agent left to its own devices.
  • Reviews become reviews again. The author can answer questions, so the reviewer is checking work rather than reverse-engineering it.

Ownership is the point

In my last post I wrote about small teams of motivated engineers who understand the market, the users and the whole stack. That only works if engineers actually own what they ship. AI agents can make those teams dramatically faster, but only if they’re working with the engineers, not around them.

So my rule of thumb is simple: if no human on the team could explain a change without asking the agent, it isn’t ready to merge.

I’m curious how other teams are handling this. Are you seeing the same flood of agent-written PRs, and has anyone found a workflow that keeps people in the loop without slowing everything down?