The gatekeeping runs both ways. And history is pretty clear about which side ends up looking foolish.
There is a specific look developers give when someone mentions vibe coding.
A slight tightening around the eyes. A pause before responding that carries more weight than the words that follow. Then: “Yeah, but does it actually understand what it’s doing?”
The implication is always the same. Real developers write real code. They understand the stack, debug the edge cases and reason about performance trade-offs before touching a keyboard. Someone who types a prompt and ships whatever comes back is not a developer in any serious sense. They are a tourist.
This is the dominant opinion in most senior engineering circles right now. And honestly, some of it is fair.
But I want to walk through something that has been sitting with me: we have been here before. Not just once. Several times. And the people holding the dismissive position never ended up being right.
This is not a defence of vibe coding. It is an attempt to read the trajectory honestly, which is a different thing.
The Pattern We Keep Forgetting
When C became widely used in the 1970s and 80s, assembly programmers had real concerns. C abstracted away control over registers, memory layout and instruction cycles. If you were writing firmware for a real-time system, that abstraction was not a convenience. It was a liability. The assembly crowd was not wrong about the trade-offs. They were wrong about what would happen next.
When garbage-collected languages arrived, the C and C++ community had real concerns. You were handing memory management to a runtime you did not control. For systems programming, that was a serious objection. Again, not wrong about the trade-offs. Wrong about what would happen next.
When ORMs became mainstream, database administrators had real concerns. Generated SQL was ugly, inefficient and occasionally catastrophic at scale. Some of that critique holds up today. But teams that refused ORMs entirely spent most of their time writing boilerplate while everyone else shipped features.
When JavaScript frameworks like React arrived, the “just use vanilla JS” camp had real concerns. Bundle sizes, abstractions leaking, components hiding state. Some of that critique still holds. The framework developers kept their jobs. The purists became a niche.
The pattern is not that the critics were stupid. It is that they focused on the current worst-case and ignored the trajectory. Every single time, the new tool got better. The abstraction got tighter. The floor rose. And the people who refused to move with it did not win the argument. They just got left behind.
What Vibe Coding Actually Is
On February 2, 2025, Andrej Karpathy put a name to something a lot of developers had been doing quietly for months. In a post on X, he described a way of building software where you lean fully into AI suggestions, skip the line-by-line mental model and just ship things that work. He called it vibe coding.
The term stuck because it accurately described both the experience and what made experienced engineers uncomfortable about it.
The discomfort is legitimate. Code you do not understand is code you cannot fix when it breaks at 2am. Accepting AI output without review creates what Addy Osmani, in a March 2026 article, called comprehension debt: the growing gap between the code that exists in your system and the code any human being genuinely understands.
That is a real problem. It deserves the attention it is getting.
But here is the part the dismissal tends to skip. Comprehension debt existed before AI. Every developer who has inherited a codebase built by a team that left has felt it. Every project that grew faster than its documentation has it. AI did not create the problem. It accelerated it. Those are different things.
The term “vibe coding” also gets applied too broadly. It covers two genuinely different groups. The first is the person who takes AI output, skips review and ships without understanding. That behaviour has real costs. The second is the developer who uses AI to get to the business logic faster, still reads what gets generated and makes judgment calls about what stays and what does not. Treating both as the same thing is how the current contempt gets built.
Where We Actually Stand: The Numbers
The data on this is worth looking at directly, not as a headline but as a trend line.
According to the Stack Overflow Developer Survey, 44% of professional developers were actively using AI tools in 2023. By 2024, that number climbed to 62%. By 2025, 84% said they use or plan to use AI tools, with 51% using them daily.
The JetBrains State of Developer Ecosystem 2025 found that 85% of developers regularly use AI tools for coding, and 62% rely on at least one AI coding assistant or agent.
That is not a slow adoption curve. That is near-saturation in two years.
What makes this especially interesting is what happened to sentiment at the same time. Positive sentiment for AI tools among developers dropped from over 70% in 2023 to 60% in 2025, even as usage climbed. Trust in AI output accuracy fell from 69% to 54%.
In other words: developers are using these tools more and trusting them less. That sounds contradictory until you realise it is actually the most mature possible relationship with a tool. You use a hammer even though you know it can hit your thumb.
The current contempt for vibe coders sits inside this tension. Experienced developers are using AI tools, watching them produce unreliable output, and concluding that anyone who trusts them completely is naive. That conclusion is correct. The mistake is assuming the tools stay at their current reliability level.
The Trust Gap Nobody Is Talking About Honestly
There is a generational split forming that the industry has not named clearly yet.
Developers who learned to code before AI tools existed have a strong intuition that something is wrong when the code in front of them came from a model rather than a human hand. That intuition is load-bearing for them. It is how they catch bugs. It is how they reason about systems.
Developers who are entering the field now, or who started in the last two or three years, do not have that reference point. For them, AI assistance is not an addition to a workflow. It is the workflow. The idea of writing every line without AI feels like the idea of writing code without an IDE feels to anyone who has used one for a decade: technically possible, slower and not obviously more correct.
Both groups are currently calling the other group wrong. Both have a point.
What neither group is saying loudly is that the floor has already moved. A junior developer in 2025, with AI tools, ships faster than a mid-level developer in 2019 without them. The productivity gap between using these tools well and not using them at all is now large enough to show up in team velocity. Not in every codebase. Not in every context. But consistently enough that ignoring it is its own form of denial.
The Inversion That Is Coming
Picture a team in 2028. They move fast. They spec features in natural language, have AI scaffold the structure, write the business logic that actually requires judgment and ship. They are not skipping understanding. They are choosing where to focus their understanding. The scaffolding is not the interesting part. The business rules, the failure modes and the architecture decisions are.
Now picture a developer who refuses to work this way. Every ticket takes longer. Code review takes longer because they are writing by hand what could be generated and verified in minutes. They call it craftsmanship.
The team does not admire the craftsmanship. The team is waiting.
This is the inversion. Right now the vibe coder is the one who gets the side-eye in code review. Give it a few years and the developer who cannot integrate AI into their workflow will be the one people route around. Not fired. Not replaced. Just quietly excluded from the parts of the work that require speed.
The side-eye does not disappear. It just points in a different direction.
Speculation: What Each Year Looks Like
This section is prediction. Label it as such. None of what follows is guaranteed. But trajectories matter, and this one has been consistent.
2026 (Now): The current moment. Senior engineers hold the cultural high ground. Vibe coding is a punchline in most engineering discussions. Developers use them widely but discuss them defensively. Developers who use them heavily downplay it in code reviews. The social cost of being seen as a “prompt coder” is still real.
2027: AI tools become a line item in job descriptions. Not “experience with AI tools preferred” but “must demonstrate proficiency with AI-assisted development workflows.” The first cohort of developers who have never worked without AI tools hits three to four years of professional experience. They start getting promoted.
2028: The first teams where AI-native workflows are the default, not the exception, start outperforming traditional teams on shipping speed by a margin too large to explain away. Engineering managers start asking the uncomfortable question: not “are you using AI?” but “why aren’t you using it more?” The burden of proof shifts.
2029: The developer who cannot integrate AI tools into a standard workflow is the one who gets the side-eye in interviews. Not because they are bad engineers. Because they are slower. And slow has a cost. The old gatekeeping does not disappear. It becomes a minority position.
2030: The loudest voices in “you should use AI tools” will be the same cohort who, in 2026, were the loudest voices against vibe coding. They will have adapted. And they will have very little patience for anyone who has not.
This is how technology adoption has gone for decades. The critics become the advocates. The laggards become the bottleneck. The cycle runs again.
The Developer Profile That Survives Both Waves
Here is the uncomfortable specificity.
The developers who will still be doing interesting work in 2030 are not the ones who mastered prompting. Prompting is not a skill with a long shelf life. The interface between humans and AI tools will keep changing. What matters is not how well you talk to the model. It is what you do with what comes back.
The profile that survives looks like this:
- Deep enough in fundamentals to read generated code critically and catch the subtle wrong answers, not just the obviously broken ones
- Fast enough with AI tools to not be the bottleneck on a team that expects them to be used
- Clear enough on system design to make the architecture decisions that AI still gets wrong with any consistency
- Honest enough about uncertainty to say “I generated this, I reviewed it and here is what I am not confident about” rather than shipping quietly and hoping
That last point matters more than people acknowledge. The single biggest failure mode of AI-assisted development right now is not bad code. It is confident bad code. Code that looks right, passes a surface review and fails in production on an edge case the developer never thought to test because they did not write the logic.
The antidote is not refusing to use AI. It is developing a finer-grained sense of where AI output is trustworthy and where it is not. That is a skill. It takes time to build. You build it faster by using the tools critically than by avoiding them entirely.
The Identity Problem Worth Naming
A lot of the current contempt for vibe coding is not really about code quality. It is about identity.
Writing code, specifically and laboriously, has been the mark of the craft for decades. The idea that someone can produce working software without that labour feels like it cheapens something. That feeling is understandable. It is also not a technical argument. And mixing it with technical arguments muddies both.
The same thing happened when typesetters were displaced by desktop publishing in the 1980s. Skilled professionals who had spent years learning the craft were watching untrained people produce work they would have considered substandard a decade earlier. They were right that the quality was lower. They were wrong about whether that would matter.
What replaced the craft was not the absence of skill. It was a different distribution of skill. The technical knowledge got abstracted away, and the judgment that used to live inside the technical execution had to move somewhere else. The people who survived that transition were the ones who figured out where the judgment moved, not the ones who insisted the old craft still mattered.
That transition is happening again. The judgment that used to live inside writing every line is moving somewhere else. The question is whether you are paying attention to where it is going.
A Scorecard for Yourself
Before you finish reading, here are five questions worth answering honestly.
1. Could you describe, in plain terms, how an AI coding assistant decides what to suggest? Not in detail. Just the rough mechanism. If you cannot, you are using a tool whose failure modes you cannot anticipate.
2. In the last month, how many times did you catch a significant error in AI-generated output that would have made it to production if you had not reviewed it? If the answer is never, you are either very lucky or not reviewing carefully enough.
3. If your team’s velocity expectation doubled next year because AI tools made that possible, would you be equipped to meet it? If the answer is no, that is the gap to close.
4. What is the last thing you learned about your codebase by writing something from scratch that you would not have learned if you had generated it? If you cannot answer this, you might be losing the feedback loop that writing gives you.
5. Are your objections to AI-assisted development technical or identity-based? Both are valid. Only one of them is useful to act on.
The Question Worth Sitting With
Every gatekeeping moment in tech history has had the same structure. The people holding the gate are usually technically correct about the trade-offs. And they are usually wrong about what matters in practice, at the speed at which practice actually moves.
The vibe coder today is someone who figured out how to move faster at the cost of depth. The critic today is someone who maintains depth at the cost of speed. Neither position is fully right.
But the history of this industry is consistent about which direction the pressure moves. Depth without speed becomes a bottleneck. Speed without depth becomes a liability. The developers who last are the ones who figure out how to hold both, and who do not spend energy sneering at the people who figured out the speed part first.
The tables have turned before.
They will turn again.
The only question is whether you will be ready when they do, or whether you will still be explaining to someone why you do not need to change.
This story is published on Generative AI. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories.
Subscribe to our newsletter and YouTube channel to stay updated with the latest news and updates on generative AI. Let’s shape the future of AI together!
