There is a persistent fantasy in business journalism that software engineers are about to be replaced. Every six months a new article appears: AI Will Make Developers Obsolete, The End of Coding, Why Your Company Won't Need Programmers in Five Years. These articles share a common error, which is the assumption that software engineering is primarily about producing code. It isn't. Software engineering is about making decisions under uncertainty in complex systems, and code is merely the medium in which those decisions are expressed. AI is not replacing that capacity. It is amplifying it beyond anything we've previously seen.

The Leverage Thesis

Sam Altman has made a version of this argument in various forums: the most important consequence of AI is not that it replaces workers but that it gives individual workers extraordinary leverage. A single engineer with the right tools can now do what used to require a team of ten. This is not hyperbole — it is an observable fact. I have personally built and shipped features in an afternoon that would have taken a team sprint two years ago. The code generation is part of it, but the larger factor is decision acceleration: AI collapses the research-prototype-iterate cycle from days to hours.

The historical parallel is the spreadsheet. Before VisiCalc, financial modeling required teams of analysts with calculators and ledger paper. After VisiCalc, a single analyst could explore more scenarios in an hour than a team could in a week. Did this eliminate financial analysts? No — it made individual analysts enormously more productive and valuable, while shifting the skill set from arithmetic to judgment. The same transformation is happening in software engineering, and the speed is breathtaking.

The question is not whether AI will change what engineers do. It already has. The question is whether you understand the nature of the change. Engineers are not being diminished. They are being armed.

✦ ✦ ✦

Productivity Across Eras

The compounding of individual engineer leverage is one of the most important economic phenomena of our time. Consider the rough trajectory:

EraToolingSolo Engineer OutputTeam Needed For Production App
1970s mainframeAssembly, COBOL~100 LOC/day useful20-50 engineers
1990s client-serverC++, Java, IDEs~500 LOC/day useful10-20 engineers
2010s cloud-nativePython, React, AWS~2,000 LOC/day useful5-10 engineers
2024 AI-assistedCopilot, GPT-4, Claude~10,000 LOC/day useful2-5 engineers
2026 AI-nativeAgentic coding, full-stack AI~50,000 LOC/day useful1-2 engineers

These numbers are approximate and somewhat artificial — lines of code is a terrible metric in isolation — but the ratio tells the story. The amount of functional output a single engineer can produce has increased by roughly 500×500\times over five decades, and the curve is steepening, not flattening.

The leverage ratio LL for an individual engineer can be modeled as:

L(t)=L0eαtL(t) = L_0 \cdot e^{\alpha t}

where L0L_0 is baseline productivity, α\alpha is the compounding rate of tooling improvement, and tt is time. For most of software history, α\alpha was modest — maybe 0.050.05 to 0.080.08 annually. In the AI era, α\alpha appears to have jumped to something like 0.30.3 to 0.50.5. This is not a linear acceleration. It is a phase transition in what one person can accomplish.

What This Means for Organizations

The organizational implications are profound and, I think, insufficiently appreciated. If one engineer can do what ten could do before, then the optimal team size for most software projects is shrinking dramatically. This has cascading effects:

Communication overhead drops quadratically. Brooks's Law tells us that communication channels in a team of nn people scale as n(n1)2\frac{n(n-1)}{2}. A team of 10 has 45 channels. A team of 2 has 1. The cognitive tax of coordination — meetings, standups, design reviews, merge conflicts, Jira tickets — consumes an astonishing fraction of engineering time in large teams. Smaller teams don't just produce more per person; they produce more per dollar because the coordination overhead approaches zero.

I once worked on a team of twelve engineers where we spent more time in meetings about the architecture than we spent actually building it. Two of us eventually prototyped the whole thing over a weekend. The prototype shipped. The architecture document didn't.

Decision quality increases with ownership scope. When one engineer owns an entire system — frontend, backend, infrastructure, deployment — they can make holistic decisions that are impossible when responsibility is fragmented. The full-stack AI-augmented engineer doesn't just write more code; they make better decisions because they hold the entire context in their head. No handoffs, no miscommunication, no telephone-game degradation of intent.

✦ ✦ ✦

The Compound Growth Problem

Here is what keeps me up at night, in the good way. The leverage is not just growing — it is compounding. Each generation of AI tools is being used to build the next generation of AI tools. Engineers using Claude are building better versions of systems like Claude. This creates a recursive loop:

Pn+1=Pn(1+δ(Pn))P_{n+1} = P_n \cdot (1 + \delta(P_n))

where PnP_n is engineering productivity at generation nn and δ(Pn)\delta(P_n) is the marginal improvement enabled by current-generation tools. The key insight is that δ\delta is itself a function of PP — better tools make it easier to build better tools. This is the same dynamic that drove Moore's Law, but applied to cognitive rather than physical technology.

The implications for individual engineers are stark. If you are an engineer who leans into these tools — who learns to think with AI rather than despite it — your individual output will compound at a rate that makes traditional career trajectories look quaint. The 10x engineer of 2015 was a statistical outlier, a mythologized figure. The 100x engineer of 2026 is just someone who has fully integrated AI into their workflow. The distribution is widening, not narrowing.

The Uncomfortable Corollary

There is, of course, a dark side to this. If individual leverage is compounding, then the gap between engineers who adopt and those who don't is also compounding. The engineer who refuses to use AI tools is not staying in place — they are falling behind at an accelerating rate. In two years, the gap will be embarrassing. In five, it will be unbridgeable.

This also means that the number of engineers needed for any given project is declining. I want to be precise here: I am not saying demand for engineers is declining. I believe demand for engineering output will increase faster than per-engineer productivity, because as software gets cheaper to build, the number of things worth building expands enormously. But the mix will shift. Fewer engineers, each doing dramatically more, each paid dramatically more. The median engineer salary will rise. The total number of engineering jobs may not.

Sam Altman's vision of the "one-person unicorn" — a billion-dollar company run by a single person with AI tools — sounded absurd when he first said it. It sounds less absurd every month. I don't know if we'll get all the way there, but the direction is clear. The atomic unit of software production is shrinking from the team to the individual, and the individual is becoming extraordinarily powerful.

This is not a threat. It is a promotion. The engineer ascendant is not a diminished figure doing rote work faster. They are a decision-maker whose judgment is leveraged across an unprecedented scope of execution. The code writes itself. The architecture, the taste, the product sense, the understanding of what to build and why — that's the engineer's job now. And it always was. We just couldn't see it clearly until the mechanical parts started falling away.

1
2
1/1