Systems / Article / 12 Oct 2026

AI is rewriting the software bill.

Less dependence on packaged software can come with much greater infrastructure use. Jane Street and data-centre forecasts make that transition concrete.

AI is rewriting the software bill.

A BofA table circulating this weekend puts AI data-centre systems at $2.2tn in 2030. Quite a headline. But follow the numbers through to the software running on those machines and the implications become rather more interesting.

In the table shared by Ren, AI takes roughly 94% of the increase in annual data-centre systems spending between 2025 and 2030. Its share of the annual market rises from 55% to 86%. Conventional systems spending still grows by 56%. The old computing estate doesn't vanish. The new spending goes overwhelmingly elsewhere. The table shared by Ren

That is a forecast, btw, not a measurement of how much work agents will perform. It doesn't tell us that 86% of applications disappear, or that every software business loses. It does give us a reason to examine what happens when the customer starts building the software, supplying the intelligence and deciding which parts of the old stack are worth paying for.

Original nine-second animation. Vertical spans encode forecast market values on one dollar scale; moving points and topology are conceptual. The conventional base grows too.

Jane Street makes this unusually concrete.

The firm has committed approximately $6bn to CoreWeave cloud services, including access to next-generation Vera Rubin systems, dedicated connectivity and tailored storage. Separately, it purchased $1bn of CoreWeave equity. These are different transactions: a capacity commitment and an investment. Neither is an annual spending figure. The stated purpose of the infrastructure includes training, refining and deploying models for financial markets. CoreWeave announcement

Jane Street's own research describes in-house language-model families reaching hundreds of billions of parameters. Here is a financial firm behaving as a model developer and major infrastructure customer. It doesn't have to sell an AI subscription to have an economic use for the intelligence. Jane Street research

Now look at the software underneath. In its Signals & Threads podcast, Jane Street explains why it built its own warehouse, Superstore. Among the reasons: per-query charges could discourage the exploratory work it wanted to encourage, and its data was already on premises. It needed the function; that didn't mean it needed the vendor's commercial model. Signals & Threads

It still prices scarcity internally: researchers bid for CPU and GPU time. Its engineers discuss improving that allocation to reflect how quickly a job's value decays. Useful work, completed in time, is the relevant economic unit.

That warehouse decision wasn't caused by today's agents. Nor does the compute contract establish how much of Jane Street's profit comes from AI. The connection is narrower, and more useful: a customer can bypass a packaged-software bill while creating substantial demand for the infrastructure that does the work.

There is a smaller, revealing example inside the same firm. Designer Edwin Morris describes using Claude to build working prototypes in the actual codebase, sometimes skipping Figma. Engineers still own the production implementation. The change is that a design idea can become executable software before the usual hand-off has even happened. Morris, February 2026

Companies have built their own software for decades. What is changing is the cost and difficulty of doing it. Jane Street is an unusually capable firm, not a representative customer. But an investment model that assumes customers will keep buying the same applications because building alternatives used to be difficult is making quite a large assumption.

The infrastructure consequences need a little more care than “more agents, more GPUs”.

An agent can write ordinary code once, and that code can subsequently run without asking a model to reason through every operation. A persistent agent interpreting new information, choosing actions and checking results keeps buying inference. Both produce useful software. Their recurring resource requirements are very different.

Databricks reports that agents create roughly four times as many Lakebase databases as humans. Around half the agentic applications have database-compute lifetimes under ten seconds. Branching can reuse stored data rather than copying it wholesale. More software, far more experimentation, and much less provisioned capacity per experiment can happen together. Four times the databases is not four times the memory. Databricks engineering

This changes the shape of the system. State can persist while execution starts and stops. A model can choose the operation, ordinary code can perform it, and a database can commit the result. Local applications, client-server connections and warehouses all have work to do. Their human interfaces need not remain the place where the work is organised—or where the bill is defended.

Salesforce has already made its intended response explicit. Its September specification targets November for a system that meters successful calls by registered external agents, through either MCP or direct APIs. Prices remain unannounced and metering hasn't begun. But the proposed commercial boundary is clear: somebody else's agent can do the work, and Salesforce intends to charge for the interaction. Salesforce specification

That creates an interesting tension. If intelligence gets cheaper, the systems it needs to use don't automatically do so. Access charges can become a larger part of the cost of a completed job. Customers then have more reason to batch operations, reuse results, negotiate access or build around expensive dependencies. Jane Street's warehouse is a useful reminder that the last option is real. It isn't costless or available to everyone.

And a successful API call isn't a completed business task. Ten billable interactions can still leave the customer with a job that failed. The customer will eventually care about the whole bill divided by useful work, however vendors choose to meter it.

Snowflake shows how untidy the financial consequences can be. Product revenue grew 37% in its latest reported quarter. Management lowered its non-GAAP product gross-margin outlook as AI workloads grew, but raised its operating-margin outlook as slower headcount growth offset cloud costs. Management also credits internal AI with reducing its reliance on headcount growth. AI changes both sides of the software income statement; the effects needn't point in the same direction. Results · Management's explanation

This is what I would take from the weekend's table. Software can become easier to create and substitute while putting it to work becomes a much larger physical business. The customer may own the models and workflow, rent the machines, and buy only the application functions it still needs.

Whether that produces BofA's $2.2tn market depends on paid work growing fast enough to absorb efficiency gains, and on capacity actually being delivered and used. A hardware forecast cannot settle that. It certainly cannot tell us which supplier will retain the margin. But an end customer's AI budget needn't be bounded by its software seats, or funded by selling AI subscriptions. Jane Street is a particularly pointed illustration.

But asking whether AI “kills SaaS” is becoming a rather crude way to frame the investment problem. The application can survive. The customer can use it more. And the right to send the invoice can still move.

Source note: calculations use the visible BofA-attributed exhibit shared by Ren. The original report and its footnotes were not available for verification. The detailed networking subrows do not fully reconcile, so the charts use the reconciled top-level categories. Figures are annual systems-market values, not cumulative capex or shares of all technology spending. Research cutoff: 11 October 2026.