DEV Community: Pathmode

The Cost of Being Worth Using

Janne Lammi — Sun, 14 Jun 2026 11:39:04 +0000

A 2026 NBER working paper followed more than 100,000 developers across four app marketplaces after they picked up AI coding tools. The tools worked. With the most autonomous of them, commits jumped 180%. Then the gain bled out downstream — about 50% more projects, only 30% more releases.

Total usage of what they shipped: unchanged.

More code. More releases. The same number of people using any of it.

The pattern is simple:

AI is increasing software output.
Usage is not increasing with it.
Attention is consolidating, not expanding.
The scarce skill is no longer building. It is deciding what deserves to exist.

The App Store Confirms It

Zoom out from those developers and the shape repeats everywhere.

Apple's App Store took in 557,000 new app submissions in 2025 — up 24% year over year, its biggest year since 2016, reversing a multi-year slide. The first quarter of 2026 then ran 84% ahead of the year before, the largest quarterly jump in a decade. The firms tracking it name one cause: vibe-coding. Anyone with an idea and a chat window can ship a functional app in a weekend now.

Total app downloads, across every major store, grew under 1%.

That's the cut. The supply of new apps, up double digits and then some. The appetite to download them, flat. The shelves filled up. Nobody new came to shop.

The Hours Are Growing. The Access Isn't.

Here is the stat that looks like it kills the argument, so let's put it on the table.

People spend more time in apps every year, not less. 5.3 trillion hours in 2025, up 3.8% over the prior year. Time-in-app has climbed for a decade.

But read the second derivative. That growth is decelerating — 7.7%, then 5.8%, then 3.8%. And it isn't spreading out. Social and communication apps alone eat about a third of all mobile time; one company's apps take roughly a fifth. The hours are growing, and they're pooling in the handful of places people already were.

Rising attention doesn't reach your new thing. The pie got bigger. The new entrants still don't get a slice.

The attention ceiling is the number of things any person will ever choose to care about. It didn't move when building got cheap. It won't move when building gets cheaper still.

This Isn't a Phone Problem

Scott Brinker has counted the marketing-software landscape every year since 2011. It went from 150 tools to 15,384 — a hundredfold in fifteen years, AI the latest accelerant.

Cursor, the AI coding tool, went from zero to $2 billion in revenue in about three years — the fastest any business-software company has ever made that climb. Building has never been cheaper or faster.

The buyers didn't get fifteen thousand times more attention. The average knowledge worker switches apps about 1,200 times a day and loses four hours a week just reorienting. Rich-world internet penetration sits at 93% — there are no new users to go get. And the front door is closing: roughly 60% of Google searches now end without a click, on the way past two-thirds as AI answers swallow the page. The traffic that used to find your new tool isn't being redistributed. It's evaporating.

Where the money goes instead: up. Microsoft's cloud business alone grew 23% to $169 billion last year. Spend is rising — and consolidating into the few platforms big enough to bundle. The long tail competes for what's left.

What AI collapsed	What didn't move
Cost of writing code	Cost of distribution
Time from idea to shipped app	Demand for new products
Who can build software	Available user attention
Speed of iteration	The bar to earn a place in someone's life
Number of apps submitted	Number of apps actually used

The attention ceiling looks the same in enterprise software as it does in mobile. The shelves fill. The buyers don't multiply.

The Filter Is Gone

So why is supply exploding straight into a demand wall?

Because the cost of producing software fell off a cliff. The price of the AI capability itself — the inference to hit a given benchmark — has dropped on the order of 50x a year, by Epoch AI's measure, echoed in Stanford's AI Index. That capability is the raw material of building, and it dragged the cost of prototyping down with it. What took a funded team and two quarters takes one person and an afternoon.

The cost of making something collapsed. Not one cost of being worth using moved an inch. Distribution didn't get easier. Attention didn't expand. The bar for the tenth app in a category that does the same thing sits exactly where it was — except now there are ten of them by Friday instead of one by next quarter.

AI collapsed the cost of building. It didn't touch the cost of being worth using.

The Decision Nobody Makes Anymore

Today anyone can pull on the turtleneck, open a chat window, and feel like a reborn Steve Jobs. So can everyone else, in your exact category. The feeling of building something visionary got cheap. Being right about it didn't.

When building was expensive, building was the filter. You couldn't ship the wrong thing easily, so the cost of construction did your triage for you. Most bad ideas died in the estimate.

That filter is gone. The estimate is now an afternoon. Which means the decision the build used to force — is this worth existing? — doesn't get made by anyone. It gets skipped. The half-formed thing ships and joins the pile of installed-and-never-opened.

The bottleneck moved up the stack. Not to whether you can build it. To whether it should exist — and to what, precisely, earns a slice of attention nobody owes you.

That is a judgment problem. It always was. The cost of building was just hiding it.

What This Means for Builders

Start from evidence, not ideas. Real user friction, not feature assumptions. When execution is cheap, the competitive edge is knowing which friction to resolve.

Define the adoption outcome before the first line of code. Not "build a checkout flow" — but "a user who completes purchase without contacting support." If you can't write the adoption outcome, you don't know what you're building.

Name what must not be built. The cheap build's greatest risk isn't failure — it's drift. Name the constraints explicitly before you start. A spec without boundaries is a blank check.

An intent tool can become part of the flood — one more way to generate more, faster, with less thought. We know it. So the point isn't to add output. It's to force the decision the cheap build skips, on purpose, up front: name what this is for, name what it must not become, name how you'll know it worked. Before, not after.

