I recently watched a software developer retainer drain to zero. What I got for it was a calendar of meetings, a stack of design-session notes, and a fifteen-page design document. No working software. No tests. No executable specification I could hand to a coding agent and watch it build. Proof of time, not proof of work.

The document was not bad, exactly. It was readable, it had diagrams, it described the system in earnest prose. It was also too vague to do anything with. I could not point a coding agent at it and get a running increment, and I could not point my own engineers at it without another round of the same conversations it claimed to summarize. I had paid for the meeting that produced the document that built nothing.

That is the moment this post is about, and it is not really a complaint about one engagement. It is the enterprise mirror of an argument I made last week about small law firms.

The Thing Protecting My Partners Is My Own Slowness

In Your Size Was Always the Advantage I told small practices that being small was an edge in the AI transition, and that the edge was perishable because their clients were moving faster than the firms were. Flip the seats and the same structure appears on my side of the table. My implementation partners have an advantage too, and it is almost entirely the slowness of the enterprise that buys from them.

Enterprises are slow on purpose. Change advisory boards, procurement cycles, architecture review, the regulated software development lifecycle I described in Six Primitives for a Code Factory: these are not inefficiencies nobody got around to fixing. They are the controls that let a regulated institution operate at all. A consultancy that has learned to navigate them holds real, hard-won value. But that value is a moat made of my friction, not of their output, and friction is exactly what the AI transition erodes. The partner billing for the time it takes to move through my gates is selling me the cost of my own slowness. The day I move faster, that line item has nothing underneath it.

So the advantage is real, and it is perishable, and the person deciding how long it lasts is me.

A Document an Agent Cannot Build From Is a Failed Artifact

Start with the deliverable, because the deliverable is where I first felt it. A fifteen-page design document that cannot drive a coding agent is, by the emerging standard of the industry, an incomplete artifact. The whole field is converging on the idea that the valuable unit of work is an executable specification, not prose about one.

GitHub shipped Spec Kit for exactly this: specifications that generate working implementations, structured so more than thirty coding agents can build from them. AWS built Kiro around the same premise, an IDE where the spec is the unit of work and the code is generated and kept in sync with it. Sean Grove of OpenAI put the number on it in his talk “The New Code”: the code itself is maybe ten to twenty percent of a developer’s value, and the other eighty to ninety percent is structured communication, understanding the problem and writing it down precisely enough that the right thing gets built. Andrej Karpathy has been making the broader version of this argument for two years, that natural language is becoming the programming layer and a clear specification is the program.

Read against that standard, my fifteen pages bought me the ten to twenty percent and skipped the part that mattered. I paid for prose and got none of the structured communication that would have let an agent, or a junior engineer, or anyone, build the thing. And the irony is that I already make this argument to myself. In Architecture Is the Prompt I wrote that the architecture corpus is the context agents read, and in The Bottleneck Was Never the Code I wrote that you should not invest in a workflow you cannot describe in one sentence of plain English. The deliverable test is the same test: hand it to a coding agent. If working software comes out, you bought a specification. If nothing comes out, you bought a PDF.

Services Are Becoming Software, and the Retainer Knows It

The reason the old deliverable persists is that the business model underneath it has not been forced to change yet. That is changing now, and the venture world has a name for it: services as software.

Foundation Capital framed the shift most clearly. The prize is not the roughly two hundred billion dollars a year companies spend on SaaS; it is the four point six trillion they spend on salaries and outsourced services. The distinction they draw is the one my retainer failed: “In the software business, a company may sell access to its platform or tool, but customers are still responsible for using that tool to achieve the desired outcome. In the services business, responsibility for achieving the desired outcome sits with the company selling the service.” My retainer sold me access to people’s time and left the responsibility for the outcome sitting with me. Sequoia makes the same case from the other direction, that for every dollar spent on software, six are spent on services, and that the work budget, not the tool budget, is the real target. Andreessen Horowitz calls it turning capital into labor: capital buys compute and a small team, and out comes work that used to require a much larger one. Even Satya Nadella, as reported from the BG2 podcast, has said the business-logic tier collapses into agents.

