This is the central tension every developer, founder, and small-business owner using AI to ship software in 2026 has to internalize: generative coding is real, the productivity gains on greenfield work are real, but the claim that "coding was easy all along" inverts the evidence. The first rigorous randomized controlled trial of experienced developers using frontier AI tools found they got slower, not faster — and the engineers believed they were speeding up. The work AI replaces was never the work that made software expensive.
Last verified: 2026-08-10
- Writing code is roughly 15-20% of what a working engineer does; the rest is research, design, review, and maintenance — work AI cannot do alone.
- The only RCT of experienced developers on large codebases found a 19% slowdown with AI, even though developers felt 20% faster.
- AI's gains concentrate in greenfield/prototype work; its failures concentrate exactly where software is most expensive — large, mature, interconnected systems.
- The engineer's job is shifting from "write code" to "decide what code to trust, verify, and run in production" — and that job is harder, not easier.
What Does "Coding Was Never the Hard Part" Actually Mean?
It means: among the many activities that produce working software, the physical act of typing correct syntax has rarely been the bottleneck. Frederick Brooks made the point quantitative in 1975 in The Mythical Man-Month, proposing a rule of thumb that a software schedule should be split as roughly ⅓ planning, ⅙ coding, ¼ component testing, and ¼ system testing — meaning coding is about one-sixth (~16%) of the effort even on a clean project. Engineers have repeated the intuition for fifty years because it matches experience: most of the cost of software lives before the first line of code and long after it ships.
What the slogan gets wrong is the implied corollary: "and therefore, now that AI writes the code, the hard parts are solved." They are not. The hard parts are still exactly where Brooks put them — in understanding the problem, designing a system that fits it, and verifying that what you built actually works for the person paying for it. AI helps most at the step that was already the cheapest, and helps least at the steps that were already the most expensive. That asymmetry is the whole story.
Why Did Programmers Earn Premium Salaries if "Coding Is Easy"?
This is the question the "coding is easy" framing can't answer. If typing code were the whole job, a junior fresh out of a bootcamp would replace a principal engineer at a tenth of the cost. Instead, experienced engineers have commanded large salaries for decades — before AI, before the internet, before the current hype cycle — because the job was always the parts around the code.
A usable mental model splits a developer's work into two very different categories, with very different economics:
| Work type | What it is | Example | AI's impact today |
|---|---|---|---|
| Daily coding | Adding a widget, a route, a form, a small feature inside an existing, understood system | "Show the last 28 days of revenue on the instructor dashboard" | Huge. A 20-minute job becomes a 5-minute job. |
| Pure engineering | Designing or rebuilding a core system: choosing the stack, handling edge cases, making it scale, debugging production failures | Building real-time multi-party video conferencing from a low-level WebRTC SFU | Small to negative. The library authors spent years getting it right; AI can't even tell you not to build it from scratch. |
The reason programmers were paid well is that the second category — not the first — is what determines whether a product works. A misimplemented dashboard widget is a minor bug. A misimplemented real-time stack is a product nobody will use. Companies paid premiums for the people who could tell the difference and execute on the hard one, and that distinction has nothing to do with how fast either group can type.
What Is the Evidence That AI Helped or Hurt Developer Productivity?
The honest answer is that the most rigorous study we have found AI slowed experienced developers down, and the more recent evidence is suggestive but methodologically messy. This is not an anti-AI point — it's a "the hard part isn't where you think" point.
The METR randomized controlled trial (July 2025). METR recruited 16 experienced open-source developers (averaging 5 years of contribution history) working on their own large, mature repositories (averaging >1.1 million lines of code). Across 246 real tasks, each task was randomly assigned to allow or disallow AI (primarily Cursor Pro with Claude 3.5/3.7 Sonnet — frontier tools at the time). Result: tasks where AI was allowed took 19% longer to complete. The perception gap is the striking part — before starting, developers predicted AI would save them 24% of the time; after finishing, they estimated it had saved them 20%. They were 20 percentage points confident in the opposite of what happened.
The February 2026 follow-up. METR tried to re-run the study with late-2025 tools and a larger pool. They couldn't get a clean read because of selection effects: an increasing share of developers refused to participate at all rather than work without AI, and many filtered out the tasks where AI helps most. Their raw numbers suggested a possible 18% speedup for returning developers (confidence interval: -38% to +9%) and 4% for new recruits (CI: -15% to +9%) — both statistically indistinguishable from zero. METR concluded the data was "only very weak evidence" and redesigned the experiment.
The balanced counterpoint. A separate randomized trial across Microsoft, Accenture, and an anonymous Fortune 100 company (4,867 developers, automated code-completion assistant) found a 26% increase in completed tasks — and notably, less-experienced developers benefited most. The difference is instructive: that study used smaller, suggestion-style tools on a different population. AI's productivity signal is real but it is uneven, and it skews toward less experienced developers doing less structurally demanding work.
The synthesis: AI helps most on greenfield, well-bounded, syntax-heavy work. It helps least — and can hurt — exactly where software engineering is most expensive, on large, mature, interconnected systems where correctness and judgment matter more than keystrokes.
Where Does AI Actually Help and Where Does It Fall Short?
This is where the "coding was never the hard part" debate stops being philosophical and becomes a practical decision tool. AI is not uniformly good or bad at "coding" — it's good at one kind of coding and bad at another, and knowing the difference is the skill.
What AI does well today:
- Activation energy. The single most-real benefit: AI gets you past the blank-page problem. Starting a new file, a new endpoint, a new component is the part most engineers procrastinate on, and AI collapses that to seconds.
- Greenfield scaffolding. Build a new app with no prior context and AI moves fast — boilerplate, CRUD endpoints, routing, a basic UI shell.
- Documentation, tests, refactors. The work engineers know they should do but avoid. AI is genuinely good at writing test scaffolding and docstrings.
- Rubber-duck reasoning. Thinking out loud with a patient, knowledgeable interlocutor at 2 a.m. is underrated.
What AI does poorly today — and where the "easy" parts turn hard:
- It makes the most statistically common decision, not the best one for your context. It doesn't know that the library you depend on just went unmaintained, or that you talked to a maintainer at a conference who is shipping something in six weeks that makes your whole problem easier, or that your cloud provider just changed a pricing model after the model's training cutoff.
- It can't tell you not to build something. Ask an LLM whether you should hand-roll a Zoom competitor from a WebRTC SFU and it will happily start building one. The senior engineer's answer is "almost never do this — buy it or self-host an existing project." That refusal is worth months of wasted work, and no frontier model reliably produces it.
- It struggles most on the largest, most mature codebases — the ones that matter most. The METR engineers' own quotes are the evidence: "it made some weird changes in other parts of the code that cost me time to find and remove," and failures were "heavily related to the size of a single file it is attempting to perform edits on."
- It cannot own outcomes. AI is never on call. It doesn't carry the pager. When something built with AI breaks in production, the tool doesn't take the blame — the engineer does. That asymmetry is the real source of engineer pushback on AI mandates, and it's reasonable, not reactionary.
What Is the "70% Problem" and Why Does It Matter?
Addy Osmani named the pattern in early 2025 after extended time using AI-assisted tooling: AI reliably gets you about 70% of the way to working software, and then loses the thread. The remaining 30% — edge cases, real-world performance, security, integration with legacy systems, the subtle bug that only surfaces under load — is exactly the part that requires an engineer who understands how the system actually works.
The practical implication is that AI doesn't eliminate the senior engineer; it changes what senior means. The senior engineer used to be the person who could write the hard code themselves. The senior engineer in 2026 is the person who can read AI-generated code, recognize the 30% where it's wrong, and fix it before it reaches production. The skill shifts from authoring to verifying — and verification is a harder skill to acquire, not an easier one, because it requires you to understand a system you didn't build.
This is also why naïve "vibe coding" — accepting AI output without understanding it — is dangerous for anything beyond a throwaway prototype. It works until it doesn't, and the moment it stops working you have to debug a system whose internals you never understood. If you're building anything that touches customer data, money, or production traffic, you need a verification and isolation layer above the AI, not just a faster way to generate code — which is exactly what making vibe coding safe with sandboxing architecture is designed to provide.
What Does Software Engineering Actually Consist Of, If Not Mostly Coding?
If coding is ~16% of a software project (Brooks, 1975) and the rest is the expensive part, what is the rest? A useful inventory, with where AI helps on each:
| Phase | Share of effort | What it involves | AI impact |
|---|---|---|---|
| Research / problem definition | ~20% | Talking to users, reading the existing system, understanding the actual constraint | Low — it has none of your context |
| Design / architecture | ~15% | Choosing the stack, data model, boundaries, failure modes | Medium — good at enumerating options, bad at picking the right one for your situation |
| Implementation (coding) | ~15% | Writing the code itself | High — this is AI's strength |
| Review | ~20% | Reading others' code (and your own), catching bugs, holding quality | Medium — AI review helps, but the judgment call is human |
| Testing / verification | ~15% | Designing cases that prove it works and catching the ones where it doesn't | Medium — AI writes tests, but designing what to verify is the hard part |
| Maintenance / ops | ~15% | Keeping it alive: debugging, migrations, incident response, cost, security | Low — the part that compounds over years and needs institutional memory |
Two things to notice. First, AI helps most on the single smallest line item. Second, the three largest line items — research, review, and maintenance — are precisely the ones that require context AI does not have and accountability AI cannot provide. The economics of the profession are about to get more concentrated in the parts AI touches least, not less.
If Figuring Out What to Build Is Hard, Why Do Product Managers Earn Less Than Senior Engineers?
This is the sharpest counter-argument to "coding was never the hard part," and it deserves a straight answer. If deciding what to build is the hard part, why aren't product managers, market researchers, and customer-success people paid like rockstars?
Because the two halves aren't separable, and the implementation carries most of the weight. A great product decision executed badly produces a product nobody uses. A mediocre product decision executed superbly can still produce a product people love. Implementation is where the decision meets reality, and reality is unforgiving — a real-time video system that lags doesn't matter how well-researched the feature list was. The work of figuring out what to build and the work of building it well are a coupled system, and decoupling them is how companies ship the wrong thing, perfectly.
The more interesting version of the question is why bad product managers and bad engineers both exist in large numbers, and the answer is the same 80/20 distribution the video gets right: the bottom 80% of any role is worse than the top 10%, and the gap inside a discipline is wider than the gap between disciplines. AI doesn't flatten this — it widens it, because it gives the bottom 80% of "daily coders" a tool that produces more output without producing more judgment, while the top 5% of engineers use the same tool to compound the judgment they already had. The people who thrive will be the ones who can move up the distribution inside their own discipline, not the ones who try to switch disciplines to escape it.
How Should Developers and Teams Adapt in 2026?
The actionable synthesis, for people using AI to build real software for real users:
- Stop measuring AI by code-output speed. The METR data is the warning: developers felt 20% faster while being 19% slower. Track shipped, verified outcomes — features that survived contact with users — not keystrokes or PR counts.
- Invest in the skills AI can't do, which are now worth more, not less. Understanding pointers, recursion, memory hierarchy, network protocols, distributed-systems failure modes, and how a large language model actually works under the hood — these are the levers that decide whether AI's 70% becomes a shipped product or a pile of plausible-looking slop. The five levels of AI coding agent adoption track this shift, from chat assistance to fully autonomous agents — each level demands more judgment from the human, not less.
- Build a verification layer above the AI, not just a prompt layer below it. Sandboxing, test design, staged rollouts, eval suites — this is engineering work, often harder than writing the original code, and it's the work that compounds.
- Learn the fields adjacent to yours. If you're a senior engineer, study user experience, customer interviews, and business models for your domain. If you're junior, go deeper on how systems work before you go wider on AI prompts. The advice is asymmetric because the failure modes are.
- Don't outsource your judgment, empathy, and taste to AI. The final line of this entire debate is not about productivity — it's about accountability. AI cannot own an outcome. It is not on call. It does not carry the weight of every feature added to a codebase that compounds in complexity over time. You do. Treat the tool as a tool, deploy it where it genuinely helps, and stay honest about the tradeoffs. That is the only way the human + AI collaboration actually works.
What This Means for You
If you're a developer: your job is shifting from "write code" to "decide what code to trust, verify it, and own it in production." That job is harder. Invest in the understanding that lets you do it — systems, networking, your domain — because that's where the premium is moving.
If you're a founder or small-business owner using AI to ship software: AI is genuinely excellent for prototypes, internal tools, and the first version of a product. It is genuinely dangerous for anything that touches customer data, money, or production reliability without an engineer who understands the output. The cheapest path to a real product is not "replace the engineer" — it's "use AI for the 70%, then pay someone who can do the 30%."
If you're a leader mandating AI adoption: the engineers' pushback is not resistance to change — it's a reasonable response to a real accountability asymmetry. AI can be enforced top-down, but it is never accountable for outcomes. Name that honestly, deploy AI where it helps, and don't paper over the tradeoffs. Your team will adopt faster when they trust you've understood the cost — and the playbook for overcoming engineer resistance to AI adoption starts from exactly this principle.
FAQ
Q: Is "coding was never the hard part" an insult to programmers? A: It's a half-truth that gets reframed as an insult. The true half — typing syntax was never the bottleneck — is something programmers have said themselves for fifty years (Brooks put coding at ~⅙ of a software schedule in 1975). The insulting half is the implied corollary that AI has now solved the hard parts, when the evidence shows AI helps most at the cheap part (syntax) and helps least at the expensive part (judgment, verification, accountability on large systems).
Q: Does AI actually make developers faster or slower? A: It depends on the work. The only RCT of experienced developers on large codebases (METR, 2025) found a 19% slowdown — while developers believed they were 20% faster. A separate enterprise RCT (Microsoft, Accenture, Fortune 100; 4,867 developers) found a 26% speedup, concentrated among less-experienced developers. The synthesis: AI accelerates greenfield and less-experienced work; it can slow down experienced engineers on large, mature systems where correctness matters more than keystrokes. METR's Feb 2026 follow-up couldn't produce a clean result due to selection bias (developers refused to work without AI).
Q: What is the "70% problem" in AI-assisted coding? A: Named by Addy Osmani in January 2025: AI reliably gets you about 70% of the way to working software, then loses the thread. The last 30% — edge cases, real-world performance, security, integration, the bug that only surfaces under load — requires an engineer who understands how the system actually works. The implication is that AI doesn't eliminate the senior engineer; it changes what "senior" means, from authoring code to verifying it.
Q: If figuring out what to build is the hard part, why do engineers earn more than product managers? A: Because the two halves aren't separable. A great product decision executed badly produces a product nobody uses; implementation is where the decision meets reality. Engineers earn the premium because the implementation carries most of the weight in whether the software actually works — a real-time system that lags is useless no matter how well-researched the feature list was. The work of deciding what to build and the work of building it well are a coupled system.
Q: What skills should a developer invest in for 2026? A: The skills AI does poorly: systems-level understanding (pointers, recursion, memory hierarchy, network protocols), distributed-systems failure modes, verification and test design, and the domain context AI lacks. For seniors, add adjacent areas (UX, customer interviews, business models). The premium is moving toward judgment, not keystrokes — the METR data on developers feeling 20% faster while being 19% slower is the case for investing in the ability to know when AI is wrong.
Q: Is vibe coding safe for production software? A: Only with a verification and isolation layer above it. Vibe coding — accepting AI output without understanding it — is fine for a throwaway prototype and dangerous for anything that touches customer data, money, or production traffic. The risk is that when it stops working, you have to debug a system whose internals you never understood. Sandboxing, staged rollouts, and eval suites are the engineering work that makes AI output safe to ship.
Every claim here is traced to a primary source, dated, and listed under Sources. Research and drafting are AI-assisted; editing, verification and publication are human decisions, and a person is accountable for what appears on this page. How we work →
Discussion
0 comments