I asked for a preview that refreshes when a file changes. I got a file watcher, a livereload server, a platform stub, and a launcher script.
Four systems. The request wanted one. And here's the trap: every individual piece was competently built. If you reviewed them in isolation you'd say good work. The failure only exists at the level of what I actually asked for, which is exactly the level nobody reviews.
Over-building is the most under-discussed AI failure mode, because it doesn't look like a failure. It looks like enthusiasm.
Why it happens
Three forces, all pointing the same way.
Training rewards thoroughness. A response that anticipates needs and covers edge cases reads as higher quality to a human rater than a minimal one. Optimise against that and you get a model whose instinct is to add.
The goal gets read as a suggestion. The failure mode is treating the user's goal as a starting point rather than a boundary. Once "refresh on change" is interpreted as "improve the dev experience", the watcher and the launcher follow logically. The scope didn't get violated so much as silently redefined.
Adding is safer than asking. Building the extra thing costs the model nothing and might be appreciated. Asking risks looking like it didn't understand. So it builds.
The real cost, which isn't the wasted work
The wasted effort is the cheap part. Three worse costs:
Surface area you didn't ask for and nobody verified. Four systems, one request, and the verification effort stayed constant — which means three of them shipped unchecked. Over-building and under-verifying are the same behaviour: attention spent on volume instead of correctness.
Maintenance you inherited by accident. That launcher script now exists in the repo. Six months from now someone will find it, assume it's load-bearing, and be careful around it. Unrequested code isn't neutral — it's a permanent tax.
The direction problem gets hidden. This is the expensive one. The extra work made it harder to notice that the whole thing was aimed at the wrong page. Effort real, direction wrong — and volume disguises a wrong direction beautifully.
The money pattern: state the interpretation before you build
One line, before any file gets written:
Building: a watch mode that rebuilds the responsive-grid page
on save. Nothing else. Confirm?That costs a few seconds and it's the highest-ROI sentence in agentic development. It's cheap to correct in three words and expensive to correct in an hour. Note what makes it work: "nothing else" is doing as much as the description.
The related habit is the disambiguating question. When two readings of a request lead to materially different work, ask — once, up front, before writing anything. Asking is not a delay, it's the cheapest step in the job. My previewer detour needed exactly one question: "the grid page, or the full-screen one?"
Then, in your standing rules, price out the behaviour explicitly:
Deliver the simple thing asked. If the literal ask is X, deliver X.
Do not substitute a technically-equivalent alternative.
No silent scope changes. No clever alternatives I didn't ask for.
Ship the minimum that satisfies the request, then stop.Blunt, and it needs to be. "Don't over-engineer" is too abstract to move a probability distribution. "Ship the minimum, then stop" is an instruction.
The one-artifact rule
A specific version of this that bit me hard enough to become its own rule.
I asked for a set of video sequences. I got a directory of separate files, one per sequence, each needing individual import. Technically it satisfied the request. Practically it was unusable — and the suggestion that I "just multi-select on import" missed the entire point.
The rule now: one importable artifact per project, never N files. If a format supports multiple items in one file, use it.
The general principle underneath: if you don't know how the output gets consumed, ask before generating variants. An agent optimising for "I produced all the things" will happily hand you a pile that satisfies the letter of the request and none of the purpose. Whether something is a deliverable is decided at the point of consumption, not the point of generation.
Where the reverse failure lives
Being fair about this, because the mirror image is also real and also costs money.
Under-delivery is when an agent quietly narrows the ask — does three of five queued items, tackles the easy parts, or scales the work down because it judged the rest unnecessary. That's the same disease: substituting its judgement for the stated scope. Deciding to do less is as much a silent scope change as deciding to do more.
The through-line is that the requested scope is the deliverable. Not a floor to build on, not a ceiling to negotiate down. If you think the scope is wrong, say so in a sentence and then build what was asked anyway — under stated assumptions if you must. Changing the scope is the requester's call.
The catch: minimal isn't sloppy
"Ship the minimum" gets misread as "ship it half-done", so let me be precise.
The minimum that satisfies the request includes it actually working, being verified, matching the surrounding code's conventions, and not leaving orphaned imports or dead files behind. YAGNI is about not building speculative features — it is not permission to skip the parts that make the requested thing real.
Minimal scope, production quality. Those aren't in tension; conflating them is how "keep it simple" becomes an excuse.
The verdict
Over-building is a failure that wears the costume of effort, which is why it survives review. It burns time, ships unverified surface area, creates accidental maintenance, and — worst — hides the possibility that the whole direction was wrong.
State the interpretation in one line before building. Ask the disambiguating question up front. Ship the minimum that satisfies the request, at full quality, then stop. One artifact, not N files. And treat the stated scope as the deliverable in both directions.
Four systems, one request. Do not @ me.
Want an AI workflow that delivers the brief instead of reinterpreting it? Get in touch, or browse the work first.