The 'AI Can't Code' Debate Is Over. The Interesting One Is Just Starting.

The “AI can’t really code” debate is over. The more interesting question is what happens to the rest of the value chain when the cost of writing code drops to near zero.

“90 plus percent of our code is actually written by Claude Code.” That is Krishna Rao, Anthropic’s CFO, speaking on the Invest Like the Best podcast in May 2026. Sundar Pichai told Google Cloud Next 2026 in April that 75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall. Snap CEO Evan Spiegel announced on April 15 that the company was cutting roughly a thousand engineers because 65% of Snap’s code is now machine-generated, and the stock rose 11% on the news. Meta has set internal 2026 targets for select teams to ship more than 75% of committed code through AI tools. Boris Cherny, who leads Anthropic’s Claude Code product, posted on X that he personally had not typed code by hand in more than two months. He shipped 22 pull requests one day and 27 the next, “each one 100% written by Claude.”

Most published research on AI coding productivity is dated by the time it lands. The 2026 studies still being widely cited for a “productivity paradox,” in which individual gains do not translate into organizational throughput, were collected on models from 2024 and 2025. Claude Sonnet 4.6 shipped on February 17, 2026. GPT-5.5 shipped on April 23. Both delivered substantial gains in agentic coding specifically. Studies based on pre-inflection data describe a different technology than the one currently shipping code at Anthropic, Google, Meta, and Snap.

The frontier question is no longer whether AI can write usable code at quality and scale. It clearly can. The more interesting question is what happens to the rest of the value chain once the cost of writing code drops to near zero. The argument that follows takes that question seriously, using two well-validated mid-twentieth-century economic frameworks as analytical lenses.

What changed

The standard description of recent AI progress in software is that AI got better at generating code. That description is accurate but partial. The larger shift is one of integration: for products of modest scope and scale, the full build pipeline (code, infrastructure, authentication, payments, deployment, and operations) now fits inside one person’s working memory.

Building software has historically required holding six cognitive surfaces at once. Frontend, backend, infrastructure, authentication, payment processing, and deployment-plus-operations were six distinct domains, each with its own tooling and failure modes. In my case, a capable AI plus a human now handles all six. The change is structural: the cost of holding any single surface in working memory, and of switching between them, fell substantially.

The shift came as much from integration as from model capability. Claude Code, Codex, the MCP ecosystem, and platform services such as Vercel, Clerk, and Stripe became wireable in ways that let an agent maintain context across the full stack while a human held the design. Model improvement helped; integration did more of the work.

A useful analogy is the transition the personal computer made from Windows to macOS. In the Windows world, a user was implicitly their own IT department, responsible for configuring drivers, debugging crashes, and managing networks. In the macOS world, the system mostly worked, and the cognitive surface available for creative work was larger. Software production has undergone a similar shift. Platform overhead fell, and the bandwidth that overhead used to consume was freed for design and product decisions.

METR, a research organization that initially measured AI as slowing experienced developers in early 2025, redesigned their entire experiment in February 2026 because the model jump invalidated their methodology. The redesign happened the same week Sonnet 4.6 shipped. Even the people whose job is to measure this carefully cannot keep up with the rate of change.

The downstream effect is harder to capture in a single statistic, but let me try. A solo person can now ship a deployed, paying-customer product in two to four weeks. That was true for approximately no one in November 2025; it is true for many people now, in many domains. No single product release marked the threshold. The shift happened as a gradient across multiple tools maturing in parallel.

The pipeline used to need six people. Now it fits inside one head.

Two economic frameworks worth applying

Coase’s theory of the firm (1937) and Christensen’s theory of disruptive innovation (1997) each describe what happens when costs collapse at the bottom of a market. Neither was written about software. Both have observable evidence in current data.

Coase’s question was why firms exist. His answer was that firms exist because doing things outside a firm has transaction costs: finding counterparties, negotiating, contracting, and monitoring quality. When transaction costs are high, work organizes inside firms. When those costs drop, firm boundaries shift outward, and activities that used to happen inside firms start happening outside of them.

