Vibe Coding is a Technical Debt Factory

I recently sat in a meeting where a Product Manager told me he had "vibe coded" a prototype over the weekend. He was ecstatic. He had spoken to a computer, told it his dreams, and the computer had spat out a working React application. He felt like a wizard. He felt like the future had finally arrived to liberate him from the tyranny of engineers like me.

Then I looked at the code.

It ran. I will give him that. It rendered pixels on the screen. But beneath the shiny interface lay a subterranean horror show of hard-coded secrets, duplicated state logic, and security vulnerabilities so gaping you could drive a truck through them. It was not software. It was a facade.

We are currently living through a mass delusion. The industry has latched onto a new term. Vibe Coding. The idea is simple. You don't need to know how to code. You just need to know the "vibe" of what you want. You supply the vision. The AI supplies the implementation.

It sounds magical. It sounds like the democratization of creation.

It is actually a catastrophe in waiting.

Is "Slop" the New Standard?

The narrative selling this dream is seductive. It tells us that the barrier to entry for software engineering has been artificially high. It argues that syntax is a gatekeeper preventing brilliant "idea guys" from building the next unicorn.

The proponents of Vibe Coding believe that natural language is the ultimate programming interface. They argue that we are moving from a deterministic era of explicit instruction to a probabilistic era of intent. In this worldview, the "how" is irrelevant. Only the "what" matters.

Platforms like Lovable and a thousand other "text-to-app" wrappers have sprung up to service this belief. They promise a world where you simply describe your application and it manifests. No debugging. No architectural diagrams. No understanding of memory management or API latency. Just pure creation.

The orthodoxy states that traditional coding skills are becoming obsolete. Why learn to invert a binary tree or understand the difference between TCP and UDP when an LLM can do it for you in seconds?

The answer is simple: Because the LLM doesn't understand it either. It just statistically predicts that it should be there.

If this utopia were real, we would see a golden age of software stability and innovation. We are seeing the opposite. The data is starting to pour in, and it paints a grim picture of the "Vibe Coding" reality. We are not building better software. We are building worse software faster than ever before.

GitClear analyzed over 150 million lines of code changed between 2020 and 2024. Their findings are damning. They found a massive increase in "code churn"—code that is written and then almost immediately deleted or rewritten. Even more worrying, they found an eight-fold increase in duplicated code blocks.

This is the hallmark of copy-paste programming. This is not efficiency. This is thrashing.

The Anatomy of the "Vibe"

Let's look at what happens inside the "Vibe" engine. This is speculation based on observation, but it aligns with the behaviour of every LLM I've tested.

When a non-technical user asks for a feature, they ask for the happy path. They ask for the visible result.

INPUT: "Make a dashboard for user metrics. I want to see daily active users."

The Vibe Coder (the human) thinks they have specified the software. They haven't. They have specified a UI.

Here is what the AI generates. This is the code that "runs" but ruins your life later.

The Vibe Implementation (What the PM ships)

// UserDashboard.js // The AI generated this. It looks great in the demo. import React, { useState, useEffect } from 'react'; function UserDashboard() { const [data, setData] = useState(null); // PROBLEM 1: This runs on every mount. No caching. No deduping. // If the user tabs away and back, we hammer the API. useEffect(() => { // PROBLEM 2: Direct fetch in component. Tightly coupled. // If we change the auth method, we have to rewrite every single component. fetch('https://api.myapp.com/metrics') .then(res => res.json()) .then(data => setData(data)) // PROBLEM 3: What happens on 401? 500? Network failure? // The AI doesn't care. The "vibe" is success, not failure handling. .catch(err => console.log(err)); }, []); if (!data) return <div>Loading...</div>; return ( <div> {/* PROBLEM 4: Direct property access without optional chaining or schema validation. If the API changes the shape of 'daily_users', the whole app crashes (White Screen of Death). */} <h1>Daily Users: {data.daily_users}</h1> {/* PROBLEM 5: Inline mapping logic that belongs in a transformer/selector layer. */} {data.history.map(item => ( <div key={item.id}>{item.count}</div> ))} </div> ); }

javascript

The output is a perfect prototype. It is also a production nightmare.

It has introduced technical debt instantly. It has created a frontend dependency on an API that hasn't been designed properly. It has managed state locally in a way that will conflict with the rest of the application.

Now, let's look at what an engineer writes. Not because we love typing, but because we understand systems.

The Engineer Implementation (What actually works)

