Anyone Can Build
Today’s models are already enough to collapse the cost of software and move the advantage somewhere else.
“Anyone can cook.” — Auguste Gusteau, Ratatouille, 2007
Pixar built a whole film around that line, and almost everyone gets it wrong. Gusteau’s motto sounds like populist cheerleading: everyone’s a chef, grab a pan. But the movie’s real claim arrives through Anton Ego, its most feared critic, and it runs the other way: greatness isn’t evenly distributed, yet it can come from anywhere. Not everyone who picks up a knife becomes an artist—and the one who does is a rat.
That, I’ve come to think, is the sharpest frame available for what AI is doing to software. Anyone can build now. That is not the same as everyone building something that lasts. The distance between those two sentences is the subject of this essay.
Prologue: Three decades in the kitchen
Gusteau’s line lands for me because I didn’t come up through anywhere prestigious. I taught myself to code by reading other people’s programs and got pulled into the early open-source world, where the work itself was visible to the companies that mattered. Straight out of high school, at the peak of the dot-com boom, I was hired by Netscape. I got there by building things, not by pedigree. In Ego’s terms, I was the rat who wandered into the kitchen.
From Netscape I went to Mozilla, where I helped build Firefox as it grew to roughly a third of the web. Then I founded a company that One Medical acquired a few years later. I spent the next eight years there, helping scale its technology team from a couple dozen people to 500 and building the medical record and member experience behind a better kind of primary care. I served as VP of Engineering when it went public and later as CTO, leading the technology organization through Amazon’s acquisition. My work has ranged from graphics code and memory allocators to company strategy, alongside some of the sharpest people I’ll ever work with.
I stepped back from operating a couple of years ago and spent much of that time head-down in frontier models. I started as a hater—not a polite skeptic—because the early versions genuinely didn’t work. Fluent, confident, and wrong is not useful. I suspect many smart people still have a verdict frozen at one bad encounter with a free chatbot. When Andrej Karpathy wrote that his coding had flipped from mostly hand-written to mostly agent-driven in a matter of weeks, what struck me wasn’t the speed. It was how far apart people’s realities had become: some engineers were already living inside the shift, while most people had barely noticed it. Somewhere in the last year, I crossed that gap myself: from hater to believer.
Around the time Opus 4 and GPT-5 came out, I could tell the tools were starting to work. They still failed often enough that I didn’t fully trust them, but the direction was clear. By Opus 4.5 and GPT-5.4, they did work. Not for every task and not without supervision, but reliably enough to change how I built software. Now, with models like Fable 5, I think we’ve fully crossed the line: the best model is better than roughly 60% of the engineers I’ve worked with. Not flashier—better. It’s not because it writes clever code. It’s because it does the boring, senior work: it digs through the codebase before acting, validates assumptions, runs the tests, checks its own output, and notices the thing three files over that the fix will break. That willingness to do the unglamorous verification is what I valued most in the strongest engineers I knew. The machine now does it by default, tirelessly, at 2 a.m.
That verdict rests on nearly thirty years of scar tissue. I can usually feel when a model is over-engineering, designing a bad system, or digging a hole, and when it is crushing the work and I should get out of its way. That experience is an advantage and a blind spot: I can’t unlearn what I know to discover what these tools feel like without it. How does the next generation build the judgment I’m leaning on, and do they even need to?
Painters went through something similar when photography arrived. A camera could record a face or a landscape without a painter, so faithful representation mattered less as painting’s defining job. Painters pushed further into perception, feeling, and form. Software may be at that point now: if the machine can handle the rendering, more of the value moves to the judgment behind it.
Execution time is collapsing; compounding time is not. Agents can parallelize implementation. They cannot instantly accumulate trust, living data, relationships, physical learning, or taste. The scarce thing is moving from the ability to produce software toward knowing what deserves to exist, and toward the advantages that real elapsed time creates.
This isn’t a prediction about some future superintelligence. It’s an attempt to work out what to do about something that has already happened. If building is no longer the hard part, most of what we assumed about software companies—their moats, pricing, headcount, and reason to exist—is up for renegotiation.
1. Start with the graveyard
Before we talk about what’s coming, look at what’s already gone, and at one of the most common coding loops of the last fifteen years. You got stuck, pasted the error into a search box, landed on a Stack Overflow thread from 2013, copied the answer, and adapted it to the system in front of you. That was never the whole job: judgment lived in choosing, adapting, and integrating. But software development already depended heavily on other people’s accumulated answers. Models didn’t invent that loop; they moved it into the editor and industrialized it.
Third-party estimates put Stack Overflow’s traffic down roughly 75% from its peak, while new questions fell from more than 200,000 a month at the 2014 peak to 3,862 in December 2025.1 Questions were always the narrower signal. Millions who used to arrive at an already-answered thread now never do. The public square where a generation learned to code emptied out in about three years.
The collapse is the point: this is not a forecast. Software knowledge is now made and shared differently, and most of us barely noticed the switch. These shifts feel gradual and then look, in hindsight, total.
And there is no single model on the other side of that switch. OpenAI’s models run long, autonomous jobs; Anthropic leads several current coding benchmarks, though some comparisons are disputed; open-weight labs keep lowering the cost floor.23 “Which model is best?” has stopped being a useful question without three qualifiers: best at what, over what horizon, and at what price? A serious setup is a routing table: this job to that model at this price, revised as the capability and price sheets change.
At the top end, governments are getting involved. OpenAI began GPT-5.6 with a short, U.S. government-requested limited preview before its general release.4 Anthropic faced a more direct intervention: it was ordered to suspend Fable 5 and Mythos 5 under U.S. export controls, then restored Fable globally and Mythos more selectively after the controls were lifted.5 The precedent matters because future capability may not arrive evenly for everyone.
2. Inside the build loop, time went to zero
Most of my code is no longer typed by me. It is written by agents: models that take a task, read the codebase, make the change, and run the tests on their own. I can fan out ten agents, or a hundred, and they work around the clock with no standups, no context switching, no sleep. That breaks the link between headcount and speed. Some clocks still matter: trust, proprietary data, and relationships only accumulate on the calendar. But the build loop itself no longer runs on human time, and software has become cheap to produce in a way it never was when engineering time set the budget. The limit now is how much useful work I get out of compute, and what that compute costs. In practice, cost is the one that bites.
Models are trained on decades of how humans build software, so they plan the way we always have. Tell one “I want a plan to do X” and it will usually give you a conventional roadmap: v0, v1, v2; a sequence of phases, each carrying a list of risks pushed into the next. That was rational when getting a phase wrong meant wasting months of engineering. It is not rational when implementation is cheap. The result looks responsible, but often it just converts unanswered questions into milestones and unnecessary extra work.
So I have to fight the model’s instinct to plan cautiously. My instruction is usually: if you don’t know the answer, you haven’t dug deeply enough or looked hard enough. Read the code. Map the system. Trace the dependencies. Design the tests. Resolve as many risks as possible while planning instead of assigning them to a future phase. I often have an agent produce a massive HTML plan document, complete with tables and diagrams, then keep pushing until it describes the full destination and a credible route there.
The aim is a plan that goes from 1 to N, not a v0 that cautiously reaches 2 and leaves the hard questions for v1 through v5. With a model like Fable, much of the discovery and de-risking can happen before it writes the first line. Not all of it: some questions only become answerable when a real user touches a real product, and no amount of planning can settle them. The test for any phase is whether it is buying information or merely deferring work. Prototype to learn. Otherwise, plan to the full destination, the basic instinct behind spec-driven development.6
Once the plan is real, implementation looks less like a prompt and more like a loop: read the code, draft, check the draft against evidence, write and run tests, read the failures, fix the result, repeat. Anthropic’s name for the formal version is evaluator-optimizer.7 The name matters less than the behavior: the model keeps doing the unglamorous verification until the work clears a bar.
Every pass through that loop costs tokens. Deeper reasoning, another self-check, another round of tests: each can buy more correctness, but each adds to the bill. Quality stops being a fixed property of the model and becomes, within limits, something you purchase. The question is no longer just “can the model do this?” It is “what will it cost to get it done to my bar?”
That is why per-token pricing is so misleading. Fable 5 lists at $10/$50 per million tokens, twice Opus 4.8’s $5/$25. Those numbers are here to illustrate the spread, not because you need to know what a token costs, or even care much what one is. The useful unit is cost per finished task. If Opus needs a correction pass, that is two runs; if Fable lands it on the first, the gap narrows. On hard, long-horizon work it can invert because the weaker model spends more total tokens thrashing. Anthropic’s examples are vendor-reported, but the shape matches what I see: a physics run reached in 36 hours, on a third of the reasoning tokens, what a rival reached after four days; Stripe compressed a months-long migration across a 50-million-line codebase into about a day.8
It does not always invert. On routine work, the cheaper model may already clear the bar, making the premium pure waste. Fable is also the wrong tool for quick back-and-forth; at maximum reasoning it can take nearly two minutes just to start responding.
In my own work, though, I am not disciplined about routing. I let Fable or GPT-5.6 do easy things all the time because the attention required to switch models costs more than the tokens I would save. At company scale, with repeated workflows and material spend, I would absolutely route each step to the cheapest model that reliably clears the bar and measure cost per completed workflow, not cost per million tokens. That routing is beginning to move inside the systems themselves, with a frontier model handing bounded work to a smaller one when it can do the job more cheaply. Token economics is an operational discipline at scale, not something every individual needs to optimize on every prompt.
3. Even if it stops here
Steve Yegge published a piece called The Flat Curve Society that I keep returning to, less for its prediction than for the mental move it forces. His argument is that the capability curve may keep rising while appearing flat to most of us: the most dangerous models get gated, and most people hit a ceiling where they can no longer tell models apart.9
He names two ceilings. Your demand horizon is set by the hardest problem you bring: if your work is not hard enough, a smarter model has no room to pull ahead. Your discernment horizon is the hardest answer you can judge. Past it, checking the work is itself beyond you.
“You can’t hand out an intelligence engine that nobody can supervise. Superhuman means unverifiable.” — Steve Yegge, The Flat Curve Society (condensed)
You do not have to buy the full lockdown thesis to steal the premise. Assume, for the sake of argument, that this is roughly as good as it gets for you and me: no further miracles, just today’s models becoming cheaper and more reliable. Even under that pessimistic assumption, the change is total. The plateau is not bad news; it is firm ground. Founders have spent years watching each release threaten to obsolete whatever they built. If capability stabilizes, we can finally reason about the consequences. If it keeps screaming upward, those consequences just arrive faster and harder.
4. What is a software company worth now?
In the past 12 months, I have built a handful of completely unrelated products, each in a weekend, each something that a few years ago would have been a company: a team of ten and the better part of a year. One person. Two days. If that is true for me, it is true for your customers—and your competitors. And I am the mild case: I build these things for myself, because I can. Someone building with intent, for a market they care about, starts from the same weekend and keeps going; whoever is most motivated on the problem space will accelerate ahead. It has changed the question I ask at the end of those weekends: why would I even release this?
Any model-driven edge diffuses across the ecosystem quickly. The industry has a name for this: differentiation entropy.10 Capabilities that differentiated you at launch become table stakes within months. A surprising number of the old moats were really moats against scarce engineering time. Workflow lock-in sounds durable until you notice how much of the switching cost was just that. Feature depth matters less when features are cheap to clone.
The model providers are also marching up the stack. When Anthropic’s legal plugin for Cowork hit investors’ radar, Bloomberg counted $285 billion erased from software stocks in a single session, with legal-information incumbents hit hardest.11 If your product is a thin wrapper around a capability the foundation labs will ship natively, you are building a feature on borrowed time.
So what survives? Investor Michael Bloch offers the most useful filter I have seen: is your defensibility bottlenecked by intelligence, or by time?12 The durable advantages share one property. They require real, elapsed, un-parallelizable years to accumulate:
Living, compounding data generated by operations that are themselves difficult to reproduce: not a static dataset, but a loop that keeps producing proprietary signal.
Real network effects, where each side of a market makes the others more valuable.
Atoms and the capital to move them. Cheap code does not buy a launch pad, a fab, a clinical trial, or a tokamak. Physical learning curves still run on calendar time.
Distribution and trust, often a stronger moat than the AI itself.13
The regulated human in the loop. Where money moves, medical decisions get made, or legal actions get taken, a human remains on the hook. That accountability is a structural moat, not a limitation to engineer around.14
The blunt version, which I believe: code is no longer a moat and features are no longer a moat. What remains is everything AI cannot reproduce on demand: accumulated trust, living data, deep workflow context that was never written down, distribution, relationships, and the compounding advantages that only time can produce. If your answer to “what makes this defensible?” is a description of your product, you do not have a moat. You have a head start.
5. How long does the boom last?
The optimist’s answer is Jevons paradox. It is not wrong, just incomplete. When steam engines became more efficient, Britain burned more coal, not less, because efficiency widened the range of applications. Make software cheap to build and we will not build the same amount with fewer people; we will build much more. Internal tools that needed five people for six months become two-sprint jobs. The custom integration that sat on the “nice to have” list for three years finally gets built. Demand for software has always been elastic.15
But run the tape forward. Give a company these tools and some time. First it burns down the known backlog: every ticket, refactor, integration, and requested feature. Then it powers through the shadow backlog: the ideas that were never written down because nobody had the bandwidth to try them. That may produce a couple of exhilarating years.
And then what? Software is not free after it exists. Every feature is surface area to supervise, secure, audit, and understand.16 Building past genuine demand can create negative value. Once the backlog and shadow backlog are cleared, the constraint moves again. It stops being “can we build it?” and becomes “do we know what is worth building?”
That next phase belongs to the things that generate that knowledge: taste, tight customer feedback loops, and go-to-market muscle. It belongs to the team that learns fastest, not the one that produces the most code.
The same cheapness that clears your backlog also makes your shipped product a spec: a legible blueprint a competitor can reproduce, then use as the starting line for its own ideas. You can peak on features because features have become the cheap part. You do not peak on judgment, relationships, or your rate of learning; those keep compounding. The moat question and the productivity question therefore have the same answer: the only durable advantage is the part of your company that cannot be read off the finished artifact.
AI does not eliminate value; it relocates it. Cheap execution will unleash an enormous burst of software, but eventually producing more matters less than knowing what deserves to exist. The winners will not be the people who generate the most code. They will be the people who learn fastest what is worth building, and who have accumulated what a competitor cannot copy from the screen. Anyone can build now. What lasts is still rare, and it can still come from anywhere.
Part 2 begins with the first sacred rule to fall and follows the price change through how software gets built, priced, funded, staffed, and learned.
Stack Overflow’s decline — new questions fell to 3,862 in December 2025, a 78% year-over-year drop, against a 2014 peak north of 200,000 a month: DevClass. Third-party traffic estimates put visits down roughly 75% from peak — Hyperdev / Matsuoka, citing Similarweb-based analyses; Stack Overflow has historically disputed such estimates. Organic-search share and current visits: Similarweb; the ~279M-visit November 2022 baseline via TechCabal, from Similarweb data. AI-tool adoption (84% using or planning to use, up from 76%): Stack Overflow 2025 Developer Survey. The deeper question-volume analysis: The Pragmatic Engineer.
GPT-5.6 general availability, Sol/Terra/Luna tiers, pricing, and Terminal-Bench 2.1 scores. OpenAI; Simon Willison; Vellum benchmark analysis.
Comparative landscape — Fable 5 at 95% on SWE-bench Verified per the independent vals.ai leaderboard; the SWE-Bench Pro comparison via Simon Willison (vendor-reported; OpenAI’s audit claims ~30% of the benchmark’s tasks are broken); the cost floor per DeepSeek’s rate card and Z.ai’s GLM-5.2 pricing; VentureBeat on open-weight GLM-5.2 matching frontier coding at a sixth of the cost.
OpenAI’s government-requested limited preview of GPT-5.6 and its objection to that process becoming “the long-term default.” OpenAI; TechCrunch; the ~20-partner figure via The Next Web, citing Bloomberg.
Anthropic’s June 9 release of Fable 5 / Mythos 5, the June 12 suspension to comply with U.S. export controls, and the July 1 restoration. Anthropic: launch post, access statement, and redeployment announcement.
I arrived at this by trial and error, but others are circling the same instinct — a comprehensive spec first, then build the whole thing: spec-driven development; and detailed up-front specs for long-running agents: Anthropic.
The agentic loop and the evaluator-optimizer pattern — one model generates, another evaluates and feeds back, repeating until the output clears a bar. Anthropic, “Building Effective Agents.”
Fable 5 vs. Opus 4.8 economics — the official rate card ($10/$50 vs. $5/$25 per million tokens): Anthropic pricing docs. The Stripe migration and the 36-hour physics run: Anthropic’s launch announcement (vendor-reported). Time-to-first-token at maximum reasoning effort: Artificial Analysis. The cost-per-finished-task framing: CloudZero.
Steve Yegge, “The Flat Curve Society” — demand vs. discernment horizons, the plateau argument, and the “SaaS is back” reversal. Medium.
“Differentiation entropy” coined by The Percolator; synthesis in Forbes.
The February 3 selloff after Anthropic’s Cowork legal plugin — a $285 billion single-session rout across software stocks per Bloomberg; the per-company closes via ComplexDiscovery.
Michael Bloch (Quiet Capital), “The Only Moats That Matter” — the intelligence-vs-time filter, living data, and time that can’t be parallelized as “the meta-moat.”
What still defends a product in 2026 — workflow depth, proprietary feedback loops, distribution, trust. a16z, “AI Will Eat Application Software”; Jerry Chen (Greylock), “The New New Moats.”
The regulated human-in-the-loop as a structural moat (fintech, healthcare, legal). Ardent Venture Partners, “The Moat Just Moved.”
The counter-reading — companies are constrained on ideas, not capacity; and more code means more to supervise, audit, and understand. Stephan Schmidt, “Everyone Gets Jevons Paradox Wrong”; Jim Rutt.