When Everyone Does Build

Last month I asked what would be left when everyone can build. That essay followed the meaning: when making gets cheap, being chosen gets expensive. “Can build” became “does build” faster than the argument could settle. This one follows the money: what happens to cost, to spend, and to organisations when the building floodgate opens.

The building is real, and I’m part of it. You know the feeling: the tiny tool works, then quietly becomes another thing you own. A few years ago custom software required a budget, a team, and months of work; I’ve watched one person describe an idea on a Friday and demo it working on the Monday. Cheaper creation has a second consequence: we create much more of it. Every department can build an internal application; any irritation can become another dashboard, agent, or database before anyone asks who owns it. The individual build gets cheaper while the organisation surrounding all those builds gets more complicated.

Which leads to the question part one left open: will AI reduce what we spend on software, or tempt us into producing so much more that aggregate cost and complexity keep rising? The early numbers cannot settle that question yet. What they can show is every condition for the second answer forming.

We are measuring the wrong unit

A coding benchmark can improve while the company gets worse at shipping software. Most discussion of AI coding tools measures the benchmark: how quickly someone completes a programming task. That matters, and it captures one layer of a three-layer system.

One controlled experiment found developers completing a bounded JavaScript task 55.8 per cent faster with GitHub Copilot. ^[1] METR later found experienced open-source developers using early-2025 tools took 19 per cent longer on real issues in familiar repositories, while believing they’d been faster. ^[2] METR has since said developers were probably seeing larger gains by early 2026, though selection effects kept it from producing a reliable estimate. ^[3]

Acceptance time absorbs task-level gains when convincing code returns as rework. The manager’s embarrassment comes later: you approved the code, then watched the team pay to correct it.

By 2026, the job has moved upstream: you tell the tool what you want, set the boundaries and acceptance gates, then go scroll Instagram Reels. You come back hoping it listened, and review what it built.

Repository context, review, testing, integration, and correction determine whether task speed reaches delivery. I wrote about the individual version of this gap: the clock that matters runs to acceptance, and it includes the rework.

DORA’s research across thousands of teams found the same gap at scale. Its 2024 analysis associated a 25 per cent increase in AI adoption with a 1.5 per cent drop in delivery throughput and a 7.2 per cent drop in delivery stability. ^[4] By 2025 teams were adapting: throughput turned positive while stability continued to suffer, and the greatest returns came from the organisational system around the tools: quality internal platforms, clear workflows, healthy data. ^[5] DORA’s own summary is the point in one line: AI is an amplifier, magnifying the strengths of high-performing organisations and the dysfunctions of struggling ones. Faster tasks are still colliding with company red lights.

The distinction that matters is the unit being measured.

Generating code is a task. Delivering dependable software is a system. Creating business value is an organisational outcome. Improvements at the first level travel to the other two only through hard, unglamorous joins, and a benchmark that measures the first level says almost nothing about the third.

The prototype was never the expensive part

A prototype is highly visible. Someone types a prompt; screens appear; buttons work; data moves. The application looks almost finished.

The remaining work is much harder to see. Who owns the data? How is access controlled? What happens when an upstream system changes? How are errors detected? What does this replace? Who supports it when its creator leaves? Who decides whether it should still exist three years from now? None of these questions produces an impressive demo. They decide whether the demo ever becomes valuable.

The risk runs like this: a team builds a two-day automation for one internal handoff. Six months later it sits inside a customer-facing process, feeds three spreadsheets, owns a shared mailbox, and can no longer be switched off. The build cost was two days. The dependency has no budget line.

AI lowers some of these later costs too: it generates tests, documents systems, helps with migrations, and for disposable tools and narrow automations it can genuinely lower the total bill. The danger sits elsewhere: a cheap build becoming a long-lived dependency without anyone consciously making that decision.

“A two-day automation quietly becomes a three-year system.”

The software rebound effect

Economists have a name for what can happen when a resource gets cheaper: Jevons paradox. Efficiency improves at the unit level, so consumption rises, and when the rise overwhelms the saving, total spend goes up.

Software is running the same experiment. Imagine an organisation with the capacity to approve and build ten internal applications a year. With AI, the cost of each initial build collapses, so it builds fifty. Even at half the cost per build, the company spends more overall, because it has created five times as many things to govern, integrate, secure, and maintain.

This pressure is arriving in portfolios that were already crowded. Okta’s 2024 customer data put the average company at 101 applications, past 100 for the first time; its Australian customers averaged 90, up 13 per cent in a single year. ^[6] Those numbers describe one vendor’s customer base, and they establish the baseline: sprawl predates the boom that is about to accelerate it.

The development expense declines while the costs migrate somewhere less visible: more systems for security to review, more interfaces for employees to hop between, duplicated data for architects to reconcile, “small experiments” for operations to keep alive. These costs rarely return to any project budget; they surface as meetings, manual reconciliation, slower decisions, and growing dependence on systems nobody wants to own. Costing a single AI-built application is easy and misleading; the honest unit is the portfolio.

A company can produce software faster than it can absorb it

Software creates value only when something in the organisation changes: a decision gets faster, a manual step disappears, an error becomes less likely, a customer gets a better outcome. Installing another interface guarantees none of this.

