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.

Getting more but not using more

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).

Learning to love marketing

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.

The boring work wins

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.

Agentic AI has moved from conference hype to a budget line item. This is where the conversation gets more interesting and more uncomfortable. Unlike traditional AI systems that respond to a single prompt, classify a document, recommend an action, or generate a summary, agentic AI systems are designed to pursue goals. They plan, call tools, inspect results, retry failed steps, consult memory, hand off tasks to other agents, and sometimes critique their own work before producing an answer or taking an action.

That extra autonomy is the value proposition. It also introduces the cost problem.

A single chatbot interaction may consume a few thousand tokens. A useful agentic workflow can consume hundreds of thousands or millions of tokens per day because it does more than answer a question. It decomposes the problem, retrieves context, reasons through options, invokes APIs, checks the output, and often runs multiple passes before reaching a result. Therefore, the economics need to be understood at the level of “agent instances,” not just model calls.

For the estimates below, I am using a blended token cost of $3 dollars per million tokens. This is not intended to reflect a single vendor’s list price. It is a blended planning figure that assumes a mix of input and output tokens, reasoning steps, retrieval-augmented generation, summarization, tool calls, memory updates, and occasional use of larger context windows. Some enterprises will pay less through volume discounts or by routing work to smaller models. Others will pay more by using premium models, long-context prompts, web browsing, large document ingestion, and repeated reasoning loops.

The basic formula is straightforward. If an agent consumes 2 million tokens per day, it consumes 730 million tokens per year. At $3 per million tokens, that single agent costs about $2,190 per year in token burn. That number sounds surprisingly low until you multiply it by the number of agents, workflows, and users, plus the surrounding infrastructure required to run these systems safely.

What an agent really costs

In the model used here, the annual token-only cost per agent ranges from about $1,095 to $3,833, depending on the use case.

• A lightweight HR recruiting or onboarding agent that consumes one million tokens per day costs about $1,095 per year.
• A more demanding software engineering agent that consumes 3.5 million tokens per day costs about $3,833 per year.
• Customer support agents are roughly $2,190 per year.
• Legal contract agents cost about $2,409 per year.
• Security triage agents run about $2,738 per year.
• Research agents are around $3,066 per year.

These figures are useful but incomplete. They include only LLM token consumption and exclude orchestration platforms, vector databases, observability, model evaluation, security controls, workflow monitoring, human review, enterprise application integration, data pipelines, audit logging, prompt management, and the engineers needed to build and maintain the systems. In real deployments, I would expect the all-in operating cost to be two to five times the raw token cost. For regulated or mission-critical environments, the multiplier can be even higher.

This is where many agentic AI business cases become less clear. The model call may be inexpensive, but the system around the model is not. An agent that can update a customer relationship management system, approve a refund, generate a purchase order, or recommend a security containment action needs guardrails, permissions, logging, rollback mechanisms, and human escalation paths. These are not optional features. They are the difference between a demo and an enterprise system.

Use cases that make economic sense

Customer support is one of the more obvious use cases. A typical support automation deployment may use eight agents: an intake classifier, a knowledge retrieval agent, a response drafting agent, an escalation agent, a quality review agent, a CRM update agent, a sentiment detection agent, and an analytics agent. At two million tokens per agent per day, each agent costs about $2,190 per year in token burn, bringing the annual total to roughly $17,520. If that system deflects even a modest number of tickets or improves agent productivity, the economics can be attractive.

Sales development is another practical example. A five-agent system for account research, lead enrichment, email personalization, CRM updates, and follow-up scheduling may consume 1.2 million tokens per agent per day. That results in an annual cost of about $1,314 per agent, or $6,570 for the full agent team. This can be compelling if it improves pipeline quality, but it can also be wasteful if agents generate low-quality outreach at scale. The cost of brand damage is not measured in tokens.

Software engineering is more expensive but potentially more valuable. A 12-agent system covering requirements analysis, architecture, code generation, testing, review, security checks, documentation, CI debugging, refactoring, release notes, dependency analysis, and hot-fix support may consume 3.5 million tokens per agent per day. That works out to about $3,833 per agent annually or roughly $45,990 for the full system. Compared with engineering salaries, the token cost is small. The real question is whether the system reliably improves throughput without increasing defects, security vulnerabilities, or maintenance complexity.

Security operations also fit the agentic model because the work is repetitive, time-sensitive, and context-intensive. A 10-agent security triage system could include agents for alert triage, log analysis, threat intelligence, endpoint investigation, network investigation, incident summarization, ticketing, compliance evidence, escalation, and post-mortem. At 2.5 million tokens per agent per day, the annual token cost is about $2,738 per agent or $27,375 for the system. This is easy to justify if it reduces alert fatigue and accelerates response, but risky if the agents hallucinate causality or bury critical signals in confident summaries.

Finance, legal, healthcare administration, market research, HR, and supply chain are also viable:

