In the early 1970s, a mathematician named Meir Lehman sat inside IBM and did something almost no one thought to do with software. He watched it age. Most of his colleagues treated a program the way a mason treats a wall, as a finished thing, mortar set, purpose fixed. Lehman had access to the release histories of IBM’s OS/360, one of the largest and most ambitious operating systems ever attempted, and when he laid the successive versions one after another he saw not a wall but a river. The thing would not hold still. Each release grew more tangled than the last. Fixes bred fixes. Structure that had once been clean silted up with exceptions, patches, workarounds, the accumulated debris of contact with a changing world. Left alone, the software did not simply endure. It rotted.

From this Lehman drew a set of laws, and two of them still hum with a strange authority. A program that is used must be continually changed, or it grows progressively less useful. And as it changes, its complexity increases, unless deliberate work is done to hold that complexity down. He had, without quite saying so, imported an old and terrible idea out of physics and into the world of code.

An Old and Terrible Idea

Rudolf Clausius had given it its name in 1865: entropy. He invented a word to describe the one direction in which the universe seemed unwilling to run, which was backward. Heat flows from hot to cold and never the reverse. Order, left to itself, decays into disorder. Every transfer of energy pays a tax, and the tax is never refunded. Clausius was thinking about steam engines, about the melancholy fact that no engine can ever be perfect. But the second law does not care about engines. It is a statement about time itself, about the way any organized thing, a crystal, a cell, a company, an operating system, tends to slide toward sludge the moment you stop pushing against the slide.

A Program Is Not an Object

No one tells you this when you learn to build. A program is a process held briefly against entropy by human attention, and the moment the attention wanders, the decay resumes. The dependency you never chose ships a change and your careful structure cracks. The interface you built against quietly moves. The model underneath your clever workflow shifts by a fraction of a degree, and the assistant that summarized your inbox flawlessly in June begins, in July, to invent meetings that never happened. Nothing broke, exactly. The world simply moved, as worlds do, and your creation did not move with it.

This decay was hidden, for most of my career, behind a larger cost, and the larger cost was the building. Writing the code was slow, expensive, the long middle of every project, and because it dominated the front of the ledger it dominated the imagination. We came to believe that construction was the hard thing. We built our entire mythology of the engineer around the act of creation, the lone author at the keyboard translating thought into instruction, line after line, and we let the quieter labor that came afterward, the tending, the patching, the endless small resistances against entropy, fall into shadow. Maintenance was janitorial. Building was art.

The accountants knew better, and had known for years. Barry Boehm spent the 1970s measuring where the money in a large system actually went, and he kept arriving at the same uncomfortable figure: more than half of a program’s lifetime cost, in many systems closer to seventy percent, was spent after it shipped. The keeping already cost more than the making. We never felt it, because the building arrived as a single dramatic bill and the keeping came diffuse, spread thin across years, a line item no one dreads the way they dread a construction budget. The larger cost was hiding in plain sight, at the bottom of a ledger we refused to read all the way down.

The Toll Booth Removed

Then the agents arrived, and they went straight for the part we had mistaken for the whole. Describe a tool in a paragraph and it exists before lunch. The long middle of Lehman’s river, the expensive stretch of pure construction, has narrowed almost to nothing. The tide has gone out, and the rocks lie bare. Creation was never where the entropy lived. Entropy lives in persistence, in the days and months after the thing works, and no agent has repealed the second law. It has only removed the toll booth that used to stand in front of it, the two weeks of effort that once made you ask, before you built a thing, whether it truly deserved to exist. Take that friction away and you take away the question. What remains is a person, a machine that never refuses, and a growing shelf of small programs, each one a process quietly demanding to be fed, each one sliding, the instant it is forgotten, back toward sludge.

The Coal Question

In 1865, while Clausius was naming the tax the universe levies on order, an English economist named William Stanley Jevons was worrying about coal. The engineers of his century had made the steam engine far more efficient, wringing more work from every lump, and everyone assumed the obvious would follow: a more efficient engine would burn less coal. Jevons watched the opposite happen. Cheaper power multiplied the uses power could be put to, until Britain was burning more coal than it ever had, precisely because each ton now did more.

Make a thing cheap enough and you do not get less of it. You get a flood, and every drop in the flood carries its own long tail of consequence. The cost of producing software has fallen the way the cost of mechanical work fell in Jevons’s England, and we are answering it exactly as the Victorians did, by building everything: a personal tool for every passing annoyance, a script for every whim, a small app to solve a problem we will have forgotten we ever had. Each of those creations is cheap to build and expensive to keep. We have manufactured a fleet of small engines, every one of them running down, every one of them demanding to be fed. The bill for making fell to almost nothing. The bill for keeping went up, because now there is so much more that has to be kept.

The vibe coders are learning this now, one abandoned project at a time, and they are learning it in the oldest possible way, which is by paying for it. What they are rediscovering is not a fact about software. It is a fact about the universe, one Clausius saw in his steam engines and Lehman saw in his release notes and every one of us eventually meets a long list full of things we built because we could. The making was never the cost. The keeping is the cost. It always was.

Subscribe now

The kitchen of the Savoy Hotel, in the winter of 1890, ran on organized panic.

Professional kitchens then worked by a method called service à la française. It looked magnificent from the dining room and it was an operational nightmare behind the door. When a party ordered a feast, the kitchen prepared as many as thirty dishes to reach the table in the same moment. One cook chased a single dish the whole way: roast the bird, build the sauce, cut the garnish, plate it, then start again. The line was full of shouting and collisions and scorched copper. Food went out cold. When the dining room filled, the whole operation seized. To the guests in the velvet booths this was the price of luxury. The front of the house was calm and the back was a brawl, and the two were understood to be separate worlds.

Georges Auguste Escoffier decided everyone had the problem backward. They were all looking at the dishes. He looked at the flow of work instead.

His answer was the brigade de cuisine. He cut the kitchen into stations, one for sauces, one for roasting, and one for pastry, each cook responsible for a narrow part of every plate. The part that mattered most was a new job: the aboyeur, the announcer. The aboyeur stood at the pass, the counter between the dining room and kitchen. Waiters did not shout orders across the line. They handed them to the aboyeur, who turned the noise of the room into a fixed set of calls the stations could execute.

Now the front of the house could do anything. A guest could eat in the grand room, order to a private suite, or ask for supper in the parlor at midnight. The request always arrived at the same place. Escoffier had not only built a faster kitchen. He had built a single point of entry that let wildly different rooms drive one engine of production. He standardized the core.

The industry is celebrating the wrong thing

Enterprise software is standing in that kitchen right now and calling it the headless revolution.

Listen to any stage at a developer conference and the future belongs to the headless application. The premise is simple: remove the presentation layer, the graphical interface people click through, and keep a pure API.

Sold that way, it reads as liberation. Strip off the rigid web pages and desktop screens and developers are free to build a mobile app, a smartwatch widget, and a feed into an autonomous assistant. The head is gone and the surfaces are limitless.

That framing praises the wrong half of the change. It counts what got removed and ignores what now has to hold. An API gets treated as a magic doorway that dissolves the integration problem, when cutting off the head does nothing to make the body work. If every new experience needs its own bespoke API to reach your data, you have not built a flexible system. You have built a web of one-off connections that fails under its own weight.

The surface underneath

Call the thing that actually matters the unified surface: a deep, capability-rich layer under everything, exposing every service through one identical face. It does not care what is calling. A legacy web portal, a phone app, a voice assistant, and an autonomous agent running inside an MCP session, each one hits the same structural boundary.

Watch a single transaction to see why that boundary earns its keep. A customer is buying a limited item in a flash sale, not from a browser but from a chat window, through an agent that authenticates over an MCP session and queries inventory. The customer says buy. In the same second, a continent away, another customer clicks buy on the same item from an ordinary website. If those two requests travel different code paths, if the headless system has splintered into separate service layers, the database sees two truths. Inventory disagrees with itself and one sale collapses. That failure is not exotic; it is the ordinary result of letting each channel own its own copy of the rules.

Zoom out from the one transaction. A modern enterprise system is not a block of code on one machine. It is a sprawl of services across hybrid clouds and distributed databases, dozens of platforms that have to move data in near real time. At that scale the physics change. You inherit the hard part: keeping state consistent across nodes when the network is slow and always partly failing.

A single surface is what makes that survivable. Route every request through one layer and the system can enforce the guarantees that keep it honest, atomicity and isolation among them. A state change in one place is visible everywhere because there is only one place. Let the headless app be a pile of endpoints built by different teams on different sprints and you lose that. Send every request, from the mobile app or the chatbot or the enterprise service bus, into the same surface, and the system keeps control of its own state. It holds performance as volume climbs. It bends under load instead of breaking.

The core, not the screen

Escoffier’s brigade did not succeed by hiding the kitchen. It succeeded by forcing the whole hotel through one orchestrated interface, the pass, where every order became the same kind of instruction. That standard is what kept the food consistent from the station to the plate, however the guest chose to order.

So the thing worth celebrating about headless software is not the discarded screen. The missing interface is trivia. What matters is the surface underneath: one layer that brings order to a distributed system that would otherwise drift out of agreement with itself. Look past the absent head and mind the integrity of the body, and you can build systems that stay consistent while everything about how they get reached keeps changing. The power was never in how the software looked. It is in what happens below the surface and whether that one place can be trusted.

If you’re a software company and you ship an AI feature to a few thousand internal users, the cost is a rounding error you can ignore. Ship the same feature to a few million of your users and the line goes vertical, fast, in a way the pilot gave no warning of. Many are surprised by this spike because during a rollout everyone is optimizing for the demo and the deadline, not the invoice, so the first real signal that anything is wrong tends to arrive as a bill nobody can explain. You can’t manage that bill because it isn’t one thing. It’s an aggregate, and aggregates hide exactly the decisions that created them.

Three Buckets, Not One Bill

Production costs for a serious AI application separates into three structural buckets that behave nothing alike. The first is LLM tokens, the per-request cost of the model doing its work. The second is the vector database, the specialized store that holds your data as embeddings and searches it by meaning rather than by keyword, which is how retrieval-augmented systems find relevant context. The third is ordinary cloud infrastructure: compute, network, storage, and the logs that quietly pile up underneath everything.

Deployed without any constraints, each of these scales on its own clock, and the total obscures which one is actually running away. A team staring at a single climbing number will often assume it’s tokens because tokens are the part everyone talks about and miss that the vector database has quietly become half the bill. You don’t manage the sum. You manage the three things that add up to it, which means you first have to see them as three things.

The Triangle Every Workload Sits Inside

The real unit of AI cost isn’t the monthly total. It’s the individual workload, and every workload sits somewhere inside a three-way trade-off between accuracy, latency, and cost. Push for higher accuracy and you reach for a larger model or longer reasoning chains, which raises both the time each request takes and the price you pay for it. Pull costs down by moving the work to a smaller, lighter model and output quality drops in a way your users will feel. Speed, quality, and price are tied together, and you cannot maximize all three at once.

This is why the rolled-up bill is unmanageable as a rolled-up bill. It’s the sum of hundreds or thousands of separate placements inside that triangle, each one a design decision someone made about a specific workload: how good does this answer need to be, how fast, and what’s it worth paying for? A summarization that feeds an overnight report can sit in the cheap, slow, good-enough corner. A fraud check in a live checkout flow cannot. Averaging those two into one line item and trying to optimize the average gets you nowhere because there’s no single lever attached to it. The levers are all one level down on the workloads.

Why Ambient Agents Break the Model

The transactional chatbot had one merciful property: a predictable cost per interaction. A user sends a message, you pay for a call and maybe a retrieval, you return an answer, and the meter stops. You could multiply cost-per-conversation by expected conversations and get a number you could plan around.

Ambient agents throw that model out. An ambient agent is a continuous, background process wired into a live data stream, watching and acting rather than waiting to be spoken to: the agent that monitors every support ticket as it lands, or every transaction, or every code change. There is no discrete interaction to price because the thing never stops. Its cost is a function of how often it wakes, how many internal loops it runs to reason through a situation, and how often it hits an exception and retries the whole scenario. A single upstream data glitch can send a fleet of ambient agents into repeated retry loops, and that retry storm is a cost event nothing in the chatbot era taught anyone to watch for. The workloads that create the most value are precisely the ones whose spend is hardest to predict, and the old mental model of cost-per-message goes quiet right when you need it most.

The Vector Database Is Its Own Discipline

One of the three buckets deserves singling out because it scales silently and punishes neglect. Optimizing a vector database isn’t a knob you turn; it’s a data-engineering practice with real choices. You decide between exact nearest-neighbor search, which checks every candidate and is accurate but expensive, and approximate nearest-neighbor indexing, which trades a sliver of recall for a large drop in cost and latency. You apply quantization, which stores the embeddings at lower numerical precision to shrink their memory footprint and the compute needed to search them. You manage traffic and right-size instances instead of provisioning for a peak you rarely hit.

