Why AI coding agents over-build your app — and how to stop it

You open Claude Code, Cursor, or Codex, describe the app you want, and watch it write hundreds of lines in seconds. It feels like magic right up until the first real review — when you realize the agent didn't build your app. It built the average app it has seen.

That average is where projects go to die.

The over-build

Ask an agent for "an online store" and it will confidently build a reviews and ratings system before you have sold anything — when reviews appear in only 35 of 90 real online stores, the least common capability in everything we counted. It will wire a live payment gateway with webhook handling on day one, when 42 of 90 stores integrate one at all and the rest take payment by handoff. It will add carrier-rate shipping when flat rate would cover your first hundred orders. None of this is what you asked for. All of it is now yours to maintain.

This is the over-build: the agent pattern-matches against everything it has ever seen and reaches for the union of all features, not the few that matter for your launch. The result looks impressive in a demo and collapses under its own weight in week two — half-built compliance pages, a billing webhook that breaks on plan downgrades, two weeks of architecture debates you didn't need to have.

The toy

The opposite failure is just as common, and worse, because it hides. Ask for an ecommerce store and the agent gives you a cart that never rechecks stock at purchase, a checkout that happily accepts an empty cart, and an admin with no order queue. It calls three hardcoded numbers a "P&L report." It treats inventory as a decorative integer that no order ever decrements.

These aren't polish issues — they're the reason the first delivery fails QA. Checkout and durable order creation show up in 44 of 90 real online stores; order management in 47; product variants with real SKU and per-variant stock in 49. The agent skipped the load-bearing walls and spent its effort on wallpaper.

Why it happens

It's not a prompting problem. It's a grounding problem.

A coding agent is extraordinary at writing code and genuinely poor at deciding what to build. It has no model of what a real product in your vertical actually ships — only a blurry average of tutorials, starters, and marketing pages. So when you describe your app "from memory," and memory is vague, the agent fills the gaps with confident guesses. Some guesses over-reach. Some under-deliver. You can't tell which until you're deep in the wreckage.

Better prompts don't fix this. You can't prompt your way to knowledge the model doesn't have.

The fix: build what real apps ship, defer what they defer

The cure is to replace guesses with counts. Before the agent writes a line, hand it a frequency-ranked inventory of what real products in your exact vertical actually ship — and let those counts become hard defaults, not suggestions.

That changes every decision from an argument into a lookup:

• Product variants with per-variant SKU, price and stock? Yes — 49 of 90 stores ship them, the most common capability in the set. Build it before anything decorative.
• A live payment gateway? Defer if a handoff will do for launch. Only 42 of 90 stores integrate one, and when you do select it, it brings server-side sessions, webhooks and idempotency with it — a week you may not have yet.
• Stock recheck at checkout? Non-negotiable — it's the difference between an order system and a toy, even though it never shows up in a demo.
• Reviews and ratings? Defer — they appear in only 35 of 90 stores and almost never matter for a first delivery.

Right-sized scope falls out of the data. The features 90% of real apps ship get built first. The long tail gets parked in a roadmap instead of half-built into your MVP. The agent stops debating and starts shipping the right thing.

Your agent has never shipped this. We have.

That's the whole idea behind a PlanSmith planner: a CLAUDE.md built from 30–50+ real, in-market products per vertical, with every recommendation carrying its count — found in N of M reviewed products — so your agent inherits the market's collective decision instead of inventing its own.

Your own agent can't fabricate "found in 49 of 90 reviewed ecommerce sources" without redoing the scrape. That's the point. The moat isn't the format of the file — it's the evidence inside it.

If you want to see what that evidence looks like, the Online Store planner is the one behind the counts on this page — 90 stores, tabulated by hand, with the scope boundaries written so an agent builds the load-bearing walls before the wallpaper. The field notes break down the other verticals the same way.