There are two ways I pair with an AI coding assistant, and for most of a year I could only have told you which one felt faster, not which one was. One afternoon in June I let an agent rewrite a 300-line module in about a minute, then spent the next two hours cleaning up after it. The size of that gap, and the fact that I had been ignoring it, is the whole reason I sat down to write this.
By driving I mean keeping my hands on the code. I write most of it, and the model works at the scale of a line or a function: a completion here, a "what's the signature for this API" there, a second read on something I already wrote. By delegating I mean the opposite posture. I describe a whole task, hand it off, walk away, and come back to review a diff I did not write. Same assistant, same me, same afternoon. Two completely different relationships to the code that comes out the other end.
TL;DR
- Delegating a whole task to an agent is front-loaded speed and back-loaded cost. The diff lands in seconds, but the work just moves downstream into review, and review is exactly where the model's wrong assumptions hide. Driving is the reverse: slow to type, cheap to trust.
- The axis that actually decides which one is faster is not task size. It is verifiability. I delegate when I can check the result faster than I could have written it, and I drive when checking is as expensive as authoring. The rest of this is me arriving at that one sentence the slow way.
What does "faster" even mean here?
The reason I could not answer the speed question for a year is that I was conflating two different clocks.
There is the clock that runs while the code appears. By that clock, delegating wins every time and it isn't close. I type three sentences of intent, and forty seconds later a diff touches six files. Driving cannot compete with that, and my nervous system knows it: a big diff scrolling past feels like progress in a way that writing one careful function never does.
Then there is the clock that runs until the code is actually correct and I trust it. That clock includes reading the diff, catching what the model quietly assumed, discovering the integration bug three days later, and re-explaining the constraint it ignored the first time. On that clock the ranking often flips, and the flip is invisible in the moment because the two clocks report at different times. Delegating bills you now and charges you later. I had been reading only the first invoice.
So the honest version of "which is faster" is a question about the second clock, and the second clock is dominated by one thing: how long it takes me to verify the output.
The two postures, side by side
Here is the comparison after tracking it deliberately across a few dozen tasks this spring, in a solo iOS codebase with no team to absorb the review load:
| Driving | Delegating | |
|---|---|---|
| My role | Author, model assists | Reviewer, agent authors |
| Feels fast? | No | Yes, dangerously so |
| Where the time goes | Typing, up front | Review and rework, after |
| Mental model of the code | I hold it the whole time | I have to reconstruct it |
| Best at | Tasks where checking is as hard as writing | Tasks I can verify at a glance |
| Worst failure | I'm slow on work a model could have done | A wrong assumption ships past a shallow review |
| Cost visibility | Obvious and immediate | Hidden and deferred |
The row I care about most is the last one. Driving fails loudly: I feel every slow minute, so I never over-trust it. Delegating fails quietly, and quiet failures are the expensive kind.
Where delegating clearly wins
When the task is cheap to verify, delegating is not just faster, it is obviously the right call, and I have stopped feeling clever about driving through work like this.
A new isolated SwiftUI settings screen is the clean example. The correctness is visible: I run it, I look at it, I tab through the fields. If the agent got the layout wrong I see it in five seconds, and the cost of being wrong is a re-render, not a corrupted file. Scaffolding a parser with a table of example inputs and expected outputs is another, because the examples are the check. So is a mechanical refactor, renaming a concept across forty call sites, where the compiler is a far better reviewer than I am and the agent is faster at the typing than I will ever be.
The pattern under all three is the same. The output carries its own test. I can look at the result and know it is right faster than I could have produced it, so handing off the production is pure profit. This is most of the surface area of a normal codebase, and pretending otherwise, insisting on writing every line by hand, is just craft nostalgia with a time cost.
Where driving quietly wins
Then there is the other kind of task, where the code is not the expensive part.
The expensive part is noticing the one wrong assumption, and you only notice it if you were already holding the whole model in your head. My Outbox is the case that taught me this. It is a small offline-first queue that retries failed sends, and I have written before about how carefully it has to behave when the network flaps and the app is backgrounded mid-flush. When I delegated a change to its retry path, the agent produced clean, plausible, well-named code that added jitter to the backoff exactly as I asked. It also, without mentioning it, moved a state write outside the lock that was the only thing keeping two retries from waking on the same tick.
That is not a bug you catch by reading a diff for style. You catch it by having spent a week inside the concurrency model months ago and feeling the wrongness before you can even articulate it. Reviewing that diff cost me more attention than writing the change would have, because to review it properly I had to rebuild the exact mental model that driving would have kept warm the entire time. The same held for the code that appends a line to another app's iCloud folder, where a subtle mistake in the coordinated-write path is silent until someone's note goes missing.
For that class of work, delegating does not save time. It just relocates the hard part from a place where I am strong, authoring with the model in my head, to a place where I am weak, spotting a buried assumption in someone else's plausible code.
So what is the actual rule?
For a long time I thought the axis was task size: small things by hand, big things to the agent. That is exactly backwards, and it cost me to learn it.
The real axis is verification cost. Delegate when you can check the result faster than you could write it. Drive when checking is as hard as writing. Task size barely matters; a 300-line SwiftUI view can be cheaper to verify than a nine-line change to a lock. What I am really doing when I choose a posture is comparing two numbers I can now feel without measuring: the cost to produce, and the cost to check. When check is much less than produce, I hand it off and don't look back. When check approaches produce, I keep my hands on the wheel, because the model's speed is buying me nothing I can safely accept.
This is also why the fashionable framing, "just get better at prompting and you can delegate everything," misses the point. The bottleneck was never how well I could specify the task. I can specify the Outbox change down to the last detail, and the review is still the expensive part, because an airtight spec does not make a subtle violation of it cheap to detect. The limit is verification, not instruction. It is the same reason I keep context, not prompts, at the center of how I work with a model: the leverage is in what the model and I can hold in common, not in the wording of the ask.
The trap I keep falling into
Knowing the rule does not make me immune to it, and I want to be honest about that rather than end on a tidy law.
The pull toward delegating is not really about speed. It is that a large diff feels like accomplishment, and driving feels like labor, and on a tired afternoon I will reach for the thing that feels like accomplishment even when the task is one I should be holding myself. I have shipped a quiet bug this way more than once, each time on a day when I let the good feeling of a fast diff stand in for the boring question of whether I could actually check it. The tell, when I catch it in time, is that I am about to approve a diff I could not have written, in a part of the system where being wrong is expensive. That specific combination is my signal to stop, close the diff, and drive.
So the two-way choice has become a one-question habit. Before I accept a handoff I ask whether I can verify this more cheaply than I could have built it. If yes, the agent keeps the work. If I hesitate, the hesitation is the answer, and I take the wheel back.
A few questions I keep getting
Isn't this just "use AI for boilerplate"? Close, but boilerplate is a proxy, and a leaky one. Some boilerplate is expensive to verify, such as security-sensitive glue, and some novel code is trivial to verify, like a pure function with obvious outputs. Verification cost is the real variable; "boilerplate" is just the case where it is usually low.
Doesn't delegating more make you worse at the hard parts over time? It is my honest worry. My hedge is that the hard parts, the ones where checking is as costly as writing, are exactly the ones the rule tells me to keep driving. If the rule holds, I stay sharp precisely where sharpness is load-bearing and offload only where it isn't.
Where does an agent's autonomy fit? Same axis, higher stakes. The more autonomously it runs, the more code accrues before I review, and the more verification debt piles up if I can't check it cheaply. Long autonomous runs are wonderful for verifiable work and quietly dangerous for the other kind, for exactly the reasons above.
The open question I actually want answered
Here is the thing I am still missing, and it is specific. When you delegate a real task to an agent, what is the single check you run before you trust the diff? Not "I read it carefully," but the concrete move: the test you write first, the invariant you assert, the one file you always open, the question you ask the model about its own output. My whole approach now rests on making verification cheap, and I am fairly sure the people who delegate well have a verification move I haven't stolen yet. I would rather learn yours than defend mine.
Simple Memo is the one-person iOS app I make: type a line and it lands in your email a second or so later, so the thought is caught before it evaporates. I post here every few days about what shipping solo keeps teaching me, this piece included. What I'm building lives at simplememofast.com.
Top comments (0)