Everyone Can Ship Now. That's the Problem.
A few weeks ago, I built a full quiz app in three hours. Peaky Blinders on one window, Claude on the other. I described what I wanted, and it appeared. I didn't write a single component. I didn't set up a build tool. I didn't think about routing.
I just thought.
That's what vibe coding does. It collapses the distance between idea and implementation so dramatically that the bottleneck is no longer "can you build it" but "do you know what to build."
And most engineers, myself included, are quietly underprepared for that shift.
The Cost of Building Used to Do the Thinking For You
For a long time, the cost of building was a forcing function for clarity. If you were going to spend two weeks on something, you'd better understand it well enough to defend your decisions. The effort of implementation forced you to ask the uncomfortable questions early, because asking them late was painful and expensive.
Vibe coding removes that friction. Which is mostly great. Genuinely. You can go from idea to working thing in an afternoon, and that's kind of wild.
But it also means you can now ship something confidently without ever asking the questions that used to be forced on you by circumstance.
What problem does this actually solve? For whom? What does success look like? What are the tradeoffs? What happens when it scales? What's the failure mode?
These aren't engineering questions. They're product questions. And they've always mattered. They just used to have a built-in enforcer. That enforcer is gone now.
I Felt This Firsthand Building Go Mastery
When I sat down to build Go Mastery, my first instinct was the engineering instinct: what components do I need, how does state flow, what's the data model.
Then I caught myself. This was supposed to be about learning Go, not building a React app to learn Go. Those are very different projects. If I'd gone down that path I'd have spent three hours on architecture and zero hours thinking about whether the quiz would actually teach anything. I'd have shipped a beautiful, thoroughly useless piece of software.
So I forced myself to stay in the product questions first.
Why do most quizzes fail to produce real learning? Because they're built to be completed, not understood. One obviously right answer surrounded by obvious decoys. You don't need to understand anything. You just need to not be distracted. It's less of a test and more of a vibe check.
What would a quiz look like if it made that strategy impossible? One wrong answer surrounded by options that all sound plausible. Suddenly you can't pattern-match your way through. You have to actually think.
What would make it even harder to shortcut? A pushback mechanic. 60% of the time, after you answer, the quiz asks "are you sure about that?" You never know if you're wrong or just being challenged. So you pause, reread, and, if you're like me, briefly question every choice you've made.
None of that thinking required code. It required understanding the problem deeply enough to have opinions about the solution. The implementation took three hours because the thinking happened first.
That's the product mindset. And vibe coding doesn't give it to you. It just makes it more visible when you don't have it.
Hallucinations Are the Same Problem, Wearing Different Clothes
Here's where it gets interesting.
AI hallucinations and learning misconceptions are structurally the same problem. In both cases, something that sounds correct isn't. In both cases, the danger isn't obvious wrongness. It's plausible wrongness. The output that's 90% right and 10% subtly broken is far more dangerous than the output that's just clearly wrong, because at least the clearly wrong answer is easy to catch.
Spotting the obviously wrong answer is table stakes. Spotting the wrong answer when everything around it sounds reasonable, that's the actual skill.
This is why I think misconception-spotting is becoming one of the most underrated skills in engineering. Not skepticism for its own sake, not compulsive fact-checking on every sentence. The specific ability to read something that sounds authoritative and plausible, hold it up against what you actually know, and find exactly where it goes sideways.
That skill is directly trained by building with AI. Every time you prompt Claude or GPT and get back something that's almost right, you're exercising it. Every time you catch a hallucination before it ships, you're getting sharper. It's like going to the gym, except the gym occasionally tries to convince you that goroutines work like JavaScript promises.
The engineers who will thrive in the vibe coding era aren't the ones who can prompt best. They're the ones who can evaluate output best. And evaluating output requires the same thing that evaluating quiz answers requires: understanding the concept deeply enough to know why something is wrong, not just that it is.
What This Means Practically
A few things I've changed about how I work since building Go Mastery:
Before writing a prompt, write the brief. What problem am I solving? Who has this problem? What does good look like? What are the constraints? Five minutes of this saves thirty minutes of iteration and one very confusing diff.
Treat AI output like a quiz answer. Not "is this right?" but "where is this wrong?" The assumption of correctness is the trap. The default should be "this is probably mostly right and I need to find the part that isn't." It usually isn't hard to find.
Study the concepts, not just the syntax. Vibe coding makes it easy to ship Go without understanding Go. But when the hallucination shows up (and it will), you need the mental model to catch it. Surface-level familiarity doesn't give you that. Understanding does.
Think in problems, not features. The question "what should I build?" is less useful than "what problem am I solving and is this the right solution?" Features are easy to generate now. Problems worth solving are still hard to find, and no amount of prompting helps with that part.
The Skill Stack Is Shifting
We're not heading toward a world where engineering skills don't matter. We're heading toward a world where the engineering skills that matter most are shifting up the stack.
Implementation is getting cheaper. Understanding is getting more valuable. Product thinking, knowing what to build, for whom, and why, is becoming the differentiator.
That's not a threat to engineers. It's honestly a pretty good development if you're willing to lean into it. The engineers who've always wanted to think at the product level but got stuck in implementation details now have the tools to do both. The ones who only ever thought about implementation are going to find that better tools make the work harder, not easier, because the tools expose what was always true: code was never the hard part.
Vibe coding doesn't replace thinking. It just makes thinking the job.
I write about Go, full-stack development, and shipping projects without overthinking them. Follow along on LinkedIn if this resonated.
Top comments (0)