Stop Calling It 'Vibe Coding' — Thoughts After Six Months of AI-Assisted Programming

Disclaimer: The views in this article are my own, but the article was generated with AI assistance. I take responsibility for the content.

Preface

I’ve been using AI for coding for over six months now, and I’ve been meaning to write something about it. Recently I’ve seen all sorts of discussions about “vibe coding” — some say programming is dead, others say AI is just a toy. In my view, both takes miss the mark.

The reality is: the world is chaotic. Some people have already leveraged AI to unlock massive productivity gains, while others haven’t even thought about how to incorporate AI into their workflow. This divide is forming a new digital chasm.

My Journey

Looking back over the past few years, my relationship with AI has gone through several stages.

First came ChatGPT, which to some extent replaced StackOverflow. No more digging through forum threads — just ask directly.

Then came Copilot. It brought AI into the IDE, starting to assist me within my codebase. But it was still fairly basic back then, mainly doing in-file completions and generation — like a smart autocomplete tool.

The real turning point was when I started using Claude Code.

At first, I only had it help me with relatively isolated features. Gradually, I discovered it could work within complex existing projects — understanding context, following established code styles, finding the right entry points. I started trusting it on details, then began discussing architecture and design decisions with it.

When I noticed these changes, I had a moment where my ten years of coding experience suddenly felt fragile in the face of AI. This feeling threw me into FOMO — fear of missing out, fear of being left behind. So for a while, I tried to do almost everything with Claude Code.

Until I burned out.

After a brief rest, I realized: my past experience wasn’t useless. Quite the opposite — it was precisely this experience that let me use AI better. Knowing which questions are worth asking, knowing how to verify whether an answer is reliable, knowing where to stay vigilant. AI let me focus more energy on architecture and design, instead of getting lost in implementation details.

Once I understood this, I started working on things I’d always wanted to do but never had the time or energy for. For example, I built an open-source ADHD medication database called adhddb.org, hoping to provide some help for people with ADHD. This project might not have much impact, but Claude Code helped me actually turn this idea into reality.

Why I Don’t Like the Term “Vibe Coding”

Now that I’ve shared my journey, let me get something off my chest — the term “vibe coding.”

It was coined by Andrej Karpathy in early 2025, originally describing a state of fully surrendering to the vibes, embracing exponential growth, and even forgetting that you’re writing code.

Sounds cool, but in actual engineering practice, this term is extremely misleading.

Seriously using AI for programming is absolutely not something that can be described as a “vibe.” You need to think about when and how to let AI intervene; you need to interact with it, correct it, debug repeatedly, before you can possibly get the results you want.

Calling this process a “vibe” makes it sound like something casual. But in reality, it requires no less thinking than writing code by hand — it’s just that the level of thinking has shifted. From “how to implement” to “how to describe requirements, how to verify results, how to spot logical flaws in the AI’s output.”

Simon Willison put it well: “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.” — regardless of who wrote it.

Trust, but Verify

If “vibe coding” isn’t the right approach, then what is? Anthropic’s blog introduced a principle called “Trust, but Verify” — and I think it captures the right mindset perfectly.

Interestingly, according to reports, more than half of Anthropic’s internal engineers say they can only “fully delegate” less than 20% of their work to Claude, because they “still felt the need to check and verify Claude’s outputs.” In other words, the people who understand AI’s capabilities best are often the ones who trust it least blindly.

Anthropic’s blog also offers a great analogy — using AI for programming is like using Google Maps for navigation:

Early stage: You watch every turn, making sure the GPS isn’t leading you into a ditch. Similarly, in the early days of AI programming, you review every line of generated code.
Mature stage: As trust builds, you start relying on navigation for macro route planning, only checking at critical junctions.
But never follow blindly: If the GPS tells you to “drive into a lake,” you must have the judgment to override it.

AI-generated code has a characteristic: it often “looks” perfectly correct — proper variable naming, perfect indentation, even comments. But the internal logic might be completely wrong. This is what “hallucination” looks like in the code domain.

So verification isn’t optional — it’s a core part of the process. Here are some practical methods I’ve found useful:

1. Dual-Agent Verification

Have one AI write the code, another AI review it. For example, after writing, open a new chat window and have the AI play the role of “senior security auditor” to find issues. AI is often more perceptive at “finding bugs” than “generating code.”