• A six-agent finance close system may cost about $9,855 per year in token burn.
• A four-agent legal contract review system may cost about $9,636.
• A seven-agent healthcare administrative workflow may cost about $13,797.
• Competitive intelligence using six agents may cost $18,396.
• HR recruiting and onboarding using five agents may cost $5,475.
• Supply chain planning and exception management using eight agents may cost $21,024.

Across all 10 example use cases I’ve mentioned in this section, the model assumes 71 agents and a total annual token burn of about $175,638.

The comparison with traditional AI

The economics of agentic AI should always be compared with simpler approaches. Traditional AI, workflow automation, rule engines, robotic process automation, and non-agentic LLM calls are often cheaper, easier to govern, and more predictable. Agentic AI is usually overkill for tasks like classification, extraction, summarization, routing, or drafting within a narrow context. A deterministic workflow with a single model call can do the job at a fraction of the cost and risk.

Agentic systems make sense when the process requires judgment across multiple steps, dynamic planning, tool use, exception handling, and adaptation to incomplete information. They are valuable when the path to the answer cannot be fully scripted in advance. They are less valuable when enterprises use them as a trendy substitute for basic automation.

The best architecture is usually hybrid. Use traditional automation where the process is stable. Use non-agentic AI where the task is bounded. Use agentic AI only where autonomy creates measurable leverage. That means fewer agents, tighter scopes, explicit budgets, model routing, token monitoring, and human checkpoints for high-impact decisions.

The financial mistake many organizations will make is to treat agents as digital employees with near-zero marginal cost. They are not. They are probabilistic software components that consume tokens, trigger tools, create operational dependencies, and require supervision. The token bill may be manageable. The governance bill may not be.

Agentic AI can absolutely be worth the money. In many cases, the annual token burn for a useful agent team is less than the loaded cost of a single employee. But that is not the same as saying it is cheap. Companies must measure agent cost per completed business outcome, not cost per prompt or cost per model call. In the end, the question is not how much an agent costs. Ask yourself the right question: Does the autonomy an agent provides outweigh the complexity it introduces?

Forget “Florida Man.” Want to hear a California Man story? 

Here goes. 

A California man rolled up to a yoga studio in San Francisco’s Marina District in a self-driving Waymo car, walked into the studio, grabbed an armful of yoga shorts, got back in the Waymo and took off. 

Six months later, police still haven’t found him, according to a story this week in The San Francisco Chronicle. Since the rider’s credit card information didn’t lead to an arrest, we can assume the perp used a stolen phone’s Waymo account and financial information to hail the ride. And by the time police requested interior video of the man’s face, Waymo had already deleted it. 

This is a “California Man” story in part because of the association of Waymo with the city of San Francisco. Soon that association will be obsolete. (In fact, while Waymo is headquartered in San Francisco and is more visible there, Arizona got Waymos two years before San Francisco did.) 

At the moment, Waymos are publicly available to riders in 11 US cities — San Francisco, Phoenix, Los Angeles, Austin, Atlanta, Miami, Orlando, Dallas, Houston, San Antonio, Nashville.

Before long, riders will be able to enjoy robot car rides from Waymo in Las Vegas, San Diego, Washington DC, Denver, Detroit, Baltimore, Boston, Charlotte, Chicago, Minneapolis, New Orleans, New York, Philadelphia, Pittsburgh, Sacramento, Seattle, St. Louis, Tampa, London, and Tokyo.

Historically, Waymo has been taking a bath on rides. 

(I’m not talking about recent stories where Waymo cars have driven onto flooded roads. On May 12, Waymo issued a voluntary recall of 3,791 cars after a software defect allowed an autonomous vehicle in April to drive into a flooded, impassable roadway in San Antonio and be swept into a creek. A week after the recall, the company paused all freeway rides and suspended service in Atlanta, Austin, Dallas, Houston, San Antonio, and Nashville because of construction-zone navigation issues.)

To date, self-driving ride-hailing services like Waymo are a loss-leader business. Waymo is secretive about its costs, but independent estimates suggest that a $20 ride for the rider may be a $50-$100 ride for Waymo, when you factor in all costs. 

But help is on the way. 

Cars that drive themselves don’t pay for themselves

A big part of why Waymo rides have been so costly is that the car is a retrofitted Jaguar I-PACE. It’s true that Waymo got a deal on the roughly $70,000 car (a steal at $50,000 per vehicle because the company bought thousands of them). 

But then Waymo had to bolt on all kinds of costly sensors and electronics to make them self-driving, including a roof-mounted lidar assembly of five units, 29 cameras all around the car, six radar units, a custom Waymo-designed AI inference compute platform, and the wiring harness and power distribution system. 

Estimates for the total cost per car for Waymo are in the $120,000 to $200,000 range. 

Another problem is that the Jaguar I-PACE is notorious for a lack of reliability, especially involving its batteries and its longevity. Jaguar stopped making I-PACE cars two years ago. 