Done with care, these disciplines let the underlying data store grow enormously while its structural cost stays nearly flat. Ignored, the same store scales its cost straight up with its data, and one day you notice that semantic search, not the model, is the biggest number on the page. The bucket that’s easiest to forget is the one most likely to surprise you.

Training and Inference Are Two Economies

Even the raw hardware line hides two economies that shouldn’t share a row. Training is the upfront, data-heavy phase, and its cost is driven by dataset volume, gradient checkpointing, and the optimizer state parked in GPU memory while the model learns. Inference is the ongoing phase, where a finished model serves live requests, and its cost is driven by how you reserve capacity, how fully you use it, and how well you handle bursty real-time demand. The optimization moves for one do almost nothing for the other. Fold them into a single “GPU spend” number and you lose the ability to pull the right lever because you can no longer see which economy the money is going to.

The Bill Is a Shape You Design

None of this yields to management as a bill because it was never a bill. It’s the accumulated shape of decisions: three buckets scaling on separate clocks, a triangle placement chosen for every workload, a new class of always-on agents whose spend moves in ways the transactional era never modeled, and two hardware economies wearing one label. Every one of those is set in the design of the system, weeks or months before the invoice reflects it.

So the vertical spike that shows up after a big rollout isn’t really a billing surprise. It’s a set of design decisions you made earlier without pricing them, arriving all at once now that a million users are exercising them. You can meet those decisions on the invoice, after they’re load-bearing and expensive to change, or you can make them on purpose at the workload level, while they’re still just choices. The bill will tell you what you decided. It was never going to decide anything for you.

Subscribe now

Ask a company what its cloud bill was last month and someone pulls the figure in a minute, split by team, service, and environment. Ask what its AI spend actually bought, which features, which teams, which of those made money, and you’ll usually get a lump sum and a shrug. The spend arrived faster than any instrument to watch it, and it’s still climbing: Gartner expects worldwide AI spending to grow 47% in 2026. So most AI deployments run on a fuel gauge with one number on it: bigger than last month. You can’t optimize what you can’t see, and right now most companies can’t see much.

The most useful way to organize the response is a three-part framework, borrowing from the FinOps Foundation’s work on AI cost. The order matters, because it’s a maturity ladder, not three dashboards you stand up at once. Visibility, then economics, then value. Each pillar answers a harder question than the last, and skipping ahead doesn’t work: you can’t tie cost to revenue before you can explain what’s driving cost, and you can’t explain the drivers before you can see the total.

Pillar One: See the Spend

The first pillar is basic tracking. Total AI spend, average daily cost, and enough anomaly detection to catch a runaway job before it becomes a five-figure surprise on the invoice. The metrics are unglamorous and most companies still don’t have them.

Its real job is less technical than it looks. Getting a single credible spend number onto an executive’s screen is what turns AI costs from an abstraction into something with an owner. The baseline it establishes is the thing every later optimization gets measured against. Until the number is visible to someone with the authority to ask why it moved, nobody is accountable for the answer, and the spend just compounds quietly in the background.

Pillar Two: Explain the Spend

Once you can see the total, you need to know what’s moving it, and this is where the metrics get operational. Cost per token, input-to-output ratios, cache-hit ratios, and one worth giving a name: call it token-to-spend drift. When the bill climbs, there are two possible causes, and they call for opposite responses. Either you’re consuming more tokens, or your traffic has drifted toward more expensive models. Drift separates the two.

The distinction is the whole value of the pillar because the symptom is identical and the right response is not. If cost is up because volume is up, you’re looking at either healthy adoption or a Jevons runaway, and the question is whether the consumption is producing anything. If cost is up because requests that used to run on a cheap model migrated to a frontier one, the answer is routing, not throttling. Same rising line, two different problems, and without the metric you’re guessing which one you have and applying the wrong fix half the time.

Pillar Three: Steer the Spend

The third pillar is the hard one and the point of the whole exercise. Cost per use case, and inference cost measured against the revenue each capability actually drives. This is where you find out which AI features pay for themselves and which are burning capital inside a demo everyone admires.

A support agent that deflects a thousand tickets a week has an inference cost you can set directly against the salaries and the churn it saves. A generative feature that ships to everyone and delights nobody has an inference cost with no revenue on the other side of the ledger, and no dashboard of token counts will tell you that; only cost-per-value will. This pillar changes what AI spend even is. Managed at the visibility level, it’s a cost center to be minimized. Managed at the value level, it’s capital allocation: you fund the capabilities that earn and starve the ones that don’t, and “spend less on AI” stops being the goal because it was never the right one.

Automate It: The Control Plane

A framework you run by hand, in spreadsheets and monthly exports and a standing review, is where every organization should start, because doing it manually is how you learn what’s worth measuring. Once it works, you automate it into an internal platform, the control plane.

The market already sells part of this as the AI gateway, a proxy that fronts every provider behind one API and tracks tokens, spend, and routing; Portkey, TrueFoundry, Kong, LiteLLM, and Cloudflare all ship one. A control plane is broader. It unifies data across providers, because almost nobody is single-vendor anymore, and puts spend, token economics, GPU fleet utilization, and business value on one surface. No off-the-shelf product covers all of that yet, which is why the teams that want it build their own. It’s the instrument panel the three pillars imply once you’re tired of assembling them by hand every month. The pillars tell you what to measure; the control plane is what measures it continuously instead of in arrears.

Build It at Agent Speed

Here’s the part specific to this moment. The teams that build these control planes build them with AI assistance, fast, and the speed isn’t a vanity metric. It’s the requirement because the thing being governed doesn’t wait for a normal release cycle.

Internal AI adoption doesn’t grow on a smooth curve. It lurches. Roll a coding agent out to the engineering org on a Tuesday and token usage can multiply by Friday in a pattern no capacity plan saw coming, because the people adopting it are precisely the people who build fast and share what works. A governance platform that takes two quarters to ship is obsolete the week it lands, since the adoption it was designed to watch has already outgrown it. The only development pace that keeps up with agent-speed adoption is agent-speed development. You end up building the meter with the same tools that are blowing up the bill, and that symmetry is the point rather than an irony: the org that can deploy agents fast enough to explode its own token usage is the same org that can build the instrument to watch the explosion, if it decides to.

Structural Viability Is the Real Target

The goal here was never a smaller bill. It’s a deployment that stays viable as it scales, which is a different and harder thing. Visibility so you can see the spend, economics so you can explain it, value so you can steer it, and a control plane quick enough to keep up with how violently the usage moves. Take those in order and AI stops being a line item that surprises you and becomes a system you actually run.

The companies that treat all of this as a reporting chore they’ll get to later will keep meeting their own AI economics for the first time on the invoice after the decisions are made and the architecture is set. The ones that build the instrument panel while the spend is still small get to steer, and steering early, while the numbers are small enough to move, is the whole advantage. The bill is coming either way. Whether you’re reading it or writing it is the choice.

Subscribe now

Every AI budget I’ve seen rests on one assumption nobody writes down: that tokens will keep getting cheaper faster than the company can find new ways to burn them. It’s an easy bet to make, because the first part is visibly true. The price of a normalized token has been falling for two years, pushed down by better models, cheaper inference, quantization, and competition among providers who all want your default. Anyone watching the per-unit numbers sees a line sloping toward zero and reasonably concludes the cost problem will solve itself if they just wait. Both halves of that bet are shakier than they look, and they fail for different reasons.

Jevons and the Coal Paradox

William Stanley Jevons worked out the first failure in 1865, looking at coal. The efficiency of steam engines had improved dramatically, and the sensible expectation was that Britain would therefore burn less coal per unit of work and stretch its reserves. The opposite happened. Cheaper, more efficient steam power made coal worth using for a hundred things it hadn’t been worth before, and total consumption climbed. Efficiency didn’t conserve the resource. It expanded the appetite for it.

Token spend follows the same curve, and the enterprise version is almost comically direct. A provider cuts the price of its model in half, and a finance team reasonably expects the AI line item to ease. Instead it grows, because the moment a token gets cheaper, three teams who couldn’t justify a feature at the old price can justify it at the new one. The support agent that was too expensive to run on every ticket now runs on every ticket. The summarization that was reserved for premium accounts now ships to everyone. The nightly job that scanned a sample of the codebase now scans all of it, twice. Each of those is a rational decision, made by someone looking at a unit price that finally cleared their bar. Added up across the company, they mean consumption grows faster than the price falls, month over month, and the bill goes up while every vendor email says prices went down. Both statements are true, and reconciling them is the whole job.

A team that understands this can at least plan for it. You stop treating each price cut as savings and start treating it as a demand trigger, because that’s what it is. You assume that cheaper tokens mean more tokens, not the same tokens for less, and you budget for the growth instead of being surprised by it every quarter. This is uncomfortable but manageable. It’s the second half of the bet that’s genuinely dangerous, because it’s the half people don’t examine at all.

The Physical Reality Underneath the Price Curve

The unexamined assumption is that the price line keeps sloping down, smoothly, more or less forever. It feels like a law, the way Moore’s Law felt like a law, and people extrapolate it the same way: draw the curve out three years, assume next year’s ambitious feature will be affordable by the time it ships, architect accordingly. But a token price is not a pure software abstraction that trends to zero because software wants to. It’s the retail price of a physical process, and underneath every fraction of a cent sit three things that don’t obey software’s economics: electricity, memory, and buildings.

Electricity is the one that’s already biting. The models run in data centers, the data centers draw enormous and growing amounts of power, and the grid is not expanding on the same timeline. Interconnection queues stretch for years in the regions where the capacity would go. Some jurisdictions have started slowing or blocking new data-center hookups because the load threatens residential supply. Power is the input that scales worst, and it’s the one the whole edifice needs most.

Memory is the second. Modern accelerators depend on high-bandwidth memory, a specialized component made by a short list of suppliers, and that kind of concentrated supply chain doesn’t respond gently to a demand spike. When everyone wants the same scarce part at once, the price of that part doesn’t glide downward on a nice curve; it jumps, and the jump lands in the cost of every token served on hardware that needs it.

Buildings are the third and slowest. A data center is a multi-year construction project with permits, land, cooling, and a power agreement that may not exist yet. You cannot conjure capacity in a quarter to meet a surge in demand, so when demand runs ahead of the concrete, the shortage shows up as price, and it stays there until the next wave of buildings comes online years later.

None of this means tokens get expensive and stay expensive. It means the smooth decline people are mentally banking is not something physics has agreed to. The realistic shape of token pricing over the next few years is lumpy: stretches of decline as new capacity and better models arrive, punctuated by flat periods and outright spikes when power, memory, or capacity binds. Structural volatility, not a glide path. And a budget built on a glide path breaks the first time the curve does something the spreadsheet didn’t allow for.

Treating Tokens Like a Commodity, Not a Line Item

So the move is to plan for a commodity, not a software line item. Treat tokens the way a manufacturer treats a volatile raw input: something with a price you don’t control, that can move against you, that you hedge and monitor rather than assume away. Concretely, that means a few things. Don’t ship features whose unit economics only work at a price you’re projecting rather than paying today; if it’s underwater at the current price, it’s a bet on the curve, and you should know you’re making a bet. Build the ability to throttle and degrade on purpose so that when a price spike hits you can drop to a cheaper model or a smaller context on your terms instead of eating the increase. Keep your workload portable across providers, because volatility is rarely synchronized and the ability to move to whoever’s cheapest this month is worth real money when one supplier’s costs jump. Watch consumption growth as closely as unit price, since the Jevons effect means the growth is where your bill actually lives.

The companies that get hurt here won’t be the ones who assumed AI was expensive. They’ll be the ones who assumed it was on an escalator to free and built a cost structure that only balances if the escalator keeps moving. The per-token price probably does keep falling on average. But average is not a plan, and the physical world underneath the abstraction has a vote it hasn’t finished casting. Budget for the price to misbehave, and the misbehaving won’t be the thing that breaks you.

Subscribe now

A year ago, the price of a token was a rounding error in most engineering budgets. You wrote the prompt, you got the answer, and the bill at the end of the month was small enough that nobody in finance asked about it. That era is over. Token spend is now a line item that VPs interrogate, and the reason is simple arithmetic: when a product makes millions of model calls a day, the difference between a frontier model like Claude Opus 4.8 at $25 per million output tokens. Claude Fable 5 is priced higher at $50 per million output tokens. By comparison, you can route to SpaceXAI’s Grok 4.5, its first model trained alongside Cursor, at $6 per million output tokens. That alone can be the difference between a healthy gross margin and a board meeting about unit economics.

The response to that pressure has a name now. It’s called model routing, and it’s spreading faster than almost any infrastructure pattern I’ve watched. In roughly ninety days it went from something a handful of cost-obsessed startups did to something nearly every serious shop does. Route the easy request to the cheap model, route the hard one to the expensive model, and send the ambiguous one to whichever model your data says handles that shape of problem best. The mechanics vary, but the move is the same: stop sending every request to one model and start choosing per request.

That this happened so fast tells you something. Routing isn’t a clever optimization a few teams discovered. It’s the natural consequence of a market that finally has more than one credible product. When OpenAI shipped GPT-4 in March 2023, it was the only place to buy frontier reasoning, and there was nothing to route between. Now there’s a deep bench: a frontier tier from three or four labs, a fast-and-cheap tier under each of them, open-weight models you can host yourself, and a long tail of specialized models tuned for code, extraction, or classification. The moment a real menu existed, routing was inevitable. The only surprise is that anyone expected it to take longer.

So routing is settled. Within a year it will be as unremarkable as a load balancer, a piece of plumbing nobody brags about. Which means the interesting question has already moved. Once everyone routes, routing itself stops being an advantage. The advantage moves to the decision the router makes. The question is no longer whether you route. It’s what you route to and how you know.

That question is where model arbitrage lives.

What arbitrage actually means here

Borrow the word from finance because the structure is identical. An arbitrage is a price difference between two things that are, for your purposes, the same. The classic version: a stock trades at one price in London and a slightly different price in New York, and someone with fast pipes buys in one market and sells in the other until the gap closes. The profit comes not from predicting anything but from noticing that two prices that should be equal aren’t.

Model arbitrage is the same trade applied to capability. For a given task, several models will produce an answer good enough to ship, and they do not charge the same price for that answer. A summarization job that GPT-4 handled at $60 per million output tokens in 2023 gets done just as well today by Claude Haiku 4.5 at five dollars, or by an open-weight model you run yourself for the cost of the GPU. If the cheaper model clears the bar the task actually requires, the difference between what you could pay and what you do pay is pure margin. You captured a price gap between two things that, for this task, were equivalent.

The catch is the phrase “for this task.” In finance the two stocks are provably identical; a share is a share. In models, equivalence is something you have to establish, task by task, and it’s rarely obvious. A cheap model that nails 95% of your customer-support replies might botch the 5% that involve a refund policy, and that 5% might be the only part that costs you money when it’s wrong. Equivalence isn’t a property of the model. It’s a property of the model against your specific task at your specific tolerance for error. The whole game is figuring out where the line sits.

The arbitrage is real, and it’s large

Take a document-extraction pipeline that pulls the vendor name, the total, and the due date off an invoice. A frontier model does this perfectly and charges accordingly. But extraction from semi-structured text is not a hard reasoning problem. A model a tenth the price will hit the same accuracy, and you can prove it by running both against a few hundred labeled invoices and comparing the fields. If the cheap model matches on your test set, every invoice you process on the expensive model from then on is money set on fire.

Now multiply that across every distinct task in a product. Classification, routing of support tickets, first-draft generation, reranking search results, tagging, translation. Each one has its own difficulty, its own error tolerance, and its own cheapest sufficient model. A team that has measured all of them and matches each task to the floor that clears it can run the same product at a fraction of the cost of a team that sends everything to the best model out of caution. Same output, wildly different bill. That spread is the arbitrage, and right now it’s enormous because most teams haven’t done the measuring. They route on vibes, or they don’t route at all and pay the frontier rate for invoice parsing.

Why this won’t simply close

The finance analogy bends in a useful way at exactly this point. In real markets, arbitrage is self-erasing. The traders who exploit a price gap also close it; their buying and selling pushes the two prices together until the opportunity is gone. The reward for finding an arbitrage is to destroy it.

Model arbitrage doesn’t close, and the reason is that the underlying prices won’t hold still. GPT-4 launched in March 2023 at $60 per million output tokens. Three years on, GPT-5 does more than that model ever could at five dollars, and a nano tier sits a little above a dollar: close to a fiftyfold drop in the price of a capable token, and the curve hasn’t flattened since. A new model ships roughly every few weeks, and each release redraws the map. A model that was frontier-only last month gets a cheap-tier cousin this month that does 90% of the job, which moves the floor for every task you’d routed to the expensive tier. Prices drop in steps, not smoothly, and capabilities jump in clusters. The cheapest model that clears a given task is a moving target that moves on the labs’ release schedule, not yours.

That’s what makes this durable rather than a one-time saving. The arbitrage isn’t a gap you find once and pocket. It’s a gap that reopens every time the menu changes, which is constantly. The teams that win aren’t the ones who found the right routing table in early 2026. They’re the ones who can re-derive it next month and the month after, without a heroic manual effort each time.

The actual asset, then, isn’t the router. Routing logic is a weekend’s work, and every cloud will sell you one. It isn’t a relationship with a particular lab either; that relationship is a liability the moment a competitor undercuts them. The asset is the measurement: a standing evaluation harness that knows, for each task you run, exactly how cheap a model you can drop to before quality falls through the floor. The team that has that can re-price its entire stack the day a new model lands. The team that doesn’t is guessing and paying for the guess.

This reframes what’s scarce. We spent the last two years treating access to the best model as the thing worth having, the way you’d treat a faster CPU. Access is no longer scarce; there are four best models and they all have an API. What’s scarce is knowing precisely how good a model your task actually needs, because that knowledge is the only thing that converts a falling price into a captured margin. The model is a commodity you rent by the token. Your understanding of your own workload is the position you hold.

Which means the eval harness has to come before the router, not after it. Label your tasks, measure where each one breaks, and keep the test set fresh enough that you can re-run it the morning a new model drops. The routing falls out of the measurement; it can’t lead it. Everyone is about to be routing. The teams that know what they’re routing to and re-check it every time the prices move will quietly run the same product for a fraction of what their competitors pay, and the gap will widen every week neither side is looking.

The board told the company to adopt AI this quarter, and the mandate arrived with a number attached. Ship the agent features, wire up the copilots, and get something in front of customers before the competition does. What the mandate did not include was a way to govern what any of it would cost, because the automated systems that watch AI spend are still being built while the spend is already happening. Every company running this play right now is flying a plane it is also assembling.

Why the Cloud FinOps Playbook Falls Short

The instinct is to reach for the FinOps playbook that already worked. Cloud taught a generation of engineers how to bring runaway infrastructure bills under control, and the discipline is mature: tag your resources, watch your dashboards, rightsize your instances, buy reserved capacity for the steady state, and autoscale the rest. That playbook assumes something specific about where cost lives. It assumes cost is a property of the infrastructure and that infrastructure sits downstream of the decisions that created it. You design the system, you build it, and then you tune what it costs to run. The tuning is a separate job, done by a separate team, after the fact.

AI breaks that assumption at the root. The cost of an AI feature is not a downstream property of its infrastructure. It’s decided in the design, committed the moment someone chooses a model, a prompt structure, a context strategy, and an agent loop. By the time the feature reaches the infrastructure layer where cloud FinOps knows how to operate, the expensive decisions have already been made and the levers that matter are behind you.

Infrastructure Costs vs. Design Costs

Consider what actually drives a cloud bill. A virtual machine costs the same per hour whether it’s computing a payroll run or sitting idle. The price is stable, published, and easy to reason about. Optimization means matching supply to demand: fewer machines when traffic is low, cheaper machines when the workload allows, and committed contracts when the baseline is known. These are legitimate engineering problems, but they’re bounded ones. The unit price is a constant you optimize around.

Now consider what drives an AI bill. Two engineers can build the same summarization feature and see their costs differ by an order of magnitude, and neither one touched the infrastructure. One passes a tight, retrieved slice of the document into a small model and gets an answer in a single call. The other stuffs the entire document into a frontier model’s context window, runs an agent that reasons across four turns, retries twice on malformed output, and calls three tools along the way. Same feature from the user’s chair. Ten times the cost, or fifty, and the difference was set entirely by design choices: model selection, context size, how many round trips the agent takes, how retries are handled, and how much retrieval the system does before it ever generates a token.

The Decisions That Drive the Bill

None of those are infrastructure knobs. They’re product and architecture decisions, and they’re made by people who have historically never had to think about a per-request bill. A product manager who adds “and it explains its reasoning” to a feature spec has just multiplied the output tokens on every call. An engineer who decides to give an agent broad autonomy instead of a single scoped prompt has traded a fixed cost for an open-ended one that scales with how hard the problem turns out to be. A designer who chooses a chat interface that invites long back-and-forth conversations has committed the company to paying for context that grows with every turn. Each of these is a financial decision. None of them looks like one from where it’s made.

Why Monitoring Alone Won’t Save You

This is why bolting a cloud-style governance layer onto AI spend catches the problem too late. A dashboard that alerts when token spend crosses a threshold is telling you about architecture that shipped weeks ago. An anomaly detector that flags a costly endpoint is flagging a design decision that’s now load-bearing in production, wired into the user experience, hard to unwind without a rewrite. The monitoring works exactly as designed and still fails because it lives at the infrastructure layer and the cost was birthed three layers up. You can watch the meter spin. You can’t easily change what it’s metering.

Who Owns AI Cost?

The stakeholder map is the other thing cloud got to keep simple. Cloud cost had a natural owner. It was infrastructure spend, so the infrastructure and platform teams owned it, and the optimization work stayed inside a group that spoke the same language and read the same dashboards. AI cost has no such tidy home. It’s set by product managers scoping features, by engineers choosing architectures, by designers shaping interactions, and only finally realized by the platform team that gets the invoice and has the least power to change what’s on it. Governance that names the platform team as the owner has named the one group that can watch the cost and not the groups that create it.

Treating Cost as a Design Constraint

So the move is to put the unit economics in front of the people who commit the spend at the moment they commit it. That means cost becomes a first-class constraint in the design review, sitting alongside latency and correctness and user experience, not a report that arrives after launch. It means product specs carry a rough token budget the way they already carry a performance budget, so “explain your reasoning on every call” gets priced before it gets built. It means engineers can see, while they’re choosing between a single scoped call and an autonomous multi-turn agent, what each option does to the marginal cost of a request. It means the architecture decisions that fix costs in place — model tiering, context discipline, when to cache, and when to retrieve instead of stuff, when a cheap model with a good spec beats an expensive one with a vague one — get made deliberately rather than discovered on the bill.

The Real Cost of Moving Fast

This is more work than watching a dashboard, and it lands on people who didn’t sign up to think about money. That’s the actual cost of moving fast on a mandate: the governance can’t be a layer you add underneath the product because the thing you’re governing was decided inside the product. The companies that treat AI spend as an infrastructure problem will keep building elegant monitoring on top of architectures they can no longer afford to change. The ones that treat it as a design problem will price the decision while it’s still a decision, when moving a number is still cheap. The bill is not where the AI cost is determined. It’s just where you find out what you already chose.

A year ago, the most productive engineer you knew had ten terminal windows open and believed that was the frontier. Each window ran an agent. Each agent stalled the moment it finished a task and waited for a human to hand it the next one. The poor soul running all ten felt like an orchestrator, moving between windows, keeping every agent fed. He wasn’t orchestrating. He was polling. He was the scheduler, the router, and the memory of a small system, and he was holding all three roles together with nothing but his own attention.

We built agents to take the typing away, and the typing did leave. What arrived to replace it was a job nobody applied for: dispatcher. Ten agents is a team of direct reports, and managing ten direct reports one keystroke at a time is a worse job than doing the work yourself. The productivity gain was real and the workflow was still broken. The human had been promoted into the one position in the system that doesn’t scale.

To see why that position exists at all, it helps to separate the two loops that agentic work actually runs on. There’s an inner loop: read the issue, write the code, run the tests, read the failure, and try again. And there’s an outer loop: decide what’s worth building, judge whether the result is correct, and choose what happens next. The agent runs the inner loop. You run the outer one. For most of the last two years those loops were welded together because the models couldn’t be trusted to run the inner loop alone. You watched the work stream past, caught the moment it went the wrong direction, hit escape, and steered it back.

That babysitting was rational when the models needed it. It isn’t rational now. The current generation reads intent well enough that watching it type is like standing behind a competent colleague and reading each line over their shoulder as they write it. You wouldn’t do that to a person you trusted, and the reason you still do it to the agent is habit, not necessity. The reflex to watch was a workaround for a weakness the models mostly grew out of. Keeping the reflex after the weakness is gone just burns the one resource you can’t refill.

Managing one manager

Once you stop watching the worker, the shape of the job changes. You stop managing ten workers and start managing one manager. Picture a single long-lived agent that never closes. An issue lands on an open-source repo. The manager wakes, reads the issue against the project’s stated goals and notes, and decides whether it’s even a fit. If it is, it spins up a worker. The worker investigates, writes the change, and runs the tests. A second agent reviews the diff. You don’t see any of that. What reaches you is a pull request with the original issue, the proposed change, and maybe a running build you can open over VNC and click around in yourself. You leave one note. You approve, or you don’t. The loop keeps going and the change lands after the checks pass.

Three things make that arrangement hold together, and none of them are the model. The first is persistent context: server-side compaction, which compresses a long task’s history so the work doesn’t collapse when the context window fills. Before that existed, every long job had to be nursed back from a fresh session, which is why people optimized their whole workflow around short tasks. The second is delegation: one thread that can create and steer sub-projects instead of doing everything itself. The third is triggers, some event that can wake the manager when an issue arrives or a build breaks, so the loop starts without you starting it. Persistent memory, delegation, a way to be woken. That’s a loop. One engineer already runs a “chief of staff” agent that wakes every ten minutes to coordinate his repository and opens a thread in the sidebar whenever it needs a human decision. He isn’t watching it. He’s answering it.

The bottleneck keeps moving

The interesting part is what happens to the bottleneck once the loop is running, because it doesn’t disappear. It moves. The first wall people hit was tokens: not enough model budget to run the work they wanted. Solve that and the next wall is compute, ten threads running at once until the laptop sounds like it’s about to take off, which is why agents started shipping their test runs to separate machines. Solve compute and the wall you hit is your own attention, and that one has no upgrade path. You can add tokens. You can rent compute. You cannot buy a second person to sit in your chair and make your judgment calls. Every constraint you remove promotes the next one, and the human is always the last constraint standing.

Which is the actual point, and it’s easy to miss while admiring the models. The models are improving faster than anything built around them. The harness the agent runs inside, the org chart of agents that decides who does what, the triggers that wake them, and the review gates that let a change land safely without you reading every line: all of that is underbuilt, and it’s underbuilt because we spent the last two years staring at the model instead of the structure. A model that can write a correct pull request in ten seconds is worth very little to you if it still requires you to be personally present for every one of them. The gap between what the model can do and what your workflow lets it do is now the whole game.

Engineering the loop

So the thing worth engineering has changed underneath us. It used to be the feature. Then, for a brief and clarifying while, it was the pull request, the unit of reviewable change. Now the object worth designing is the loop itself: the standing arrangement of manager and workers and triggers and review that turns an incoming issue into a landed change while you’re doing something else. That’s a design problem with real decisions in it. What does the manager escalate and what does it decide alone? Which work runs in the cloud and which needs your machine? What has to be true before a change lands without a human reading it? Those questions have the texture of architecture, because that’s what they are.

The engineer juggling ten terminals wasn’t behind because he lacked good agents. He had good agents. He was behind because he was still the loop, doing by hand the coordination that should have been built once and left to run. The future isn’t twenty terminals open at once, each one waiting for you to notice it. It’s the loop you build so the twentieth terminal never has to open.

Nearly every app you use was built for a person who looks at a screen, points at things, and fixes small mistakes by eye before they matter. An agent doesn’t look. It reads, it acts, and it acts for someone who isn’t watching it work. So the product that wins the agent’s business won’t be the one with the prettiest dashboard. It’ll be the one an agent can pick up and run correctly on the first try, with nobody in the room to catch the error.

Design your product as if an agent is one of your most important users. That doesn’t mean ripping out your interface and bolting on a chat box; a prompt box on top of a confused product just gives the confusion a friendlier face. It means exposing the real structure of what your software does, clearly enough that a person and an agent can both run it. Four things make that possible, and most products today get all four wrong.

The API is the product, not a side door

The API used to be where you put the features that were convenient to expose. The clean ones. The ones that didn’t touch messy internal state or force a user through a three-step wizard with a warning to read and click past. The full product lived in the UI, and the API got a tidy excerpt of it, enough to integrate against but never the whole machine.

An agent works through that contract and nothing else. If a job your users do every day takes four actions and you exposed three, the agent can’t finish. It gets most of the way and stalls. Or worse: it finds a creative path through the three you did expose and leaves your data somewhere no human would have put it. Whatever your API leaves out, the agent can’t do, no matter how central it is to your product.

So expose the real actions, including the ones that felt too risky or too fiddly to publish. The wizard with the scary warning becomes an endpoint with a confirm flag. The thing a person does by shift-selecting forty rows and hitting delete becomes one call that takes forty IDs. The test is simple: if a person can do it in your product, an agent should be able to ask for it through the API.

Documentation has to change shape too. Most API docs only describe endpoints: here’s the route, here are the fields, here’s what comes back. An agent needs to know what the thing means, not just what it accepts. What’s an “account” in your system, and how is it different from an “organization” and a “workspace”? When does a charge become an invoice? Docs that explain the business concepts, and the rules connecting them, let an agent reason about a task instead of guessing at field names. Endpoint reference tells it how to call; concept docs tell it when and why.

And the object model has to be one model. The same entity should carry the same name and the same shape in the UI, the API, the exports, the webhooks, and the audit log. When a “customer” in the interface is an “account” in the API, a “user” in the CSV export, and a “party” in the webhook payload, a human shrugs and pattern-matches across the inconsistency without noticing. An agent can’t. It reads all five surfaces literally and concludes you have five different things. One concept with five names is five chances for the agent to act on the wrong one.

Make actions visible and reversible

Agents make mistakes.

So do people, and we’ve built our whole relationship with software around that fact: undo buttons, confirmation dialogs, the half-second of hesitation before someone clicks delete. But a person carries something an agent doesn’t. They remember what they did and roughly why. Ask them an hour later and they can reconstruct the decision and walk it back by hand, even if it takes a while to retrace.

An agent has no memory you can count on. The reasoning that produced an action may be gone the moment the action completes. If your product is the only durable record of what happened, that record has to be a good one. That means a trace for every action: what was attempted, what context informed it, which tool or endpoint was called, what changed, and how to undo it. Not a log line that reads PATCH /accounts/8821 200. A record a human reviewer, or another agent, can read later and understand: this agent, acting for this person, changed this field from this to that, because it was working on this task.

Often the reader isn’t a person at all. A supervising agent checks the work it delegated, or a compliance system scans for actions that crossed a line, and once in a while a human skims a week of agent activity over coffee, looking for anything that smells wrong. None of them can reconstruct what the agent was thinking, because that’s gone. So the trace has to carry the why, in a form the next reader can act on, whoever that reader turns out to be. A trace written for a developer staring at a stack trace at midnight won’t cut it.

Reversibility is the harder half. Plenty of products can tell you what happened; far fewer can put it back. The teams agents get trusted with will be the ones where a wrong action costs a rollback instead of a weekend. A product that can’t undo an agent’s mistake is one no sensible person lets an agent near for anything that matters. Action-level observability isn’t a feature you build for your own debugging; it’s the price of being let into the loop at all.

Permissions that assume delegated work

Almost every permission system in production today encodes one idea: a user is a person, and a person either can or can’t do a thing. Roles, scopes, access levels, all of it built around a human identity making a human decision in real time. Agentic work breaks that model, and not by needing more access. It needs access with more shape to it.

A founder building for this should be asking one precise question: what can an agent safely do on behalf of a user, a team, a whole company? The honest answer sits between “everything its owner can” and “nothing,” and the product has to give that middle ground a vocabulary.

Some of it is scope: an agent gets exactly the slice of authority its task needs and none of the rest. Some of it is time. A grant for Tuesday’s migration should expire Wednesday morning, not sit live for a year because nobody revoked it. Thresholds matter too: let the agent move forty dollars on its own, but make it stop and find a human for forty thousand. Give it a dry-run mode so it can show what it would do and wait for a yes. And put the rules in the system itself, enforced on every call, instead of in some operator’s head where they only get enforced when that operator happens to be watching.

None of this is exotic. A finance team already understands spending limits and approval chains; an ops team already understands temporary access. The work is taking those instincts, the ones we apply to people through process and trust, and turning them into mechanisms the product enforces on a non-human actor that won’t get tired, won’t feel awkward exceeding its mandate, and will do exactly what its permissions allow, ten thousand times, at three in the morning.

Data quality is now product surface

There’s a comfortable idea that data quality is an internal problem. Stale records, ambiguous fields, three duplicate copies of the same customer, an edge case nobody wrote down: messy, embarrassing, but contained. A human operator routes around all of it without thinking. They know the “status” field went unused after 2023, that the real email is in the second record and not the first, that when the amount is zero it actually means “pending” because of a bug from years ago that hardened into a convention.

An agent knows none of that, and it has no instinct to be suspicious. It reads your data as true and acts. Hand it the stale record and it emails someone who left the company a year ago. Give it two fields that both look like an email and it picks the wrong one. And when it meets that zero-means-pending charge, it tells the customer they owe nothing. Where your ops team quietly routes around the mess, the agent runs straight through it and multiplies it across every record you have.

So data quality has moved. It used to be something your operations team absorbed quietly behind the interface. Now it’s surface area, as much a part of what you ship as any endpoint. The duplicate entities, the fields whose meaning drifted, the edge cases that live only in tribal knowledge: every one of them is a place an agent can go wrong on a user’s behalf. An agent is only as good as the context it can trust, and your product is that context. Cleaning up the records, making the names mean one thing, writing down the conventions that only live in someone’s head: that used to be housekeeping for a slow afternoon. Now it decides whether an agent comes to rely on your product or quietly learns to route around it.

What you’re actually building

These four pieces are the same piece seen from four sides. An honest API, traces you can read and reverse, permissions built for delegation, data clean enough to act on: each one answers whether a thing that reads instead of looks can run your software without wrecking it or getting wrecked by it.

Identity already got the agent through your door; that part’s mostly solved. What it finds on the other side is still up to you. Build it so a non-human operator can see the structure, undo its own mistakes, hold exactly the authority you handed it, and trust the data in front of it, and agents will get sent to you to do real work. Skip it, and you become one more tool agents quietly learn to avoid, and you won’t even get a bug report to tell you why; the traffic just thins out and then it’s gone.

A year ago, the price of a token was a rounding error in most engineering budgets. You wrote the prompt, you got the answer, and the bill at the end of the month was small enough that nobody in finance asked about it. That era is over. Token spend is now a line item that VPs interrogate, and the reason is simple arithmetic: when a product makes millions of model calls a day, the difference between a frontier model like Claude Opus 4.8 at twenty-five dollars per million output tokens and a budget tier at a dollar or two is the difference between a healthy gross margin and a board meeting about unit economics.

The response to that pressure has a name now. It’s called model routing, and it spread faster than almost any infrastructure pattern I’ve watched. In roughly ninety days it went from something a handful of cost-obsessed startups did to something nearly every serious shop does. Route the easy request to the cheap model, route the hard one to the expensive model, and send the ambiguous one to whichever model your data says handles that shape of problem best. The mechanics vary, but the move is the same: stop sending every request to one model and start choosing per request.

That this happened so fast tells you something. Routing isn’t a clever optimization a few teams discovered. It’s the natural consequence of a market that finally has more than one credible product. When OpenAI shipped GPT-4 in March 2023, it was the only place to buy frontier reasoning, and there was nothing to route between. Now there’s a deep bench: a frontier tier from three or four labs, a fast-and-cheap tier under each of them, open-weight models you can host yourself, and a long tail of specialized models tuned for code, extraction, or classification. The moment a real menu existed, routing was inevitable. The only surprise is that anyone expected it to take longer.

So routing is settled. Within a year it will be as unremarkable as a load balancer, a piece of plumbing nobody brags about. Which means the interesting question has already moved. Once everyone routes, routing itself stops being an advantage. The advantage moves to the decision the router makes. The question is no longer whether you route. It’s what you route to, and how you know.

That question is where model arbitrage lives.

What arbitrage actually means here

Borrow the word from finance, because the structure is identical. An arbitrage is a price difference between two things that are, for your purposes, the same. The classic version: a stock trades at one price in London and a slightly different price in New York, and someone with fast pipes buys in one market and sells in the other until the gap closes. The profit comes not from predicting anything but from noticing that two prices that should be equal aren’t.

Model arbitrage is the same trade applied to capability. For a given task, several models will produce an answer good enough to ship, and they do not charge the same price for that answer. A summarization job that GPT-4 handled at sixty dollars per million output tokens in 2023 gets done just as well today by Claude Haiku 4.5 at five dollars, or by an open-weight model you run yourself for the cost of the GPU. If the cheaper model clears the bar the task actually requires, the difference between what you could pay and what you do pay is pure margin. You captured a price gap between two things that, for this task, were equivalent.

The catch is the phrase “for this task.” In finance the two stocks are provably identical; a share is a share. In models, equivalence is something you have to establish, task by task, and it’s rarely obvious. A cheap model that nails 95% of your customer-support replies might botch the 5% that involve a refund policy, and that 5% might be the only part that costs you money when it’s wrong. Equivalence isn’t a property of the model. It’s a property of the model against your specific task at your specific tolerance for error. The whole game is figuring out where the line sits.

The arbitrage is real, and it’s large

Take a document-extraction pipeline that pulls the vendor name, the total, and the due date off an invoice. A frontier model does this perfectly and charges accordingly. But extraction from semi-structured text is not a hard reasoning problem. A model a tenth the price will hit the same accuracy, and you can prove it by running both against a few hundred labeled invoices and comparing the fields. If the cheap model matches on your test set, every invoice you process on the expensive model from then on is money set on fire.

Now multiply that across every distinct task in a product. Classification, routing of support tickets, first-draft generation, reranking search results, tagging, translation. Each one has its own difficulty, its own error tolerance, and its own cheapest sufficient model. A team that has measured all of them and matches each task to the floor that clears it can run the same product at a fraction of the cost of a team that sends everything to the best model out of caution. Same output, wildly different bill. That spread is the arbitrage, and right now it’s enormous, because most teams haven’t done the measuring. They route on vibes, or they don’t route at all and pay the frontier rate for invoice parsing.

Why this won’t simply close

The finance analogy bends in a useful way at exactly this point. In real markets, arbitrage is self-erasing. The traders who exploit a price gap also close it; their buying and selling pushes the two prices together until the opportunity is gone. The reward for finding an arbitrage is to destroy it.

Model arbitrage doesn’t close, and the reason is that the underlying prices won’t hold still. GPT-4 launched in March 2023 at sixty dollars per million output tokens. Three years on, GPT-5 does more than that model ever could at five dollars, and a nano tier sits a little above a dollar: close to a fiftyfold drop in the price of a capable token, and the curve hasn’t flattened since. A new model ships roughly every few weeks, and each release redraws the map. A model that was frontier-only last month gets a cheap-tier cousin this month that does 90% of the job, which moves the floor for every task you’d routed to the expensive tier. Prices drop in steps, not smoothly, and capabilities jump in clusters. The cheapest model that clears a given task is a moving target that moves on the labs’ release schedule, not yours.

That’s what makes this durable rather than a one-time saving. The arbitrage isn’t a gap you find once and pocket. It’s a gap that reopens every time the menu changes, which is constantly. The teams that win aren’t the ones who found the right routing table in early 2026. They’re the ones who can re-derive it next month, and the month after, without a heroic manual effort each time.

The actual asset, then, isn’t the router. Routing logic is a weekend’s work, and every cloud will sell you one. It isn’t a relationship with a particular lab either; that relationship is a liability the moment a competitor undercuts them. The asset is the measurement: a standing evaluation harness that knows, for each task you run, exactly how cheap a model you can drop to before quality falls through the floor. The team that has that can re-price its entire stack the day a new model lands. The team that doesn’t is guessing, and paying for the guess.

This reframes what’s scarce. We spent the last two years treating access to the best model as the thing worth having, the way you’d treat a faster CPU. Access is no longer scarce; there are four best models and they all have an API. What’s scarce is knowing precisely how good a model your task actually needs, because that knowledge is the only thing that converts a falling price into a captured margin. The model is a commodity you rent by the token. Your understanding of your own workload is the position you hold.

Which means the eval harness has to come before the router, not after it. Label your tasks, measure where each one breaks, and keep the test set fresh enough that you can re-run it the morning a new model drops. The routing falls out of the measurement; it can’t lead it. Everyone is about to be routing. The teams that know what they’re routing to, and re-check it every time the prices move, will quietly run the same product for a fraction of what their competitors pay, and the gap will widen every week neither side is looking.

Subscribe now

Every frontier lab shipped a coding agent in the last year. OpenAI, Anthropic, Google, the open-weight teams behind Kimi and DeepSeek. If you only watched the launches, you’d think the world ran out of software to write and these companies were racing to serve the same few million programmers. That’s not what’s happening. The coding agent is the most general bet any of these labs has placed, and the fact that it writes code is almost incidental.

Here’s what the launches don’t say out loud: coding is a proxy for computer use. A command line, a handful of scripts, and an API on nearly every service get you most of the way to automating any knowledge work, not just software. When a model can write and run code, it can rename ten thousand files, reconcile two spreadsheets, pull a report from an internal tool, reformat it, and email the result. None of that is “programming” in the sense we picture when we imagine an engineer at a standup. It’s office work. The coding agent just happens to be the body that can do it.

Watch a capable one work and the disguise gets obvious. It writes a three-line script to do what a person would have done with forty clicks across three windows, runs it, reads the output, and decides what to do next. The code is scaffolding it throws away the moment the task is done. What’s left is the result, which is the only part anyone wanted.

The computer was always programmable

We forgot that the computer was always programmable. For its first few decades, that’s all it was. You typed instructions and it followed them. The graphical interface was an act of translation built for people: it took the machine’s native programmability and hid it behind buttons and windows so someone who never wanted to learn a shell could still get work done. That translation was a gift to us and a tax on the machine. Every menu, every modal, and every drag target exists because a human needs to see it and point at it.

An agent needs none of that. Give a model a shell and it talks to the computer in the computer’s own language, the one we papered over forty years ago because it was too hard for most people. So the labs aren’t teaching agents to code because code is the goal. They’re teaching agents to code because code is the widest door into the machine. Once you’re through that door, the question stops being “what can this model write” and becomes “what can this model reach.”

The file system is the working primitive

That’s why the file system matters so much right now. It’s the working primitive of this era, and it earns the role by asking nothing new of anyone. It’s already on every machine. It’s ready for a command line. An agent can move through it, read from it, and act on it without a single special interface built first. A folder of PDFs is a database the agent already knows how to query. A directory of notes is memory it can update between tasks.

Andrej Karpathy’s idea of an agent keeping its own wiki on disk works precisely because the file system demands no setup. You don’t provision it. You don’t define a schema or stand up a service. The simplest abstraction wins, and today the simplest abstraction that lets an agent touch real work is a folder it can open. That simplicity is the whole point, and it’s also the catch. The file system works because it’s text, and text is what these models were born fluent in. But most of the world’s work doesn’t live in text you can read off a page. It lives behind screens.

Vision breaks the text ceiling

Vision is the next layer, and it’s the one that breaks the ceiling. A coding agent can do anything you can express as a script. It still can’t do the thing a temp does on their first morning: look at an unfamiliar screen, find the button that says “Approve,” and click it. Plenty of software offers no API, no command line, and no clean way in except the pixels a person stares at. When an agent can read a screen the way it reads a file, the reachable surface stops being “everything programmable” and becomes “everything visible.” That’s a far larger number. It includes the legacy desktop app the finance team won’t give up, the internal tool nobody documented, and the vendor portal that ships no integration on purpose.

Vision doesn’t replace the coding layer. It extends that layer to the parts of the computer we never bothered to make programmable, because the only user was ever a human with eyes. You can read the order of operations in how the labs are moving. Coding first, because it’s the cheapest and most reliable way to reach the programmable majority of tasks. Vision second, because it’s harder and the models aren’t quite there, but it’s the only path to the rest. The endpoint isn’t a smarter autocomplete. It’s an agent that operates a computer the way you do, through whatever interface happens to be in front of it.

What this means for what you build

This should change what you build. The instinct, when a new capability appears, is to wrap it. Put a clean interface on the coding agent, add a few buttons, and ship a product. But look at what the agents are converging toward. They’re learning to use the computer directly, the same surfaces a person uses. The wrapper you build to sit between the agent and the work is the exact thing the next model release makes unnecessary. We used to add value by being the friendly layer over a hard system. The friendly layer is now the thing getting automated.

What survives is the opposite of a wrapper. It’s whatever makes the underlying surface richer for an agent that’s already standing on it. If your software is the system of record, the durable move is making it something an agent can read and act on cleanly, not bolting an AI button onto the screens you already have. If your value is locked inside documents, the play isn’t a chatbot stretched over them; it’s turning those documents into context an agent can trust. The labs are handing every builder a worker who already uses a command line and will soon use a screen. The work left for the rest of us isn’t building the worker. It’s making sure that when the worker shows up, the thing it needs to touch is ready to be touched.

This is why the coding agent is a bigger deal than it looks, and why reading it as a tool for programmers misses the point. Code was never the territory. It’s the road: paved, already running almost everywhere, and the few places it can’t reach are the places vision is being built to cover. If you’re deciding where to spend the next two years, don’t spend them smoothing the on-ramp to that road. Build the destination worth driving to, and make sure an agent can get in the door.

Subscribe now

The code review is a dying art. It used to be the last checkpoint before production. A human pulled up the diff, read it line by line, asked the questions that mattered, and signed off. That person was why you could sleep at night. They’d seen the failure before, so they caught it before your customers did.

That checkpoint is gone, and most teams haven’t admitted it yet.

The code still gets written, more of it than ever. An agent ships in an afternoon what used to take a week. It compiles, the tests pass, it looks right, so it merges. The diff that lands in the review queue is too big to read with any care, and there are forty more behind it. The person who used to read every line now skims for whatever looks obviously wrong. Nothing looks obviously wrong. That’s the problem.

Why reading harder won’t save you

The instinct is to read more carefully. Hire reviewers, buy a review tool that summarizes the diff and flags the risky parts, slow down and look.

It won’t hold. The bottleneck used to be typing; now it’s reading, and reading is the part that doesn’t scale. A reviewer can read a function and confirm it’s internally consistent. What they can’t do, at the speed agents now produce code, is hold every invariant of a live distributed system in their head and check each new function against all of them. The invariant that got violated lives in a different file, a different service, last week’s deploy. It isn’t in the diff, and no amount of staring will put it there.

Better review tools answer the reviewer’s questions faster. They don’t reduce the number of questions, and every question is about an invariant the code might have broken. Does this fire once? Does it roll back if it crashes halfway? Can these two writes race? The list is long, and it grows with every service you add. You’ll never read your way to the bottom of it.

Where the question goes next

If you can’t read your way out, the question has to change. Not “how do we review this code well enough to trust it,” but “how do we make the code trustworthy whether or not anyone reads it.”

That’s the only version of the question that survives a world where most code is written by agents and skimmed, not authored, by humans. Correctness can’t keep living in the reviewer’s head, because the reviewer can’t keep up. It has to move down a layer, into the substrate the code runs on: where retries fire once because the runtime makes them idempotent, where a crash halfway through a write rolls back because the transaction is atomic, where two writes can’t race because the system serializes them. Put correctness in the runtime, and the agent can write naive code on top of it while the system stays correct anyway. Not because someone caught the bug in review, but because the bug was never possible to write.

The fear is real, and reading harder won’t make it go away. The last human who read every line isn’t coming back. What can come back is the thing that person gave you: confidence that the code in production won’t betray you six weeks from now. That confidence used to come from a careful pair of eyes on a diff. Now it has to come from the ground the code stands on.

A 2019 study co-authored by Microsoft Research gathered nearly 6,000 self-reports from professional developers about what they actually do all day. The answers did not surprise anyone who has sat through countless sprint meetings, architecture reviews, and requirements conversations.

Writing code turns out to be one of the smaller things developers do. Estimates vary widely by study, anywhere from nine percent of the day to sixty-one percent. Either way, a large share of every day goes to something other than typing: figuring out what to build, and whether it’s the right thing to build at all.

Most of the day isn’t code

Which is why you can double your rate of code production and watch the gain evaporate. Typing was never what slowed delivery. You produce more code, which puts pressure on things like the review process. Turn the firehose up and the question becomes whether your review can absorb the flow at quality. Most teams never measure that before they turn up the volume.

Agentic engineering is that valve thrown wide open. It pours code into the pipeline you already have, faster, and magnifies the debt you were already carrying. You feel quick in the one place you can see, lines appearing on screen, while the parts that actually gate delivery get slower.

The job behind the keyboard

Your role was always translation, turning requirements from the business into something that adds value to your users. The keyboard work was the visible proxy for that, the thing you could point to at the end of the day. Now the proxy is cheap and the real work stands exposed.

Does this match the requirement? Which constraints apply? Writing for an embedded device with kilobytes of memory and writing for a cloud platform at scale are different problems, and an agent will solve the wrong one with great fluency. Knowing which problem you’re in is the judgment that doesn’t go away.

What was actually scarce

None of this reads as loss once you see what was actually scarce. The craft pride of the profession attached itself to the code, because the code was the hard part you could hold up and show someone.

That pride is looking for its real object now. It was never the syntax or the speed of your hands. It was the judgment about what to build, and the taste to reject a fluent wrong answer by asking for options before you commit to one.

Keep those and the agent becomes the best junior engineer you’ve ever managed. Lose track of them and it’s a faster way to ship the wrong thing, with screenshots to prove how fast you got there.

For most of the web’s history, “shipping the app” meant shipping a website. If you had budget, you added an iOS build, maybe an Android one, and a public API so partners could pull data. The list of ways someone could touch your product was short, and it stayed short for years. A team could hand-build each entry because there were three or four of them and they rarely changed.

The surface count keeps growing

That list isn’t short anymore, and it changes every quarter. You still have web and mobile. You have a REST API and probably a GraphQL one beside it. You have webhooks. You have an MCP server now because your users want their agents to reach your product without a human clicking through a UI. You have a Slack app, a browser extension, a CLI, and an embeddable widget that lives inside someone else’s dashboard. Each of these is a surface: a distinct way a human or a machine touches the same underlying product.

