"Vibe coding" used to mean something specific. Andrej Karpathy coined it earlier this year. Let the model drive. Accept the diffs. Don't sweat the details. It was a vibe. Hence the name.
Then the internet got hold of it.
Now the term is doing two completely incompatible jobs at once.
On one end, it describes my 13-year-old son. I taught him some HTML and CSS a few years back, a little JavaScript, and let him loose on Scratch. He's now shipping Android apps and websites that punch wildly above his weight class.
On the other end, it describes me. 17 years into a software engineering career. I don't write code anymore. I architect systems and direct AI agents that build them.
Same term. Wildly different activities. The only thing they share is the tool.
And into that confusion, predictably, walks the course bro.
The Pitch
You've seen the posts. Ring light, whiteboard, software engineering is over. Bootcamps are dead. CS degrees are obsolete. Anyone can be a senior engineer now. All you need is the 8-week cohort. $2,000. Limited seats. Next session starts Monday.
The proof is always a demo. Look at this app I built in a weekend. Look at this SaaS doing $10k MRR. Look at this AI agent that does my taxes and walks my dog.
You never see the part that comes after the demo.
You don't see the production incident at 2am. You don't see the database migration that corrupts a tenant's data. You don't see the security review that finds the API key committed to the repo on day three. You don't see the codebase six months in, when every new feature takes twice as long because the foundation was laid by someone who didn't know what a foundation was.
That's not because those things don't happen. It's because they happen to the customer, after the course is paid for.
The Actual Difference
Here's what I think is true, having lived on both sides of this.
AI is a real capability multiplier. The multiplier is applied to what you already know.
A senior engineer with Claude Code isn't doing the same job a beginner is doing. We're not even in the same building. The interface looks similar. We're both typing English into a text box and getting code back. But the work is fundamentally different.
When I sit down to build a feature, the AI is the implementation layer. The interesting work is upstream of that. What's the right data model? Where does this responsibility belong in the system? What's the failure mode when this third-party API goes down? What does the migration path look like for existing tenants? Is this a feature, or is it a symptom that the abstraction is wrong and we should refactor instead?
Claude can help me think through those questions. It can't answer them. The answers depend on context the model doesn't have. The business. The team. The customer. The 18 months of history that explain why this part of the codebase looks the way it does.
My job is to hold all of that in my head and translate it into prompts and reviews.
The AI's job is to type fast.
A beginner using the same tool is doing something different. They're describing what they want and accepting whatever comes out, because they don't have the framework to evaluate it.
That's fine for a Wordle clone. The Wordle clone works or it doesn't. You can tell by playing it.
It's not fine for anything that has a database, multiple users, money moving through it, or a future.
Where The Gap Shows Up
My son was building an interactive globe a little while back. Tap a country, get details about it. Cool project. He got it mostly working with Claude's help.
But he kept hitting this bug. He'd tap Antarctica and the app would tell him he'd tapped Russia. He tried a few things. He couldn't unstick it. He came to me.
What I had to explain wasn't really about code.
2D and 3D mapping are different problems wearing similar clothes. In 2D you have an x and a y, you map them to whatever you want, and you're done. In 3D, x and y still exist, but they mean something different depending on what surface you're looking at and from what angle. Latitude and longitude are real, but turning a tap on a screen into a point on a sphere is a chain of math. Any link in the chain can be wrong.
Then I showed him how to debug it the way an engineer debugs it. Which is the part the AI can't teach him yet.
The bug isn't "Antarctica returns Russia." That's the symptom. The bug is somewhere in the transformation.
So: tap China. What do you get? If you're getting a US state, your latitude is probably inverted. Tap South Africa. If you get Argentina, that's one kind of wrong. If you get Alaska, that's a totally different kind of wrong.
The pattern of wrongness tells you where the math broke. You're not fixing the bug. You're locating it first.
That's the conversation. That's what a 13-year-old vibe coder actually needs. No course in the world is going to give him that. He needed someone to explain a coordinate system, and then to show him that debugging is a science of narrowing.
What Beginners Actually Can't Do Yet
Vague gatekeeping is annoying. I'm trying not to do that. So here are the concrete things that separate "I made a thing" from "I built software":
You can't review code for problems you don't know exist. Claude will happily write you an auth system with a subtle vulnerability. If you don't know what to look for, you'll ship it. Same for SQL injection, race conditions, IDOR bugs, leaked credentials, and the entire OWASP top ten.
You can't tell when the model is confidently wrong about architecture. Claude has opinions. Some are good. Some will paint you into a corner you won't notice until you're three months and ten thousand lines deep.
You can't maintain what you didn't understand when it was written. The first feature is easy. The fortieth feature, layered onto a foundation no human ever modeled, is where the wheels come off.
None of these are permanent limits. They're skills. You can learn them. People have been learning them for decades.
AI doesn't shortcut that process. It makes the learning faster if you're doing it deliberately. It makes the faking faster if you're not.
The Part I Actually Love
I want to be clear about something. It would be easy to read everything above as a guy with 17 years of experience pulling the ladder up behind him.
That's not what this is.
I love that the barrier to entry is collapsing. I love it. It's one of the best things that has ever happened to this field.
For most of my career, software engineering had a brutal filter on the front of it. You had to wade through a semester of pointer arithmetic before you got to make anything fun. You had to fight your environment for a week before you could render a triangle. The number of people who had a real spark for building things, but bounced off the toolchain before they ever got to build, has to be in the millions. We lost them. They went and did something else, and we never got to see what they would have made.
That filter is gone now.
A kid with an idea can have a working prototype the same afternoon. The idea is the bottleneck again, the way it should have been the whole time.
That is good. Unambiguously good.
And here's the other thing. I want fewer people in this field who are "just working a job."
I've spent my whole career around two kinds of engineers. People who light up when they talk about what they're building. And people who are counting the hours until they can close the laptop.
Guess which ones write the bugs. Guess which ones ghost the on-call rotation. Guess which ones treat the codebase like someone else's problem.
The ticket-closers were always here. They were here because the gate was high enough that "I can grind through a CS degree" was a sufficient qualification, regardless of whether you actually liked the work.
Lower the gate, and you change who walks through it.
You get more of the kid who builds an interactive globe at 13 because he wanted to. You get the artist who finally builds the thing she's been sketching in notebooks for a decade. You get the small-business owner who automates the thing nobody would build for him.
You get builders. Passionate, weird, obsessive builders.
That's exactly who I want in the room.
The course bros aren't the gate falling. The course bros are feeding on the gate falling. They saw a real, beautiful thing happening — a generation of people getting access to a craft that was previously walled off — and they figured out how to charge admission to a door that's already open.
That's the whole game. They're not democratizing anything. The democratization already happened. They're standing in front of it with a card reader.
When I'm hard on the course bros, I'm not being hard on the beginners. I'm being hard on the people selling to the beginners. Those are not the same thing.
The People I Worry About
It's not the beginners. Beginners are fine. Beginners are how we all started, and the current generation of them — my son included — has tools that would have melted my brain in 2008.
It's the ones who get sold the lie. Who pay the two grand. Sit through the cohort. Ship a demo. Walk into a real engineering interview, or worse, a real engineering job, believing they're a senior because someone with a course to sell told them they were.
That gap closes hard. It closes on them.
My kid is going to be a better engineer than I am. Not because he vibe-codes — he does, and that's fine. Because when his globe app told him Antarctica was Russia, he came and asked someone who could explain why.
That's the loop. Tool, attempt, failure, understanding, next attempt. There's no shortcut around the understanding step. Anyone selling you one is selling you a story about yourself.
The Actual Point
The fundamentals haven't changed. The interface to applying them has.
The tools are real. The leverage is real. The transformation in how we build software is real, and I'm betting my career on it.
The course bro selling you a shortcut around the actual work is not.
Use the tools. Skip the course. Do the reps.