Burning Through 80 Billion Tokens: Why Vibe Coding Is Doomed to Fail

Introduction: A 40-Day, 80-Billion-Token AI Programming Experiment

A Bilibili content creator used an extreme method to test a hotly debated question in the industry: Can Vibe Coding (programming by intuition) actually support real software engineering?

According to his own account, he consumed roughly 4 billion tokens in a single day, and over 40 days conservatively burned through an estimated total of 80 billion tokens, all dedicated to testing various AI orchestration mechanisms. The conclusion he reached was rather sharp: The faster you Vibe Code, the sooner you die.

Background: Tokens and Context Windows

A token is the fundamental unit that large language models use to process text. One token roughly corresponds to 4 characters or 3/4 of a word in English, while in Chinese a single character typically takes up 1-2 tokens. The model bills and processes text by token every time it generates or understands text—which is why burning 80 billion tokens over 40 days is so staggering in terms of cost. At mainstream commercial API pricing, this could mean hundreds of thousands of dollars. Closely related to tokens is the "context window," the maximum total number of tokens a model can "remember" and process in a single pass. Early GPT-3.5 had only a 4K context, while today Claude, Gemini, and others have expanded to the million-token level. But no matter how large the window, the model's attention to the middle portion of long contexts still degrades (the "lost in the middle" phenomenon), which is precisely the technical root of the "single-model context limitation" the article repeatedly emphasizes.

This view sounds counterintuitive—after all, the core marketing pitch of AI programming tools over the past year has been "generate an app with a single sentence." But when we peel back the demo veneer, we find the root of the problem lies in two unavoidable engineering fundamentals: complexity and context limitations.

The Honeymoon Phase of Vibe Coding: Why Early Results Were So Impressive

The original form of Vibe Coding was "generate a demo with a single sentence": a small HTML game, a rocket launch animation, a simple management system. At the time, there were no intermediate outputs, no sub-agents, and none of these mechanisms.

Frontend demo effect

Why did these demos look so impressive? The creator offered an explanation worth pondering:

"Essentially, because your requirements were vague, the AI automatically matched them to its training dataset. The higher the quality of the training dataset and the lower the degree of compression in the model's learning, the better the result."

In other words, those "one-click rocket launch mini-game" demos are perfect because vague requirements happened to hit high-quality samples in the training set. Content like frontend effects and classic mini-games has a massive amount of high-quality code on the internet, so the AI only needs to perform low-compression "retrieval-style generation."

Extension: Training Data Distribution and Retrieval-Style Generation

This touches on the essence of how large models work. The neural network training process can be understood as lossy compression of massive amounts of data—the model compresses internet-scale text into billions to hundreds of billions of parameters. For content that appears frequently and follows clear patterns in the training set (like classic frontend effects and common mini-games), the model is doing near-lossless "memory retrieval"; but for rare, customized business logic, the model must perform high-compression generalized reasoning, and the probability of error rises dramatically. This explains the huge gap between demo results and real projects—demos happen to fall within the "sweet spot" of the data distribution.

This also explains why insiders become wary when they see "one-click generation"—it demonstrates dataset coverage, not genuine engineering capability.

The Three Hidden Prerequisites That Make Vibe Coding Work

The creator emphasized that Vibe Coding does indeed work at the demo stage, but this depends on three easily overlooked prerequisites.

1. Low Complexity, No Ongoing Maintenance Needs

Typical demo scenarios (such as a small inventory management system built with SQLite) share common features: small code volume, mainstream requirements, and no need for long-term iteration.

Can be checked with the naked eye

2. Results Can Be Verified by Eye

Because the code volume is small, developers can directly verify whether the results are correct with their own eyes, without needing rigorous validation, constraints, or plans. The AI can often determine the best implementation path on its own.

3. Manageable Code Volume

The creator provided a set of empirical data: early web application demos had a code volume of around 20,000 lines, whereas real projects now have ballooned to 80,000 to 120,000 lines. He noted that complexity grows "almost linearly" (though not strictly 100% linearly).

