The Era of the "Previous Vibe Coder" Begins: The Invisibility of Clean Code and the Technical Debt Bill of AI

The software world has been in a strange state of intoxication for the past year. The voices of those claiming "we cut developer costs by 90% with AI" or "I built a SaaS application from scratch in 10 minutes" are everywhere. In corporate boardrooms, presentations are being made about AI agents that will replace entire engineering teams. Yet behind this excitement lies a reality that no one wants to talk about out loud.

The gap between the speed of churning out code at the keyboard—that transient feeling of pseudo-productivity we call "vibe velocity"—and actually launching a secure, performant, and sustainable product to production (net throughput) is growing wider every day.

And this trajectory is bringing the industry to the brink of a crisis that is all too familiar, but this time with a different culprit: the "Previous Vibe Coder" problem.

Not All AI-Assisted Coding Is Vibe Coding

The term needs a tighter boundary. Martin Fowler defines vibe coding as building an application by telling an LLM what to make, trying the result, and prompting for changes without inspecting the generated code. What makes it vibe coding is not that AI writes the code. It is that the developer “forgets that the code even exists.”

An experienced developer who delegates code generation while still overseeing the architecture, tests, security, and maintenance consequences is working differently. Fowler calls this agentic programming. If every AI-assisted workflow is labelled vibe coding, the real risk becomes harder to see: what matters is less who produced the code than whether someone understands, tests, and owns the resulting system.

In this essay, “vibe coder” does not mean every developer who uses AI. It refers to a way of working that turns generated code into a product without understanding it, explaining the decisions behind it, or verifying it to the standard demanded by its real-world consequences.

How AI Subsidizes Sloppiness

AI can make code generation cheaper without removing the cost of care, testing, or architecture. It can simply make those costs easier to defer.

To put this in economic terms: AI temporarily zeroes out the cost of code generation (CAPEX), while invisibly compounding and deferring the long-term cost of code maintenance and operations (OPEX).

Writing tests, scanning for security vulnerabilities, thinking through edge cases, and preserving architecture require a developer to expend significant mental effort and time. AI eliminates this immediate friction by giving you code that "looks like it works" in seconds.

If you are thinking, "But AI can write tests too," I suggest being cautious. Without a human review of the failing behavior, an AI can optimize for a green dashboard by changing the test rather than resolving the root cause. You can see all green while the test has been weakened to accept the failure.

The key phrase here is: looks like it works.

A developer can move "quickly" to the next feature without noticing the structural decay behind the code. In software, that invisible debt (OPEX) often appears later as slower change, harder diagnosis, and more expensive operation.

The Silent Death of DRY and Library Chaos

The risk is not a universal property of every model or workflow. It arises when an AI works from incomplete project context and a team accepts a locally plausible answer without testing it against the system's architecture.

A 2025 research preprint, drawing on internally developed MVPs and recent industry reports, describes this as a flow–debt trade-off: seamless code generation can be accompanied by architectural inconsistencies, security vulnerabilities, and higher maintenance overhead. Its scope does not prove that every AI-assisted project will fail this way, but it gives the concern a more concrete mechanism. Read the 2025 flow–debt preprint.

The cleanest victim of this local bias is one of the most fundamental rules of software: DRY (Don’t Repeat Yourself).

Chaos and Bundle Bloat on the Frontend

When you ask an AI to design a new page in a frontend project, the following scenario plays out constantly:

1. Page A: Library X is added to the project, and a pre-built component is imported.
2. Page B: The AI forgets about the existence of Library X and writes hundreds of lines of code inline from scratch to achieve the exact same functionality.
3. Page C: It invents yet another inline function with completely different logic to do the same thing.

The result? The project gets bloated with unnecessary dependencies while simultaneously accumulating duplicate inline code. This directly bloats the bundle size downloaded by the user's browser, hurting page load speed and Core Web Vitals (LCP, INP). Worse, when a bug emerges, you have to hunt it down and fix it in ten different places. Don't assume, "I write my custom agent rules and system prompts to prevent this, so it won't happen." It still does. And unfortunately, in the real world, we don't solve bugs by writing "you're right, I'm sorry, my bad."

Bypassing Architecture on the Backend

The same lack of discipline infects the backend. Imagine you have a clean Route → Handler → Service → Repository (CQRS-like) architecture. When you ask an AI to add a new API endpoint, it avoids setting up those layers one by one (lazy pathing). To get the quickest answer, it directly embeds a raw SQL query or database call inside the Route definition.

