Vibe Coding Doesn't Take Your Skills. It Takes Your Mandatory Stop Points

Whenever the downside of vibe coding comes up, people say the same thing: "AI code just isn't good enough yet", or the gloomier version, "developers will get lazy and their skills will atrophy."

I think both miss the target. AI-written code keeps getting better, and I've already written about the skills question. But something else is being taken away that almost nobody names:

Vibe coding erases the mandatory stop points: the moments when the slowness of hand-written code used to force you to think before you committed.

Sounds abstract? Let me tell you what just happened to me.

Tech A versus tech B: one afternoon to build, two weeks to tear down

On a recent project I had to pick the technology for a major feature. In the old days, a decision like that would have eaten several days: reading docs, building a small prototype, weighing trade-offs. Not this time. The AI suggested option A, which sounded perfectly reasonable, and since building was almost free, I said yes. One afternoon later, the feature was fully working.

Two weeks later I discovered option B: a better fit for the ecosystem we already had, with far less patching on our side. So I tore out everything built on A and rebuilt it on B.

The point isn't that I chose wrong. The point is that in the old days I wouldn't have made that kind of mistake. Not because I was smarter, but because hand-written code was expensive enough that I had to research before writing the first line. That expense was a mandatory stop point. Vibe coding made building a hundred times cheaper, and along with it, erased the reason to stop.

The evaluation phase didn't disappear. It just got pushed to after the build was done, in the form of "hmm, looks like B might be better." Tearing down and rebuilding is the late-payment invoice for the research you skipped.

And if you've been feeling less confident about the code AI produces for you, even with all the tests green, that feeling isn't you getting weaker. The data says it's the right signal.

The data: faster at building, blinder at deciding

You think you're faster. The clock says otherwise

In mid-2025, the research organization METR published a randomized controlled trial (the same methodology standard used for drug trials) with 16 experienced developers working on 246 real tasks in the open-source repositories they regularly contribute to. The result: when using AI tools, they were 19% slower.

The more shocking number is about perception. Before the trial, the developers predicted AI would make them 24% faster. After they had already been slowed down by 19%, they still estimated they'd been 20% faster (full study on arXiv). A 39-percentage-point gap between feeling and reality.

Why such a big gap? Because vibe coding gives you a constant sense of motion: code pours out, the screen changes, the feature takes shape. That sense of motion hides the time you burn re-checking, fixing "almost right" code, and, like my tech A story, tearing down and rebuilding.

Code is easy to generate, hard to keep

GitClear's 2025 code quality report, which analyzed 211 million changed lines of code from 2020 to 2024, paints exactly that picture:

• Code churn (code that has to be revised shortly after it's written) rose from 3.3% (2021) to 5.7% (2024). Nearly double.
• The share of copy/pasted lines rose from 8.3% to 12.3%; duplicated code blocks increased eightfold in 2024 alone.
• Meanwhile, the share of lines attributed to refactoring fell from 25% to under 10%. 2024 was the first year in the dataset where copy/paste overtook moved (refactored) code.

In plain English: we're generating code faster than ever and caring for it less than ever. Churn nearly doubling means a meaningful slice of "productivity" is just rewriting what was just written: the statistical version of my tech A to tech B story.

Shipping faster, breaking more

Google's 2025 DORA report surveyed nearly 5,000 technology professionals: 90% already use AI at work. The good news: AI is now associated with higher delivery throughput. The bad news: it still has a negative relationship with system stability. Teams ship faster but break more, unless they have strong enough brakes (automated testing, disciplined version control, fast feedback loops).

DORA's own conclusion: AI is an amplifier, not a fix. Teams with good processes get even better with AI. Teams without them just lack process ten times faster.

The four-stop framework: put the brakes back on purpose

The answer isn't to go back to writing everything by hand; being slow everywhere is exactly as wasteful as being fast everywhere. The answer is to deliberately reinstate the stop points, right where they used to exist naturally. These are the four I've adopted since the tech A incident.

1. Stop before choosing: separate the decision from the build

Before letting the AI write a single line of code, make it do something else first: compare options A, B and C against the real constraints of this project (scale, team, existing ecosystem, maintainability) and spell out each option's failure points. AI is very good at this, but only when you ask; by default it will go along with whatever direction you walked in with.

Then record the decision in a five-line note (an ADR): "Chose A because of X and Y. Considered B, rejected because of Z." Thirty minutes. Roughly a hundred times cheaper than one teardown and rebuild.

Genuinely torn? This is where vibe coding flips the rules in your favor: have the AI build the thinnest possible version with both A and B in a single session, compare them side by side, and only then build for real. Code thrown away on purpose is research cost. Code thrown away because you built the whole thing before thinking is waste.

2. Stop before building: you write the spec, AI writes the solution

The old kind of confidence came from "I wrote it, so I understand every line." That isn't coming back, and it doesn't need to. What replaces it is "I verified it, so I know it does the right thing": you define the acceptance criteria and the important test cases first, and the AI handles the implementation. A good tech lead never read all of their team's code anyway. They trust verified behavior, not memorizing every line.

3. Stop before merging: review by risk tier, not evenly

"There isn't time to read everything" is a fact you can't change, so stop trying. Tier it: code that touches money, authentication, user data, API contracts gets read line by line. UI, content, and internal refactors covered by tests get a skim of the diff and trust in the tests. Trying to read everything evenly means the most dangerous parts only get skimmed too.

A speed trick: make the AI explain before you read the code: what changed, why, what trade-offs, where the risks are. Wherever the explanation makes you think "wait, why that?", that's exactly where to look hard. Remember METR's 39-point gap: your own sense that "it's fine" needs verifying too.

4. Stop before switching: raise the bar for changing, not for choosing

The initial choice only needs to be "good enough". But switching has to clear a much higher bar: the new option must be better by enough to cover the cost of rewriting, the risk of new bugs, and the time you'll spend reviewing everything again from scratch. "B is better than A" is almost never enough. The right sentence is: "A is causing a specific pain that B solves." Reopen the ADR from stop point 1. If B doesn't win on the exact criteria that made you choose A, it's just grass-is-greener. Most urges to switch die right here.

The cost and the payoff, in money

Let's talk business, plainly.

When 90% of teams out there use AI, build speed is no longer a competitive advantage. It's table stakes. Everyone can ship a feature in an afternoon now. What separates winners from losers, per the DORA data, is the braking system: the team that stays stable while staying fast wins. The team that's only fast accumulates 5.7% churn, eight times the duplicated code, and teardowns nobody ever invoices.

And if you're a business owner hiring a team that "builds websites with AI, really fast", the question worth asking isn't "are you fast?" Anyone can answer that one. The question worth asking is: "Where are your stop points?" Who decides on the technology, and based on what? Who defines the tests? How is the code that touches my money reviewed? The team that answers fluently deserves your project. (And yes, I'm happy to answer those four questions, in writing.)

Vibe coding doesn't take your skills. It takes the places where slowness used to force you to think. The skills are still there; there's just nothing left forcing them to speak up. Reinstate the four stop points, and you get back the most valuable thing this speed craze is quietly erasing: the ability to decide with a clear head.

---

Data sources: METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089); GitClear — AI Copilot Code Quality: 2025 Research; Google Cloud — 2025 DORA Report: State of AI-assisted Software Development (dora.dev).