Marc Andreessen says software is about to eat the world much faster. I think he is right about the direction and early about the timeline, and I think almost every engineering organization is about to discover that the constraint was never typing.
Yesterday Marc Andreessen published Investing in Cognition, posted on X under the title “Software is about to eat the world much faster.” It is a sequel to his 2011 essay, and the argument is compact. Technology’s share of market capitalization among the ten largest businesses in the world went from 31.5% to 94.4% in fifteen years. That happened while roughly one in 300 people on earth wrote software, and every line of it came out of a human hand. His line for what comes next: “It is about to eat the world at the speed of compute.”
Then the evidence. Devin went from writing 13% of Cognition’s production code to more than 90% in a year. Mercedes-Benz compressed an eight month COBOL migration into eight days. Rivian raised test generation velocity tenfold. At Itau, 70% of security vulnerabilities are remediated automatically. Scott Wu’s framing is that engineers move from bricklayer to architect, trading the manual labour of assembly for the design of systems.
Aaron Levie made the demand-side argument the same day, and it is the one I find hardest to disagree with: lower the cost of code and we will simply do far more with it, which means, in his words, “we need more of them, not fewer.”
I have spent nine years building measurement infrastructure for engineering organizations. So my reaction to all of this is not disagreement. It is a specific worry about what happens between the capability and the outcome.
The historical pattern holds. Compilers were supposed to shrink the profession. So was open source. So was the cloud. Each one lowered the unit cost of software and each one was followed by an expansion in demand that absorbed far more engineers than it displaced. Cheaper code has always meant more code, because the backlog of things worth building has never once been the binding constraint.
The Jevons logic applies cleanly here. There is no company I have ever worked with that had run out of things it wanted built. Every engineering roadmap I see is a triage document. When the cost of producing a change collapses, the set of economically viable changes expands enormously, and the previously uneconomical use cases are not marginal, they are most of the list.
So I think the direction is right, and I think the sceptics who read 90% agent-written code as the end of the profession are making the same error people made about compilers.
13% to 90% in twelve months is a remarkable figure. It is also Cognition measuring Cognition: an agent company, with an unusually strong engineering culture, deploying its own product against its own codebase, and instrumented well enough to produce the number in the first place.
Figure 1. Cognition’s reported trajectory for agent-authored production code. The figure that matters more is the one your own organization would produce if asked the same question this afternoon.
Ask a Fortune 500 engineering organization what share of merged code was agent-authored last month, broken down by service and by autonomy level, and you will not get an answer. You will get a licence count. That is the whole gap between an essay about the future and a plan for next quarter.
This is the same problem Anthropic’s economists modelled at national scale last week in their 2030 scenarios: capability runs ahead of adoption, and the interesting variance sits in the gap. What is true of the economy is true of a codebase.
Here is my central claim. The SDLC was designed around a scarcity that no longer exists.
Every stage of it, and every metric we built on top of it, assumed that producing a change was the expensive part. Sprint planning rations engineer-weeks. Estimation prices typing. Code review is sized for the volume one human can emit. Throughput metrics count commits and pull requests because those were proxies for effort.
Remove the scarcity from one stage and you do not get a faster pipeline. You get a queue.
Figure 2. Schematic. Generation capacity has moved by an order of magnitude. Review and verification capacity has moved by roughly nothing, because both are still gated on human attention.
This is what I see in the data across engineering organizations that have adopted agents aggressively. Pull request volume climbs. Merge time climbs with it. Review latency stretches. Batch sizes get bigger because an agent has no reason to keep a change small. Six weeks later, incident volume and rework tick up, and by then nobody connects the two, because the throughput dashboard is green.
The cost of writing code has collapsed. The cost of being sure about code you did not write has not moved at all.
Verification is now the marginal cost of software. Everything else is approaching free.
That single sentence reorganizes the economics of an engineering organization. If generation is free and verification is expensive, then every investment that used to go into helping people write code faster should now go into helping people establish confidence faster: test infrastructure, evals, deterministic checks, observability, blast-radius controls, provenance on machine-authored changes, and review tooling that triages by risk rather than by arrival order.
Figure 3. Schematic of the cost inversion. Once producing a change is nearly free, the marginal cost of shipping software is the cost of establishing that it is correct, safe and maintainable.
There is a second-order effect that nobody in the optimistic camp is pricing yet. Cheap code means more code, and more code means more surface area to secure, comprehend, operate and eventually replace. The Itau number cuts both ways: agents remediating 70% of vulnerabilities is excellent, and the volume of code being produced is what makes that capability necessary rather than merely nice.
The bricklayer to architect framing is the right shape and it hides a workforce problem.
Nobody has ever produced an architect without first producing a bricklayer. Judgment about systems is not taught, it is accumulated, and it accumulates through exactly the tasks that agents now do best: implementing the obvious thing, breaking it, fixing it, and learning why it broke. If you automate the first two years of an engineering career and keep the expectation that engineers arrive with architect-level judgment, you have created a pipeline problem that becomes visible in about 2029 and takes a decade to unwind.
The 100x engineer that Marc describes, operating as CTO of a fleet of agents, is real. I have seen individuals working that way and their output is genuinely startling. But that leverage multiplies judgment. Applied to poor judgment, the same fleet produces failure at 100x as well, and the organization finds out later than it used to, because nobody was reading the code on the way through.
| Stage | Was | Becomes | What to measure now |
|---|---|---|---|
| Specification | A ticket, written loosely, clarified in review | The highest-leverage artifact in the org. Ambiguity now compiles into a thousand lines instantly. | Rework attributable to spec defects |
| Implementation | The expensive middle. Where the time went. | A scheduling and orchestration problem. Near-free, near-instant, unbounded in volume. | Agent-authored share, by service and autonomy level |
| Review | Peer check on work you could have written yourself | The constraint. Tiered by risk, not by arrival order, with agents doing the first pass. | Review latency and batch size, not PR count |
| Testing | Coverage written after the fact | Evals, properties and contracts written before generation. The spec’s executable half. | Defect escape rate per thousand agent changes |
| Operate | Deploy and monitor | Faster failure, wider blast radius, provenance on every change | Incident rate tied back to authorship |
| Maintain | Inherited code someone here wrote | Inherited code nobody here wrote or read | Comprehension debt, and who can still explain the system |
If I compress my view into five claims:
The strongest counter to my position is that verification gets automated too, and faster than I expect. If agents become reliable reviewers of other agents, the queue I am describing dissolves and the constraint moves again, probably to specification. I take that seriously. My hesitation is that verification is not only a technical problem, it is an accountability problem, and accountability has so far refused to delegate. Somebody signs off. That somebody is currently a person, and regulators, auditors and customers all assume it stays that way.
Marc ended his 2011 essay by saying he knew where he was putting his money, and fifteen years later he says he still does. He has earned that. Software did eat the world, and agents are going to make the next fifteen years look faster than the last fifteen.
My version is narrower. I know where I would put the next engineering dollar, and it is not into more generation capacity. Generation is solved and getting cheaper every quarter. I would put it into knowing, with evidence rather than vibes, what the agents are actually doing to my codebase, my cycle time, my defect rate and my people. The companies that can answer that question in 2027 will be operating a different business from the ones that cannot, and they will be running on the same models.
Sources: Marc Andreessen, Investing in Cognition (a16z, 9 September 2026), posted on X as “Software is about to eat the world much faster.” Aaron Levie, post on X, 9 September 2026. Cognition’s $2B Series E at a $48B valuation, led by Andreessen Horowitz and Accel, reported 8 September 2026. Figures 1, 2 and 3 are my own; Figure 1 plots a figure reported by Cognition, Figures 2 and 3 are schematic.
Ready to unlock your SDLC productivity?
