Vibe coding is just another layer of abstraction

There's a lot of noise these days about how the vibe coding scenario is going to play out. What it means for software, for jobs, for the people learning to code right now. I've been watching the discussion mostly from the sidelines — reading more than posting — and my opinion has shifted between camps a few times. Right now I'd describe my position as wait-and-watch. Not because I don't have a view, but because both extremes feel wrong in ways that are worth unpacking.

On one end you have the AI skeptics. The argument is something like: this is all hype, the models are stochastic parrots, and the whole thing is going to end the way the crypto cycle ended — a bunch of broken promises and a quiet retreat. On the other end you have people predicting the imminent end of all knowledge work. AGI any minute now. Programmers will be obsolete by next quarter. I don't find either of these positions credible, and the honest middle is more interesting than either of them.

Let me try to lay out where I actually sit.

1. Vibe coding is real, and it's a force multiplier.

I'll start with what I do believe. AI-assisted programming — codegen, copilots, vibe coding, whatever you want to call it — is a genuine force multiplier. You can accomplish things now that would have taken much longer a few years ago. There's no question about that. I use these tools daily and they make me faster. They also make me a slightly different kind of programmer than I was before, which is its own thing worth thinking about.

But the framing I find most useful isn't "is this transformative or not." The more useful framing is: what kind of thing is it, in the long arc of how programming has evolved? And once you ask that question, the answer becomes a little less dramatic.

2. Programming has always been a stack of abstractions.

If you're a student of computing history this part will be familiar, but it bears repeating. The story of programming is the story of one abstraction stacked on top of another.

We started with hardware. Vacuum tubes, then transistors, with the logic mostly encoded into the hardware itself. Then someone figured out you could keep the hardware fixed and feed it small snippets of logic that get executed by a CPU. That gave us the first real abstraction: assembly. Anyone who's done assembly knows just how painful it is to add two variables. So we built another abstraction on top — high-level languages. COBOL, FORTRAN, and eventually C, which I'd argue was the first real general-purpose language that opened the floodgates.

From C we got C++ when people wanted abstractions for objects. Then Java, then Python, then the modern soup of languages most people use today. And here's a thing people often miss: when you're writing Python, you're usually writing CPython, which means there's a C layer underneath the Python layer. The stack is still there. It's just hidden.

Vibe coding is the next layer up. You speak English, and a model translates your intent into something semantically and syntactically valid. That's it. That's what it is. It's a new abstraction sitting on top of the existing primitives, the same way C sat on top of assembly, and Python sat on top of C.

Framing it this way takes some of the magic away, which I think is healthy. It's still impressive. It's just not unprecedented in kind, only in degree.

3. The skill that matters is peeling back the layers.

Here's the thing every working engineer eventually learns: the abstraction you're operating at will, at some point, fail you. Not always, but often enough that it stops being surprising.

Let me give a small example. You pick up a fancy library or framework. You learn the high-level API. You ship things. Then one day something breaks in a way the docs don't explain. You can wait for someone on GitHub to answer your issue, or you can crack the library open and read the code. If the bug is in the library itself, fine — you fix it or work around it. But sometimes the issue is one layer deeper, in the language runtime or the system call or the way memory is being allocated. So you go one more level down. And sometimes one more after that.

This is the skill. The ability to look under the hood at the layer you're working on, figure out it's not the culprit, and keep descending until you find the real problem. Some abstractions you'll never need to crack open. But you have to be willing to crack open the ones the problem demands you crack open.

Vibe coding doesn't change this. If anything, it adds another layer to potentially descend through. When the model produces something that almost works but subtly doesn't, you still need to read the code it generated. You still need to understand why it chose that approach. You still need to know enough about the layer below to recognize when the generated code is wrong.

4. Top-down and bottoms-up are both valid. The problem decides.

There's a perennial debate about how to learn programming. Bottoms-up people start with fundamentals — how the CPU works, how memory is laid out, how compilers work — and build their way up. Top-down people start with the API, ship something, and only descend as the need arises.

I don't think either is correct in isolation. The problem in front of you decides which approach makes sense.

If you're building a generic internal tool — say, a small dashboard for tracking something nobody else will ever use — top-down is fine. Lovable, Bolt, whatever. You don't need to know what's happening underneath. You'll get something that works, and that's enough.

