The promise is always the same: delegate the building and productivity skyrockets. Offshoring promised it. AI coding assistants promise it now. The reality is also the same: specifying what to build takes almost as much time as actually building it, and underspecification produces surreal nightmares.
Simple Picture
You hire someone to build a bookshelf. You say “build me a bookshelf.” They build one that is three feet tall, has no back panel, and the shelves are two inches apart. Every dimension you failed to specify was filled in by their defaults, not yours. You realize that to get the bookshelf you wanted, you would have had to describe it in enough detail that you might as well have built it yourself. The only completely unambiguous description of the bookshelf is the bookshelf.
The Delegation Shift
Three forms of delegation — the stagiaire (intern), the offshore team, and the AI coding assistant — all produce the same transformation. The nature of work shifts:
- From doing to specifying
- From building to teaching
- From creating to verifying
Each shift is presented as a productivity gain. Each is actually a change in the type of work, not a reduction in its quantity. The person who used to write code now writes specifications. The person who used to build now explains how to build. The person who used to create now reviews what was created. And the new work — specifying, teaching, verifying — requires the same deep understanding as the original work, plus the additional skill of communicating that understanding unambiguously.
The Weinberg principle lands here: people seldom know what they want until you give them what they asked for. The specification, no matter how detailed, is always an approximation of intent. The gap between specification and intent is where all the nightmares live.
The Specification Trap
With offshore teams, the lessons came fast:
- You had to specify every failure state, because that was not something the remote team “just knew”
- You had to specify which libraries to use, how and where to log, which external APIs to check
- Even when everything conceivable was specified, the result could meet all acceptance criteria and also take the system down on every 57th run
- The demo would work perfectly while the implementation was built on data structures designed by H.R. Giger
The technical debt connection is direct: the code meets the spec but contains no understanding. The specification captured what, but not why. When the people who wrote the mental spec leave — taking all the refinements they made since — the code becomes a toxic asset. It works, but nobody knows why it works, and every change is a gamble.
The fog of work thickens: the further the builder is from the specifier, the more the specification must compensate for lost context. At the extreme, the specification must be so detailed that it becomes a programming language — at which point you realize that a completely unambiguous specification of a program is called a program.
The AI Version
AI coding assistants repeat the cycle at higher speed. The promise: describe what you want in natural language, and the AI builds it. The reality: natural language is ambiguous by nature, and the AI fills every ambiguity with its own defaults — which are drawn from training data, not from your intent.
The engineering algorithm applies with force: before asking an AI to build something, ask whether the thing should exist at all. The AI will happily build the wrong thing faster than you could build the right thing yourself. The constraint has shifted: the bottleneck is no longer coding speed but specification quality — and specification quality is bounded by the same human understanding that building required.
Dimwit / Midwit / Better Take
The dimwit take is “AI/outsourcing makes developers 10x more productive.”
The midwit take is “AI is just a tool — use it for the boring parts and keep the creative work.”
The better take is that the hard part of building software was never the typing — it was the thinking. Every delegation technology promises to eliminate the typing and discovers that the thinking cannot be delegated. The person who can specify unambiguously what to build is the person who already understands the problem deeply enough to build it — which means delegation works best for work that the delegator has already done before and worst for work that requires discovery. And discovery is where all the value lives.
Main Payoff
The pattern generalizes beyond software. Every time you delegate — to a team, to a tool, to a process — you are trading doing for specifying. The trade is worth making only when your specification skills exceed your doing skills by enough to justify the translation overhead. For novel, ambiguous, or discovery-oriented work, the translation overhead exceeds the doing — and the delegation produces worse results slower. The Peopleware principle circles back: the manager’s job is to make work possible, not to specify it into existence. And the best way to make work possible is to hire people who do not need specifications — people who understand the problem well enough to discover the solution themselves.
References:
- Byrne Hobart, Offshoring and AI Agents, The Diff