Coding was never the bottleneck
Coding agents work fast. Claude Code, Cursor, and Codex can multiply a single person's output several times over. So is the software industry as a whole speeding up by the same factor? The answer is surprising. It is not.
The founder of `.txt`, the open-source structured-generation library, tackled this paradox head-on in an essay published on April 29. The title: "The bottleneck was never the code." It opens with a personal experience — he handed Codex an experiment he'd been putting off for over a year, and got results back within a few hours.
Individual productivity has clearly exploded. So why isn't company-wide progress accelerating to match? The answer to that question carries weight for solo founders, team leads, and executives alike.
Brooks saw this fifty years ago
Fred Brooks's 1975 book The Mythical Man-Month is a classic of software engineering. He had a way of putting it.
Software, he said, is the residue left over after people negotiate what to build. Not that code doesn't matter — but code is the output of a harder task. The genuinely hard work is getting people in a room to agree on "what should we actually build?"
For the past fifty years, that residue — code — was so expensive that all our attention went there. Typing speed, language design, framework choices, IDE plugins, code review tools. Every one of them was a tool for driving down the cost of writing code.
With the arrival of coding agents, that cost has finally dropped far enough. And what was buried underneath has come into view: people struggling to reach agreement.
The new bottleneck: the ability to write specs
On a team where agents handle the implementation, what slows things down? The answer is specification — specs precise enough for an agent to take and execute.
The roadmap has to be written down. The acceptance criteria have to be written down. "What we actually want" has to be expressed precisely, as a test suite, a ticket, or a design document.
The original essay puts it exactly right: features get implemented at breathtaking speed, and engineers no longer wait on other engineers. They wait on the next well-crafted spec. The bottleneck shifts from the people who write the code to the people who decide what code should exist. In other words: to management.
The same logic applies to a solo founder. Claude Code can work eight hours straight, but you only get results in proportion to how clearly you defined, that morning, what should be built today. The faster the tools get, the more conspicuous slow decision-making becomes.
Jevons paradox comes for code
There's a paradox the 19th-century economist William Stanley Jevons discovered: when something gets cheaper, consumption doesn't fall — it rises. As coal efficiency improved, coal consumption actually went up, because coal became worth using in far more places.
Code works the same way. When code gets ten times cheaper, you don't spend a tenth of the effort on the same output — you spend the same effort on things that weren't worth building before. The prototype you skipped because it was "a waste of time" gets built in an afternoon. The internal tool nobody particularly needed gets built and then forgotten.
One line from the essay cuts to the heart of it: every vibe-coded product with twelve features is eleven features short of being great.
Steve Jobs's 1997 line gets quoted again: focusing is about saying no. That year, Jobs killed roughly 70% of Apple's product line, and the company that came back was a company that had learned how to subtract.
Working with agents makes this discipline harder, not easier. Everyone loves the thrill of shipping a new feature. With the cost of writing code near zero, the restraint not to build what shouldn't be built becomes more necessary than ever.
Context becomes gold
What do negotiation and agreement actually run on? Shared context.
Context is the raw material an organization runs on: a shared understanding of what we're building, why it matters, what's been tried, who decided what, and which parts are load-bearing versus vestigial. People accumulate it by osmosis — by sitting in the same room, reading the same Slack channels, debugging the same outage at 2 a.m.
Most of it never gets written down. When a senior engineer says "this will break the migration" in a PR review, she's drawing on context that exists in no document.
Agents can't do osmosis. They don't pick up context from being in the room, don't half-overhear planning meetings, don't carry memories of last quarter's outage. Whatever you fail to put into the prompt, the file tree, the tools, or explicit instructions, the agent simply doesn't have.
The essay nails it: without context, an agent produces a plausible answer to a slightly wrong version of the question.
This is the solo founder's particular challenge. In a one-person business, all the context lives in your head. When you work with an agent yourself, that context flows naturally. But the moment a second person joins — or the moment you return to the same task a few days later — that context is gone.
How agents change documentation
The problem is clear. Context has become the rate-limiting step, yet writing it down is the thing people are least inclined to do.
There's an old joke: "Real programmers don't document their programs." It was less a joke than a fact. Not writing documents nobody would read was perfectly rational.
Here's the interesting twist: agents read unreasonably well. Every PR comment, every closed issue, every commit message, every stale design doc, every Slack archive — they read it all and extract patterns nobody ever wrote down.
The system the essay's author is building at .txt demonstrates this: an agent that crawls the codebase, issues, PRs, and threads to assemble a knowledge base of implicit decisions, conventions, and the "why we did it this way." Other agents then draw on that knowledge base when they work on the code.
What gets extracted isn't "this module exists" but things like "this module is weird because the migration had to preserve the old behavior," or "this benchmark matters because a previous optimization quietly shifted the distribution."
The osmosis people used to do informally gets externalized into a form both agents and humans can read. Context-consuming agents, it turns out, need context-producing agents. And once that loop starts spinning, the organization ends up with a written foundation it could never have built on its own.
The new moat isn't technology — it's organization
Who wins the next decade? The essay's conclusion is unambiguous: not the companies with the best models or the best agent infrastructure, but the companies whose 50, 200, or 2,000 people can stay aligned around a shrinking set of decisions and produce more output per head.
This is a problem of culture and management. It always was.
Every previous generation of tooling made the same promise. IDEs, version control, CI, microservices, DevOps — all of them promised to solve the collaboration problem with better tools. In the end, every one turned out to be a multiplier on whatever organizational coherence already existed. If the organization was coherent, the tool amplified that. If it wasn't, the tool amplified the chaos.
Small teams get coherence for free. That's why the loudest agent evangelists are small teams — and within their own context, they're mostly right. Past a certain scale, coherence has to be built and maintained. And then the multiplier cuts sharply in both directions: good organizations get better, and bad organizations break down faster.
The essay's final insight is the real message of this piece: agents are overrated as a way to make individuals write code faster, and underrated as a way to make organizations externalize what they know.
What solo founders should take from this
The essay was written with companies of fifty or more in mind, but it speaks directly to solo founders too.
Start externalizing the context in your head sooner. Even a one-person business eventually sees the day a second person walks in. If you only start writing your context down then, it's too late. Building up your CLAUDE.md, your AGENTS.md, your design docs starting now is a gift to your future self — and to your future colleague.
Be wary of the pleasure of adding features. Claude Code will happily build you a new feature in an afternoon. Whether that feature ever deserved to exist is a separate question. The most expensive resource in a one-person business is time, and time spent on the wrong feature never comes back. The ability to say no becomes a solo founder's core competency.
Spend more time writing specs. If you skip the spec because "the agent will finish it in an hour anyway," what piles up is a stack of wrong one-hour deliverables. Thirty minutes on the spec plus thirty on implementation beats two hours of wandering without one.
And above all, maintain a coherent picture of what you're building. No tool can do this for you. That coherence is a solo business's real moat.
What becomes visible when code gets cheap
One insight from the essay stands above the rest. For the fifty years that code was expensive, our focus on it blinded us to everything else. The moment code got cheap, the real work buried beneath it came into view: people trying to reach agreement.
This isn't bad news — it's good news. The more powerful coding agents become, the more the differentiator shifts from writing code well to defining clearly what should be built. Making decisions explicit, putting context in writing, maintaining coherence. That is work no tool can absorb. It is human work.
The shift from the people who write code to the people who decide what the code should be — that change is happening right now, simultaneously, at organizations of every size and for every solo founder.
The bottleneck was never the code. For fifty years, it just looked like it.