Software has historically been the inside-the-firm version of that calculation. If a company needed software, the two real options were to license it from a vendor or to hire a team and build it internally. Both options required organizational scale. A third option (build it yourself, alone, in a weekend, for the cost of a few model subscriptions) existed only in theory.

The Retool 2026 Build vs. Buy Report puts numbers on the resulting shift. 35% of enterprise teams have already replaced at least one purchased SaaS tool with custom-built software. 78% expect to build more in 2026. 60% of these builders created the tools outside IT oversight in the past year, and 51% have production software currently in use by their teams. Workflow automation and internal admin tools, where the gap between what generic SaaS provides and what an organization actually needs is widest, face the most pressure.

This is the Coase mechanism in observable data. Build costs dropped past a threshold, and work began migrating outside the firm boundary that used to contain it: sometimes outside the firm entirely, sometimes outside the IT department, and sometimes outside the SaaS vendor relationship.

Christensen’s observation was that incumbents tend to be defeated not by competitors who do what they do better, but by competitors who serve markets the incumbents cannot profitably enter. The reason is structural: their cost base is too high. A company built around $50,000-per-customer economics cannot profitably serve a $500-per-customer market. Below the cost floor of every plausible incumbent, the market goes unserved until a new entrant with a different cost structure arrives.

Cheaper software production drops that floor. Problems that used to require $250,000 of development investment can now be addressed for five to twenty-five thousand. Problems that needed teams of five can be approached by one person. Many such problems were not solved at all under the prior cost structure. They sat below the hurdle rate of every plausible incumbent, served by spreadsheets and manual workflows or simply endured.

The market data is consistent with this prediction. Vertical SaaS, which means software built for specific industries rather than horizontal use cases, is forecast to capture roughly 60% of new SaaS market growth in 2026 and to reach approximately $720 billion in revenue by 2028, at a 25.89% CAGR. The fastest-growing categories within vertical SaaS are the ones the Christensen framework would predict: previously fragmented or underserved niches such as salon client-retention tools (at $79-$149 per month, serving the 80,000+ U.S. salons that horizontal CRMs never targeted), construction-compliance tools tailored to regional regulatory profiles, and specialty trade workflows. These are exactly the markets that sat below the hurdle rate of every general-purpose incumbent.

When Coase and Christensen are stacked, two consequences follow. First, more software-shaped problems become economically viable to solve, including categories that were not previously framed as software problems: manual workflows, internal tools, and niche professional needs. Second, a meaningful share of those problems will be solved outside of firms, by individuals or small teams, for themselves and their immediate communities.

Software is now living through both Coase and Christensen at once.

Both mechanisms have observable friction. Building software internally still requires either skilled engineering labor or AI orchestration capability, neither of which is uniformly distributed. Security, maintenance, and reliability remain real concerns for internally-built systems. The 78% who expect to build more in 2026 is an expectation, and results have not yet been measured. The shift toward vertical and micro-SaaS does not mean horizontal platforms disappear; most of the build-vs-buy displacement occurs at the margins of incumbent businesses rather than at their cores.

Two paths

The shift described above leads to at least two coherent responses, with different return profiles.

Path A is build-and-market. AI assistance has made the skill of shipping software accessible to a substantially larger population. A builder on Path A picks a problem, builds the thing, and distributes it through whatever channels are available: paid acquisition, SEO, content, and community. Pieter Levels and Danny Postma are well-known examples of this path executed successfully. They are also examples of the right tail of a long distribution. Solo founder outcomes follow a power law, and surveys put the share of bootstrapped SaaS founders who ever reach $1.2M ARR at under 3%. The path works for those who execute on it; characterizing the typical experience requires noting how thin the success rate is. I am walking Path A myself with Voice Legacy. I am aware of how this looks. The argument is still right.

The structural constraint on Path A is distribution, not building. AI made building cheaper; it did not make customer acquisition cheaper. Solo-founder surveys in 2025-2026 consistently identify customer acquisition (and the gap between “product live” and “first ten users”) as the binding constraint, alongside burnout, which is the largest predictor of solo-founder failure across recent surveys at 54% reported burnout and 75% reporting anxiety episodes. The competition for distribution on Path A is intensifying as the population of cross-trained, AI-assisted builders grows.

