First Done, Never Shipped: The Hidden Cost of Vibe Coding

Two months in, I looked at the numbers.

By one measure, he was our best developer. More code shipped than anyone else on the team. He’d picked up Claude Code quickly — faster than most — and was using it constantly. The output was real. Velocity looked great.

Then I looked at the bug report.

He was responsible for six times more defects than the next closest person on the team. Not 20% more. Not twice as many. Six times.

I’ve been watching the vibe coding conversation for a while now. The hype is real — non-technical founders spinning up MVPs, designers shipping working prototypes, PMs building internal tools that would have taken a sprint two years ago. And the developer productivity angle is just as compelling: senior engineers using AI pair programming to compress days into hours.

But there’s a version of this story nobody talks about as much.

AI doesn’t make you a better developer. It makes you a faster version of the developer you already are.

If you understand the code, it’s a force multiplier. You write less, think more, catch the edge cases before they ship. You use AI to handle the tedious scaffolding while you apply judgment to the parts that actually matter. The output goes up, and so does the quality.

If you don’t understand the code, it’s also a force multiplier. You generate more, think less, and ship problems at scale. The output goes up. The quality craters.

That’s the part that’s hard to see from the outside — and hard to admit when you’re inside it.

Our first developer wasn’t malicious. He wasn’t lazy. He was enthusiastic. He genuinely believed he was doing well, and by the only metric he could easily see, he was. Lines committed. Features closed. Tickets moved. The dashboard looked good.

He was usually the first one done. He was almost never the first one to production.

What the dashboard didn’t show was what was inside the code. Patches on top of patches. Logic that worked in the happy path and fell apart everywhere else. Defects that took the people around him hours to diagnose and fix — hours that never showed up attributed to him, because by then he was already onto the next thing. We tried to help. We put him on a performance plan. Walked through the issues. Made the expectations explicit. It didn’t turn around, and eventually we let him go.

The other developer we hired around the same time took a completely different path.

He had domain expertise — he understood the problems we were solving before he ever touched our codebase. He adopted AI tools just as quickly, but he used them differently. He wasn’t generating code and shipping it. He was generating code and interrogating it. Understanding what it did, why it worked, what it would break. Within a few months, he’d become the person we turn to for the most technically complex work we have — specifically how we handle inference inside our application. That’s not a role we assigned him. He earned it because the team kept discovering he could think through things nobody else could.

When we recognized what we had, we asked him a simple question: is there anyone in your network with the same capacity and interest in doing this kind of work? He’s since led us to two more developers who fit the same profile. Both have worked out.

The thing I keep coming back to is how invisible this pattern is until it compounds — in both directions.

Velocity metrics don’t catch the bad version. Story points don’t catch it. Closed tickets don’t catch it. The first sign is usually someone on the team muttering about weird bugs in unfamiliar corners of the codebase. Then the time-to-fix goes up. Then you look at the data. By then, you’ve already paid the tax.

The good version is equally invisible at first. A developer who slows down to understand what the AI generated doesn’t look like a star in week three. The metrics don’t reward interrogating a pull request. They reward closing one.

Once AI makes code generation fast and cheap, the bottleneck moves. The scarce resource isn’t output. It’s judgment. The ability to look at the code you generated and know whether it’s right. To understand the tradeoffs you made and the ones you didn’t. To maintain, debug, and extend what you built six months from now.

That judgment doesn’t come from the model. It comes from the developer.

I think about this every time I see a job posting that says “must be fluent with AI coding tools.” Fair enough — but that’s table stakes now. The question worth asking is whether the person can evaluate what those tools produce. Whether they can spot the hallucination. Whether they can read the diff and tell you what it actually does, not just what it was supposed to do.

If the answer is yes, they’re going to be exceptional. They’ll also help you find others like them. People with genuine judgment tend to know other people with genuine judgment. Treat them as a talent source, not just a contributor.

AI is an amplifier.

Put a developer with domain expertise and genuine understanding in front of it, and you get more of both — faster. Put a developer without those things in front of it, and you get more of that faster, too.

The underlying ability doesn’t change. The speed at which it manifests does.

That’s not an argument against AI tools. It’s an argument for being clear-eyed about what they are.

They’re not a shortcut to competence. They’re a multiplier of whatever competence you bring.

Choose accordingly when you’re hiring. And be honest with yourself when you’re building.