Where are all the AI apps that were promised?

Community
, , , , ,
1

The AI Apps Nobody Sees

Iceberg
Iceberg1732Ă—986 217 KB

A few days ago, Answer.AI published a quiet but precise analysis that reached Hacker News and generated 77 comments. The question they asked was simple: if AI makes developers 2x, 10x, perhaps 100x more productive, where is the software?

They looked at PyPI — the central repository of Python packages, with 800,000 packages and consistent historical data. The main finding: there is no visible productivity jump. No inflection point when ChatGPT launched. No Cambrian explosion of new packages. The update cadence of existing packages barely moved. For a technology that supposedly is restructuring how software is built, the aggregate numbers are surprisingly flat.

But the data tells a more interesting story than “AI hype is oversized.” And the discussion on Hacker News adds the pieces that the graphs cannot show.

What the data really says

The only place where Answer.AI does see a clear effect is in packages about AI — tools and libraries that are part of the AI ecosystem itself. Those show a jump of more than double in update frequency post-ChatGPT, concentrated in the most popular packages. The authors offer two explanations: either those building AI tools are also the ones who know how to use AI effectively (a skill effect), or the enormous flow of funding toward AI is simply paying for more development work (a money effect). Probably both.

Everything else? No significant changes.

Where the apps really went

What PyPI data cannot see is the explosion of software that was never meant to be distributed.

The Hacker News thread is full of examples. One developer replaced VSCode with a hyper-personal dashboard that combines news, issues, PRs, a markdown editor, a calendar, and AI buttons that do things that cannot be done programmatically — and doesn’t share it because it wouldn’t fit anyone else’s workflow. Another built a shopping app in 20 minutes, specific to how and where they shop, useless to anyone else. A third described building dozens of personal tools in the last year to solve problems they accumulated over decades — things they have no intention of selling or sharing.

This is the invisible productivity gain. It didn’t show up on PyPI because it was never meant to go on PyPI.

One commentator summed it up with clarity: the minimum threshold for an app to make sense dropped to a single person. That’s new. Before LLMs, writing software for an audience of one rarely made economic sense. Now it does. The result is a category of software with no distribution channel, no metrics, no visibility — but genuinely useful to whoever built it.

There’s also a second category: software that exists but is transitory. One developer described using Codex to spin up a small web app to handle OAuth credentials for a few minutes and then delete it. Code as disposable artifact. That’s a real productivity gain that’s never going to register anywhere.

The problem with calling yourself an “AI app”

The third thread of the discussion is one that product teams should take seriously.

Several comments made the same observation independently: AI apps that really gain users are the ones where AI is invisible. The ones marketed as “AI-powered” attract curiosity but not retention. The ones that simply solve a problem — and happen to use LLMs under the hood — get real use.

One commentator put it well: most people don’t want AI. They want software that does magically useful things. The implementation detail is irrelevant. Marketing a product as an “AI app” is like selling a faster computer by talking about its silicon specs — you’re talking to yourself, not your customer.

Consumer sentiment data shows measurable negative reactions to AI branding in unexpected contexts. Yet pressure from leadership to launch “AI-first features” remains intense. That tension — between what the market really responds to and what the org chart demands — is a real product risk.

The gap that persists

The honest summary of Answer.AI’s findings is this: there is no evidence that developers in general are 10x more productive. But there is evidence that specific developers, working on specific things, are building significantly faster. The gains are real and concentrated, not universal and diffuse.

The gap between model capability and product distribution was always the hardest problem. LLMs did not solve sales cycles, trust, onboarding, or the 10% of engineering effort that represents 90% of the pain. What changed is the floor: the cost of a working prototype collapsed. What didn’t change is everything that happens after the prototype.

For product teams and founders, the practical takeaway is this: the models are ready. The distribution bottleneck is yours to solve.

Are you seeing this effect in your own projects? Are you building personal software you’ll never distribute, or are you still aiming for products with real users? Tell us in the comments.

Sources: