In April 2026, Uber’s Chief Technology Officer told staff the company had spent its entire annual budget for AI coding tools in four months. The response, reported in June, was a cap: $1,500 per employee per month, per tool, covering agentic coding software such as Claude Code and Cursor.
What makes this more than a procurement story is what preceded it. Leadership had encouraged maximum AI usage and tracked it competitively on internal leaderboards. The budget did not evaporate through neglect; it evaporated through enthusiastic compliance with company policy, because these tools are billed by the token rather than by the seat and nobody had a model for what that would cost.
Then there is the detail worth pausing on. Asked about the relationship between AI usage and the new consumer features it was supposed to produce, Uber’s Chief Operating Officer, Andrew Macdonald, said “it’s very hard to draw a line.” The spending was measured to the dollar. The return was not measured in any comparable way.
That gap — exact costs, illegible returns — is the most interesting thing happening in applied AI right now, and it is a direct consequence of where the engineering has moved.
Three layers, two migrations
The skill that determines whether you get useful output from a language model has relocated twice in about three years.
It began in the prompt: how you phrased the request. It moved to the context: what the model could see when it answered. It is now moving to the loop: how many attempts the system gets, what it checks its work against, and when it stops.
Each move is datable, and each has a literature. What each move did not do is retire the layer beneath it. This is worth stating early, because the popular version of this story is a succession — prompt engineering is dead, long live context engineering — and the succession framing is wrong. Sandeco Macedo, in the first paper to treat loop design as a discipline in its own right, positions it “as a new layer in the progression from prompt to context to harness to loop,” and argues “against the stronger headlines, that it does not retire prompt engineering; loop and prompt are distinct tools with distinct uses.”
What happens instead is commoditisation. Each layer becomes cheaper, more teachable, and less of an advantage, while the scarce work moves one step outward.
One caveat on my own framing: Macedo counts four layers, not three, inserting the harness — the scaffolding an agent runs inside — between context and loop. I fold it into the loop layer below for narrative economy, but his division is the more precise one.
| Layer | What you control | What breaks | Cost driver | Evidence of payoff |
|---|---|---|---|---|
| Prompt | The wording of the request | Ambiguity, poor instructions | Per call | Strong, now commoditised |
| Context | What the model can see | Retrieval quality, window limits | Context size | Moderate |
| Loop | Attempts, verification, stopping | Non-termination, unbounded recovery | Iterations | Weak and contested |
The rest of this piece walks the three layers, then asks the economic question: if the engineering moved outward, did the value move with it?
Prompt engineering, and how you know it has been commoditised
Prompt engineering was the first discipline to form around large language models, and it produced real technique. Jules White and colleagues catalogued reusable prompt patterns in early 2023 — a structured vocabulary for what had been folklore. By 2024, Sander Schulhoff and colleagues could publish a systematic survey of the field, which is what a discipline looks like once it has enough substance to be surveyed.
None of that stopped working. Careful instructions still beat careless ones.
But look at what the prominent work is now for. Daniel Lee and Edward Palmer’s 2025 systematic review exists specifically to inform university curricula. Bertalan Meskó’s heavily-cited tutorial teaches prompting to medical professionals. Both are instructional: they exist to transfer the skill to people who do not have it.
That impression is consistent with a smaller check of my own — in a 40-paper sample of 2023-onward indexed literature, the most-cited items were dominated by teaching and domain-application work rather than new method. I offer that as a sample rather than a survey; it is not a claim about the whole field, and indexed databases lag a frontier that currently lives on preprint servers.
The direction is the economic tell all the same. When a skill becomes the subject of curriculum-design reviews, it has stopped conferring advantage. You do not build a competitive moat out of something with a systematic review advising universities how to teach it to undergraduates.
Commoditisation is not failure. It is what success looks like from the outside: the technique worked well enough to be codified, and codification is what destroys scarcity. Prompt engineering did not die. It graduated into infrastructure.
Context engineering: the window becomes the constraint
The second migration has an unusually precise date. On 19 June 2025, Shopify’s CEO Tobi Lütke proposed “context engineering” as a better name than prompt engineering for what practitioners were actually doing. Six days later Andrej Karpathy amplified it, and the term went mainstream within weeks. Karpathy’s definition, as quoted by LangChain, is “the delicate art and science of filling the context window with just the right information for the next step.”
The shift it names is real. Once you are building anything beyond a chat box, the question stops being how do I phrase this and becomes what should the model be looking at. Several things compete for the same finite window: the system prompt, retrieved documents, conversation history, tool descriptions, the results of previous tool calls, and the user’s actual request. Every token spent on one is a token unavailable to another. Managing that allocation is an engineering problem with real design decisions in it.
The objection: this is just software engineering
The obvious criticism is that this is a rebrand. If context matters, then maintaining context is an engineering problem — and we already have a name for engineering problems. On this view, context engineering is a subset of software engineering, dressed up as a new discipline for the benefit of people selling courses.
The objection has force, and it is worth meeting rather than dodging. The best rebuttal I have seen came from a Hacker News commenter: all squares are rectangles, but not all rectangles are squares. Prompt engineering is a subset of context engineering; context engineering includes optimisations — retrieval strategy, memory design, compaction — that are not prompting in any recognisable sense.
That is a fair answer to the narrow charge of rebranding. It is not an answer to the broader charge that none of this is new to anyone who has built an information retrieval system. The honest position is that context engineering is a useful label for a real cluster of problems, not a new body of knowledge. Labels have value. They just have less value than their proponents claim.
Loop engineering: the newest layer, and the least settled
The third migration is happening now, which makes it harder to write about honestly.
Strip an agent to its essentials and it is a language model in a loop with tools: it takes input, reasons, calls a tool, looks at the result, and goes round again until the task is done or something stops it. Loop engineering is the discipline of making that cycle reliable.
The term is genuinely new. The surrounding academic literature was still defining its basic vocabulary a year ago — the 2025 output is dominated by taxonomy papers, including Sapkota and colleagues’ conceptual taxonomy distinguishing AI agents from agentic AI. A field publishing taxonomies is a field that has not yet agreed what it is studying.
The first serious treatment of loops as an object of design is Macedo’s June 2026 paper, Stop Hand-Holding Your Coding Agent. It proposes the loop specification: a bounded, reusable artifact with five components — a trigger, a goal, a verification step, a stopping rule, and a memory. Analysing fifty real loops, Macedo found 70% verified within what he calls the autonomous zone and 74% explicitly named their terminal states, while automated triggering and durable memory remained underdeveloped.
Two of those five components deserve emphasis, because they are where the failures live.
Stopping rules. An agent whose feedback path is not properly bounded can iterate indefinitely — a failure mode now documented well enough to have acquired a name, the infinite agentic loop. In a per-token billing regime, a non-terminating agent is not merely a bug. It is an open-ended invoice.
Verification. Everything depends on whether the system can tell good output from bad without a human. A separate line of work argues the loop paradigm is structurally weak on exactly these grounds, identifying implicit dependencies between steps, unbounded recovery loops, and mutable execution history that makes debugging hard.
The practitioner’s verdict: most people don’t need this
Michael Rouveure, who runs production agent loops, offers the most useful sceptical framing in an honest assessment of the practice. Loops pay off, he argues, only when four conditions hold simultaneously: the task repeats weekly or more often, machines can automatically reject bad output via tests or linters or builds, the budget can absorb failed iterations, and the agent has real tools — logs, reproduction environments.
Good candidates: CI-failure triage, dependency bumps, lint fixes, flaky test reproduction. Bad candidates: architecture rewrites, authentication and payments code, production deploys.
He also relays the sharper objection, from engineer Gergely Orosz, that most people have neither unlimited token budgets nor a genuine agent-prompting bottleneck. Rouveure’s own conclusion is that “most people don’t need one yet.”
That verdict is worth holding onto. A discipline can be real and still be irrelevant to most of the people being told they need it.
The case against the whole framing
So far this has been a story about attention moving outward. Before drawing economic conclusions from it, the argument has to survive its strongest objection — which is not that the frontier failed to move, but that nobody can demonstrate the payoff at any layer.
The best evidence on this is uncomfortable for everyone. In July 2025, METR published a randomised controlled trial of early-2025 AI tools on experienced open-source developers. Sixteen developers worked 246 real issues drawn from repositories they already maintained, using Cursor Pro with Claude 3.5 and 3.7 Sonnet. The result was widely reported: developers were 19% slower with AI, while believing they had been 20% faster.
That figure has been cited relentlessly by people who want AI productivity claims to be false. It deserves better handling than it usually gets, because METR has substantially walked it back.
In February 2026, METR changed its experiment design after identifying a selection effect running through the study. Between 30% and 50% of developers told the researchers they were choosing not to submit certain tasks at all, because they did not want to attempt them without AI. The tasks most likely to show a benefit were quietly filtered out of the sample before measurement began.
The revised estimates are −18% for a subset of ten developers from the original cohort, with a confidence interval from −38% to +9%, and −4% among forty-seven newly recruited developers, with an interval from −15% to +9%.
Both intervals cross zero. METR’s own assessment is that its data is “only very weak evidence” for the size of any change — and, crucially, that because the selection effect removed the developers most optimistic about AI, “the true speedup could be much higher.”
The correct reading is not “AI makes developers slower.” It is that the most carefully designed study on the question revised its estimates toward zero, described its own evidence as very weak, and ended with intervals that include no effect in either direction. On the central question of whether any of this pays off, we do not have an answer — and the people best equipped to produce one are saying so.
Meanwhile the market has its own view. Gartner predicted in June 2025 that over 40% of agentic AI projects would be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. It also named the practice of “agent washing” — rebranding assistants, robotic process automation, and chatbots as agentic without substantial agentic capability — and estimated that only around 130 of the thousands of self-described agentic AI vendors were the real thing. Anushree Verma, the Gartner analyst behind the forecast, put it bluntly: “Most agentic AI projects right now are early stage experiments or proof of concepts that are mostly driven by hype and are often misapplied.”
If loop engineering is a discipline erected on agentic deployments, and a large fraction of those deployments are cancelled, the discipline may turn out to be an artefact of a hype cycle rather than a durable layer.
What the evidence actually supports
Here is where the argument has to become careful, because two claims are routinely run together and only one of them is supported.
Cost migration is demonstrated. When you are billed per token, the cost of a task becomes a function of how many times the system goes round the loop. This is not a projection; it is arithmetic, and Uber’s experience is what it looks like in practice. Simon Willison worked through what the cap implies: an engineer using two tools at the limit runs roughly $36,000 a year, or about 11% of a median Uber software engineer’s $330,000 compensation. Even as an upper bound, that puts AI tooling in the same conversation as salary — a material line item measured against labour cost, not a rounding error in a software budget.
Anthropic’s own engineering write-up on its multi-agent research system puts numbers to the mechanism: “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens as chats.” The same analysis reports that on one benchmark, “token usage by itself explains 80% of the variance” in performance.
That last finding is the most economically significant sentence I have encountered in this literature, and it comes from a lab with every commercial incentive to report the opposite. If token consumption explains most of the variation in how well an agent performs, then performance is to a substantial degree bought rather than engineered. Anthropic reports that a multi-agent configuration outperformed a single-agent one by 90.2% on an internal evaluation — at roughly fifteen times the tokens.
Value migration is not demonstrated. That better outcomes can be purchased with more tokens tells you nothing about whether the purchase is worth making. That is precisely the question METR could not answer and Uber could not measure.
Keeping these two claims apart is the whole discipline of thinking clearly about this. Cost has moved, legibly and measurably, from headcount and licences to iterations. Whether value moved with it is unresolved.
The scarce asset is a cheap verifier
If the cost of a task scales with iteration count, and the quality of the output depends on whether the system can tell good work from bad, then the binding constraint is neither the model nor the prompt. It is the verifier.
A verifier is anything that rejects bad output without consuming human attention: a test suite, a type checker, a compiler, a linter, a benchmark, a schema. Where a cheap and trustworthy verifier exists, loops are economically sensible — you can afford failed iterations because failure is caught automatically and early. This is exactly why Rouveure’s list of good candidates is what it is. CI-failure triage and lint fixes have excellent verifiers. Architecture decisions and payments code do not.
Notice that this claim survives the METR objection, because it is a claim about cost structure rather than about productivity. It does not require believing that agents make anyone faster. It only requires that iterations cost money and that catching errors by hand costs more.
It also suggests that the most valuable engineering work in this area is not prompt-shaped, context-shaped, or loop-shaped. It is the deeply unglamorous work of building things that can automatically say no.
What follows
For practitioners. The scarce skill is no longer phrasing, and increasingly is not retrieval either. It is designing verification and stopping conditions — deciding what “done” means precisely enough that a machine can check it. If your domain has no cheap verifier, building one is probably higher-leverage than any amount of loop design.
For firms. Per-token billing needs budget instrumentation before rollout, not after the budget is gone. Uber’s failure was not overspending; it was that spending could not be traced to value while it was happening. Any organisation deploying agentic tooling without per-team cost attribution and hard spending caps is running Uber’s experiment again with the result already known.
For labour. Each layer’s commoditisation moved well-paid work outward — from wording, to information architecture, to system design and evaluation. That pattern is visible in what gets published and what gets taught. But the METR results should make everyone cautious about quantifying the effect. We can observe that attention moved. We cannot yet say what it was worth.
Conclusion
The engineering attention has moved outward twice, from prompt to context to loop, and each layer commoditised the one beneath it rather than replacing it. Cost followed that movement deterministically, because per-token billing converts iteration into expenditure. Value did not follow legibly, and the best available study on the question retracted the strength of its own headline finding.
Whether loop engineering proves to be a durable discipline or a transitional workaround for models that cannot yet verify their own work is genuinely open. The evidence does not settle it, and writing that claims otherwise — in either direction — is running ahead of what anyone can currently demonstrate.
What is not open is the accounting. Uber knew its budget was gone in four months to the dollar, while its COO could say only that drawing a line from that spending to shipped features was “very hard.” Until firms can answer the second question with the precision they bring to the first, the most valuable thing to engineer is not the prompt, the context, or the loop. It is the measurement.