When code gets cheap, the mockup loses its job

Almost every argument about how to build software is an argument about one number: what it costs to change the software late. If that number is high, waterfall makes sense. If it is low, agile does. For fifty years the number was high, so we built an industry around settling decisions early, while settling them was still cheap. Design was the best version of that, and Figma was the best design tool.

The number just fell. Agentic code generation cut the cost of producing and changing working software by something like an order of magnitude. When the expensive thing gets cheap, everything we built to economise on it has to earn its place again. A mockup is a forecast of expensive code, and you stop needing the forecast once you can build the thing it was predicting.

Why we ever designed up front

The case for deciding early was empirical, and it held for decades. Barry Boehm looked at waterfall projects at TRW and IBM in the 1970s and found that a defect caught while you are still writing requirements costs almost nothing to fix, while the same defect caught after the system ships can cost up to a hundred times more. That was on large, formal projects. The cost of change rose steeply with time.

That curve is the hidden premise under every heavyweight process. If changing code late is brutally expensive, don’t change it late. Get the decision right before the costly part starts.

Design is the strongest way to do that. A wireframe is a place to be wrong for free. A high-fidelity prototype is a place to be wrong that looks expensive and isn’t: you can throw away a screen, a flow, an entire information architecture, and all you have spent is design time. The whole Figma stack exists for this. Multiplayer canvas, design systems, dev handoff, prototypes real enough to user-test. All of it lets an organisation make the expensive calls about a product before committing the expensive resource, which is engineering.

That is the job Figma was hired to do. Make the costly decision cheaply, somewhere other than code, so code only ever gets written once the decision is settled. While code was the expensive part, that was worth a great deal, and Figma did it very well.

Agile asked for a flatter curve and half got it

Agile was a bet against Boehm’s curve. Kent Beck put it plainly: flattening the cost-of-change curve is “the technical premise” of Extreme Programming. If you can make changing code late nearly as cheap as changing it early, through tests and continuous integration and refactoring, then you should put the big decisions off until the last responsible moment. Late decisions are better informed, and some of them you never have to make at all. Working software over comprehensive documentation. Responding to change over following a plan.

Beck never had data for the flat curve, and the claim is gone from the book’s second edition. The idea outran the evidence. The practices were good anyway, and the curve did get flatter. It never got flat. Code stayed expensive enough that a high-fidelity stand-in still paid for itself, so most shops that called themselves agile ran a quiet contradiction. Agile in the ceremony: standups, sprints, retros. Waterfall in the part that mattered, where decisions still got front-loaded into a fully specced backlog of Figma screens during a sprint zero nobody admitted was a design phase. The manifesto asked teams to defer decisions. The economics wouldn’t let them, so they deferred the paperwork and front-loaded the decisions anyway.

Wanting a different cost structure doesn’t give you one. While code was dear, big design up front was the rational play whatever the standup cadence implied. Agile was right about what it wanted and wrong about whether engineering practice alone could pay for it.

What agentic code changed

What finally pays for deferral is a price change rather than a better methodology.

When an agent can produce a working, data-backed, interactive screen in roughly the time it used to take to mock one up, two costs collapse together. Producing software gets cheaper, which shows up directly in the unit economics of building things now. The bigger collapse is the cost of changing what you have produced. Regenerating a flow you got wrong is another prompt rather than a re-engineering project. The curve Beck wanted to flatten through discipline got flattened by price instead.

The market is already pricing this. A clutch of prompt-to-code tools turn a sentence into running software: Lovable, Bolt, v0, and Figma’s own Figma Make, shipped at Config 2025. People are paying for them at a speed the old design-tools category never saw. Lovable reportedly reached roughly $20M of recurring revenue within two months of launch, and Bolt ramped about as fast. Nobody adopts a tool that quickly for novelty. They adopt it because it does something cheaply that used to be expensive.

There is a catch, and I have written about it from the other side of the keyboard. Cheap to produce is not free to own. Someone still has to review the generated thing, debug it and understand it, and there is a hard ceiling on the complexity a non-technical builder can carry before the missing layer underneath stops them cold. The cost of code moved from typing to judgment. It did not go to zero, and that line is the one the rest of the argument walks.

You still make the decisions

A flat cost-of-change curve doesn’t mean decisions stopped mattering. It means the penalty for deciding late is gone, and that penalty was the only reason to make the decisions up front.

When being wrong about a flow costs a regeneration instead of a sprint, you stop trying to be right about it in advance. You build the leanest real version, put it in front of someone, and watch. Design the experiment rather than the artefact. What people do diverges from what they say, and a clickable mockup only ever collects the saying. The real thing collects the doing, and once the real thing costs about what the mockup costs, there is no reason left to collect the weaker signal.

So the up-front design phase shrinks, and not because designers got lazy or taste stopped counting. Its economic purpose was making the costly decision before the costly build, and the build stopped being costly. You make fewer decisions in the mockup because the cheapest place to decide moved to the running thing.

Figma’s product got better; its job got smaller

Figma’s product is the best it has ever been. Config 2025 was not a company asleep at the wheel: Figma Make, Sites, Buzz and Draw, AI threaded through the canvas, prompt-to-code shipped by the incumbent faster than the incumbent’s-dilemma script says it should be. The business is strong with it. Coming into its 2025 IPO the company was posting around $900M of annualised revenue, growing in the mid-forties percent, profitable, with net dollar retention near 132%, which means existing customers spend more each year rather than less. If product quality and execution were the question, there would be no question.

The job is the question, and the job is migrating. Design always did more than defer cost. It aligns a team, gives them a shared map of the product, lets them explore cheaply before anything is committed. None of that disappears. But cost-deferral is what made a separate design medium economically mandatory rather than merely useful, and it is the part agentic code is dissolving. Figma’s value to an organisation rested on making the expensive decision cheaply, before code. As code gets cheap, the value of making that decision in a separate, non-functional medium falls. Not to zero, but structurally.

You can read the tension in Figma’s own S-1, where the company names AI and competition among its principal risks: a business compounding beautifully, naming in the same document the force that re-prices what it sells. The capital markets have circled this for years. Adobe agreed to pay $20B for Figma in 2022, walked away in 2023 under regulatory pressure and wrote a $1B cheque to do so, and Figma went public on its own in 2025. I read the post-IPO trading as the market pricing this risk, though a share price never tells you why, so take that as my read rather than a verdict.

Dylan Field’s defence is that Figma’s rendering engine and design architecture are hard to replicate and aren’t sitting in public code for a model to learn from. He is right, and it doesn’t settle the question. That moat protects the tool. The work is relocating to code, where Figma’s engine isn’t the thing anyone is asking for.

The limits

Figma isn’t doomed. The multiplayer canvas, the design systems, the shared spatial memory of how an org’s product actually fits together are real assets, and a company growing in the forties with that retention has time and money to move. The narrower claim is harder to shake than “Figma dies”: the specific economic engine that made Figma indispensable, where code is expensive so you decide in Figma first, is weakening. Shipping a better product doesn’t repair a job that is being done somewhere else. It is a market problem that looks like a product problem.

Design judgment doesn’t disappear either. If anything it gets more valuable. When the curve is flat and you are iterating on the real thing in public, taste, information architecture and interaction sense are what separate the cheap-to-produce version that is any good from the cheap-to-produce version that is slop. What collapses is the artefact: the separate, throwaway, non-functional representation. The discipline stays, and a flat curve raises the premium on people who know which direction to regenerate in.

The mockup was a forecast of expensive code. Code got cheap, so build the thing instead of predicting it, and decide late, the way you always wanted to.