Why developers push back on vibe coding

Vibe coding takes less time to learn than people expect. The harder part is not the tool. It is knowing the field well enough to tell good output from output that only looks good. That is the actual skill, and it is exactly what most developers already have.

Which is what makes their hesitation interesting. Not because they cannot learn to use these tools. Because using them changes what their job actually is.

Once you generate code instead of writing it, there is a one-way door. Nobody comes back from that and hand-writes the same feature the old way, not because they are lazy, but because the tool is genuinely faster once you trust it. The problem is what happens after. Vibe-coded code does not read the way a person would have written it. It is not organized around the habits a team shares. Another developer opening that file later is not reading familiar code. They are reverse engineering a decision they were not part of.

That is a real cost, and developers feel it immediately, because they are usually the ones who inherit it.

A developer’s job has always included a kind of vouching. When something ships, their name is on the parts they touched, whether that is written down anywhere or not. If it breaks in production, if it has a security hole, if it cannot be extended six months from now, someone is going to ask who approved it. That question gets much harder to answer honestly when nobody fully read the code, because reading it would have taken longer than writing it from scratch.

So the reluctance is not about ego, or fear of being replaced by a tool, at least not entirely. It is closer to a professional instinct. If part of your job is understanding why the system works the way it does, a black box in the middle of that system is a real problem, not an inconvenience.

I do not think this makes the shift avoidable. I have written before about why the actual source of truth is moving into the codebase itself, past design files and specs that go stale the moment nobody has time to update them. That shift is already happening, whether or not it is comfortable.

But it does mean the resistance deserves more credit than it usually gets. Most of the people who are cautious about this are not behind. They are doing the version of their job that has always mattered most: making sure someone can stand behind what shipped.

Maybe the next generation of engineers, trained inside this way of working from the start, will relate to code differently. Fair enough. We are early. AI assistance has existed for less time than it takes most engineers to finish a degree, and the profession has not caught up to what that means yet.

Until it does, the discomfort is not a sign that developers are resisting progress. It is a sign that the question of who is accountable for what ships has not been answered yet. That question is worth taking seriously, not rushing past.