The limits of building agents only from vibe-code tools — and what it costs you at scale

Nothing here is an argument against vibe coding. We use agentic coding tools daily and they are the fastest way to find out whether an idea is worth building. The problem is a specific one: an agent that was only ever vibe-coded is a demo of a product, not the product, and the gap between those two shows up all at once.

The wall is not code quality

The usual criticism — messy code, no tests — misses the real failure. Vibe-coded agents fail in production because of four things that never come up while you are prototyping.

First, permissions. In a prototype the agent runs with your credentials and can do anything you can. In production it needs a scoped identity, per-tool authorisation, and a record of which action it took on whose behalf.

Second, evaluation. A prototype is judged by whether the last run looked good. A production agent needs a regression suite over real historical cases, because a prompt or model change that improves one path routinely breaks three others silently.

Third, cost. A prototype's cost is invisible because you ran it eleven times. At a thousand runs a day, an agent that retries loops or pulls oversized context turns into an unpredictable monthly bill with no ceiling.

Fourth, failure behaviour. Prototypes have no defined behaviour for "the tool is down", "the model returned nonsense", or "confidence is low". Production needs each of those to have an explicit answer, usually a human.

How it affects scale specifically

Scale exposes these in a predictable order. At low volume you feel it as flakiness someone manually fixes. At moderate volume you feel it as cost you cannot forecast and a support load nobody budgeted for. At real volume you feel it as trust collapse: one visible wrong action, and the team stops routing work to the agent — after which it is expensive shelfware.

The compounding cost is architectural. Prototypes tend to encode business rules inside prompts, hardcode a single happy path, and treat the model as the system of record. Every one of those has to be undone before you can add a second workflow, so the cheap start becomes the reason the second agent takes longer than the first.

What has to be rebuilt, honestly

In our experience the salvage rate is high but uneven. The parts that survive are the product thinking, the prompts as a starting point, and the discovered edge cases — genuinely valuable, and much faster to have discovered this way than by writing a spec.

The parts that get replaced are the integration layer, the state and permission model, the retry and fallback logic, and anything that assumed the model would always behave. Plan for the rebuild rather than being surprised by it; that framing keeps the prototype an asset instead of a sunk cost.

Keeping the speed without paying twice

Prototype deliberately. Decide up front that the vibe-coded version exists to answer questions — is the workflow bounded, do the tools expose what we need, where does it go wrong — and not to become the production system.

Then harden in one pass: scoped credentials, approval gates on anything that writes or spends, a regression suite built from real historical cases, per-task cost ceilings, and logs you can audit. That is the shape of the production agent build, and it is the same work whether we do it or your team does.

If you already have a prototype that cannot be trusted in production, that is a normal starting point and a faster one than a blank page. Bring it to a scoping call or start the intake and we will tell you what survives before quoting the rest.

For the wider picture on why this matters commercially rather than technically, see AI agent impact on the market and our lives and securing agents — most of the security failures we see are prototype assumptions that reached production.