An organisation can build twenty AI tools while its incentives, approval processes, data ownership, and operating model stay exactly where they were. People work around the new systems: the result gets copied back into the old spreadsheet, because nobody changed the approval path, and the old workflow quietly returns. The software functions; the organisation fails to absorb it. That failure mode has a familiar shape: the clean demo running on a dirty organisation, now mass-produced.

Gartner has reported the die-off: by the end of 2025, at least half of generative AI projects had been abandoned after proof of concept, on poor data quality, inadequate risk controls, escalating costs, and unclear business value. ^[7] Most of that list describes weak absorption.

A company can now ship tools faster than it can change ownership, workflows, and behaviour. The bottleneck moves from production to absorption.

The receipts from part one

Part one argued the edge would move to meaning: the human layer that decides what gets chosen. A month later, the argument has numbers.

Stripe’s Atlas data shows the flood mid-arrival. By 2025, 42 per cent of Atlas founders described their businesses as AI companies, up from 15 per cent in early 2023, and in the second quarter of 2026 solo founders hit an all-time high of 63 per cent of new Atlas C corporations. ^{[8] [9]} And the results are concentrating, consistent with a contest of meaning. Among solo-founded Atlas startups, median first-six-month revenue fell 23 per cent year over year in 2025 while top-decile revenue rose 19 per cent. Four years earlier, the top decile earned about 34 times the median; by 2025 the gap had widened to 61 times. ^[9]

Your feature can work perfectly and still disappear into a market flooded with competent copies. Entry keeps getting easier; being chosen keeps getting dearer. Distribution, capital and timing feed the widening too; so does a contest of meaning, and this is exactly the shape part one predicted it would leave in a revenue table.

Cheap creation still expands the economy. Twenty per cent of 2025 Atlas startups charged their first customer within 30 days of incorporation, up from 8 per cent in 2020, and median first-six-month revenue across the whole 2025 cohort rose 39 per cent. ^[8] The problem begins when creation itself becomes the objective: a company celebrating applications launched, a founder celebrating build speed, a team celebrating code volume. Building became easy to measure at exactly the moment it stopped measuring success.

Somewhere right now, a steering committee is approving a dashboard that counts the dashboards.

The new discipline is selection

Until now, most organisations had more ideas than engineers, so prioritisation happened partly through scarcity: weak ideas died because they couldn’t get a team. AI weakens that filter wherever a prototype can bypass the engineering queue. Your backlog used to reject weak ideas for you; now every weak idea can arrive looking finished.

So the filter has to be rebuilt on purpose, as deliberate refusal. Part one described the trait: a company with strong judgement uses AI “to kill ideas as readily as it spawns them”. Selection is that trait turned into process. Before building, a leader should be able to say which existing process or application disappears, who owns the new system for its whole life, what measurable behaviour changes, and why this deserves to become permanent. Founders face the mirror-image test: which advantage survives the weekend when a competitor rebuilds the visible product?

Engineering now proves feasibility. The case for existence has to come from somewhere else.

Johnny’s verdict

My bet: we will build five times as much software because each project looks cheap alone, and total spend will rise. Nobody has measured the aggregate yet; treat the bet as the planning assumption and make it pay either way:

• Price the full life. Before approving anything, name the year-three owner, the process that disappears, and the boring costs: integration, security surface, support load, attention. A build with no funeral attached is an addition, whatever the slide says.
• Make removal a first-class metric. Count systems retired and consolidated next to systems shipped. A portfolio that only grows is a portfolio nobody is managing.
• Judge tools by changed behaviour. Which decision got faster, which manual step died, which customer got a better outcome. Licences deployed and tokens consumed measure enthusiasm.
• Founders: name the asset that survives cloning. Data, distribution, trust, workflow depth. If the honest answer is “the feature set”, the weekend that built you can rebuild you. The 61-times table is the scoreboard.

Part one ended with the maker’s ledger: AI lowers the cost of making and raises the value of meaning. A month of data adds the buyer’s ledger: it also raises the volume of the made, and volume has a carrying cost that lands on whoever approved it.

The cost of producing software is falling faster than organisations are improving at absorbing it. The widening gap will decide whether the next decade of technology budgets buys leverage, or merely accumulates software.

You are auditing my software portfolio, which has become cheap to grow. Start with the evidence you already hold: search our past chats and your memory of me, and collect everything I asked you to help build, spec, or automate (apps, agents, automations, dashboards, scripts), including the ones I only mentioned in passing. If you can't reach our history, ask me to list what my team or I have built or commissioned this year instead.

Judge each item against these rules:
1. What existing process or tool did it replace? If nothing was replaced, it was added.
2. Who owns it in year three, by name?
3. What measurable behaviour changed because it exists?
4. What does it cost beyond the build: integration, security surface, support, attention?
5. Knowing all that, would we build it again today?

Deliver a keep / consolidate / remove table, worst offender first, plus the one build that should never have been approved and the single question that would have stopped it.

If you can browse the web, read the full essay first — it carries the complete argument and sources: https://thejop.com/essays/when-everyone-does-build/

Prompt from "When Everyone Does Build" — Johnny Opinion Press, thejop.com