Most teams treat each surface as its own project. The web app has its own state management, its own notion of what a “project” is and which buttons should be disabled when. The mobile app reimplements that logic in Swift and Kotlin. The API has its own serializers and its own idea of which fields are writable. The MCP server, bolted on last quarter, has a third interpretation of the same rules. Five teams, or five sprints, each building a slightly different model of the same business.

The second change is where you pay

The cost of that isn’t the first build. It’s the second change. A product manager decides that an archived project can be restored within thirty days but not after. That’s one rule. Now it has to be re-expressed in the web client’s state machine, the mobile view models, the API’s permission checks, the MCP tool’s input schema, and the Slack command handler. Five implementations of one idea, written by different people at different times werre tested to different standards. They drift. The web app enforces the thirty-day window; the API forgot; the agent calling your MCP server happily restores a project from last year and corrupts a report. Nobody decided that behavior. It’s the residue of five surfaces each owning a copy of logic that should have lived in one place.

One state, many projections

The alternative is a single canonical representation of what your application is and what it can do, with each surface as a thin projection of that representation. The state lives in one place: what entities exist, what fields they carry, which transitions are legal, and who’s allowed to perform them. No surface owns any of that. A surface is a view onto it. The web client renders the state as HTML and interactive controls. The API renders it as JSON over HTTP. The MCP server renders the same legal transitions as tools an agent can call, with the same permission checks the web UI runs. When “restore within thirty days” becomes a rule, you define it once, against the canonical model, and every surface inherits it the moment you deploy. The agent can’t restore the year-old project because the state machine it’s projecting through won’t allow the transition. Not because someone remembered to add a guard in the MCP handler.

This sounds like ordinary good architecture, and at a small scale you can argue it’s premature. You can’t anymore. The objection used to be “you’re building an abstraction for surfaces you don’t have yet.” But you do have them, and you’re getting more whether you plan for them or not. MCP didn’t exist before Anthropic published it in November 2024. By 2026 it’s a surface your users expect, the same way they expected a mobile app in 2012 and a public API in 2016. You’re going to pay the cost of supporting these surfaces regardless. The only decision left is whether you pay it once, against a shared model, or N times, once per surface, plus the compounding tax of keeping N copies in sync forever.

New surfaces are distribution channels

That’s the defensive case. The offensive case is where this turns into an actual advantage, and it’s about speed.

Every surface is a distribution channel. It’s a place your product can be reached that it couldn’t before, by a kind of user or a kind of software that wasn’t in the room last year. When agents became real buyers of software functionality in 2025, the products that already exposed their capabilities as clean, callable transitions got reached. The products whose logic was trapped inside a React bundle did not. An agent can’t click a button that only exists as a rendered component with three hundred lines of event handlers behind it. It can call a tool. If your capabilities are already modeled as transitions on a shared state, exposing them as tools is a projection you write in days. If they’re scattered across client code, it’s a quarter of untangling, and you ship the integration after the moment that mattered has passed.

Speed on surfaces compounds. The architecture that makes your fifth surface cheap makes your eighth surface nearly free because the expensive part (deciding what your app actually is and means) is already done and reused. The team that can light up a new surface in a week while a competitor takes two quarters isn’t just faster. It’s present in places the competitor is absent: inside the agent that became the default way a customer segment gets work done, inside the partner’s dashboard, on the platform that didn’t exist when either company wrote its first line of code. Being early to a surface is worth what being early to the App Store was in 2009 or early to having any web presence was in 1996. The norms get set, the integrations get built, and the default gets chosen while the latecomers are still refactoring.

One place to reason about the product

There’s a quieter benefit too. When the state is canonical and surfaces are projections, you can reason about your whole product from one place. You can answer “who can do what” by reading the model, not by auditing five codebases and hoping they agree. New surfaces become a question of how to render existing truth, not what the truth is. That separation is what lets a small team behave like a large one: the work of defining the product happens once and the work of exposing it scales out cheaply.

Prepare for the surface without a name

The next surface is already coming, and you don’t know its name yet. Two years ago nobody was provisioning for MCP; two years from now there’s a channel we’re not describing here because it hasn’t shipped. The question that decides whether you reach it in time isn’t how clever your web app is. It’s whether your product is one thing with many views or a pile of views pretending to be one thing.

Fred Brooks published The Mythical Man-Month in 1975, and every working engineer has absorbed its central lesson whether they’ve read it or not: adding people to a late software project makes it later. The reason is communication. Each new engineer multiplies the number of conversations the team has to hold in its collective head, and at some point the conversations cost more than the code they produce. Fifty years later we quote Brooks like scripture and build as if he were wrong.

The trap only springs on the projects that work. Software that fails never has this problem. The moment you have revenue, you have users, and users hand you feature requests and bug reports and a competitor shipping something you don’t have yet. Any company worth running takes on technical debt on purpose, as a bet, because the alternative is losing. So success is what generates the demands that wear down the thing that made you successful.

You don’t get to opt out. The bill arrives precisely because you won.

What you’re paying down, as the code grows, is cohesion. Early on a system has a few authors who share an unspoken model of how things should work: where logic belongs, what the error-handling convention is, which abstractions are sacred and which are throwaway. None of it is written down because none of it needs to be. The architecture lives in three or four people’s heads, and those heads talk every day.

Then you hire, because the feature requests don’t stop, and each new contributor shows up without the shared model. They write reasonable code in a slightly different dialect. The seniors review what they can, but review is a bottleneck and the queue grows faster than the reviewers do. Standards that were obvious become standards that are merely documented, and a documented standard is one that gets skipped at 11pm the night before a release. Give it a few years and the codebase no longer expresses one point of view. It expresses the running average of everyone who ever touched it, which is to say it expresses almost nothing.

We’ve spent decades calling this a people problem and throwing people-shaped fixes at it. Style guides. Onboarding decks. Architecture review boards. The staff engineer who personally reads every pull request until the week they quit. All of these help a little, and all of them share one flaw: they need a human holding the standard in mind at the exact moment the standard is at risk. We’re bad at that. We get tired, we get rushed, we want to be agreeable to the colleague whose code we’re reviewing at 11pm. The standard doesn’t collapse because someone decided to abandon it. It just erodes, one reasonable exception at a time, because no single decision was ever made to hold the line.

Now the same dynamic is arriving faster than anything we’ve had to absorb before. Agents write code, and they write a lot of it, fast. Whatever drift you used to get from a new hire over six months you can now get from an agent over an afternoon. The agent has no model of your system. It has a general model of all systems, which is worse, because its output is plausible. It will hand you code that looks like it belongs and quietly breaks the convention you’ve protected for three years. Put a handful of agents behind every engineer on the team and the old review bottleneck doesn’t just strain, it gives.

Declarative enforcement changes the shape of the problem. The idea predates AI and it’s simpler than it sounds. The people responsible for the system, the architects and senior engineers, write down the constraints that must hold across the codebase, and the machine enforces them instead of human memory. Not as a guideline anyone can talk their way past, but as a rule the build itself checks. The architect’s judgment stops living only in a head and starts living in a form the system can apply on its own.

What matters is when the check fires. A rule that only runs in review runs too late: the code’s written, the author’s moved on, the reviewer is the bottleneck all over again. A rule that runs inside the editor, while the code is being typed, changes the whole economy of the thing. The constraint becomes a wall you hit in the moment instead of a verdict you get back a day later. And it doesn’t care who’s writing. A human in the editor and an agent generating a thousand lines hit the same wall at the same place. You stop having to trust that the agent absorbed your conventions, because trust never enters into it. The code passes or it doesn’t. And that’s the part that takes a minute to sit with, because we’ve spent this whole transition asking how to make the model write code that meets our standards, as if the answer were somewhere inside the model. It isn’t, and it can’t be, because the model doesn’t know your standards and won’t ever know them in a way you can rely on. The answer sits outside the model, in the constraints you’ve made explicit enough for a machine to check. You stop trying to grow a better author and start defining what acceptable output looks like, then let anything that wants to contribute clear that bar or fail trying. The author gets interchangeable. The specification is the thing you actually maintain now.

For a big organization this reprices a kind of work that has always felt like dead weight. Compliance: the rules a regulated company has to hold on every line it ships, access controls, data-handling requirements, the audit trail. None of it ships a single feature to a single customer. It’s the work developers do so the company is allowed to keep operating, and for years it’s been enforced through documentation, training, and a quiet hope that everyone remembers the policy under deadline. Write it as constraints the editor checks, and that entire class of requirement stops being something people have to remember and becomes something the system won’t let them violate in the first place. The compliance rule and the architectural rule turn out to be the same kind of object. Both are intent, written down, made enforceable.

Brooks’s law was never really about headcount. It was about the cost of keeping many minds aligned around one design, and how that cost climbs faster than the team that’s paying it. For fifty years the only move we had was to align the minds: hire slowly, document everything, review until your eyes bled. That move is failing under a load it was never built for, because the new contributors aren’t minds and they show up by the thousand.

So you move the alignment out of the minds and into the system. Write the constraint once, where the judgment actually lives, and let it hold against every author the same way. The seniors don’t review more. They decide what’s allowed to be true, and the codebase keeps enforcing that decision at three in the morning when nobody’s awake to defend it. The cohesion tax doesn’t go away. You just stop paying it one tired reviewer at a time.

The price of a working line of code has been falling for many years, and this year it landed near zero. Each step took a slice of the work out of human hands: the compiler, the high-level language, the package registry, the answer already posted on Stack Overflow, and the autocomplete that finished your line. Agents took what was left. You describe a feature and the code comes back, compiling, passing the tests for the cases you named, clean when you run the demo. Translating intent into code, the skill that used to define the job, has stopped being scarce.

But now there is a new cost, and it moved somewhere harder to see.

The bug is in what nobody wrote

Picture a money transfer: debit one account, credit another. Routine. An agent writes it in seconds, and the code is right for every case you’d think to check. A customer moves $200 from checking to savings. Four months later that customer notices the $200 left checking and never arrived in savings. The server had restarted in the quarter-second between the two writes. The debit committed; the credit never ran. Nothing was logged, because from the program’s point of view nothing went wrong. It did exactly what it was told, right up until the moment it stopped existing.

That bug isn’t in the diff. You can read every line the agent produced and never find it because the defect is a line that was never written: the one that makes the debit and the credit succeed or fail together. The agent wrote what the prompt described. The prompt described a transfer, not a crash halfway through one.

This is the shape of nearly every expensive bug now. Not a wrong instruction sitting in the code where a reviewer can catch it, but a missing one. The retry that fires twice and charges twice. Two buyers both told yes for the last unit in stock. An event that arrives before the event it depends on. Engineers who’ve been burned carry these cases as instinct; they flinch at a write that isn’t idempotent the way you flinch at a hot stove. An agent has no scar tissue. It has a prompt.

Absence is the one thing our tools can’t catch

The blindness is structural. A demo exercises the path you built it to show. A test suite checks the cases someone thought to write down. Code review reads what’s on the screen. All three are good at judging what’s present and useless against what’s absent, and the bugs that reach production have always lived in the absence. We tolerated that for decades because the human author was also a slow author, and slowness worked as a filter. You couldn’t ship a thousand unconsidered edge cases in a week; you didn’t have the hours to write them.

That filter is gone. Code generation happens at machine speed and the omissions ride along with it, while the work of catching them, reading carefully and imagining what breaks runs at the same speed it always did. So a senior engineer starts reading every change line by line because the green checkmarks stopped meaning what they used to. Team throughput collapses to whatever that one careful person can vet in a day. The bill that never showed up as a bug shows up as a bottleneck instead, and the rest of it arrives later still: a support ticket, a day spent reproducing a fault that only fires when the network stalls at the wrong instant, a refund, a customer who quietly takes their next order somewhere else. None of it lands on the line item marked “engineering.”

The oldest move in computing

The instinct is to make the agent more careful. Sharper prompts, more tests, a second agent reviewing the first one’s output. That treats an omission as a mistake, and it isn’t one. You can’t reliably prompt your way to remembering every failure mode of every distributed operation any more than you could train every programmer to never once leak a pointer.

We’ve beaten problems with exactly this shape before, and never by trying harder. We moved them. Scheduling lived inside each application until the operating system took it over and handed out time slices. Memory safety was a discipline you kept by hand until virtual memory gave every process its own address space and made one program physically unable to corrupt another’s. Crash recovery meant a custom repair script bolted onto every accounting system until the database swallowed transactions whole and gave back one promise: the write happened completely, or it didn’t happen at all. Each of these began as careful, error-prone handiwork. Each ended as a layer beneath the application, where the failure it guarded against could no longer occur.

The hard problem still sitting up in the application, unmoved, is distributed correctness, the work of retrying without duplicating, surviving a crash mid-write, ordering events that have to arrive in sequence, and letting only one of two racing requests win. Every program that touches more than one machine solves this for itself, unevenly, and now generates that code at agent speed. Libraries help, but a library sits beside your code, not beneath it; you can call it wrong or forget to call it at all.