This is not theory the services firms can wait out. Accenture told its own people to use AI or leave, and is exiting more than eleven thousand staff where reskilling is not viable. TCS announced cuts of around two percent of its workforce, more than twelve thousand jobs, citing delayed client decisions and soft discretionary spend. The pyramid that bills leveraged junior hours for mechanical work is under the same pressure BigLaw’s is, for the same reason. And the cautionary half is real too: when Klarna swung hard at replacing software and headcount with AI, it ended up replacing tools with other tools and rehiring people where quality fell short. The transition is happening. It is not clean, and it is not free.

Pay for What Ships, Not for the Clock

If services are becoming software, then I should buy them the way I buy software outcomes, not the way I rent hours. The consulting world is already repricing itself around this. McKinsey now earns roughly a quarter of its fees from performance-based arrangements, where the client names an outcome and the fee rides on delivering it. Salesforce priced Agentforce per conversation rather than per seat, charging for work performed instead of access granted. The billable hour is cracking under a simple arithmetic that consulting itself has noticed: you cannot bill sixty hours for the deck AI now produces in six.

This is the structural pressure I wrote about in The 48-Hour Repricing, where delivery-only value dies and any pricing model that counts human hours as the unit of value is exposed. The buyer-side move is to stop paying for the clock and start paying for artifacts that ship: a merged pull request, a passing test suite, a deployed increment, an executable specification a coding agent can build from. Those are things I can verify. A timesheet and a design document are things I have to take on faith, and faith is what drained the retainer.

The Fork, and Why I Am Not Just Ripping It Out

So here is the fork I actually face: keep funding the retainer, or build the case to bring the work in-house and fund a coding factory worth owning. The honest answer is not either-or, and it is not a victory lap for in-house. It is a barbell, and the realism matters because I have a small team.

Build the differentiated core in-house. The work that depends on the domain, the data, the risk model, the judgment about what is worth building, that is where an owned harness compounds. This is the whole argument of Six Primitives for a Code Factory: the engine is rented, the harness is the moat, and a small team can own the harness because you build the loop once and it runs on every ticket forever. And it is the argument of Judgment Is the New Moat: when execution gets cheap, the scarce thing is knowing what to build, which is exactly the work I cannot and would not outsource.

Then keep partners, but only for the right work and only on the new terms. Commodity build-out and surge capacity are fine to buy. What I will not buy again is time billed against my slowness with a prose document at the end. The partners who come with me are the ones who turn their deliverable into something an agent can build and price it against what ships. The ones who cannot are selling the meeting that produced the document that built nothing, and I have already paid for that once.

What I Cannot Promise, Including to Myself

The honest part is that in-house is not automatically faster, and I should be as skeptical of my own optimism as I am of the retainer’s invoice. The strongest evidence here cuts both ways. METR ran a randomized controlled trial with experienced open-source developers on mature codebases and found they were about nineteen percent slower with early-2025 AI tools, while believing they had been roughly twenty percent faster. That felt-versus-measured gap punctures the consultant’s “we deliver with AI now” pitch and my own “we will just build it ourselves” confidence in the same stroke. DORA’s research points the same way: AI lifts individual productivity while, without small-batch discipline, it can worsen delivery throughput and stability. The tool is not the win. The discipline around it is.

Which is the same lesson on both sides of the buy decision. A partner with AI and no discipline ships faster-looking work that breaks more. An in-house team with AI and no discipline does the same, on the in-house payroll. With a small team I cannot build everything, so the actual work is the judgment about what to build, what to buy, and which partners are worth keeping. That judgment does not come in a fifteen-page document.

The Slowness Was the Whole Moat

The advantage my implementation partners have over me is my own slowness, and I am spending this year dismantling it, deliberately, with a factory and a standard for what counts as delivered. The partners who see that coming are already changing what they hand me and how they charge for it. The ones who do not are betting that my gates stay slow forever. That is not a bet I plan to let them win.

The retainer ran dry and left me fifteen pages. The next thing I fund, from a partner or from my own team, has to leave me something that ships.

---

The companion reads are Six Primitives for a Code Factory, the in-house build this post argues for, and Your Size Was Always the Advantage, the same perishable-advantage argument from the other side of the table.

If you run an implementation practice that has already made this turn, or you are a buyer who has found a way to pay for what ships instead of the clock, I want to compare notes. Find me on X @orestesgarcia or LinkedIn /in/setsero.