But here's where it gets interesting: even internal tools have a longer tail than people expect. There's a running joke that software is never done. Hardware ships and is done. Software keeps moving — that's why someone like Linus is still pushing changes to Linux decades in. Even your tiny internal tool, if you actually use it for a year, is going to need upkeep. Some integration breaks. Some dependency goes stale. You realize you can't keep relying on a cloud provider for the data and you need backups. The maintenance reality of software is something the vibe-coding-only crowd tends to underestimate.

5. Public products are a different game.

Internal tool? Sure, vibe code it. But anything public-facing — anything that's actually a business — is a different beast.

I don't think we're at a stage where someone can type "build me a social network like Facebook" into a chat box and get something that holds up. You might get something that works for ten users. Beyond that, the cracks show. Public products have to deal with security, scale, edge cases, integration with payment and identity systems, regulatory stuff, and a hundred other things that aren't visible from the prompt.

Can you build a quick-and-dirty prototype with vibe coding? Absolutely. Can you build a system that scales, handles real users, and survives in the wild? Not yet. Not without engineers thinking carefully at multiple layers of abstraction. Taste, judgment, and opinions about how things should be built — these still matter, and they're going to keep mattering for a while.

6. Follow the money on the hype.

There's a saying that to understand someone's motivations, follow the money. I find this applies cleanly to a lot of the loudest takes about AI right now.

The LLM providers benefit from messaging that says knowledge work is ending and AGI is around the corner. That's how they justify the valuations and raise the next round. Course sellers benefit from fear-mongering about your job disappearing — fear sells courses. I'm not saying these people are lying. Many of them probably believe what they're saying. But the financial incentives are aligned with the dramatic version of the story, and you should factor that in when you're deciding how seriously to take it.

Will the nature of knowledge work change? Yes. It always does. As humans get better tools, what counts as a meaningful job shifts. But will it happen on the timeline being shouted about in podcast clips? I really doubt it.

7. What about students?

A question I keep seeing: should students still study CS? Should anyone learn to code from scratch?

I think yes. Fundamentals still matter. Maybe they matter more, not less, because the people who understand the layers below will be the ones who can actually fix things when the abstraction breaks. The shortcut goes away, but the underlying terrain stays the same.

There's an analogy I keep coming back to. The other day I was at a store and saw a bunch of products that looked nice and were very cheap — clones of well-known originals. They looked fine on the shelf. But the moment I held one in my hand, I could tell. The weight was off. The materials felt different. The plastic flexed in a way the original didn't. The difference wasn't visible at a glance, but it was unmistakable up close.

I think software is going to be like this. There will be a flood of generic vibe-coded apps. Some of them will work fine. Some of them will succeed. But there will also be a market — and I think a growing one — for software that's clearly been made by someone with taste and intent. The MacBook-versus-generic-PC distinction never really went away, even when the hardware was on par. The thing that set Apple apart wasn't just specs. It was the opinionated integration of hardware and software, the willingness to make choices, the sense that someone had thought carefully about every detail.

Most people building vibe-coded apps for the first time don't see this difference. They look at two apps that solve the same problem and shrug. But people who build software for a living can usually spot the generic one within thirty seconds of opening it. That gap — between what the maker sees and what the casual user sees — is a thing the people building seriously can lean into.

8. On gatekeeping.

I don't want any of this to come across as gatekeeping. There's a strain of thinking in tech — "this is hard, you shouldn't try, leave it to the professionals" — that I don't subscribe to. I think someone with no formal background can come in and build genuinely good things. The bar to entry has dropped, and that's mostly a good thing.

But — and this is the part the optimist takes often skip — the people who succeed at it are going to be the ones willing to peel through the layers when the problem demands it. Not always. Not for every project. But often enough that the willingness becomes the differentiator.

You don't need a fancy degree. You don't need to have memorized the dragon book. You just need the persistence to keep going when the abstraction you're working at doesn't have the answer, and the curiosity to look one layer deeper.

Generalist problem-solving, in other words. The thing that's always mattered.

I'll close where I started: I'm in wait-and-watch territory. Not because I'm fence-sitting, but because the honest answer to "how is this going to play out" is that nobody knows yet. The skeptics are wrong about the magnitude of the change. The maximalists are wrong about the timeline. The truth is somewhere in the boring middle — a real shift, on a longer timescale than the hype cycle suggests, with the same engineering fundamentals continuing to matter underneath.

If you're building right now, the advice I'd give myself is: use the new tools, ship faster than you used to, but stay willing to descend through the abstractions when something breaks. That part hasn't changed. I don't think it will.

This essay got long. I had more to say than I thought. Maybe I'll write the rest later.