What’s the ultimate goal of agent development?
To stop developing.
It sounds like a word game, but I mean it. Getting myself out of the development loop, participating in development less and less. The point isn’t having something else write the code; it’s that I disappear entirely from that repeating execution seat. That’s the sense in which I use the word “automation.”
And getting there takes one thing: separating what’s my job from what’s the agent’s. When I actually drew that line, my seat turned out to be at the start and the end of the loop.
Why the start needs a human
At first I figured setting a goal was enough. It didn’t work that way. Drafts I delegated with only a direction came back generic; sessions given a goal with no spec drifted off course midway. I covered this at length in a piece about how every skill eventually converges on the same shape, but the gist is this: an agent is only as smart as the context a human has set up for it. Starve it of context, and it makes up something plausible-sounding.
Building that context is my job at the start. It narrows down to two things: requirements and decisions.
Requirements mean pinning down, in a document, what to build, what the constraints are, and what depends on what. It’s the map I hand the agent. Decisions mean settling the hard-to-reverse choices ahead of time: which stack to use, how to structure storage. Leave those fuzzy and let things run on auto, and even a 0.5% miss gets inherited by everything built on top of it. The cost of debugging that later ends up bigger than whatever the automation saved.
One more thing goes on top: an exit condition per item, deciding what has to pass for it to count as done. With that in place, the agent doesn’t end on “I think it’s done”; it ends when the condition passes, and I can walk away trusting that condition. The rule I wrote down while drafting a myWiki build plan was:
“Anything you can decide inside the fence is yours to decide autonomously. Anything outside the fence, or anything that can’t be undone, is mine.”
Requirements pinned, decisions made, exit conditions attached. Once those three are ready, execution goes to a goal run. From there, the loop belongs to the agent.
Why the end needs a human
When the loop finishes, a result comes out. That’s my second seat.
I once left this seat empty and it broke me. It was while building myWiki: I skipped running tests and just kept the agent building, unattended. Output piled up, I lost track of where things actually stood, and meanwhile I kept wanting to change the requirements. Call it accumulated debt. I ended up taking three days off.
So passing the exit condition doesn’t mean it’s over. I review what came out, check whether the direction still holds, and adjust when it doesn’t. This part still needs a human for now. Drafts still need a fair amount of my review, and I still re-steer the direction all the time.
Needing review doesn’t mean grabbing every result and fixing it by hand, though. That’s not automation, that’s automating the supervision. Only the things that need judgment come up to me, and judgment is all I do. Some things do surface mid-run: decisions the agent can’t make, irreversible ones that are mine, stop the loop and escalate. So strictly speaking it’s the start, the end, and occasionally the middle. But I’m out of the repeating execution itself.
Draw the boundary, set the priorities
So the picture is this: I’m at the start and the end, and the loop runs in between.
Draw that boundary wrong and both sides break. Put an agent where a human should sit, and quality collapses. Put a human where an agent should sit, and productivity tanks. If I’m writing every draft myself or manually running each plan item by hand, I start wondering what the point of automation even is.
Once the boundary held, my role flipped. I used to type every keystroke myself; now the agent executes and only the judgment calls reach me. From executor to manager. Several threads run at once in a single day, and the time I’m actually holding onto is small.
Saying I’m fully out of the loop would be premature. The review and the steering at the end are still mine. But draw the boundary well, decide what to hand over first, and bit by bit I think I get further out of the development loop. Right now I’m widening the space between the start and the end, little by little.