Sphere Partners
The Prompt Isn't the Product

The Prompt Isn't the Product.

AI amplified how fast I could produce a plausible answer. It did nothing to amplify how fast I could tell a plausible one from a correct one — and a type that compiled, passed review and was backwards is the smallest proof of that I have.

6 min read
In this article

Weekly requests to Uber's internal coding agents grew 9.4 times over between February and August this year, while weekly active users across the company — engineers and non-engineers both — grew seven times over. Cost per session is down 52% from its June peak. More than 70% of pull requests are now agent-authored. Those are Uber's own numbers, from its own engineering blog, and they are exactly the kind of numbers that get forwarded around a leadership team with “we should be doing this” attached.

Uber's own published figures, each on its own scale

Usage grew nearly tenfold and cost per session did not follow it up — that gap is engineering, not a bigger model.

Weekly agent requests, Feb → Aug (scale 0–10×)×9.4
Cost per session, share of June peak (scale 0–100%)48% (−52%)

The number is real. What it measures is not “AI replaced engineering.” It's request volume flowing through a system that engineers built, evaluate continuously, and pay for by the request — 3,600 internal agent skills, run 30,000 times a day, against routing and cost accounting someone had to design first. I watched the same gap open up at much smaller scale, on a permission check, this year.

A prompt is not a delivery process

We had two hand-rolled types answering the same question two different ways: had a permission dialog already fired. Collapsing them into one type was the kind of change a prompt handles well — mechanical, well-specified, easy to verify by reading. It compiled on the first try. Every call site type-checked.

It was also backwards. The old types answered “did it already fire?” — so call sites read guard !oldLatch() else { return }. The replacement, a type called Once, answers the opposite question — “did I get it?” — so the same idiom silently inverts: the first caller returns early, the permission dialog never appears, and the tool fails with a message about System Settings that nobody can act on. The compiler cannot catch this. Both spellings are valid Bool. Nothing about the type system, the tests we already had, or the fact that it built cleanly said anything was wrong.

What the prompt did not do

The prompt did not know that the two functions it was replacing meant opposite things by the word “yes.” That's not a knowledge gap a bigger model closes — it's a fact about this codebase, invisible from the diff, that only someone who remembered writing the original two latches would think to check. Finding it meant reading both call sites by hand, asking what “true” was supposed to mean at each one, and writing a test that claims the permission 500 times concurrently and checks that exactly one caller wins. The prompt produced correct-looking code. The engineering was noticing that “correct-looking” and “correct” were not the same claim, and building the one test that could tell them apart.

Amplifies is not the same as replaces

None of this makes the tool less useful — the collapse from two latches to one was the right call, and a prompt got me there faster than I'd have got there typing it by hand. The claim I'd push back on is the one that treats speed as the whole story. AI amplified how fast I could produce a plausible answer. It did nothing to amplify how fast I could tell a plausible answer from a correct one — that part was still mine, and it was still the part that mattered, because the failure mode here isn't a crash. It's a feature that silently stops working and reports a message that sends the next person looking in System Settings instead of at the code.

What actually matters

The prompt produces the artefact. Verifying it is still engineering, and it doesn't get faster just because the artefact arrived faster.

I've made a version of this argument twice already this year — first in Compiled Is Not Done, then a month later in Compiled Is Not Done: Why “It Ran” Is Not “It Works” for AI, because a compiler and a test suite both agreeing with a change is not the same claim as the change being right. The Once bug is the smallest, most literal version of that I've hit: a type that compiles, passes review, and is backwards.

The one question

Before you count a piece of AI-assisted work as done, ask who checked it and how — not whether it compiled, ran once, or looked right on the first read. If the honest answer is “it looked right,” you have a prompt, not a product yet.

Frequently asked questions

No. Compiling proves the change is well-formed, not that it means what you intended. The example in this article inverted a boolean whose two spellings were both valid, so the type system, the existing tests and a clean build all agreed with a change that silently disabled a permission prompt. “It compiled” is evidence about syntax and types, never about intent.

Request volume through an internal platform, not engineering headcount replaced. The figure sits on top of roughly 3,600 internal agent skills run about 30,000 times a day, with routing, continuous evaluation and per-request cost accounting that engineers designed and maintain. The interesting part is that cost per session fell 52% from its June peak while usage grew — that gap is engineering work, not a bigger model.

Ask what each boolean, return value or branch is supposed to mean at every call site, then write the one test that can distinguish a plausible answer from a correct one. In the case described here that was a concurrency test claiming the permission 500 times and asserting exactly one caller wins. Reading the diff would never have surfaced it, because the diff looked right.

It makes producing a plausible artefact faster. It does not make telling a plausible artefact from a correct one faster, and that second step is unchanged work that still belongs to a person. Teams that count only the first half report large speed-ups and then absorb the difference later as silent failures in production.

Speed is the easy half. If your team is shipping AI-assisted work faster than it can verify it, the gap is a delivery process, not a model. Let’s look at where yours actually closes. Book a walkthrough.

We'd love to hear from you!

Please provide your contact details, and our team will get back to you promptly.