2. Test First

Before generating implementation code, have the AI generate test cases first. You review the test logic, confirm the tests are reasonable, then have the AI generate the implementation. If the tests don’t pass, the code has no value.

3. Static Analysis as Safety Net

Set up TypeScript, ESLint, and similar tools. If AI-generated code can’t even pass type checking, reject it and ask for a rewrite.

4. Human Review as Final Check

Even if the code runs, review readability and maintainability. Machines can ensure code “works,” but only humans can ensure it’s “maintainable.”

How to Use AI “Seriously”

Verification is the last line of defense, but the better approach is to improve AI output quality at the source. This requires effort in two areas: interaction and correction.

Interaction: Context Engineering

Don’t just ask “how do I write a login page.”

The rigorous approach:

Gather context: Feed the AI relevant schemas, component library docs, API definitions
Set a role: “You are a senior frontend architect, focused on security and accessibility”
Define constraints: “Must use React Hook Form, must use Zod for validation”
Step-by-step instructions: “First explain your design approach, then list the file structure, finally generate the core code”

Correction: Iterative Feedback

When AI output is wrong, don’t rush to fix it manually, and don’t just regenerate.

Feed the AI the compilation errors or runtime stack traces directly
Ask why: “Why did you choose this library? What are the pros and cons compared to XX?”
Guided fixes: “The code throws an error when handling empty arrays, please add boundary checks”

This iterative feedback not only fixes the immediate problem but also helps you understand the AI’s thinking patterns, building experience for future interactions.

DHH Can Refuse, You Probably Can’t

After all this talk about “how to use AI well,” some might ask: what if I just don’t want to use AI?

DHH recently said that even though AI is powerful, he still wants to preserve the right to write code by hand, because it’s something he enjoys.

I respect this choice. But I also believe that being able to refuse something is because you have the freedom and privilege to refuse.

DHH has enormous industry reputation and wealth accumulation. He writes code not for survival or to meet deadlines, but for artistic expression and personal satisfaction. He has the capital to choose a less efficient but more enjoyable approach.

But for most regular developers, the situation is different:

Job market competition is intensifying, with ever-higher demands for development efficiency
A large number of junior-level tasks are being automated
For indie developers, AI is a survival lever — it lets one person accomplish what used to require a team

DHH’s perspective represents a kind of “craftsman” romanticism, which is beautiful. But regular people face the reality of “industrialization.” Learning to use AI isn’t about giving up the joy of programming — it’s about gaining a foothold in this era.

AI is a great lever for regular people. It amplifies individual capability, letting one person become a team.

Don’t Skimp on the Subscription

If you’ve decided to use AI, don’t cut corners on tools.

Many people try AI programming with free models, end up disappointed, and conclude that “AI is useless.” This is a classic cognitive bias caused by choosing the wrong tools.

Problems with free or lightweight models:

Weak at complex logical reasoning, generating code full of subtle logic errors
Small context windows, unable to understand the entire project structure
High hallucination rate, prone to fabricating non-existent APIs

Using inferior models creates massive “error correction costs.” You spend tons of time debugging AI’s mistakes, eventually feeling like you might as well have written it yourself.

Invest some money in AI, use the best-performing model you can find. For professional developers, a subscription of a few dozen dollars per month is just a fraction of your hourly wage, but what you get in return is a 24/7 available senior pair programming partner with a massive knowledge base who can generate code in seconds.

This isn’t just buying a tool — it’s buying time and cognitive bandwidth.

I use Claude Code daily, and always prioritize using the most powerful model available (currently Opus 4.5). Even though it costs significantly more, I think it’s worth it. Because only when you use the most advanced model can you truly practice “trust and verify” — if the model itself isn’t strong enough, you don’t even have a foundation for trust, just endless error correction.

Finally

The world is chaotic. The old order is crumbling, the new order hasn’t been established yet.

In this transition period, neither blindly proclaiming “programming is dead” nor stubbornly refusing to change, but using AI with a pragmatic, rigorous, critical attitude — this is probably the best survival strategy for regular people in the AI era.

The real future belongs to those who can master AI, not those who depend on it.

So stop calling it “vibe coding.” Call it whatever you want, but this thing is anything but casual.