Vibe Coding & AI Fatigue: The Hidden Cost of Effortless Code

In the weeks following Karpathy's post, the response was electric — and revealing. Engineers across experience levels posted versions of the same confession: "I thought I was the only one." The term gave language to a behavior that had become widespread almost overnight, driven by increasingly capable AI coding tools like Claude, Copilot, Cursor, and ChatGPT.

But something else surfaced in those responses. Beneath the jokes and the relief of having a name for it, there was something closer to anxiety. Engineers weren't just vibe coding because it felt good. Many were vibe coding because they felt they had to — because their teams expected it, because their peers seemed to move faster, because the baseline for what "keeping up" meant had changed overnight.

This page is about the hidden cost. Not the moral case against AI coding tools — those tools are genuinely useful. The question is: what happens to you when vibe coding becomes your only mode?

What Vibe Coding Actually Means

Let's be precise, because "vibe coding" can mean different things depending on who's doing it and why.

At its core, vibe coding describes a workflow where:

• You describe what you want in natural language
• AI generates the code
• You copy-paste, run it, see what happens
• You iterate based on errors or desired changes
• The AI handles the implementation details; you handle the direction

This is genuinely useful for prototyping, exploring unfamiliar APIs, scaffolding projects, or writing boilerplate. No one is arguing against that. The problem — and the source of the anxiety — is the boundary between "this is a useful tool" and "this is all I do."

The Spectrum: From Tool to Dependency

Most engineers start at the green end of this spectrum. A new tool comes out, you try it on something small, it works surprisingly well. You start using it more. At some point — often without realizing it — you've crossed into yellow territory. The yellow zone isn't inherently bad, but it's where the slippery slope begins.

The red zone is where the AI fatigue shows up. Here's how to know if you're there:

The Four Losses of Vibe Coding Without Boundaries

1. The Skill That Compounds

Programming skill is not a fixed quantity you acquire and retain. It's more like a physical capacity — cardiovascular fitness, say. It builds through repeated challenge and recovers through rest. If you stop challenging yourself and rely on AI to carry the load, the skill doesn't just pause. It actively erodes.

Betsy Sparrow's research on the "Google Effect" (2011) showed that people became worse at recalling information they knew they could look up. The same mechanism applies to problem-solving: when you know an AI can generate the solution, your brain is less motivated to build the path to it. Robert Bjork's research on "desirable difficulties" explains why this matters — the struggle to retrieve or construct something is precisely what makes the memory or skill more durable.

2. The Identity That Hollows Out

Software engineers derive significant professional identity from their ability to build things. Not just "ship things" — build them. To understand them deeply enough to reason about them, debug them, teach them to someone else, make trade-offs in them.

When you vibe code extensively, you can still ship. But the inner experience changes. The work starts to feel more like curation than creation. And over time, many engineers report a creeping sense of fraudulence — not quite imposter syndrome, but something adjacent. A sense that the competence other people see in you is partly borrowed from a machine.

3. The Ownership That Never Forms

Deep ownership over work — the feeling that something is genuinely yours — requires that you were there for the hard parts. The凌晨 debugging. The architecture decision. The moment when you understood why a particular approach was wrong before you understood why the right one was right.

Vibe coding skips most of those moments. The result is engineers who ship a lot of code they have a surface-level relationship with. When that code breaks in production at 2am, or when a colleague asks a probing question about it, the anxiety that surfaces is not about the code — it's about the gap between the responsibility you hold and the understanding you have.

4. The Confidence That's Backward

Here's one of the most insidious effects: vibe coding can generate a peculiar form of inflated confidence that doesn't survive contact with reality. Because you can get things working quickly, you feel capable. But the actual underlying competence — the ability to build, debug, and reason about software without AI assistance — diverges downward even as the output surface looks impressive.

This is the "competence illusion" we wrote about in the skill atrophy page. The gap between your perceived competence (high, because things work) and your actual competence (declining, because you haven't built the underlying structures) creates a specific form of vulnerability: you're most at risk precisely when you feel most confident.

The Compounding Trap: Why Engineers Can't Stop

Here's what makes vibe coding so difficult to pull back from once it becomes habitual: it works — at least at first, and at least superficially. The immediate feedback loop is rewarding. You get code quickly. Things appear to work. Teammates see output.

The problem is what happens over months, not weeks:

• Skill drift: Your unaided problem-solving ability quietly declines. You don't notice because AI is always there to bridge the gap.
• Compensatory reliance: As skill drifts, you lean more heavily on AI to maintain output. This accelerates the drift. The loop reinforces itself.
• Exit cost rises: The longer you've vibe coded, the more daunting the prospect of "going back to doing it yourself" becomes. The gap between where you are and where you want to be feels larger.
• Identity investment: By the time the anxiety surfaces, you've built months of portfolio and reputation around a mode of working you're not sure you can sustain without AI. There's now a lot riding on the story being true.

This is the compounding trap. The earlier you intervene, the easier it is to reverse. The longer you wait, the more the compounding works against you.

How Vibe Coding Compares to Normal AI-Assisted Coding

The Engineers Most at Risk

The Self-Assessment: Is Vibe Coding Hurting You?

How to Vibe Code Without Burning Out

This is not an argument for abandoning AI coding tools. Used deliberately, they are extraordinary amplifiers. The question is how to use them without eroding the underlying competence that makes you valuable — and that gives your work meaning.

The Three Non-Negotiable Practices

The Thought Experiment for Teams

If you're a tech lead or manager reading this: ask yourself what would happen if AI tools disappeared from your team's workflow for one month. Not a pessimistic fantasy — just a genuine calibration exercise. How much of your team's actual competence would remain? How much of what you call "velocity" is AI-generated output that would not survive a competence audit?

This is not about AI being bad. It's about the difference between a team that uses AI as an amplifier and a team that's become dependent on it as a crutch. The former gets the benefits of AI and retains competence. The latter risks both the skill erosion and the identity damage that comes with it.

FAQ

Continue Exploring