Development

You know what I mean by vibe coding? That approach where you throw prompts at an AI, get code back, and ship it without caring about what’s actually under the hood. It’s the “move fast and ship” mentality taken to an extreme.

That’s not me. I build with Claude Code every day, but I care about what’s being built.

The difference is partnership versus just getting code generated. AI is great for removing friction in development, but only when you guide it properly. I don’t need to understand every technical implementation detail, but I absolutely need to understand how to prompt these systems well and how to tell good output from garbage.

This is coding at a different level of abstraction. Way less debugging, more strategic thinking.

Vibe coding relies on blind trust. You ask for a feature, get some code, and assume it works because it runs. The approach I follow (the same one the best engineers have always used) involves asking the right questions, steering toward better solutions, and reviewing code.

Here’s what I mean: I have Claude Code and Copilot work as complementary tools. I scope ideas and technical details with Claude, then either log them as issues for later or tackle them right away. And when it’s time for a pull request, I have the other AI pair programmer handle the review.

They function like tireless pair programmers and I’m the technical lead kicking off the effort and making the calls.

The key insight is guidance versus automation. Vibe coders stop at “it works,” but I’m concerned with whether the solution is correct and sustainable. Will this scale? Is the architecture sound? Does it handle edge cases?

The details matter because understanding structure and correctness keeps you from shipping nonsense. Maybe that changes as AI-augmented engineering gets better, but today, having judgment about the code is what separates functional software from potential disasters.

Even these new AI “vibe-coding” platforms like Lovable, GitHub Spark, and v0 offer a choice: you can vibe with the no-code interface, or you can peek under the hood.

We’re curious beings, so be curious. Watch how your prompts and choices translate into code, learning along the way.

That’s the approach I advocate. Use these tools, absolutely, but stay engaged and curious about how they work. Ask questions. Understand patterns. Let each project teach you something new and you’ve already won.

The best developers are better at prompting, better product leaders, better strategic thinkers, and better at tracking what changed in their codebase. The good news: those skills transfer whether you’re working with AI or humans.

So yea, I don’t vibe code.

Nobody tells you that AI-augmented coding makes implementation skills abundant and strategic thinking priceless.

Last weekend, I experimented with a simple chatbot for my blog. I got it working in thirty minutes. Even just a few months ago, this was a nights and weekends endeavor, at best.

Well, mostly working. RAG pipeline, embeddings, and the whole thing connected and responding to questions about my posts—but with the occasional hallucination I hadn’t fixed yet.

Something felt different. Where was the part where I spent three hours debugging why the vector database wouldn’t talk to the frontend? Where was the documentation rabbit hole? The Stack Overflow shame spiral?

None of that happened.

It got me thinking about where we are today as engineers compared to a few months ago. A shift at the core of our practice is happening in real time.

I used to think good developers were fast typists who memorized syntax. Now they’re people who know what to build and recognize when it’s built right. The muscle memory that took years to develop? Less relevant every month.

I have a friend who writes everything from scratch and is proud to understand every line. Meanwhile, others ship releases in the time it takes him to set up authentication. In a way, we’re both right. My friend understands his codebase perfectly. I understand my users’ problems perfectly. Different skills for a different game.

I find I’m doing much more creative work now as well. When you’re not burned out from wrestling with dependencies and import statements, you have brain space for the interesting questions. What should this actually do? How should it feel to use? What problem are we solving? Does it matter?

Even yesterday, a newer developer asked if AI would make them obsolete. Wrong question. The right question is: what kind of developer do you want to be? The kind who can implement anything, or the kind who knows what’s worth implementing?

Both matter. But only one is getting scarcer.