Make the failure impossible by construction

So put the model one layer down. The agent writes business logic against a runtime that owns the dangerous paths, and a verifier holds that logic to the rules you declared. Every write is idempotent by default, so the transfer that runs twice does nothing the second time. A process that dies mid-operation resumes where it stopped, the debit and the credit still bound to each other. When two requests reach for the last unit at once, the runtime serializes them and exactly one hears yes. The agent never has to remember any of this because the runtime doesn’t give it room to get it wrong.

The efficiencies of agentic code generation are real, but the true costs are poorly understood. An agent writes a service in four minutes that would have cost a senior engineer two days, and the line item drops from two days of salary to a few dollars of tokens. That money didn’t disappear. It moved downstream, into the build farm, the test fleet, the release pipeline, and the pager rotation, and none of those line items sits next to the four-minute win where anyone would think to add it back. You booked the discount at the keyboard. The bill comes due everywhere else.

This is the part of the agentic-engineering pitch that nobody puts on the slide. The productivity is genuine and the savings on code generation are genuine, and both are measured at exactly the wrong point in the system. You booked the discount at the keyboard. The bill arrives everywhere else.

The cheapest thing got cheaper, so we made more of it

Jevons noticed it with coal in 1865: make a resource cheaper to use and you don’t spend less on it, you use far more of it. Tokens are coal now. When generating code drops to near-free, you don’t end up with the same amount of code written faster. You end up with ten times the code, and Jeff Atwood’s old line stops being a quip and starts being a budget: software is a liability, not an asset. Every line is something to compile, test, review, deploy, secure, and eventually debug at three in the morning.

So start with the part everyone forgets to multiply. Five engineers each driving a swarm of agents don’t write five times the code. They write ten or twenty times more, and “write code” is only the first step in a long pipeline that now has to swallow all of it: build, test, review, deploy, operate. Walk that pipeline one stage at a time and apply a single test at each: take the number, multiply it by ten, and ask whether the stage holds. Most of them don’t, even in shops with the best tooling in the industry, and the ones that buckle first are the ones nobody was watching.

Testing is where the bill lands first

Compilation isn’t free, in wall-clock or in compute, and most engineers have never once looked at how much of their test infrastructure eats. They are about to find out. Here is the number that should scare you: at scale, the dependency graph grows quadratically with the codebase, not linearly. Ten times more code does not mean ten times more tests to run. It means a hundred times, maybe a thousand, because every change has to prove it didn’t break everything downstream of it, and the set of things downstream exploded.

That turns a background cost into a line item. A test suite that used to be an afterthought becomes one of the largest compute consumers in the company, and it has to run on every one of those ten-times-more commits, because the agents themselves love running tests. Tests are how an agent knows it did good work, so it runs them constantly, on its own initiative, burning your fleet to check its own homework.

And the old shipping rule quietly breaks. Today you ship when every test passes: a long conjunction of Booleans, all of them green. That works while the suite is small enough that the infrastructure running it is reliable. Run a hundred thousand tests on hardware that flakes even a little, and the odds that all all hundred thousand come back green at once approach zero. You can’t ship anything. So the rule that kept you safe, everything must be true, becomes a rule you have to abandon for something statistical, and now you are guessing which tests are the ones that matter. That is a different and much scarier way to live.

Deploys, and the safety valve nobody priced

Push the same multiplier into release and a load-bearing assumption gives way. Ask why rollbacks work at all today, and the honest answer is timing: you release software slightly slower than it takes you to detect a problem in production. That gap is the whole safety valve. A bad change lands, the graphs go red, you roll back to the last good state before too much piled on top.

Now speed up releases so they’re happening faster than detection. The bad change lands, and before your monitoring even notices, three more changes have shipped on top of it, each one entangled with the last. The rollback you reach for has to contend with all of them. The valve that made fast deployment survivable was never the deploy speed. It was the margin between shipping and noticing, and cheap code generation is the thing eating that margin.

Locally correct, globally wrong

The nastiest costs aren’t capacity at all. They’re the second-order ones, the bugs that compile clean and pass review and surface six weeks later in production. Agents are good at writing code that is easy to write. They are not reliably good at code that is easy to maintain, and they don’t carry the long-horizon judgment that keeps a system coherent. Each change can be locally correct, defensible on its own, reviewed and merged, and the whole still drifts toward globally wrong.

Distributed systems are where this gets expensive, and it helps to see why. A single program either works or it doesn’t, and you can usually reproduce the failure on your laptop. A network of services fails differently. Each service can be correct on its own and the system can still break in the seams between them: a call that times out and gets retried twice, a message that arrives out of order, two services that each hold a defensible view of the same record and disagree the moment they compare notes under load. Now multiply the parts. Ten times more services means ten times more of those seams, more retries colliding with more timeouts, more partial failures where half the system has the new state and half has the old. These are the bugs that don’t show up in any one service’s tests, because no one service is wrong. They appear only when the pieces run together at scale, which makes them the hardest failures in the field to reproduce and the most expensive to chase.

The same multiplier reaches the doors between services. An internal API that you left unhardened because “only our own code calls it” is now called by agents, and an agent doesn’t read your README or honor your conventions. It finds the endpoint, calls it, and reaches whatever data the endpoint will hand back. Every internal interface is effectively public the moment an agent can reach it, and the hardening you deferred because it felt safe inside the perimeter is suddenly load-bearing.

The team that never made it into the spreadsheet

Trace the chain and notice who is standing at the end of it. Bigger build fleets, exploding test compute, riskier deploys, a brittle million-line system where one bad config flag takes everything down, distributed bugs that take a war room to find. The people who absorb all of that are the operations and SRE teams, and their cost rarely gets entered against the agentic productivity win. The savings land on the engineering ledger. The new load lands on a team in a different org with a different budget, and the two numbers are never put on the same page.

There is a darker version, too. If a token engine becomes load-bearing, weird things happen. Picture a rollback path that depends on an agent having budget, and someone burns that budget dry an hour before the incident. The cheapest resource in the system, the thing you stopped metering because it felt free, is now the thing standing between you and recovery.

None of this argues for slowing down. The productivity is real and it is not going back in the box. The argument is narrower and harder to dodge: the savings and the costs live in different places, and a discount you book in one node while the bill comes due in five others is not a discount. It’s a transfer. The teams getting credit for the speed and the teams paying for it should at least be looking at the same ledger. Right now they aren’t, and the gap between the four-minute service and its true cost is exactly the size of an ops budget nobody approved.

The most valuable user your product will ever have can’t sign up for it. It can’t read your onboarding tour, and it’ll never see your pricing page the way you designed it. It’s an agent, and it’s already choosing, registering for, and operating software on someone’s behalf. It does none of the things your product was built to expect.

Software has spent its whole life bent toward one creature: a human at a screen. We made the signup form short because people hate typing. We added the password reset because people forget. We wrote the empty-state nudges and the three-tier pricing page with the middle option highlighted, all of it tuned to a person deciding whether to hand over their attention and their credit card. The user was assumed. The user had a body.

How an agent shows up

Instead, consider how an agent arrives. A human finds your product through a friend, a search, a talk at some conference. An agent finds it by reading a list of tools and matching capabilities to a task. It doesn’t care about your brand. It cares whether your API does the thing, whether the docs are precise enough to act on, and whether it can authenticate without a human in the loop. The funnel you spent a decade tuning is invisible to it. What it can see is the contract: what you do, stated exactly, in a form a machine can consume.

Signup is worse, because we’ve treated it as almost sacred and the whole ritual assumes a person. A name. An email. A verification link clicked from an inbox. A CAPTCHA built for the sole purpose of proving you aren’t what’s now your most important customer. An agent has no inbox and no patience for a checkbox asking it to confirm it’s human. So either you build a path for it to register and get its own credentials, or it routes around you to whoever did. The signup form, that careful little gate, turns into a wall against the exact traffic you want.

The real problem is identity

Most teams reach for the wrong frame here. They assume an agent is a faster human, a power user who reads the docs and hammers the API, so they rate-limit it, treat its traffic as a threat, and bolt on a service account as an afterthought. But it’s a different kind of actor with a different set of needs, and the need it cares about most is the one your product probably handles worst: identity.

An agent operating your stack is acting for someone, a person or a company, but it isn’t that person. It needs its own identity, scoped to exactly what it’s allowed to do and nothing more. It needs permissions you can grant in narrow slices and revoke the second something looks off. It needs an audit trail, because when an autonomous thing moves money or deletes records, “the user did it” stops being a true sentence. The old model gave one identity per human and called it done. The new one has a human who delegates to an agent that may delegate to three more, and every link in that chain has to be provable.

The agent is becoming the customer, and the software that wins will be the software an agent can adopt without asking a person for help at every step. That’s an auth problem, a permissions problem, a question of whether you can hand a non-human actor a real, governable identity. Get it right and an agent can choose you, sign up, and start working in seconds. Get it wrong and it never makes it past your front door, however good the thing behind the door happens to be.

What changes for the teams building

This changes the work. For years the obsession was reducing friction for humans: shaving fields off the form, smoothing the path to the first click. That work doesn’t vanish, but it’s no longer where the game gets won. The advantage now goes to making your product legible and operable by something that reads instead of looks, delegates instead of clicks, and has to prove who it is and on whose behalf. The teams that win the next decade won’t have the prettiest onboarding. They’ll have products an agent can pick up and run with, safely, without anyone holding its hand.

There’s a temptation to treat all this as niche, a thing for the AI-native startups to fuss over while everyone else keeps serving people. Comfortable, and wrong. The agent isn’t a new segment bolted onto your existing customers. It’s a layer quietly moving in between you and them, deciding which tools get used and which get skipped. Your real customer is starting to delegate the choosing.

The question was never whether to support agents. It’s whether your most valuable user can get through the door at all. For most products today the honest answer is no. It can’t sign up, can’t authenticate, can’t be trusted with a scoped slice of power. That gap is the whole difference between a tool agents reach for and one they quietly route around.

There is a kind of factory that runs without light. The Japanese built the first ones decades ago: robotic arms assembling other robotic arms in windowless halls, in the dark, because a machine has no eyes to spare and no need of the sun. Lights-out manufacturing, the trade called it. The phrase carried a faint dread, the suggestion of a place where the work continued after everyone went home, where the human had become not the worker but the absence the work was designed around.

Agentic engineers have carried the phrase into software. A software dark factory is a codebase tended by swarms of agents instead of hands, writing and rewriting itself around the clock, shipping faster than any person can read the diff.

The bottleneck is always paid

The idea is older than the silicon. It begins in the cotton country of the English north, where the first scarcity to die was not the weaver’s but the spinner’s. For centuries it took several spinners to keep a single weaver in yarn, and then the jenny and the water frame arrived and the yarn became a flood. The strange consequence, the one nobody predicted, is that the machines made the weaver rich. For a span of about twenty years a man who could throw a shuttle was among the best-paid laborers in England, because the bottleneck had moved to him, and the bottleneck is always paid.

Then the power loom came for the weaver too, and the scarcity moved again, upstream, into the man who decided what the mill should make and what it should refuse to make. The weaver, who had been the whole story, became a footnote to a machine.

A wall of terminals

An AI-pilled engineer will spin up what the trade calls swim lanes, five or ten or twenty of them at once, each a separate agent gnawing at a separate corner of the code: one on the failing tests, one on a feature, one chasing the defects that surface at night. The work, from the outside, looks like nothing. A man at a desk before a wall of terminals, each scrolling its own monologue, and him moving down the row the way a chess master walks a simul, ten seconds at a board, a glance, a nod, typing almost nothing, now and then killing a process mid-sentence with the briskness of a man who has heard enough.

He does not write the code. He cannot read all of it. One such engineer described a night that began as exhaustion and a bad idea at two in the morning and ended, by his own count, in twenty-seven hundred commits, a million lines changed, eighty-two percent of the core rewritten.

The tokens, which everyone assumed would be the constraint, are cheap. The constraint is the one resource the mill cannot manufacture, which is his attention, the finite span of a single mind trying to hold twenty machines in view at once. The bottleneck has climbed all the way up to taste.

The factory has no floor

Taste is a strange word to find at the end of an engineering story, but it is the right one. Engineers who live this way say they can feel when an agent has gone wrong. Not by what it produces but by how it talks, the way a manager senses that a clever subordinate has begun to bluff. The reasoning waffles. It loses the thread of its own intention. What they are catching is signal pulled from noise by an instinct nobody taught them, and here the story turns uneasy, because the instinct was not earned in the dark factory. It was earned in the years before, in the decades of writing code by hand, of being close to the cloth.

The mills knew this problem, though they never had to solve it. The owner’s eye for cloth was not a gift; it was a residue. He could tell good cambric from bad at a glance because he had spent his youth on the floor among the looms, had handled the stuff, had ruined some. His judgment was the sediment of labor, and when the labor moved into the machines there was still a floor downstairs, still a place a young man could go to ruin cloth and learn.

