A two-part essay on the deep reasons coding is uniquely suited to AI agents, and why developers shouldn’t expect their compensation to scale linearly with their new superpowers.
Part 1: Why Coding Is the Job AI Was Built To Do
Every few months a new chart circulates listing the jobs “most exposed” to AI. Translators, writers, customer service reps, paralegals, and — almost always near the top — software developers. Microsoft’s 2025 Working with AI study, which scored 200,000 real Copilot conversations against the O*NET task taxonomy, put computer and mathematical roles among the very highest in AI applicability. The pattern is consistent across studies from McKinsey, Anthropic, and academic researchers: knowledge work involving symbols, text, and rules is in the bullseye.
But while customer service exposure makes intuitive sense (scripted interactions, bounded domains, transcripts everywhere), coding’s dominance is more interesting. Why is writing software — supposedly one of the most intellectually demanding professions of our age — one of the first jobs that probabilistic language models can do meaningfully well?
The usual answer is “there’s a lot of code on GitHub.” That’s true but shallow. The deeper answer is that coding is the closest thing we have to a fully artificial domain: humans designed every piece of it, top to bottom, to be unambiguous and mechanically checkable. That design choice — made by Turing, Church, McCarthy, and everyone since — turns out to be exactly the substrate that LLMs and agents thrive on.
Coding is a game humans invented with the rules written down
When you write English, the “rules” are descriptive, contested, and full of context-dependent meanings. There’s no compiler for a sentence. Some words don’t translate between languages at all — saudade, mamihlapinatapai, Schadenfreude — because meaning depends on culture, idiom, and shared history that isn’t encoded anywhere formal.
Code is the opposite. Programming languages were designed to be unambiguous. Every Python statement has exactly one parse tree. Every C function has a defined memory model. Every SQL query has a deterministic execution semantics. When the model writes for i in range(, the space of valid continuations is narrow and checkable — by a parser, by a type checker, by the runtime itself.
This means coding comes with something natural language fundamentally lacks: a free, deterministic oracle. The compiler tells you if the syntax is wrong. The test suite tells you if the behavior is wrong. The linter tells you if the style is wrong. For an AI agent, this is gold — it can generate, run, observe failure, and iterate, all without a human in the loop. That feedback loop is why agentic coding works at all. Try imagining the equivalent loop for “write me a moving eulogy” or “negotiate this contract.” There’s no runtime for meaning.
Humans are usually pretty bad at the games we invent. Not because we don’t understand the rules — we wrote them — but because once the game gets going, our minds simply aren’t built to track the exponential, or even merely linear, growth that follows. Chess has a finite, fully-specified rule set written by us, and we still can’t see more than a handful of moves ahead. Compound interest is arithmetic we teach to teenagers, and adults still routinely misjudge it by orders of magnitude. Programming is the same story at industrial scale: we designed a system where every line is deterministic, every state is in principle inspectable — and then we built codebases with millions of those deterministic lines interacting in ways no single human can hold in their head. (I’ve written more about this general pattern of humans being bad at their own games.) AI doesn’t suffer from that ceiling in the same way. It doesn’t get tired tracking the seventeenth nested callback or the forty-third config flag. The game was always tractable in principle; it’s just that we, the inventors, were never the ideal players.
Turing completeness makes all computable knowledge translatable
Here’s where I want to draw a careful distinction. People sometimes invoke “Turing completeness” as if it means “computers can solve anything.” It doesn’t. The halting problem is undecidable. Rice’s theorem says no algorithm can decide non-trivial semantic properties of arbitrary programs. Gödel showed that sufficiently expressive formal systems are incomplete. LLMs, being themselves computable, can’t outrun any of these limits — they can give heuristics and probabilistic confidence, but never a universal decision procedure.
What Turing completeness does give us is something subtler and, for AI, hugely valuable: any computable solution expressed in one language can in principle be re-expressed in another. That means six decades of code — COBOL, Fortran, C, Java, Python, JavaScript, Rust, Go — collectively form a single, vast, cross-language corpus of “things humans figured out how to compute.” A function written in 1985 to validate ISBNs in C can be translated, refactored, and re-deployed as a microservice in Go in 2026.
LLMs are extraordinarily good at this kind of cross-language pattern transfer. Meta’s TransCoder and its successors showed that even unsupervised code translation works surprisingly well. Modern agents do this routinely: “port this Python service to TypeScript,” “modernize this Java 8 codebase to Java 21,” “rewrite this Bash pipeline as a Python script with proper error handling.” None of these tasks is creating new mathematics. They’re reshuffling known computable knowledge across a substrate where the rules of equivalence are guaranteed by theory.
That’s a genuinely different situation from natural language, where translation is lossy by nature. Code’s Turing-complete universality plus AI’s pattern-recognition capacity turns the entire history of programming into a re-codeable knowledge base. That’s the real reason “there’s a lot of code on GitHub” matters — it’s not just volume, it’s interoperable volume.
Most software engineering is not innovation
The other half of why AI handles coding so well is uncomfortable but true: most software engineering isn’t inventing new algorithms. There’s a reason they call it software engineering at work and computer science at uni — the two jobs look almost nothing alike. University trains you to think about NP-completeness, novel data structures, and the theory of computation. Then you graduate and spend the next decade writing CRUD endpoints, wiring up auth flows, mapping JSON to database rows, and arguing in pull requests about where to put the null check.
The average production codebase is roughly 80% glue: form validation, ORM mappings, API integrations, authentication, data pipelines, configuration management, test scaffolding, error handling. The patterns are well-known. The libraries already exist. The “engineering” is mostly choosing among proven options and adapting them to specific labels and schemas.
This is exactly the quadrant where LLMs shine. Given a bounded spec — “ingest this CSV, deduplicate by email, write to Postgres, send a Slack notification on failure” — the solution space is dominated by idiomatic patterns the model has seen thousands of times. The agent isn’t reasoning about novel mathematics; it’s doing high-quality Lego assembly with appropriate library calls. And because every piece is testable, the probabilistic guesses can be filtered through deterministic checks before they ever reach a human.
What doesn’t get automated this easily is the outer loop: deciding what to build, framing the trade-offs, architecting systems that age gracefully, owning reliability, navigating organizational and security constraints. Those tasks involve specification quality, judgment under ambiguity, and stakeholder coordination — none of which have a compiler. Notice that this outer loop is much closer to what computer science aspired to teach you than to what software engineering jobs have historically demanded. AI may actually be pulling the working profession closer to the academic discipline it was named after, by automating away the parts that were never really “science” to begin with.
So why coding and not, say, law?
Both law and code are formal-ish text. But law’s “execution model” is a courtroom: slow, contested, full of judgment calls, with outcomes that depend on judges, juries, jurisdictions, and politics. Code’s execution model is a CPU: fast, deterministic, identical everywhere, with outcomes you can re-run a million times per second. AI agents need cheap, fast, reliable feedback to learn and self-correct. Code provides it natively. Law, medicine, and most of human professional life don’t.
Stacking it all up, coding is unusually well-positioned because it combines: a formal grammar (parsers as judges), a deterministic runtime (tests as judges), cross-language translatability (Turing equivalence as a theoretical backbone), a massive open corpus (decades of public code), and a problem distribution dominated by recombination of known patterns rather than novel invention. No other major profession scores high on all five of those axes simultaneously. That’s why coding, not customer service, is the most-discussed displacement story — customer service is automatable because conversations are bounded; coding is automatable because the entire domain was engineered to be mechanically checkable from the start.
The honest limit
None of this means programmers are obsolete. The theoretical ceilings — undecidability, Rice’s theorem, the lack of a universal verifier — remain. Real systems still drift, integrate badly, accumulate hidden state, and fail in ways no test suite anticipated. Recent studies have tempered the 2–3x productivity hype: a 2025 METR randomized trial of experienced open-source developers found that AI tools sometimes slowed experienced devs down on their own complex codebases. A 2026 longitudinal study found AI usage rose ~65% while PR throughput only rose ~8%. Real-world net gains tend to land in the 10–40% range, not 3x. The Forbes summary of recent enterprise data put task-level gains at 14–55% but noted that 95% of enterprise AI pilots fail to translate into measurable business outcomes.
So the right framing is: AI is uniquely well-matched to coding as a domain, and within that domain it dramatically lowers the cost of routine implementation. But it doesn’t dissolve the hard parts — architecture, specification, judgment, debugging novel systems — and it doesn’t repeal computability theory. The job changes; it doesn’t vanish.
Part 2: More Coders, Not Fewer — And Why Your Paycheck Still Won’t 3x
The natural next question is: if AI can do all this, are software jobs about to evaporate? And if not, shouldn’t developers who ship 2–3x more get paid 2–3x more?
Both answers are more interesting than the obvious ones. The short version: the market is likely to need more coders, not fewer — but the kind of coder it needs is changing, and compensation has never scaled linearly with raw output anyway.
The Jevons effect: cheaper coding means more coding
There’s an economic force worth naming up front. When a production input gets cheaper, demand for it usually increases, often more than proportionally — economists call this the Jevons paradox. Cheaper compute didn’t reduce compute spending; it exploded it. Cheaper storage didn’t reduce storage spending; it created the data economy. Cheaper bandwidth didn’t reduce internet traffic; it gave us streaming video, video calls, and the entire cloud.
Coding follows the same logic. If AI cuts the cost of implementing a feature by 30–50%, many projects that were previously uneconomic become viable. Every business has a long backlog of “we’d build that if it cost half as much” — internal tools, custom integrations, deep automation, niche products, personalization features, observability dashboards. As the unit cost of software falls, the total amount of software the world wants goes up, probably by more than the cost savings.
This is why “AI will replace software jobs” is mostly the wrong frame. The more accurate frame is: the world will need more people who can orchestrate AI to build software, not fewer. One developer with agents can ship what five developers used to ship — but the world also wants ten times as much software as it used to, because so much more of it is now affordable to build. Net direction: more coders, doing more leveraged work.
But the kind of coder is shifting
This isn’t evenly distributed good news. Three groups feel the shift differently:
Juniors are having a harder time getting in. The traditional first-job tasks — boilerplate features, simple bug fixes, glue code, basic CRUD — are exactly the work AI does best. Companies that used to hire three juniors to handle that workload now hire one and give them an agent. Entry-level positions are genuinely tighter, and the data from 2025–2026 reflects it: junior developer postings have softened in many markets even while overall demand for software has held up. The strategic response for a junior is not “wait it out” — it’s to compress the path to senior deliberately. That means learning to direct agents rather than compete with them, getting fluent in system design and debugging early (the things agents are still weakest at), owning end-to-end outcomes rather than tickets, and treating AI tools as a force multiplier from day one rather than a crutch to be embarrassed about. The juniors who do this well will reach the leverage point faster than seniors who refuse to adapt.
Average and below-average coders will feel real pressure. If most of your value was producing competent, idiomatic implementations of known patterns at a reasonable pace, an agent now does that for ten dollars an hour with no PTO. Being a steady, average producer of routine code is the most automatable position to be in. The honest answer here is that the market is going to ask more from this group — either move toward the higher-leverage skills (specification, architecture, agent orchestration, debugging weird production failures) or accept that the role itself is compressing. This is uncomfortable but worth saying clearly rather than dressing up.
Strong engineers who embrace agents are getting more valuable, not less. A developer who can clearly specify a problem, decompose it for one or several agents, evaluate the output critically, and integrate it into a robust system is doing the work of what used to be a small team. That kind of person is more in demand than before, because they unlock projects that wouldn’t otherwise be staffable. The ceiling on their effective output has gone up, and the market is pricing that.
So the right picture isn’t “AI replaces coders.” It’s: AI compresses the bottom rung, raises the bar for the middle, and amplifies the top. Net headcount probably grows. But the distribution shifts toward people who can run agents, not people who can out-type them.
Output is not value, and value is rarely linear
Now to the compensation question. If AI really does make developers 1.5–3x more productive, and many feel that effect day to day, shouldn’t pay track output?
The intuitive answer is yes. The economic answer is no.
In factory work, output and value are roughly proportional. Make twice the widgets, sell twice the widgets, earn twice the revenue. Pay scales accordingly. Software has never worked that way. The value of code is wildly nonlinear in its volume:
- Bottleneck removal. A 200-line patch to a database connection pool can unblock dozens of teams and save more money than a 200,000-line internal tool that nobody uses.
- Threshold effects. A product can sit at 80% of usable for years and generate no revenue, then cross a reliability or latency threshold and suddenly compound.
- Winner-take-most markets. Being meaningfully better in software often captures a disproportionate share of demand. Being slightly worse captures almost none.
- Compounding leverage. A well-designed abstraction reduces future work for years. A poorly-designed one creates future work for years.
In this kind of system, “more output” is at best a weak proxy for “more value.” Studies of software productivity have shown for decades that team output measured in code volume correlates poorly with delivered business value. The famous Standish-style findings that a large share of shipped software features go essentially unused make the same point from the other side: code can be produced and still be worth nothing.
AI accelerates the production of code. It does not, by itself, improve the judgment about what code is worth producing. So the productivity uplift gets you more shots on goal — but the score still depends on hitting the right targets.
The rising bar isn’t new
Each previous wave of developer tooling raised the effective output per developer dramatically:
- The compiler and the IDE didn’t double salaries when they replaced punch cards.
- High-level languages didn’t double salaries when they replaced assembly.
- Open source didn’t double salaries when it replaced rebuilding everything in-house.
- Cloud and CI/CD didn’t double salaries when they replaced server racks and manual deployments.
Each step also raised what was expected of “one developer’s worth of work.” Compensation did rise over the long run — software developer wages have grown well above the median for forty years — but never in a clean 1:1 ratio with productivity. The gains were absorbed by the system: more software got built, more companies became software companies, more demand for engineers emerged, and pay rose because demand rose, not because individual output mechanically did.
AI is the next step on that curve, not a discontinuity from it. The bar will move up. The pay will move up too, but for the systemic reason — more software work in the world — not the individual reason of “I personally produce more lines now.”
Where the asymmetric upside actually lives
So is there a way for developers to capture exponential rewards from AI-amplified output? Yes — but it doesn’t look like a salary bump. It looks like leverage:
- Equity in products that win big. If your team uses AI throughput to find the killer feature, the threshold-crossing improvement, the architecture that scales — the reward shows up in equity, bonuses, and the value of the business, not in your hourly rate. Software has always rewarded threshold-crossing decisions disproportionately. AI doesn’t change that; it just gives more teams more chances to find one.
- Personal leverage as a builder. Solo founders and small teams now ship things that required ten engineers five years ago. The economic value of “one person who can build a real product end-to-end” has gone up sharply. That’s a genuine asymmetric opportunity — but it requires owning outcomes, not just billing hours.
- Becoming the person who directs the agents. As more of the mechanical coding gets done by AI, the scarce skill becomes specification, architecture, and judgment — the outer loop. People who can frame problems precisely enough that agents can execute on them, and who can evaluate agent output critically, become disproportionately valuable.
- Tackling work that used to be uneconomic. Internal tools, custom integrations, deep automation, niche products — vast amounts of software work that was previously not worth funding now become viable. There’s more work, not less, but it’s differently distributed.
What to say to your team
A version that’s honest with developers and consistent with the data:
AI tools really do raise effective output, probably 20–40% in practice for most well-scoped work, and occasionally more in favorable conditions. That’s significant. It also means the expectation of what one person can deliver has moved up — not as a punishment, but as the natural consequence of having better tools.
The reward model is not “more code equals more pay.” Software value has never been linear in code volume, and AI doesn’t change that. What AI changes is leverage: you can attack bigger problems, explore more solutions, and ship things that weren’t economical before.
The upside lives in winning — in finding the high-leverage move, hitting the threshold, building the thing that compounds. If we win that way, the rewards can be much larger than the old “do everything by hand” model ever offered. But they show up as shared success — equity, bonuses, growth, optionality — rather than a proportional wage bump.
The worst response is to treat AI as a way to do the same job more slowly with more help. The best response is to treat it as a way to do work that was previously out of reach.
A note for leaders
The flip side is also worth saying. If you’re running a team, the temptation is to treat AI gains as pure margin: same output, fewer people, lower cost. That’s the linear thinking applied from the other direction, and it tends to capture only the smallest version of the opportunity. The leaders getting outsized returns from AI seem to be the ones doing the opposite — keeping or growing teams, but pointing them at problems that weren’t on the roadmap before because they would have been too expensive. PwC’s 2026 study found that three-quarters of AI’s measurable economic gains were captured by just 20% of companies, and those leading companies were focused on growth rather than cost-cutting. That asymmetry is itself a nonlinearity worth respecting.
Closing
The two halves of this essay tell one story. Coding is uniquely suited to AI because humans designed it to be a formal, deterministic, cross-translatable, testable game — the rare professional domain that comes with its own built-in judge. That makes AI agents genuinely transformative for software work in a way they aren’t (yet) for most other professions. It also exposes the awkward truth that we, the inventors of the game, were never quite the right species to play it at scale.
But the same Jevons-style economics that make cheap inputs grow markets, and the same nonlinearity that makes software valuable in the first place, mean two things at once: the world will probably need more coders directing AI rather than fewer, and the productivity gains won’t flow back to individuals as a proportional pay bump. They flow into the system — more software gets built, more problems become tractable, more demand emerges, and the winners are the people and teams who use the new leverage to find the high-value moves.
AI hasn’t turned software engineering into a linear production line. It’s turned it into a leverage playground. The question isn’t “how do I ship 3x more of what I used to ship.” It’s “what was previously impossible that I can now reach?”
That’s a much more interesting question — and the answers, for the people who find them, are likely to be worth far more than 3x.
Leave a Comment