The 100,000 developers in that study weren't failing to build. They built more than ever. Building more just wasn't enough to get more of it used — the paper's own name for the gap is a weak link, the human work downstream that doesn't scale because code generation does.

Name the weakest link in that chain and it isn't typing. It's the decision nobody is forced to make anymore: is this worth existing, and what makes it worth a slice of attention no one owes you. Cheap building doesn't make that call for you. It just lets you skip it faster.

That's the trade the whole industry is taking right now without naming it.

The cost of building fell off a cliff. Judgment didn't — which is exactly why it's the only scarce thing left. Context isn't judgment, and judgment is now the whole game.

Start building with intent →

Sources: Demirer, Musolff & Yang, "Writing Code vs. Shipping Code" (NBER w35275, 2026) for the commits → releases → usage chain; Appfigures for 2025 App Store submissions (Apple only), and The Information via TechCrunch / Entrepreneur for the +84% Q1 2026 jump (Apple only); Sensor Tower State of Mobile 2026 for total downloads (all major stores) and time-in-app; Epoch AI and the Stanford HAI AI Index 2025 for the inference-cost decline; Scott Brinker / MarTech.org for the martech-landscape count (150 → 15,384); TechCrunch for Cursor's ARR trajectory; Harvard Business Review (2022) for the 1,200-toggles-a-day study; the ITU's Facts & Figures 2024 for 93% high-income internet penetration; SparkToro / Datos for zero-click search; and Microsoft's FY2025 results for cloud-revenue concentration. App-market figures are vendor estimates; submission counts are Apple's App Store only, while downloads span all major stores; the inference-cost figure is the median rate to reach a fixed capability, not frontier cost.

Input Factories

Janne Lammi — Tue, 19 May 2026 12:30:46 +0000

Everyone is building agent factories.

Cursor, Codex, Claude Code, Devin. Coding agents that plan, write, test, ship. Internal pipelines with five, eight, twelve sub-agents in series. Orchestrators that retry. Eval loops. Tool calls. The pipeline keeps getting better, almost weekly.

This is not the hard part.

A factory amplifies whatever you feed it. If you feed it a thin brief, it builds something thin, faster. If you feed it a contradictory spec, it resolves the contradiction silently — usually wrong. If you feed it nothing, it invents.

Most teams are scaling their ambiguity.

The agent factory is solved. The input factory isn't.

By "input factory" I mean the layer above the build. The thing that decides what the agents read before they generate. It contains:

the intent (why this exists, who it's for, what it must do)
the product spec (scope, edges, what good looks like)
the design rules (tokens, voice, components, don'ts)
the brand (how it sounds, what it never says)
the playbooks (how this team approaches this kind of work)
the reference code (this is how we do it here)

These already exist. They live in Notion, Figma, Slack threads, the repo, somebody's head. They drift. They contradict each other. Nobody owns them. When the build is wrong, no one knows which one to fix.

This is the bottleneck.

Here is the loop most teams are running today:

Agent builds something
Designer or PM reviews the PR
PR is wrong
Fix the PR

Here is the loop they should be running:

Agent builds something
Designer or PM reviews the PR
PR is wrong
Which input was thin, stale, or contradictory?
Fix the input
Run the next thing through the better input

The first loop scales the work. The second loop scales the system.

The first loop is what most teams will look back on as the embarrassing era — when senior people spent their time fixing outputs an agent produced from inputs the senior person never actually wrote.

There is a role shift coming, and it is bigger than it sounds.

The designer stops being the one who fixes the output. They become the one who curates the system that produces the output. When the build comes back wrong, the question is no longer "how do I edit this?" but "what was missing from what the agent read?"

The PM stops chasing tickets. They author the intent — the why — and the evidence behind it. The thing nothing downstream can guess at.

The engineer stops translating. They integrate. They write the reference code, the conventions, the constraints. They make the input layer real in the repo.

In this world the seniority of the work moves upstream. The most leveraged person on the team is whoever owns the inputs.

I think the reason nobody has built this yet is that the inputs feel like just files. Markdown, Figma frames, brand decks, a couple of shared docs. It feels low-status. The factory feels high-status.

But the factory is a commodity. There will be five good ones in eighteen months and they will mostly do the same thing.

The inputs are not a commodity. They are your product's actual intent, captured and made legible to a machine. They are the only thing that makes your factory's output yours instead of generic.

A real input factory does a few things the file-soup version doesn't:

It authors — the inputs are written deliberately, not assembled from drift.

It evidences — every claim points back to the user signal that justifies it.

It governs — somebody owns each input, somebody updates it, the staleness is visible.

It compiles — at build time, the right slice of input is packaged into the agent's context. Not the whole pile. The right slice.

It diffs — when the output is wrong, you can trace which input was insufficient, and improve it.

Karpathy has been writing about a version of this from the other direction: raw notes compiled into a wiki an LLM can read. He is right about the pipeline. The thing he leaves implicit is that for product work, the raw notes aren't notes. They are intent, spec, brand, design rules, playbooks. The wiki isn't a wiki. It is the input factory.

The companies that figure this out first will look, from the outside, like they have better agents.

They won't. They will have better inputs.

If you are building an agent factory right now, the question worth asking is: what does my factory read, who wrote it, and how do I know it's still true?

If you do not have a good answer, the factory is the wrong place to spend the next quarter.

Build the input factory.

I'm building Pathmode, the input layer for product teams building with AI.