Skip to main content
  1. Posts/

The agent ran for twenty minutes

·1064 words·5 mins·
Table of Contents

Autonomous agent loops don’t remove the human from the work. They relocate you. When the agent runs unsupervised for twenty minutes, your leverage collapses onto two moments: the spec you wrote before it started, and the review you can actually do on what it handed back. The middle is gone. You used to sit in that middle and steer, and now you don’t, and that changes the job more than the productivity numbers admit.

This is the shape of 2026. If 2023 was code completion and 2024 was the rise of the AI IDE, this year is the autonomous loop: an agent that takes a task, runs its own execution cycle for many minutes, and returns a finished-looking result while you were doing something else. The industry is calling it agent engineering. The name that fits better is the disappearing middle.

Typing was never the bottleneck
#

I draft with a coding agent every day. I’m drafting this with one running in another pane. So I want to be precise about what actually changed, because two things people say about this moment are both a little wrong.

The first wrong thing: “It writes the code for you now.” It always kind of did. Autocomplete wrote the code. The IDE wrote the code. Typing speed stopped being the constraint years ago, and anyone who was honest knew it. The bottleneck was deciding what to build and confirming it was built right. The loop doesn’t touch the first half of that, which I’ve written about already: the fix is usually the spec, not the prompt. Vague in, vague out, at any level of autonomy.

The second wrong thing is subtler, and it’s the one I want to sit on.

The middle is where you used to catch drift
#

Interactive pairing had a property nobody named because it was free. You watched the work grow. A suggestion appeared, you accepted or rejected it, the next one built on that, and you were course-correcting continuously without calling it that. When the model started down a bad path, you felt it early, at line ten, before it had committed to the mistake across forty files. You had a memory of every intermediate decision because you were present for each one.

The autonomous loop takes that away. It runs for twenty minutes and hands you a large, plausible, finished-looking diff you did not watch grow. Nowhere in that diff is there a record of the three forks where it could have gone another way, the assumption it made about your auth model, the edge case it decided didn’t matter. It made those calls alone, and the diff presents them all with the same flat confidence, the load-bearing choice indistinguishable from the trivial one.

Reviewing that is a genuinely different skill than reviewing your own work, and a harder one. When you review code you co-authored, you carry a map of where the risk lives. You remember which part felt shaky, which shortcut you took at 4pm, which function you’d want a second pair of eyes on. That memory is the review. Reviewing an agent’s diff, you have none of it. You’re reading unfamiliar code that you nominally wrote, with no felt sense of where the author cut a corner, because there was no author in the way you mean it.

The skill you haven’t built yet
#

So the load-bearing muscle for 2026 isn’t prompting and it isn’t watching the agent type. It’s reviewing a large diff you didn’t co-author, at speed, on code you’re on the hook for, and finding the five percent that’s wrong without the memory that usually points you there.

Most of us have not built that muscle. We built the other one. Years of reviewing our own work, and reviewing pull requests from people whose intermediate reasoning we could ask about in Slack. The agent’s PR has no one to ask. This is adjacent to the re-checking discipline I’ve argued for before, watching the 5% the automation gets wrong, but it goes past it. That piece was about the habit of validating instead of eyeballing. This is about the specific difficulty of validating output whose construction you never saw, where you can’t even feel which part deserves the hard look.

Here’s the counter I take seriously, because it’s the honest one: the loop really is more productive. This isn’t nostalgia for the days of accepting suggestions one at a time. I’m not going back, and neither are you. The twenty autonomous minutes genuinely buy something real, and the agent clears ground faster than continuous pairing ever did.

But the time it saves has to go somewhere, and the somewhere is review. That’s the trade the productivity pitch quietly skips. You don’t get to bank the twenty minutes. You spend them reading a diff more carefully than you’ve ever had to read one, with less context than you’ve ever had, on work you’re accountable for as if you’d written every line. If you pocket the time instead of paying it into review, you didn’t get faster. You just moved the bug downstream and put your name on it.

What this changes about the work
#

The handoff and the review are the whole game now. Everything upstream of the loop is specification: deciding precisely enough what you want that an agent running alone won’t wander. Everything downstream is verification: reading what came back with the assumption that plausible and correct are different words. The part in between, the part that felt like the work, the flow of watching it come together, that part is being automated, and I don’t think we get it back.

The engineers who do well in this phase won’t be the ones with the cleverest prompts. They’ll be the ones who can pick up a forty-file diff they’ve never seen, that they technically authorized, and know within minutes where the bodies are buried. That’s a taste-and-judgment skill, it’s teachable, and almost nobody is practicing it on purpose yet.

I’m trying to. When an agent hands me a big diff, I don’t skim it for the shape and approve. I read it as if a stranger wrote it and I’m the last line of defense, because on that diff, I am. The agent ran for twenty minutes without me. The twenty minutes it saved are the twenty I now owe the review.

Chandler Thompson
Author
Chandler Thompson
I lead engineering teams and coach the people who run them. This is where I write down what actually worked.

Related