The hidden cost of vibe coding 💸

TL;DR: Vibe coding looks free, but it’s not: tokens, output, sessions and rework carry a real cost that never shows up on the receipt. Learning to measure it means knowing when to delegate and when to keep the reins.

The bill that never arrives 🧾

You know that feeling of hyper-productivity when the agent writes code while you sip your coffee? The terminal scrolls, lines pile up, and you think: “Wow, I’m doing it all.” Then the bill arrives. Not the electricity one — the token one.

Vibe coding isn’t free. It’s just deferred. Every session, every turn, every line of output the agent generates has a cost that eyes don’t see, but the wallet (or the corporate budget) faithfully records. And the problem isn’t the cost itself — it’s the fact that you’re not measuring it.

The math of the invisible 🔢

Let’s do a quick calculation. An average coding agent generates between 2,000 and 5,000 tokens of output per session. Output cost is typically 3-5x that of input. Which means every time the agent “thinks out loud” about a function, it’s costing you far more than you think.

And then there’s rework. That function that looked perfect but, after three commits, you have to rewrite because it doesn’t handle an edge case. Or that refactor that introduced a silent bug that only the integration test (the one you haven’t written yet) can catch.

Every wasted token isn’t just money: it’s latency, useless context, and a model that has to read stuff it doesn’t need.

As explained in the Costs and tokens guide, output costs more than input — often 3-5x. And rework multiplies the bill by a factor nobody wants to calculate.

Where tokens hide 💣

Tokens are invisible, but they accumulate in predictable places. The window context — everything the agent must read to understand your project — grows with every turn. Every file you add to the context, every commit you include in the history, every instruction you put in the prompt becomes weight the model must process.

Then there are sub-agents. Many modern frameworks delegate to secondary models for specific tasks: research, testing, deployment. Each sub-agent has its own token consumption, often invisible to the main user. It’s like having a team of consultants where you only see the final invoice.

And don’t forget model routing: not every prompt deserves the same model. Using a high-end model for a trivial task is like taking a taxi to cross the street. Knowing when to use the cheap model and when to upgrade is a skill that saves real budget.

Infinite sessions: the hidden habit 🔄

There’s a pattern we all know but few admit: the infinite session. You start with a simple task, the agent produces something, you spot an issue, ask for a fix, another one emerges, and so on for twenty turns. In the end you have a file that works, but you’ve burned through an amount of tokens that could have covered an entire sprint of manual work.

The real cost of vibe coding isn’t the single token — it’s the absence of a plan. When you delegate without knowing exactly what you want, every turn becomes an experiment. And experiments cost.

As I wrote in Vibe coding ≠ innovation, enthusiasm alone doesn’t make the difference. You need method. And method, when it comes to agents, means knowing when to stop asking.

When to delegate and when not to ⚖️

The right question isn’t “should I use the agent yes or no?” — it’s “what do I delegate and when?”

Delegate to the agent things you already know and want to speed up: boilerplate, repetitive tests, format conversions, one-off scripts. These are activities where the risk of rework is low and the speed gain is high.

Don’t delegate things that require architectural context, design choices, or domain understanding. The agent can write code, but it doesn’t understand the why behind a technology choice. And when you try to explain it in three lines of prompt, you get a solution that looks correct but hides trade-offs that only experience can recognize.

The trick is complexity awareness: simple, well-defined tasks get delegated; ambiguous, contextual tasks stay yours.

The real cost: rework 🔁

There’s a cost almost nobody measures: the time lost figuring out what the agent did. When you blindly accept output without review, you’re accumulating silent technical debt. And technical debt, like all debt, eventually has to be repaid — with interest.

Rework isn’t just rewriting code. It’s also:

• Understanding what the agent did (reading time)
• Verifying it hasn’t introduced bugs (testing time)
• Fixing subtle errors (debugging time)
• Documenting what you did (documentation time)

Every hour of rework costs far more than an hour of careful development from the first line.

Code written with method costs less than code written in a hurry — even if the latter seems faster.

How to take back control 🎯

Here’s a pragmatic checklist to avoid being swallowed by the vibe coding vortex:

1. Define the result before delegating: know exactly what you want before opening the session.
2. Token budget: set a mental (or physical) limit per session. If you exceed it, stop and reassess.
3. Review every output: never blindly accept. Read, understand, verify.
4. Measure rework: keep track of how many times you have to fix what the agent produced.
5. Delegate in small increments: ten sessions of a hundred tokens are better than one of a thousand.

It’s not about not using agents — it’s about using them with awareness. The real advantage isn’t speed, it’s the quality of delegation.

The real balance ⚖️

The balance isn’t between human and machine. It’s between blind delegation and conscious delegation. On one side, the tokens you burn without realizing it; on the other, the quality you get when you know exactly what to ask for.

The hidden cost of vibe coding isn’t the extra token — it’s the attention you didn’t dedicate to figuring out whether you were delegating the right way.

And maybe the highest cost is believing that productivity and speed are the same thing. They’re not. They never were.