In January 2026, The Information reported that Cursor — the AI coding tool valued in the tens of billions of dollars — was running at a gross margin of roughly negative 23%. Not unprofitable in the ordinary startup sense of spending on growth. Negative gross margin: losing money on the product itself, before a single dollar goes to its own engineers, offices or sales team.
The investment firm Foundamental had estimated something similar a few months earlier — that around mid-2025, with Cursor's revenue near $500 million a year, it was paying Anthropic roughly $650 million for model usage. About $1.30 spent on the model for every dollar collected from customers, before infrastructure or staff. This is not a story about one company mismanaging its costs. It's what happens, structurally, whenever the good you're selling gets cheap to produce and someone upstream still controls the part that isn't. The go-to-market half of what happens to pricing when code gets cheap to produce is handled in more depth by . The go-to-market half of what happens to pricing when code gets cheap to produce is handled in more depth by XenGrowth's revenue operations work.
The economics of this were written down before AI existed
Carl Shapiro and Hal Varian's Information Rules, published in 1999, is the clearest statement of the mechanism. Information goods — and code is an information good — have a strange cost curve: the first copy is expensive, sometimes very expensive, and every copy after that costs almost nothing. Cost-plus pricing, the instinct to mark up your unit cost by some healthy percentage, simply breaks down when unit cost rounds to zero. Shapiro and Varian's conclusion was blunt: price on value to the customer, not on cost to produce, because in a competitive market with near-zero marginal cost and no lock-in, price gets driven toward that marginal cost regardless of what it cost you to build the thing in the first place.
Chris Anderson's Free, ten years later, took the same mechanism and ran it forward in time. As the marginal costs underlying digital goods — processing, bandwidth, storage — kept falling, he argued, price would keep following them down, and free would stop being a marketing gimmick and start being the rational endpoint of ordinary competition. The businesses that survived that process weren't the ones that resisted it. They were the ones that stopped trying to charge for the thing getting cheap and found something adjacent to charge for instead — attention, a premium tier, a complementary product, a service wrapped around the free core.
Condition | What Shapiro & Varian / Anderson predict | What it looks like now |
|---|---|---|
Marginal cost of the good falls sharply | Cost-plus pricing stops working; price competes toward the new marginal cost | AI-assisted code generation collapses the cost of producing a working feature |
No lock-in, no switching cost | Price falls toward zero; the good becomes a commodity | Dozens of functionally similar AI coding tools, IDE plugins and app builders launch within months of each other |
A supplier controls the dominant remaining cost | Margin migrates to that supplier, not the seller of the finished good | Model providers who also sell competing end-products capture the margin from companies built on top of their API |
A seller finds something adjacent to charge for | Durable business model, even as the core good gets cheap or free | Distribution, workflow lock-in, data, or a bundle become the actual product being sold |
This is the frame worth holding onto: falling production cost is not, by itself, bad news or good news for anyone. It's a redistribution mechanism. It moves value away from whoever used to be scarce — the people and companies who could produce the thing — toward whoever controls what's still scarce once production isn't: distribution, the customer relationship, the data, or the input the producer can't easily replace. writes about exactly that redistribution from the demand side of the business. covers the the operations side of this side of this. The XenGrowth resource library covers the the operations side of this side of this.
Where the margin actually went, in Cursor's case
Cursor is a useful live example precisely because its numbers are public enough to reason about. It sells a product built substantially on top of Anthropic's and OpenAI's models. Every additional customer generates additional model usage, and that usage is billed by the same companies that also sell their own, competing coding products. The more Cursor grew, the more it paid to the party best positioned to replace it — which is the textbook shape of Shapiro and Varian's argument about a supplier who hasn't lost pricing power even while the thing built on top of their input has become commoditized.
Cursor's own response, reported alongside the margin figures, was to build its own model — Composer, released in October 2025 — to handle routine requests without paying a third party for every one of them. By April 2026 it had reportedly turned gross-margin positive on its largest corporate accounts while still serving individual developers at a loss. That's not a fluke of execution. It's the only structurally available move: either control the input that's currently rented, or find a customer segment sticky enough to stop the commodity-pricing pressure from reaching it. Cursor tried both at once.
Aggregation theory: where margin migrates once supply is commoditized
Ben Thompson's Aggregation Theory, published on Stratechery in 2015, describes the demand-side half of this same pattern, developed originally for media and marketplaces rather than AI, but the mechanism transfers cleanly. Once suppliers in a value chain become interchangeable — modularized, commoditized, easy to switch between — the party that wins is whoever owns the actual relationship with the end user. Suppliers compete against each other for access to that relationship; the aggregator gains leverage precisely because none of the suppliers are irreplaceable anymore. is a reasonable next stop for the measurement side of owning that relationship. approaches this from the AI agents and marketing automation side. XenGrowth on AI agents and marketing automation approaches this from the AI agents and marketing automation side.
Clayton Christensen's Conservation of Attractive Profits makes the same claim from a different angle: profit doesn't disappear when a layer of a value chain gets commoditized, it relocates to whichever adjacent layer becomes newly proprietary and differentiated. Apply that to software production and the prediction is specific: as writing code gets cheap and interchangeable across many providers, the profit that used to sit with "whoever can build it" doesn't vanish. It moves to whoever owns the customer relationship, whoever controls distribution into an existing user base, or whoever bundles the now-cheap capability into something a customer already can't leave.
Cheap production doesn't destroy margin. It relocates it — usually to whichever layer of the value chain the buyer still can't easily walk away from.
Where this has already happened in software, before AI
The pattern isn't new to this AI cycle; it's just moving faster. Website builders commoditized custom HTML work and pushed margin toward the platforms that bundled hosting, templates and a marketplace — not toward the individual freelancers who used to charge for building a page from scratch. Basic logo and graphic design work commoditized against template marketplaces and crowdsourced platforms, and the money moved to whoever owned the marketplace, not to whoever produced the individual design. Commodity cloud compute did something similar one layer up: once running a server became cheap and interchangeable across providers, differentiated margin moved to the managed layers built on top — the platforms, the developer experience, the things a customer would actually notice switching away from.
Category | What got cheap | Where the margin ended up |
|---|---|---|
Website building | Hand-written HTML/CSS for a basic site | Platforms bundling hosting, templates and a marketplace of themes |
Logo and basic graphic design | One-off design commissions | Marketplaces and template libraries, not individual designers |
Raw compute | Running a server, provisioning a VM | Managed platforms and developer-experience layers built on top of commodity compute |
AI-assisted coding (current) | Producing a working feature or a first draft of an app | Contested: moving toward whoever owns the model, or whoever owns the customer relationship — not yet settled |
The pattern in that last row isn't finished, and it's worth being honest that nobody actually knows where it lands yet. What the earlier three rows do establish is that it doesn't usually land with the producer of the newly-cheap thing. History's batting average on that question is not good news for anyone whose entire pitch is "I can build this cheaply, using AI, faster than you can." Cheap and fast is the commodity condition, not the moat. Once production stops being the differentiator, acquisition and retention become the whole game, which is the part is actually about. On AI search, GEO and discovery specifically, is worth reading. On AI search, GEO and discovery specifically, XenGrowth on AI search, GEO and discovery is worth reading.
What this argument is not
It's worth being explicit about the boundary here, because this topic gets conflated constantly. This is not an argument about whether AI reduces the number of engineering jobs, and it isn't a restatement of the case for or against a coming leverage multiplier in how much work one engineer can do. Those are real, separate questions with their own evidence, and they're covered elsewhere on this site in the depth they deserve — the payroll data on junior hiring, the randomized trial evidence on whether AI tools actually speed experienced developers up, the Amdahl's-law argument about how much of the job coding really is. None of that evidence is repeated here, and none of it is needed to make the pricing argument, because the pricing argument doesn't depend on how many people it takes to produce the code. It depends only on what happens to price and margin once the cost of producing it falls, regardless of whether one person or five people did the producing.
That distinction matters because the two arguments can point in different directions without contradicting each other. A company could need fewer engineers to ship the same feature set and still see zero improvement in its own margin, if the money it stops spending on engineers gets spent instead on the model bill that replaced them — which is close to a literal description of what happened at Cursor. Cheaper production and better margin are not the same claim, and conflating them is how a real economic argument turns into a talking point. covers the industry side of separating cost from margin in more depth.
What this changes about how to price and position software
Stop pricing on production cost. If the cost of producing your feature keeps falling, a cost-plus number falls with it and a competitor undercuts you before you've noticed — price on the value the customer gets, the way Shapiro and Varian argued from the start
Identify your version of Cursor's model bill. Any input you rent from a supplier who can also sell direct to your customer is a margin leak that gets worse as you grow, not better — know which line that is before it's 130% of revenue
Ask what a customer would actually lose by switching away from you tomorrow. If the honest answer is 'not much,' the commodity-pricing pressure described here is coming for you regardless of how good the underlying product is
Look one layer away from the thing getting cheap for where the durable margin is moving. It's rarely the good itself once it's easy to produce — it's the bundle, the relationship or the distribution around it
Treat 'we can build it cheaper with AI' as a temporary cost advantage, not a business model. Every competitor has access to the same falling production cost, which is exactly why it stops being a competitive advantage the moment everyone has it
None of this is an argument that building things stops mattering. Somebody still has to build the thing well enough that a customer wants it in the first place — that's a threshold condition, not a strategy. What changes is which side of the value chain gets to keep the profit once building it is no longer the scarce, hard-to-replicate part. That has always been the part of software economics that determines who wins, long before any of this involved a language model.
Further reading from XenGrowth
Where this work meets go-to-market
Deciding where margin actually lands once production is cheap is a go-to-market question as much as an engineering one — publishes operator guides on that side of it.
Further reading from XenGrowth
Where this work meets go-to-market
The operational playbooks that sit alongside what happens to pricing when code gets cheap to produce live with .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
The operational playbooks that sit alongside what happens to pricing when code gets cheap to produce live with the team at XenGrowth.
Three questions about a software category, answered the way you'd answer them for a real product. It follows the same reasoning as the post — the destination of the margin depends on switching costs and who owns the customer, not on how good the product is.
