Vibe Coding Got Me to 80%. Engineering Got Me the Other 20%.

I actually like vibe coding. There. I said it.

I know we're supposed to pick a side now. Either AI coding is apparently destroying the entire software industry, or you need to fire up six agents, never read another line of code again and become a $100 million ARR founder by Friday. I'm somewhere in the middle.

What it's great at

I use AI to code basically every day, and it has completely changed how fast I can turn an idea into something real. I can have some random idea at 11 PM, open my editor, explain what I'm thinking, throw an agent at it and suddenly there’s an actual interface in front of me.

That is insane. And honestly, I don't think we appreciate how insane it is because we've gotten used to it so quickly. Things that would've taken me a weekend can sometimes take a few hours. Things I probably wouldn't even bother building before because of the setup cost? Now I'll just try them.

The 80% trap

But I've also learned something after building enough stuff this way. AI is unbelievably good at getting me to like… 80%. And 80% is dangerous, because 80% looks finished.

The buttons work. The page looks good. You can sign in. The API returns something. The demo works. You post it online and everybody says, “Bro this is fire.”

And then an actual person starts using it. Now everything is on fire.

• The background job failed.
• The UI says the upload completed but processing actually crashed.
• Some random race condition only happens when two things run together.
• The AI created the same utility function in three different places.
• One component somehow has 700 lines.
• Your database schema made perfect sense four features ago and now you hate yourself.
• The API you're using returned something slightly different from what you expected.

And the best one: the agent fixes your bug. Great. Then you discover three hours later that the fix quietly broke something completely unrelated.

That's when the vibe stops vibing, and actual software engineering starts.

Works vs. keeps working

I've started seeing a very clear line between building something that works and building something that keeps working. AI has made the first one dramatically easier. I'm not convinced it has made the second one equally easy.

Production software has history. It has weird users, migrations, retries, state and permissions. It has old decisions, and new decisions fighting old decisions. It has APIs controlled by other companies, data you absolutely cannot lose, and users doing things you were 100% sure nobody would ever do. That's where understanding what you're building starts to matter.

I can verify the result

To be clear, this isn't me becoming one of those people who says you need to handwrite everything. Please don't. I don't want to manually write boilerplate just so I can feel like a real programmer. If an agent can do something faster than me and I can verify the result, I'm going to let the agent do it. Every single time.

The important part of that sentence is I can verify the result. That's the part I think gets lost. AI-generated code still has to become your code. Your database. Your infrastructure. Your users. Your 2 AM production bug. The AI does not care that your app went down. I promise.

Better engineer, better prompts

I've noticed the better I've gotten at software engineering, the better I've also gotten at using AI. Not because I learned some magical prompting technique, but because I can give it better direction. Instead of:

Build me an upload system.

It's more like:

Uploads should go directly to object storage. Persist the asset before processing. Processing needs to be asynchronous because these files can be large. Jobs have to be idempotent because retries are possible. Track processing state separately from upload state.

Now the agent has boundaries. It has architecture. It knows what I'm trying to protect against. The prompt got better because my understanding got better.

That's why I don't really buy the idea that AI makes learning software engineering pointless. I think it makes pretending to understand software easier. Big difference.

The last 20%

You can build a surprisingly impressive application without knowing much now. That's genuinely cool, and more people should build things. But if you want to go from prototype to product, you're eventually going to hit the part where prompting harder doesn't solve the problem. You need to understand:

• why something is slow
• why the state is inconsistent
• why your architecture is becoming impossible to extend
• why an agent keeps making the same mistake
• why your production environment behaves differently from local

That's the 20%. And unfortunately, the last 20% of building something is somehow 80% of the pain. Classic.

The funny thing is, AI still helps me there. A lot. I'll use it to inspect logs, trace execution, compare implementations, write tests around a bug, research something I've never worked with, explain an unfamiliar part of a codebase and generate possible fixes. The difference is I'm no longer asking “can you build this for me?” I'm collaborating with it around a system that I understand. That's a much more useful relationship.

So yeah, I vibe code

Proudly. It lets me move stupidly fast. It lets me test ideas I probably would've talked myself out of building. It makes programming more fun because I can spend less time fighting boilerplate and more time actually thinking about the product.

But I also don't think vibe coding replaces engineering. I think it gets you to the point where engineering becomes necessary much faster. And maybe that's the best way to describe where software development is right now: the barrier to creating software is collapsing. The barrier to creating good software isn't.