Vibe Coding Will Ruin Engineering

In a slow game

On my team someone ships five features a week using AI.

I ship one.

I’m the underperformer.

What’s actually different

The devs shipping ten features a week aren’t using AI as a tool.

They’re using it as a replacement for thinking.

AI designs the system. AI writes the code. AI reviews itself. They push to production and move on.

The feature count goes up. The dashboard looks great. The manager is happy.

Nobody asks what happens when something breaks.

The measurement problem

Non-technical managers measure productivity by features shipped. Lines of code per week. Tickets closed.

That’s how they got promoted. That’s how they justify headcount. So that’s how they evaluate engineers.

But volume isn’t value.

You can ship ten features a week and one critical bug in that batch costs the business more than five solid features would have saved.

Managers don’t see that part. They look at the number going up and they look good. That’s it.

So the engineer shipping one careful feature is slowing the team down. The engineer shipping five features with AI and not reading the code is a hero.

You feel it in standups. You feel it in performance reviews. You see who gets the promotion.

Where vibe coding is fine and where it isn’t

Simple UI work — let AI write all of it. One-off scripts. Predictable logic. The blast radius is small if something goes wrong.

That’s not what’s happening on most teams.

People are vibe coding state management. Authentication. Payment systems. Complex interconnected backend logic.

Those are the systems where one bad decision can kill your company. And AI is writing them. And nobody is reviewing them carefully.

Why engineers do it anyway

Because they’re being told — use AI, ship this in two days, or we’ll find someone who will.

When you don’t write the code yourself you lose the cognitive connection to it. You don’t know why a function got named the way it did. You don’t know why a pattern was chosen. You don’t know why it works.

AI made those decisions. Not you.

So when something breaks at 3 a.m. you’re debugging code you’ve never actually thought about. Your name is on the pull request but you didn’t engineer anything.

You’re a human sticker on AI’s work.

The moment that sticks with me

Last week I jumped on a call with someone on my team to work through their pull request.

I asked why they used a particular pattern when we already had a utility that does the same thing.

The answer was — I don’t know. AI did it.

That’s an engineer. Talking about code with their name on it.

And I’m not blaming them. The manager wanted five features by Friday. There was no time to read it carefully. The system stopped paying them to be careful and started paying them to ship.

What this does to junior devs

The way you actually learn to code is through struggle.

Stuck on a bug for three days. Wrestling a concept for a week. Sometimes a month before the aha moment.

That’s where real understanding lives.

Junior devs today just ask the AI to fix it. No struggle. No aha moment. No real connection to the code.

Nobody’s paying them to learn the hard way. They’re paid to ship fast.

The system is teaching them that fast equals good.

And one day they’ll be the senior engineers. And they’ll be debugging systems they don’t understand at 3 a.m.

My honest confession

I told you I ship one feature a week. That’s the version of me that gets to do the job right.

But I can’t ship one feature a week when my teammates are shipping ten. I’d be fired.

So the system pressures me into shipping three with less depth than I’d like.

That’s the compromise that keeps me employed.

I’m not preaching. I’m just telling you what working engineers are actually experiencing right now.

We’re all compromising. Nobody chose this. We’re all just stuck in it.

Who’s actually selling this

AI lab CEOs. Every podcast. Every keynote. Every interview.

We generate 50% of our code with AI. You can ship ten times more features. 100x productivity.

That’s their pitch. That’s what investors need to hear to keep valuations going.

So managers hear it and believe it. Then they walk into standups asking why we’re not ten times more productive.

And engineers sit there pretending this is normal. Pretending the ten times thing is real. Knowing it’s a ticking bomb in the production codebase.

The CEO sells the dream. The manager buys it. The engineer pays for it.

What happens when production breaks

Nobody remembers the manager who pushed for ten times velocity.

Nobody remembers the CEO from the podcast who already cashed out his stock options on the AI narrative.

Everyone remembers John. Whose name is on the repo.

John takes the 3 a.m. call. John sits through the war room. John explains what happened and cleans it up.

Faster code today is a career risk tomorrow.

What you can actually do

Pushing back alone just makes you the underperformer.

But you can talk to your teammates. Try to draw boundaries as a team about where vibe coding is acceptable and where it isn’t.

If you can get even two or three people agreeing on that line you’ve done more than most companies are doing right now.

We can’t fix this alone.

But we can at least stop pretending it’s fine.

Want more stuff like this? Even more detailed? I go into deep dives every single day on my 📌Substack📌

At the price of a coffee I can give you enough knowledge to replace a bachelor’s degree in computer science or maybe even a masters, who knows.

💜 If you like my work and would like to support to me financially. Even a small donation would help a lot!

My PayPal — Please Support