Notes on Becoming Useless

Last week, a product manager I’m working with on a side project asked me to review 13 pull requests. We are in 2026, so of course, the PRs weren't written by a developer but by an AI agent.

I reviewed every one of them. Went through the diffs, checked the logic, looked at the test coverage. Our static analysis, security scanning, and agent-driven testing had already flagged and resolved the issues I'd normally catch.

I finally approved them, because that's the process.

At the end of the week, she came to me annoyed. The review process was broken, she said. The delays were too long. Every PR sitting in my queue was breaking her flow and making it difficult to be efficient. She was right.

And then, talking it through, we arrived at the uncomfortable realization together: I hadn't added any value to a single one of those reviews. The automated tooling had already done the work. I was just the bottleneck. Or maybe my ego was just a bottleneck.

So we decided to build an agent that auto-approves PRs based on risk level. If it's low-risk, it merges. If it's high-risk, it routes to a human.

I wrote about this in December, in my piece on self-driving software. The thesis was that during the first half of 2026, we'd start seeing autonomous product operations: systems where customer requests are analyzed, prioritized, built, tested, and evaluated without a human driving every step.

So I'm not surprised this is happening. This is my research goal for 2026: become one of the best in the world with this. But knowing something is coming and having your PM tell you to your face that you're the bottleneck, that's when the abstraction becomes concrete and you feel the ground shift.

I want to work through what I think it means.

The economics of the gate

Code review exists because shipping code is risky and developers are expensive. A pull request is a gate: before anything goes live, a human reads it, thinks about it, and gives permission. That tradeoff made sense for decades.

But gates have costs. A developer writes a feature. It sits in review for hours. The reviewer context-switches away from their own work. There's back-and-forth. By the time it merges, the developer has moved on, attention fractured. We've all accepted this tax as the price of safety.

What I'm observing now: the agents reviewing code are more thorough than I am. They don't context-switch. They don't get tired. They don't batch reviews because they're busy with something else. 

The old flow (feature request, developer codes, waits for reviewer, reviewer interrupts their work, reviews, approves, developer fixes, merges, deploys) takes days and sometimes weeks of elapsed time. The new flow (feature request, agent codes, static analysis, security scan, automated tests in headless browsers, auto-merge, deploy) can take about fifteen minutes.

But the more interesting effect is on granularity. When each review is expensive, you batch work into large PRs. When the gate is free, you ship tiny changes. Smaller PRs mean less risk. If something breaks, you know exactly what caused it.

The thing I didn't expect

The speed improvement is obvious, and frankly, predictable. That was the whole point of the Coding capability I described in December. What I didn't anticipate was the impact on ownership of the software.

My PM didn't need to translate her ideas into developer-speak. She didn't need to play telephone between what she wanted and what got built. She used an agent, and the agent built it. The bottleneck wasn't the coding anymore. It was me, sitting in the middle, reviewing work that had already been validated.

I've been thinking about this a lot. Every person in an organization who has an idea (support, operations, business analysts) has been locked out of building software. Not because they lack intelligence, but because the path from "I want this" to "this is deployed" was complex, requiring fighting for resources and a lot of coordination effort.

When the cost of merging a PR drops to near zero, when testing is automated, and when guardrails catch the risky stuff and route it appropriately, that intermediary layer thins out. Your PM tests a hypothesis directly. Your support team pushes a small fix. Your founder prototypes an idea without filing a ticket.

I'm not sure we fully understood what this does to org design yet. I'm still working through it.

The agent we built

After that conversation, we designed an auto-approval agent based on risk classification.

Here's how we've structured it. Database changes get a security-focused agent review plus human approval: that's the expensive gate, and it should stay expensive. Infrastructure, API contract and business logic changes still require human eyes (for now). Everything else auto-merges.

This will break production at some point. I'm looking forward to that, because that's where the real learning happens. I'm committing to documenting what fails and sharing it publicly. 

What's next

As of this week, the agent is live. No human in the loop at all for qualifying changes. We'll see how it goes.

A few things I'm watching. 

1. Quality over time: the agent-reviewed code shipping now is solid, but I'm running on a small sample. I want to see what a few weeks of this looks like before drawing conclusions.
2. Where the human gate remains essential beyond the obvious ones (database, infrastructure):  I don't have a clear picture yet.
3. And the org design question that keeps nagging at me: if non-engineers can ship code, what does that do to team structure? To hiring? How do we define the role of a software developer?

No answers yet. Just observations from the field. More to come as things break ;)