// useUserMetrics.ts // The Engineer writes this. It handles reality. import { useQuery } from '@tanstack/react-query'; // Using established libraries for caching import { z } from 'zod'; // Runtime validation because APIs lie // 1. Define the Schema. Contract first. const MetricsSchema = z.object({ daily_users: z.number(), history: z.array(z.object({ id: z.string(), count: z.number() })) }); export const useUserMetrics = () => { return useQuery({ queryKey: ['metrics', 'daily'], queryFn: async () => { // 2. Abstraction layer for API calls const data = await apiClient.get('/metrics'); // 3. Validation layer. If this fails, we know EXACTLY why. // We don't just crash the UI. const parsed = MetricsSchema.safeParse(data); if (!parsed.success) { throw new Error("API Contract Violation"); } return parsed.data; }, // 4. Configuration for stale-while-revalidate strategies staleTime: 1000 * 60 * 5, retry: 2 }); };

typescript

The "Vibe Coder" looks at the first example and sees success. It works. It's short.

The engineer looks at the first example and sees a rewrite. The second example is longer, yes. But it handles network flakiness, API drift, caching, and race conditions. The AI did not generate the second example because the prompt didn't ask for "runtime schema validation using Zod."

The prompt asked for a vibe.

The Context Gap

The Google 2025 DORA report reinforces this. They found that a 90% increase in AI adoption correlated with a 9% climb in bug rates and a massive 91% increase in code review time.

Think about that for a second. We are spending double the time reviewing code because the code we are generating is suspect.

The "Context Gap" is the killer here. The AI sees the file you are working on. It might see the file next to it. It does not see the legacy database schema from 2018 that you have to interface with. It does not understand the regulatory compliance requirement that forces you to encrypt that specific field. It does not "know" your architecture. It guesses.

When you write code by hand, you are forced to confront the details line by line. You have to think about the variable types. You have to think about the error handling. The friction of typing is a quality control mechanism. It forces your brain to engage with the logic.

When you generate code, you bypass that friction. You can generate a thousand lines of garbage in a second. This means the role of the engineer shifts from "writer" to "auditor". And auditing is harder than writing.

To audit code effectively, you need a deeper understanding of the system than the person (or machine) who wrote it. You need to spot the subtle bug that the AI introduced because it didn't understand the thread-safety model of your specific language version.

You cannot audit what you do not understand.

The Pseudo-Code of Failure

Let's look at the internal logic of a "Vibe Coding" session. This is what I suspect is happening when the abstraction leaks.

INPUT: "Update the user profile to allow multiple addresses." VIBE_LAYER: - Retrieves 'User Profile' React Component. - Retrieves 'Address' Form. - Ignores 'Database' context (Foreign Keys). - Ignores 'Billing' context (Billing address must be unique). GENERATION: - Change frontend to array of addresses. - Update API POST request payload. RESULT: - Frontend looks correct. allows adding 5 addresses. - Backend receives JSON array. - Database constraint (One-to-One) explodes. - 500 Internal Server Error.

The Vibe Coder hits the button. The UI updates. They smile. They deploy.

Then the support tickets start rolling in.

What This Actually Means

We are sitting on a time bomb of AI-generated technical debt. In two years, we will see a wave of high-profile failures in companies that went all-in on "Vibe Coding".

We will see security breaches caused by hallucinations. We are already seeing the user base for platforms like Lovable churn. People sign up. They build a demo. It looks great. They show their investors. Then they try to add a complex feature. They try to integrate a legacy payment gateway. They try to scale it to 10,000 users.

The system breaks. The code is a tangled mess of hallucinated logic and spaghetti dependencies. The user cannot fix it because they never understood it. They leave.

The market knows this. We are seeing a correction. The job market is not hiring "Vibe Coders". It is aggressively hiring senior engineers who can fix the mess.

This is the deeper truth: Vibe Coding is a lie because it relies on a fundamental misunderstanding of what software engineering is.

Coding is not the act of typing syntax. That is typing. Coding is the act of rigorous specification. It is the process of taking a vague, fuzzy human requirement and constraining it until it can be executed deterministically by a machine.

When you use a Vibe Coding platform, you are not skipping the hard part. You are ignoring it.

GenAI is probabilistic. If you feed it garbage, it smiles. It nods. It says "Certainly! Here is the code." It generates code that looks right. It adopts the "vibe" of correctness. This is where the term "slop" comes from. It is code that occupies space but provides no nutritional value to the system.

TL;DR For The Scrollers

• Vibe Coding creates prototypes, not products. It handles the "happy path" and ignores the edge cases where software actually lives.
• Churn is skyrocketing. GitClear data shows an 8x increase in duplicated code. We are generating slop, not solutions.
• The friction is the point. The effort of writing code forces you to understand the logic. Removing the friction removes the understanding.
• Auditing > Writing. The job of the future isn't prompt engineering; it's being a Senior Code Auditor who can spot the subtle lies the AI tells.
• Context is King. AI lacks the historical and architectural context of your specific system. It guesses.

Edward Burton ships production AI systems and writes about the stuff that actually works. Skeptic of hype. Builder of things.

Production > Demos. Always.

More at tyingshoelaces.com

How many hours have you spent debugging code that an AI (or an "Idea Guy") claimed was "basically done"?

\