Vibes Come Due

A screenshot made the rounds recently. An engineer at a prominent AI research lab shared their monthly usage dashboard: $1.3 million in OpenAI tokens over the past 30 days. Six hundred and three billion tokens consumed. The reactions were predictable. Half the internet called it irresponsible. The other half, mostly the AI influencer crowd, declared it the new baseline. If you are not burning billions of tokens a month, their argument goes, you are simply not going to make it.

There is an old decision framework in software engineering: buy versus build. Do you license an existing tool, or do you write it yourself? The trade-off involves time, money, control, and ongoing maintenance burden. Experienced engineers weigh these factors constantly. Now a third option has emerged. You can vibe it. Throw AI agents at the problem and let the model figure it out. Three doors. Three very different price tags. Most teams racing to the vibe door have not stopped to read the other two invoices.

Vibing feels fast. It feels like forward progress. But it costs both time and money in ways that do not show up on the token dashboard. The visible bill is one thing. The invisible part is the debugging time when the agent generates something that is almost correct but not quite. It is the review cycles, the prompt tweaks, the edge cases the model misses. It is the architectural decisions deferred because it was easier to ask the agent than to think through the trade-off yourself. Vibing is not free. It is just billing on a different invoice.

I have seen this dynamic before. From roughly 2016 to 2020, the industry played out the same script with a different technology. Startups running more Kubernetes clusters than they had paying customers. A friend of mine once confessed he was running 10 microservices inside a single Kubernetes cluster. He had 3 customers. He was not exaggerating. The thinking was simple: if large hyperscalers ran thousands of microservices, every startup needed the same architecture. It did not matter that the problems were orders of magnitude apart. The big players do it, so you must too.

That era did not end well. Many teams spent years unwinding architectures that should have been a single deployable. David Heinemeier Hansson pushed back in 2016 with his essay "The Majestic Monolith," arguing that small teams should embrace a single well-structured codebase instead of chasing microservices. Kelsey Hightower, one of the original creators of Kubernetes, has spent years telling conference audiences the same thing: you probably do not need Kubernetes. The microservices hangover was real, and it was expensive.

The same script is running again, just with a different cast. Instead of Kubernetes adoption as a badge of engineering maturity, it is now token burn rate. Instead of resume-driven architecture, it is vibe-driven development. The AI influencers who migrated over from the crypto hype cycle tell you to run 500 agents in the cloud at all times. Buy their course. They will teach you how. The logic is seductive because it is simple, but it is also wrong.

The $1.3 million screenshot is also misleading in a way few people discuss. The engineer who posted it was not paying for those tokens. The spend was part of a research partnership. The tokens were effectively free. If you try to replicate that burn rate with your own credit card or your company's cloud account, you will pay full retail price. The math does not transfer. Copying the behavior without copying the economics is how you go broke.

There is a deeper corporate irony here. Walk into any large company 18 months ago and ask for a RAM upgrade. You needed a vice president to sign off on four hundred dollars. Ask for a decent office chair. Used, maybe, if you were lucky. Now those same companies are telling engineers to use all the AI they want. Spend as many tokens as you can. Some employees are reportedly being evaluated on how much AI they adopt, with vague consequences for those who do not use it enough.

This will not last. Companies have a rhythm, and the rhythm always swings back. At some point, a finance team will run the numbers and realize $1.3 million a month in tokens is roughly the cost of 30 full-time engineers. The question will shift from "how much AI are you using" to "what did those tokens actually produce." The pendulum will move from token maxing to token efficiency. The people who assumed unlimited spend was the new normal will get caught off guard.

I expect a new consultant class to emerge around this shift. Token efficiency coaches. Prompt trainers. The spiritual successors to the agile coaches who showed up a decade ago to teach teams how to fill in story point spreadsheets. They will probably be just as grating. But the underlying question they will ask is a fair one: what is the cheapest way to get the outcome? Buy it, build it, or vibe it? And if you choose to vibe it, how do you measure whether the tokens were worth it?

The engineers who thrive in this next phase will not be the ones who vibed the hardest. They will be the ones who made intelligent trade-offs. They will know when to buy, when to build, and when to let an agent handle the boilerplate so they can focus on the hard parts. They will treat AI as a tool in the toolkit, not an identity. The real question is not whether to use AI. The question is whether this particular problem is best solved by reaching for a license, writing it yourself, or vibing it. Most teams skip the first two questions. That is the mistake.