When the code volume is small, even if engineering bad smells appear—such as "domain intrusion" (writing module A's logic into module B), tight coupling, and weakly typed code—it "doesn't matter, as long as the AI can maintain it and it runs." The problem is, once the system grows large, all this debt erupts at once.

Background: Software Engineering Debt and Architectural Governance

The above—"domain intrusion," "tight coupling," "weak typing"—all fall into the classic category of technical debt. The core methodologies accumulated over decades of software engineering—such as Domain-Driven Design (DDD), the SOLID principles, and layered architecture—are essentially all meant to combat the entropy increase caused by growing complexity. Studies show that software maintenance costs often account for more than 60% of total costs, and chaotic architecture causes maintenance costs to rise exponentially. This is precisely why bad smells that were previously ignored erupt all at once when code volume balloons from 20,000 to 120,000 lines.

The Turning Point: When a Demo Must Become a Production System

This is the core argument of the entire analysis. When a Vibe Coding demo needs to actually go into production, it must confront an entire suite of software engineering requirements:

RBAC permission systems
Caching, databases, task queues
Formal technology selection
Observability, maintainability, high performance
Controllable architecture

Design not comprehensive enough

Extension: The Hidden Bar for Production-Grade Systems

RBAC (Role-Based Access Control) is the de facto standard for permission management in enterprise systems, achieving flexible authorization through the indirect "user-role-permission" mapping. Observability typically includes three pillars—Logging, Metrics, and Tracing—used to quickly locate problems when distributed systems fail. Task queues (such as RabbitMQ, Kafka) are used to decouple system components and smooth out load spikes. These capabilities can be completely omitted in a demo, but are indispensable in production—they are the very markers of software engineering maturity, and also the parts most easily overlooked by AI during the rapid generation phase.

Loss of Architectural Control Leads to Code Rot

The creator pointed out that if you don't manually control the architecture and let the AI iterate on its own, two failure modes emerge:

Incomplete investigation—the AI, due to context limitations, cannot fully understand the system and makes wrong designs;
Over-engineering—introducing large amounts of unnecessary abstraction, dependencies, and "reinventing the wheel."

He gave a vivid example: all that was needed was a local in-process queue ("a single upper-layer interface would do it"), but the AI cooked up a complex implementation requiring idempotency, requiring reliability, and pulling in a whole pile of dependencies—things that "someone else's library already did long ago."

The Plan Mechanism Introduces New Problems

To cope with complexity, people began having the AI first make a plan and then execute. But the plan itself has pitfalls:

Fake implementation: it looks well-planned, but is actually a placeholder ("fake toothpicks");
The plan itself is flawed: requiring hours of repeated iteration;
Single-model context limitation: a single model's context window is limited, unable to investigate comprehensively, so the conclusions it reaches are inherently flawed.

Ultimately, developers "realize they need to return to software engineering"—maintaining engineering documentation, development standards, and constraints. AI didn't make software engineering disappear; it just deferred it to the moment when the system becomes complex.

Agent Teams and Model Benchmarks: Two Overrated Solutions

The Information Loss Problem of Agent Teams

Regarding multi-agent collaboration (Agent Teams), the creator's critique focuses on the lossy compression of information transfer:

"The information density per unit of text has a limit. The AI can't judge what content is important and what isn't, and changing the phrasing may cause boundaries to be lost, and then it gets it wrong."

Information density has a limit

Background: The Information Bottleneck in Multi-Agent Collaboration

Agent Teams (multi-agent systems) are a hot paradigm in current AI engineering, typified by frameworks like AutoGPT and MetaGPT, which have multiple AI roles (such as "product manager," "architect," "programmer") divide labor and collaborate to complete complex tasks. The theoretical advantage lies in division of labor reducing the cognitive load on any single agent, but in practice there is a fundamental bottleneck: agents can only pass information to each other through natural language (text), and natural language is a lossy compression medium. When one agent "translates" complex technical constraints into text and passes them to a downstream agent, implicit boundary conditions, exception handling, and other details are easily lost in the retelling—exactly like the principle of information distorting layer by layer in a game of "telephone," and also the deep reason why Agent Teams struggle to handle long-chain complex tasks.

Using a certain AI programming tool as an example: because context compression caused constraint loss, it ultimately couldn't judge whether the command itself was problematic, resulting in an incident—which is also why the industry later introduced sandboxes and review mechanisms.

The Credibility Problem of Model Benchmarks

Regarding model benchmarks, the creator took a cautious stance, listing several avenues for cheating:

You don't know how many times they actually ran it;
Whether they secretly used test data to train the model;
The frameworks and orchestration mechanisms used are opaque;
Whether they used an internal beta model.

Extension: Benchmarks and Data Contamination

Common benchmarks for AI programming ability include HumanEval and SWE-bench. So-called "secretly using test data to train" is known in the industry as "data contamination"—since benchmark questions are often publicly available on the internet, if they get included in the model's training data, the model has effectively "seen the exam questions in advance," so the score is inflated without any actual improvement in capability. This is also why SWE-bench and others have released continuously updated private test set versions. In addition, prompt engineering during evaluation, sampling counts (the k value in pass@k), and scaffolding frameworks all significantly affect scores, making benchmarks from different sources nearly impossible to compare side by side.

The judgment criterion he offered is very practical:

"A model with poor benchmarks is definitely bad to use; but a model with high benchmarks might be faking it. Either way, just don't use the ones with poor benchmarks."

In other words, benchmarks only have elimination value and cannot serve as a positive basis for selection.

Conclusion: Cognitive Bandwidth Is the Fundamental Bottleneck

The most profound insight of the entire analysis lies in attributing the problem to human cognitive capacity:

"When a person's brain capacity is limited, the number of things they can pay attention to is limited. Facing a complex architecture and an enormous system, they simply cannot solve the corresponding problems."

Based on this, the creator gave an extreme judgment on currently popular solutions like "AI enterprise collaboration," "complex orchestration," "Cloud Workflow," and "Agent Teams": they are doomed to fail.

This conclusion may be too absolute, but the logic behind it is worth every AI programming practitioner's consideration:

The success of Vibe Coding is built on a triple prerequisite of "low complexity + high-quality training data + verifiable by eye";
Once a system enters a real production environment, context limitations and information compression loss become unavoidable hard constraints;
Software engineering never disappeared; AI just made you mistakenly believe, at the wrong moment, that you could skip it.

The truly sustainable approach may not be to replace software engineering with AI, but to let AI work within an architectural framework under human control—write a little slower, so you can live a little longer.