The dark factory has no floor. The judgment that supervises the machines was built by the very labor the machines have eliminated, and nobody can say where the next generation’s taste is supposed to come from, when no one types and there is nothing left to apprentice to. The first cohort of listeners may also be the last that knows what it is listening for.

No refuge is permanent

The dark factory, then, is not a story about speed. It is a story about where the human goes when the hands are no longer needed. We thought the engineer was the one who wrote the code. It turns out the engineer was always the one who decided what was worth keeping, and only now, with the writing given away, can we see that this was the work all along.

But the weaver believed his scarcity was sacred too, in the brief golden years when the machines were making him rich, and the rule the mills teach is that no refuge is permanent. Taste is where the scarcity lives now, not where it dies.

The lights are off. Someone is still in the building. He is not typing. He is listening for the one machine that has started to lie.

For as long as I’ve known software development, the work was translation. Someone (a customer, a product manager, sometimes yourself) held an intent in their head: build a billing system, index this corpus, ship this feature. The job of the engineer was to take that intent and produce something a computer could execute. Lines of code. Schemas. Configuration. Deployment scripts. The translation was the craft. We hired for it, interviewed for it, and built whole industries around teaching it.

That work has stopped being scarce.

I want to be careful what I’m claiming. Translation didn’t vanish. Models still get it wrong. Production systems still need people who understand memory layouts, distributed consistency, and why a 200ms tail latency might be load-bearing for a business. But the act of writing the code (the daily, hourly motion that defined what software engineering felt like for two generations) has been removed from the critical path. Around late 2024, the output of frontier models crossed a quiet threshold. The code they produced started being more often right than wrong, more often readable than not, and good enough that engineers started shipping it without rewriting it. That’s a different relationship to the machine than we had a year before.

What’s left, when translation isn’t the bottleneck, is a discipline without a name.

This essay is an attempt to give it one. Call it agentic engineering: the practice of producing reliable software by directing AI agents through specification, implementation, review, testing, deployment, and maintenance, while retaining human ownership of intent, architecture, and correctness.

Why the old names don’t fit

We’ve been working without vocabulary for almost two years, and it shows. Every team I talk to calls what they’re doing something different, and most of them are wrong in the same way: they pick a name that describes the tool and pretend it describes the practice.

“AI-assisted coding” was the first attempt. It’s the name a coding tool gives itself when it wants to sound non-threatening. The metaphor is the autocomplete bar. The engineer drives; the AI suggests. This was true in 2023. It stopped being true the moment you could hand an agent a repo and a task and walk away for an hour. A practice where the AI is doing most of the typing isn’t “assisted.”

“Vibe coding” captured something real. It went viral because it gave a name to the moment anyone could ship a working app by describing what they wanted. That story about lowering the floor matters. It’s not the story of how serious software gets built. Karpathy drew the line cleanly: vibe coding raises the floor; agentic engineering raises the ceiling. They use the same infrastructure and they’re not the same activity. Conflating them is how production systems end up with bugs no one can find because no one ever read the code.

“Prompt engineering” had a six-month run as a job title in 2023 and has since collapsed back into being a skill, not a discipline. Writing a good prompt is part of agentic engineering the way writing a good function name is part of software engineering. Table stakes. Not the work.

What’s missing from all of these names is the part that’s actually hard: getting a stochastic, fallible, occasionally brilliant collaborator to produce software that holds together when ten thousand users hit it on a Tuesday morning. That’s a discipline. It deserves a name. The name is agentic engineering.

What an agent is

A quick clarification before going further, because the word “agent” has been smeared across about fifteen different things in the trade press.

An agent, here, is an AI system that takes a goal expressed in natural language, plans its own intermediate steps, calls tools, reads the results, and revises its plan until the goal is met or a budget runs out. It is not a chatbot. It is not a single LLM call inside an IDE. It is a loop. The loop is the thing that makes the work feel different from anything we’ve called “AI” before.

The agent reads the codebase you point it at. It runs the tests it wrote. It opens a pull request. If the build fails, it reads the failure and tries again. That loop is doing the typing now.

The discipline of agentic engineering is the discipline of being the human at the other end of that loop.

The four practices

Four practices distinguish agentic engineering from what came before. I’ll claim each one is necessary and that the four together are sufficient — at least at the resolution at which I can see the field today, in 2026.

1. Specifying intent precisely enough that an agent can act on it

The first thing that changes when an agent can write code is that the spec stops being a comms artifact and starts being the actual program.

In the old world, a spec was a thing you wrote so that humans on your team would understand what you wanted. Engineers reading the spec did the hard interpretive work, filling in the gaps, asking clarifying questions, making judgment calls about what the writer probably meant. The code was the source of truth. The spec was scaffolding.

In agentic engineering, the spec gets executed. Not literally. But what the agent produces is downstream of how clearly you described what you wanted, and the agent doesn’t ask the clarifying questions a junior engineer would. It guesses. And it guesses confidently. A spec that says “the user should be able to recover their account” produces wildly different code depending on whether the agent assumed email recovery, SMS recovery, security questions, or all three.

This is the central skill of the new discipline: writing intent that survives a long agent run. Specs that survive have a few properties. They distinguish what’s load-bearing from what’s incidental. They name the failure modes the engineer cares about. They say what the system is not supposed to do. They tell the agent which tradeoffs the engineer has already made, so the agent doesn’t relitigate them halfway through.

You don’t learn this by writing prompts. You learn it by reading the code an agent produced from a vague spec, and watching where it went wrong.

2. Architecting systems the agent can verify itself against

The second practice is about what you build around the agent so it can tell whether it’s done.

A coder who can’t tell whether their code is working is a liability. The same is true of an agent. Most of the work of getting agents to ship production-grade software is in giving them feedback loops short enough and sharp enough that they can self-correct before they go off the rails.

What does that look like in practice? Type systems the agent has to satisfy before tests even run. Test suites that run in seconds, not minutes. Linters that fail loudly on the patterns the agent is prone to. Schemas that make malformed data impossible to commit. Observability that lets the agent read what its own code did in production. The shape of the codebase changes when its primary author is a machine that can’t yet tell good from bad without help.

This is the part of agentic engineering that looks most like traditional software architecture, and it’s the part most teams underinvest in. They focus on the model and the prompt. They neglect the question of how the agent knows when it’s wrong. Then they wonder why their agent-written code passes review but breaks in production.

A useful working rule: if your test suite takes ten minutes to run, your agent is flying blind. Get it under sixty seconds or accept that the agent will produce code that compiles, passes review, and silently breaks.

3. Steering the agent through the work without micromanaging the code

The third practice is the hardest to teach because it looks, from the outside, like doing nothing.

An engineer steering an agent well spends most of their time reading. Reading the agent’s plan before it executes. Reading its commit messages. Reading the diff. Catching the moment the agent went off the road two steps ago, before it builds the next ten steps on a wrong foundation. The steering happens in interruptions. Stop, you’re solving the wrong problem. Or: stop, the idea is right, but use the existing service instead of writing a new one.

This is the skill that separates engineers who get production-grade output from agents and engineers who don’t. It’s a taste-level skill, not a syntax-level one. The engineer doesn’t need to remember the API. The agent has the API. The engineer needs to recognize, in two lines of code, whether the agent has understood the problem or is improvising plausibly around it.

There’s a corollary worth pulling out, because it changes how teams should hire: the engineers best at this are not the ones who can type the fastest. They’re the ones who’ve spent ten years reading other people’s code and developing an instinct for when something is subtly wrong. Code review used to be a tax. It’s now the job.

4. Owning everything that ships, including what the agent got subtly wrong

The last practice is the one most teams haven’t internalized, and it’s the one that turns agentic engineering into a discipline rather than a workflow.

If an agent writes the code, who’s responsible when it breaks?

The engineer is. Always. Every time. There is no version of agentic engineering where the answer is “the model did it.” The engineer set the spec. The engineer accepted the diff. The engineer’s name is on the commit. When the billing system charges customers twice on the first of the month, no court and no customer cares whether the bug was in the engineer’s spec, the agent’s interpretation, or the model’s training data.

This is not a complaint about the technology. It’s a structural property of how accountability works. The model is not a legal person. It cannot be sued, fired, or asked to explain itself under oath. Responsibility flows to the human who decided what to ship. It always has and it always will.

The implication is that agentic engineering, done well, is a more demanding discipline than what came before, not a less demanding one. The engineer is now responsible for a much larger volume of code produced at a much faster rate, with the same standard of correctness applied at the end. The model speeds up the production. It does not change the quality bar. If anything, it raises it, because the team next door is shipping at the same speed.

The engineer’s job is no longer “wrote the code.” It’s “owns the system.” The latter is harder.

What it isn’t

A definition gets sharper when you say what it excludes.

Agentic engineering is not AI-pair programming. Pair programming assumes a peer relationship; the agent isn’t a peer, it’s a tool with high variance. Treating it like a peer (”let me hear your opinion on the design”) misallocates the relationship. The agent doesn’t have opinions. It has distributions over completions. The engineer’s job is to know which distribution to draw from and when to override it.

It is not vibe coding. Vibe coding is describing what you want and shipping what comes back without reading it. That’s fine for a weekend toy. It’s malpractice for a system that handles money or health data or anything else where being wrong has consequences. The discipline of agentic engineering is exactly the discipline of reading what comes back, and the people who skip that step aren’t doing agentic engineering. They’re gambling.

It is not prompt engineering. Prompt engineering is a tactic inside the practice. Calling agentic engineering “prompt engineering” is like calling software engineering “typing.”

And it is not, despite a lot of recent press to the contrary, something only large research teams or model labs can do. The agents are commodities now. The discipline of using them well is open to anyone willing to learn it. That openness is the most interesting thing about this moment.

What used to matter, and what matters now

For most of software’s history, the engineer’s edge came from being able to produce code other people couldn’t. Knowing the language deeply. Knowing the library. Knowing the trick. The engineer’s career was built on a stockpile of implementation knowledge that other people didn’t have.

That stockpile is worth less now. The model has the library in its head. It has the trick. It can produce in three seconds a working implementation of something it would have taken a senior engineer three hours to write a year ago.

What’s worth more is the part the engineer carries that the model can’t fake.

Knowing what to build. The model can write the code for a feature; it can’t tell you the feature is the wrong feature for the product to ship this quarter. Product judgment was always part of engineering. It’s now the larger part.

Knowing what good looks like in this codebase. The model has seen ten million codebases. It hasn’t seen yours. It doesn’t know which patterns this team uses, which it’s tried and abandoned, which conventions are load-bearing because of an outage six months ago. The engineer who carries the institutional memory of a system steers an agent in that system better than any engineer who doesn’t.

Knowing when to stop. The model will keep building. It will write tests, refactor structures, add features, until the budget runs out. The engineer is the one who says: this is enough; ship it; the next thing is more important. Saying “enough” was always part of engineering. It’s now decisive.

The shorthand: we used to optimize the code. We now optimize the intent, and let the code follow.

Why this needs to be a discipline, not a workflow

I’ll close on the part of the argument I most want to fix in place because it determines what we build next.

A workflow is something you adopt. A discipline is something you train for. A workflow has tips and tricks. A discipline has a body of knowledge, a set of failure modes the field has learned to anticipate, and standards that distinguish a practitioner from someone who’s winging it.

Presently, agentic engineering looks like a workflow. Every team is figuring it out independently. The patterns that work are being rediscovered in different shapes inside every company. Failure modes recur (agents fabricate API calls; agents delete files they shouldn’t have touched) and the lessons get written up in private Slacks and then forgotten because nobody owns the body of knowledge.

That doesn’t last. It can’t. The economic gravity is too large. Every team in production software in 2026 is doing some version of this, and the gap between teams that do it well and teams that don’t is going to widen quickly. When the gap is wide enough, the discipline coalesces. People will start calling themselves agentic engineers the way they started calling themselves machine learning engineers in the 2010s, or site reliability engineers a decade before that. There will be conferences and benchmarks, and a canon of mistakes practitioners are expected to have read about so they don’t repeat them in production.

We can let that happen passively over the next five years, or we can name the discipline now and start writing down what we’ve learned. That’s the bet I’m taking with The Intent Layer and with the Center for Agentic Engineering. The bet is that the field is ready for the vocabulary, and the people writing the vocabulary will shape what the field becomes.

So here’s the definition again, and it’s the definition I’d like to see cited:

Agentic engineering is the practice of producing reliable software by directing AI agents through specification, implementation, review, testing, deployment, and maintenance, while retaining human ownership of intent, architecture, and correctness.

The four practices: specify intent the agent can act on; architect systems the agent can verify itself against; steer the agent through the work without micromanaging the code; own everything that ships.

If you’re already doing this, you have a name for it now. If you’re not, you have a target to train for.

The next decade of software gets built by the people who take it seriously.