Finally, Waymo can’t do what regular car owners do and sell the car to recover some of the initial investment. Nobody wants an electric car with a depleted battery covered in electronics and sensors that can’t be used. 

The good news is that we learned this week that used Waymo batteries will be repurposed as backup storage for power grids in California and Texas. 

Say “Oh, Hi!” to the Ojai

The combination of growth and the end of manufacturing for the Jaguar I-PACE means that Waymo’s next platform is right on time. The car is called the Ojai, named after the unaffordable artsy hippie mecca located 80 miles northwest of Los Angeles. 

Waymo announced last week that the company will soon open Ojai cars to free rides for select riders in San Francisco, Los Angeles, and Phoenix. (See this Redditor’s drone photos  of the current fleet of Ojai cars in Mesa, AZ.)

The Ojai is a purpose-built electric minivan made by Zeekr, an arm of China-based Geely Automobile Holdings. It’s got doors that slide open like an elevator door, more legroom than the I-PACE, three screens for passengers, Braille instructions, grab bars, a flat floor with low-step height for easier entry, charge ports, cupholders, more cargo space, better batteries, faster EV charging, and easier cleaning and maintenance than the I-PACE cars. 

It’s much cheaper for Waymo to buy — and much cheaper and faster to integrate Waymo electronics. 

The Ojai gets Waymo’s sixth-generation Driver as a factory-co-engineered system with just 23 sensors (13 cameras, four lidar, six radar). While that’s far fewer sensors, they’re much more capable than the older generations of Waymo systems. One of my favorite details of the Ojai sensor package is that each car will have 10 sensor wipers with heaters and fluid sprayers specifically designed for snow, rain, and adverse weather. They’re like tiny, high-tech windshield wipers, but for the glass in front of the sensors. Ojai cars will likely do far better in rain and snow conditions. 

Weirdly, the Ojai still has needless controls, like a steering wheel and gas and brake pedals. And the only reason for those is that the US Congress is asleep at the wheel. US. federal motor vehicle safety standards require steering wheels and pedals for street-legal vehicles, and neither NHTSA nor Congress has granted a permanent exemption for purpose-built driverless vehicles. 

Despite the vestigial controls, the difference between the two cars is that the Jaguar was an old-school car designed for drivers, while the Ojai is the new concept for cars, one built for riders. And for riders, the Ojai is better in every way that matters. 

The Chinese factor

There’s only one factor keeping Ojai cars from replacing the full Jaguar I-PACE: They’re  made in China. 

Waymo is getting around the 100% tariff imposed by the Trump Administration by “location-laundering” the build. Zeekr completes the Ojai shells in Gothenburg, Sweden, and because the “substantial transformation” occurs within the EU, the vehicles are classified as EU-origin products. The stripped-down gliders arrive with no modems, ECUs, or autonomy software, and Waymo installs all connected technology at its Mesa facility, which satisfies the Commerce Department’s 2027 and 2030 rules prohibiting Chinese-linked vehicle electronics. 

Some lawmakers are using Waymo as a case study for general anxieties about Chinese technology infiltration into American infrastructure. The other problem is protectionism. If un-tariffed Chinese cars were allowed into the US market, the US car industry would likely be decimated by the competition. Chinese carmakers like BYD enjoy a 25% material cost advantage over Western carmakers. They would enter $5,000 to $10,000 cheaper than comparable U.S. offerings, according to some estimates. 

So, Washington is jittery about Chinese-made cars. 

I drove a BYD rental car in the UK last month. And I can tell you, they’re great cars and very enjoyable to drive. (My only complaint was that the steering wheel was on the wrong side.)

Instead of Waymo taking a risky bet on Ojai cars, they’re instead expanding with Hyundai Ioniq 5 EVs, which are produced locally and will be retrofitted with Waymo’s sixth-generation Driver at that Mesa facility. This is a massive deal in which Hyundai will supply Waymo with 50,000 cars by 2028. 

Waymo hasn’t disclosed plans for Ojai cars, but it’s unlikely to even come close to the number of Hyundai cars it is on the hook for. 

(The company also has around 100 Zeekr cars, but plans to expand that fleet to a few thousand.)

The right solution for Waymo’s next few years would be all Ojai cars with no steering wheel or pedals. The Ojai is purpose-built for autonomous car ride sharing, affordable, and capable in all weather. But that’s not going to happen because of Congressional inaction, China panic, and protectionism in Washington. 

Instead, Waymo’s future is to use too many cars from the past, by which I mean much or most of its fleet will be driverless cars retrofitted from cars that prioritize the driver, rather than the passengers. And reports suggest that the price of Hyundai cars will be comparable to the overpriced Jaguars. 

I’m sure the Hyundai Ioniq 5 will be nice. But an all-Ojai fleet would have been the better future for Waymo. Instead of the right car for the job, Waymo is stuck with an expensive, less comfortable, less capable car than the Ojai.