It works on day one. But the caching layers in the Service are bypassed, validation rules are skipped, and testability is destroyed. Half of the project maintains a disciplined architecture, while the other half degenerates into spaghetti code querying the database directly.

The Invisibility of Clean Code

Good engineering quality in software is like negative space; it is defined by the absence of problems, not their presence.

Nobody values the extra time you spend writing secure code until your database is breached and user data is leaked. Or, when an unoptimized background loop written by an AI consumes 5% of a user's phone battery per hour, whereas optimized code consumes only 1%. The user doesn't notice this directly, but it silently drains the lifespan of their device. A backend might run fine when three people use it per hour, but when eighty people hit it simultaneously, it takes a lot more to keep it standing.

This dynamic mirrors George Akerlof's "Market for Lemons" (Information Asymmetry) theory. Because the buyer (the manager or the end-user) cannot inspect the internal quality of the code from the outside, the market rapidly fills up with cheap, quickly generated "lemons," making good engineering invisible.

As the market gets flooded with the noise of fast-but-sloppy products built by AI, this invisible quality is economically penalized. The effort of engineers who strive to write clean, secure, and performant code is overshadowed by those saying, "Look, we did this with AI in 10 minutes." That is, until the first major security breach or scaling crisis hits.

The "Previous Vibe Coder" Problem

It is a running joke in the industry that a new developer looking at a codebase will immediately complain, "the developer before me made everything spaghetti." Now, a new actor enters this joke: "The previous vibe coder."

Companies may believe they are building products cheaply today using AI. One plausible outcome is that, when they later need a new feature or a critical fix, they encounter a technical-debt swamp with weak standards and little retained human understanding.

At that point, remediation may require senior engineers to clean up and refactor the spaghetti heap at a premium. This is a projection, not a universal forecast: the cost of software development may not have disappeared so much as been deferred to the "next developer," with interest.

What Happens When Models Improve? (The Jevons Trap)

Techno-optimists will immediately defend their position: "These are problems of today's models (GPT-5.6, Fable 5). Once future models are perfect, these errors will disappear."

This argument misses two fundamental truths:

The Law of Specification Equivalence

No matter how smart an AI is, the input telling it what to do must still come from a human. Specifying a highly complex system with absolute precision and no logical gaps (specification) requires no less mental effort than coding it. Asking an AI to "write a payment system" is not enough; you must define every refund policy, tax bracket, and fraud detection rule. This specification process is, in itself, a new form of coding—and it remains entirely prone to human error.

EDITOR'S NOTE — September 5, 2026: I am adding one point to this section after publication. Writing a specification is only part of the work; the team also needs to preserve and review it. In Structured-Prompt-Driven Development, Wei Zhang and Jessie Jie Xia propose keeping the prompts—and the intent and constraints they capture—under version control. That turns the description from a one-off chat message into a record the team can inspect and revise.

This does not remove the work of preparing a specification. The article describes a method used inside Thoughtworks. It provides no independent comparison showing an improvement in speed, quality, reliability, cost, or return on investment.

The Jevons Paradox and the Conservation of Complexity

When coal engines became more efficient, global coal consumption did not decrease; instead, the number of coal-powered machines exploded, causing coal consumption to compound. As AI models improve and writing code becomes cheaper, we will not write less code. Instead, the scale and complexity of the systems we build will explode. When AI gets 10x smarter, we will build systems that are 10x more complex. Complexity is conserved; it simply shifts to a higher plane.

And most importantly, AI has no real-world accountability (skin in the game). AI does not pay the AWS bill when it fails, it does not wake up at 3 AM to page alerts when the database locks, and it does not stand in court after a security breach. Accountability is the only thing that cannot be delegated. That is why engineering is not just about writing code; it is about taking responsibility for that code.

This distinction also appears in Rest of World's report on how ordinary people use AI at work. It describes a personal trainer with no coding background building an app with Claude to support his own work, alongside small-business owners using AI for pricing and operations. These can be valuable and real use cases. But a prototype, or a private tool that helps its owner, is not thereby a reliable public product. The next stage still needs an engineer who can make architectural decisions, test security and performance, handle failures, and take responsibility for the system in production.

Conclusion

AI is not destroying software engineering; on the contrary, it is highlighting the importance of architectural vision, discipline, security, and performance more than ever.

When the technical debt bill is finally presented to those who produced "fast garbage" with AI, the winners will once again be the responsible engineers who know how to tame the chaos and value invisible quality.