In the first half of 2025, METR ran the experiment everyone doing this work should read before forming an opinion about their own productivity. Sixteen experienced open-source developers, 246 real tasks on repositories they knew well, randomly assigned to use AI tools or not. The result was a 19% slowdown when they used them. The developers had forecast a 24% speed-up going in. After finishing — after actually being slower — they estimated they had been about 20% faster.1
I want to be careful with this, because it is the most quoted study in the field and it is quoted badly in both directions. The authors are explicit about what it does not show: not that AI fails to speed up developers generally, since their sample may not represent typical developers; not that the tools are ineffective in other domains; not that better usage strategies or more familiarity would not produce a speed-up in the same setting.1 It is one careful study of experienced people on mature codebases. It is not a verdict.
But the perception gap is the part that survives every caveat, and it is the foundation of this essay. Whatever the true effect on your work, your felt sense of it is not evidence. A group of skilled engineers experienced a slowdown and reported a speed-up. That is not carelessness; it is what the work feels like from inside. Delegation feels like progress, because you are always doing something and never waiting.
Which means the first discipline of this craft is refusing to trust the thing you most want to trust.
The day is not typing any more
Strip out the tooling debates and what is left of a senior engineer's day is a sequence of decisions, most of them made before any code exists and the rest made about code someone else produced.
What am I delegating, and in what units. What does correct look like, stated precisely enough that I could tell. What do I check, given that I cannot check all of it. And the one that separates people who are good at this from people who are fast at it: when do I stop delegating and do it myself.
None of that is new work exactly. It is the work that used to be squeezed into the gaps around implementation, and implementation is what left. The skill did not disappear. It moved to the part of the job that was always there and was never the bottleneck.
Decomposition is the whole game
If I had to name the single technical skill that most determines whether someone is effective with agents, it is decomposition — and it is not the same activity that word used to describe.
Decomposition used to be architecture: an occasional, high-ceremony exercise where you divided a system into modules and then lived inside that division for months. Now it is a per-task, hourly activity, and the criterion has changed. You are not dividing work into pieces that are logically coherent. You are dividing it into pieces where you can state the done-condition before you start.
That is the test. If I cannot say what correct output looks like for a unit of work, delegating it is not delegation, it is hoping. And hope produces exactly the failure mode I described in the review essay: something plausible, well-formed, locally impeccable and globally wrong, arriving faster than I can evaluate it.
The practical consequence is that I spend real time up front on something that looks, to anyone watching, like procrastination. Writing down what I expect. Deciding the boundary. Occasionally discovering during that exercise that I do not actually understand the problem yet — which is the most valuable thing the practice produces, and it would have been discovered three hours later and more expensively under the old shape.
[ PLACEHOLDER: how you actually decompose — the size of unit you delegate, whether you write the done-condition as a test, a sentence, an interface, or something else, and one concrete example from Gigabit work. This is the section that decides whether the essay reads as lived or as reasoned. ]
Knowing when to take the keys back
The hardest judgement in this job, and the one I am least able to teach, is when to stop delegating and open the file myself.
The signals I have learned to notice are unglamorous. When I cannot state what correct looks like, I stop, because I have already failed the test above. When the third attempt is a variation rather than a correction — when the output is moving sideways rather than converging — I stop, because that pattern almost never resolves itself with a fourth. And the one I catch myself in most often: when I am editing the prompt instead of thinking about the problem. That is a tell that I have substituted a tractable activity for the hard one, and it can absorb an entire afternoon pleasantly.
The reason this judgement matters more than it sounds is that its failure mode is invisible. Persisting with delegation past the point of usefulness does not produce an error. It produces a slightly worse outcome, somewhat later, with no signal that a different choice was available — which is, once again, the perception gap doing its work.
[ PLACEHOLDER: your own stopping heuristics, and ideally one instance where you got it wrong in each direction — took the keys back too early on something an agent would have handled, and persisted far too long on something you should have written yourself. The second is the more useful story and the more uncomfortable one. ]
The thing that erodes
There is a cost to this way of working that I think is real and that I have not resolved.
A randomised study of developers learning an unfamiliar asynchronous programming library found that heavy AI reliance impaired conceptual understanding, code reading and debugging ability, without delivering significant efficiency gains on average. Participants who fully delegated the coding did show some productivity improvement — at the cost of actually learning the library.2 The authors' summary is the line I keep: AI-enhanced productivity is not a shortcut to competence.
Notice which skills those are. Conceptual understanding, code reading, debugging — precisely the capacities that make someone worth having on a hard problem at two in the morning. The tool erodes the exact abilities that qualify you to supervise it.
The more useful half of the same study is that this is not automatic. The researchers identified six distinct interaction patterns, and three of them — the ones involving active cognitive engagement rather than wholesale handoff — preserved learning outcomes even with AI available.2 So the variable is not whether you use these tools. It is whether you are still thinking while you do.
Which gives a practical rule I try to hold to, and fail at under deadline: delegate what you already understand; do yourself what you are trying to learn. Inverted, it is a very efficient way to become someone who ships things they cannot explain.
This also worries me at the level of a team rather than a person. If the struggle is what produces seniority, and juniors are handed tools that remove the struggle, the pipeline that made senior engineers stops running — and the supervision this whole model depends on is a senior activity. I do not have a good answer. I am fairly sure "hire only seniors" is not one, since it assumes a supply that this dynamic is busy consuming.
[ PLACEHOLDER: how Gigaverse handles this in practice — what you deliberately have people do without agents, whether there is a rule, and whether it survives contact with a delivery deadline. If the honest answer is that you have not solved it either, that is worth saying plainly; almost nobody writing about this admits it. ]
What I would tell someone starting
Three things, in the order I think they matter.
Measure something. Not because the measurement will be good, but because the alternative is your own sense of velocity, and the study at the top of this essay is what that is worth. Even a crude count of what you shipped and what came back beats a feeling.
Get good at stating done-conditions. It is the highest-leverage habit available and it is almost entirely a writing skill. If you cannot express what correct means, no model and no harness will rescue you.
Keep a domain you do by hand. Not for sentiment — as maintenance. Pick the part of the stack where your judgement is load-bearing and keep your hands in it, because that judgement is what you are selling and it is depreciating quietly while you supervise.
The honest caveat: this is a description of how I work rather than a claim that it is how anyone should. The two studies I lean on are careful and narrow — sixteen developers in one, a single unfamiliar library in the other — and both sets of authors are clearer about their limits than most people citing them. My own evidence is a small number of years, one team, and the same unreliable instrument I spent the opening warning you about. Where this essay is confident, it is confident about the shape of the problem: the perception gap is real, decomposition is the binding skill, and the abilities that erode are the ones you supervise with. Where it describes practice, it describes mine, provisionally, and I expect to revise it.