Path B is domain-and-channel. Consider someone who has spent twelve years as a litigation paralegal. They know how discovery workflows fail, which steps are unnecessarily manual, which combinations of tools nobody bothers to integrate because the segment is too narrow to justify a vendor team. Previously, they could see all of this and do nothing with it; they were not engineers. With AI assistance, they can now produce working software, or close enough. The build bottleneck that previously stood between their domain expertise and a shippable product is gone. They have four hundred paralegals in their professional network. They can seed the tool through three Slack groups and a few direct introductions, reach thirty paying customers in a month, and never run a paid advertisement.

The same structural pattern shows up across domains. An operations manager at a mid-sized logistics company watches the same routing problem cause the same monthly fire for six years and is told repeatedly by IT that the project sits below the priority threshold. A shop foreman knows what a digital punch list should look like for the jobs his crew runs. Someone in revenue operations has rebuilt the same niche reporting workflow inside three different SaaS tools and knows precisely what should have existed all along.

These examples are illustrative rather than reported. The pattern they describe is supported by the underlying economics and by the build-vs-buy data above.

AI made the easy parts of building software easier. The hard parts of building software (knowing what to build, knowing who has the problem, and getting them to trust you enough to buy) are exactly as hard as they were. Possibly harder, since more people are competing on them now. The marginal value created by the AI shift accrues to whichever inputs AI did not similarly reduce. Domain expertise and community access are, by hypothesis, two of those inputs.

The easy parts got easier. The hard parts are still hard.

The asymmetry in returns between the two paths follows from this. On Path A, each additional year of building experience competes against a population of newly-trained builders that is also expanding. On Path B, each additional year of domain experience, and each existing relationship within a community, is not directly substitutable by AI tools. Both paths have compounding effects. The argument is that Path B compounds against less competition, because the relevant inputs to compete are not in the set of things AI is currently making cheap.

A note on the cross-trained-generalist prescription

The most-circulated career prescription for the AI era says everyone should become a cross-trained hybrid: engineers should learn product, product managers should learn to code, and the resulting generalist will own the future. The advice is not wrong on its face. People who can both ship and reason about product will do better than people who can only do one. Skill acquisition is generally net positive.

The advice is also unconsciously optimizing for the input AI is making cheaper. Building skill, formerly scarce, is becoming more abundant. The advice tells people to acquire more of it. Position (meaning prior domain expertise and existing community access) is not similarly affected. AI does not produce either of those for anyone. If returns flow to inputs that remain scarce, the better marginal action is to acquire the kind of input AI is not making abundant.

The builder-Twitter framing treats “anyone can build now” as the punchline. The actual punchline is the inverse. Anyone can produce working code now, but producing a successful product still requires the parts AI did not touch. Those parts (domain insight, customer access, taste, and trust) were the hard parts in 2015. They are the hard parts in 2026. The cost of the easy parts collapsing simply makes it more obvious which parts were always the hard ones.

To be specific about what this argument is not claiming: it does not claim that Path A fails, nor that engineers should not learn product or that PMs should not learn engineering. It claims that the disproportionate returns from the current AI shift accrue to a path the dominant career advice does not foreground, and that this path is accessible to people who already have domain expertise, including people who do not match the standard tech-founder archetype.

Anyone can produce code now. Building a product was always about everything else.

Practical implications

For someone on Path A: the path works, the competition for distribution is intensifying, and the burnout rate is well-documented. The relevant adjustment is going in informed.

For someone with significant domain expertise who has previously been told their niche was “too small” or “too specialized” to support custom software: the cost calculation that produced that judgment is no longer the same calculation. Whether the niche is now economically servable is a question worth re-running with the current cost structure rather than the one that applied in 2023.

Three questions worth working through:

1. What domain do you understand deeply enough to recognize a workflow problem that other people in that domain treat as normal?

2. What community within that domain are you already trusted in?

3. What would you build for them if building were nearly free?

Building is nearly free. Domain expertise and community trust are not. Compound the second.