Anyone can build an app now. But nobody seems to care.
Well, not nobody. VCs keep funding startups that add AI to, well, everything. But users aren’t buying the massive influx of new apps. In a chart shared by Jen Zhu Scott based on the new National Bureau of Economic Research’s working paper “Writing Code vs. Shipping Code,” iOS app releases have exploded since the advent of agentic AI. That would perhaps be cause for celebration had app reviews not declined during this same period, and apps with significant usage have stayed essentially flat.
In other words, more apps but almost nobody new showing up to use them.
For those of us that grew up in open source, it’s a familiar problem. The greater the abundance of code, the greater the need to help would-be customers navigate it through marketing (including branding), sales, etc. AI is creating so much noise, in terms of new code, new products, etc., that the real work has shifted to taste-making. I’ve been saying for a while that developer productivity isn’t about producing more code faster. Or at least it shouldn’t be. Productivity is about producing well-architected, secure, maintainable code that solves a problem someone actually has.
That’s a very different thing. It’s not something AI can fix; at least, not yet.
Charity Majors put it more bluntly in a post I wrote in 2024: “Writing code is the easiest part of software engineering,” she said. The harder parts are figuring out what to build, integrating it into a larger system, validating that it works, maintaining it over time, and getting humans to trust it enough to use it.
Turns out the harder parts are really hard. Mert Demirer, Leon Musolff, and Liyuan Yang tracked more than 100,000 GitHub developers alongside their AI usage telemetry. Autocomplete, interactive agents, and autonomous agents each ramped raw coding activity, with cumulative effects on commits of 40%, 140%, and 180%. That sounds great until you look how the gains attenuate the closer you get to actual users. For example, that 180% jump in commits became roughly 50% more projects and just 30% more actual releases. The report’s authors call this the weak-link problem: The strong link (writing code) got much stronger, while the weak links (everything else humans have to do) didn’t. The estimated elasticity of substitution between AI and human effort is 0.25, which is economist for “these complement each other, but they don’t replace each other.”
When the authors checked four major app marketplaces, they found a bump in new apps but no increase in total usage. In other words, we’re getting better at creating things with AI’s help; apparently we’re not good at turning that into user interest. User attention (and budget) is finite. The hard part is to figure out how to get users to care enough to pay (with their time or their money).
So what’s actually scarce in a world of near-infinite software? Not code, for sure. No, what’s scarce is attention, trust, and a reason to switch.
That means the durable advantages in software increasingly live in the parts of the business developers often undervalue, like a recognizable brand (something that Red Hat figured out early on in open source) or a channel they already use. Or it could be in areas that developers appreciate but don’t pay for, like good documentation or a welcoming community.
This isn’t a new idea; it’s just newly unavoidable. We’re watching something similar inside enterprises, where AI adoption is wildly uneven, not because the technology has no value, but because the organizational plumbing around it often hasn’t been built. This is why a new kind of speed is important. I once argued that speed was the killer app, and that was mostly true. Today the more interesting speed is how quickly you can earn trust, fit into a workflow, answer objections, and get adopted.
Years ago I wrote that RethinkDB was dead and MongoDB wasn’t what killed it. RethinkDB was at the time, by many technical measures, a better database, built around “correctness, simplicity, and consistency.” It still lost—and badly. Its founder’s own postmortem was unsparing: They had picked a brutal market and tuned the product to the wrong definition of good. Being technically right turned out to have almost nothing to do with getting adopted.
With AI we’re generating a thousand smaller “RethinkDBs,” only faster and with nicer landing pages generated by the same model that wrote the code. These aren’t going to win, any more than RethinkDB was able to unseat MongoDB. It’s not just about the tech, but rather about making that tech fit within a user’s or enterprise’s world and making it easy to adopt. AI makes this harder, not easier.
It’s a cliché that developers don’t like marketing. It’s also false in my inexperience. What developers don’t like is traditional marketing. During my time at MongoDB and now at Oracle, my developer relations teams have focused on offering developers deep, hands-on enablement, and the response has been fantastic. Is a technical tutorial marketing? Of course it is. So is a forward-deployed engineer working side by side with an enterprise’s engineers to help them effectively use your tech. Just because it’s not a 30-second Super Bowl ad doesn’t mean it’s not marketing.
Years ago the Dilbert cartoon captured developers’ disdain for marketing. It was funny then, and it’s funny now, but it has never been true.
Years ago Matt Klein, creator of the open source Envoy project, once talked me through all the non-development work that goes into making an open source project thrive. As he reflected, “If you look at what I did in 2016 and early 2017 to [introduce] and grow the project, it was not technical.” So what was it, if not core engineering? “It was all leadership, public relations, marketing, documentation, etc., and I did it all myself and I nearly killed myself [doing it].” As he summed it up for me, it was a “f—ing lot of work,” and much (most?) of it wasn’t about code. It was about helping users appreciate the value of that code.
TL;DR? The boring but essential go-to-market grind has always been the real job. It’s what will separate winners from losers in AI.
None of this is an argument against AI coding tools. Developers should absolutely use them. I use them constantly.
But AI can’t compensate for the hard work that goes into making a product successful in the market. In a world drowning in AI-generated sameness, taste becomes a competitive advantage. For me, “taste” translates into knowing what not to build, or what not to publish. It’s also all about knowing how to market one’s product, which might include ads but definitely needs to incorporate technical training that helps developers make sense of your code.
In short, there’s no Field of Dreams “build it and they will come.” There’s just a lot of hard, human work to help real people find and use your code.