The strange thing about AI coding isn't that machines can write software now.
It's that we're finally discovering how much of software engineering had very little to do with typing code in the first place.
In early 2025, “vibe coding” sounded like a meme.
Andrej Karpathy described it as essentially giving in to the model, accepting generated code, and worrying less about the code itself. He openly described accepting changes without reading the diffs and letting the code grow beyond his normal comprehension. He also made an important exception: for disposable weekend projects, it was “not too bad.”
That distinction should have ended the argument.
It didn't.
Instead, the internet split into two camps.
One side said:
“This isn't engineering.”
The other said:
“You just don't understand what engineering is becoming.”
A year later, I'm less interested in which side wins.
I'm interested in something more uncomfortable.
What if both sides were looking at different parts of the same transition?
The Original Sin of Vibe Coding
The biggest misconception about vibe coding is that it means:
“Using AI to write code.”
It doesn't.
Simon Willison made that distinction very clearly in 2025. His argument was basically that if an LLM writes the code but you review, test, understand, and take responsibility for it, that's not really vibe coding. That's simply using an LLM as a programming tool.
The more interesting definition is much messier:
You have an idea.
You describe it.
The model writes something.
You run it.
Something breaks.
You describe the break.
The model changes the code.
You run it again.
It works.
You ship it.
That workflow feels almost magical.
And sometimes it is.
But there's an interesting word hiding inside that loop:
works.
What does “works” actually mean?
Does it pass the demo?
Does it pass the tests?
Does it survive production?
Can another developer understand it?
Can you debug it six months later?
Does it preserve the right security boundaries?
Does it make the next feature easier or harder?
Or does “works” simply mean:
“I don't see an error anymore.”
Those are very different definitions of success.
I Found Myself Doing It Too
This is where the debate gets personal for me.
I've built projects where AI was involved in much more than autocomplete.
Take Arcane Dice.
It's a 3D physics dice roller with Three.js, Ammo.js and an AI dungeon-master layer.
I could describe a feature, let the model implement it, run the project, find something broken, paste the error back, and keep going.
And that's incredibly productive.
You can get from:
“I have an idea.”
to:
“There's a working prototype in the browser.”
much faster than you could before.
That's the part of AI coding that critics sometimes underestimate.
The leverage is real.
But then something funny happens.
The project gets bigger.
The components multiply.
State starts crossing boundaries.
One feature touches three other systems.
A “small” change suddenly has consequences somewhere else.
And the questions change.
You stop asking:
“Can the AI write this?”
and start asking:
“Why did it write it this way?”
That's a completely different question.
The Code Gets Cheaper. The Context Doesn't.
This might be the most important economic change AI has introduced into programming.
The cost of generating code has collapsed.
The cost of understanding a system hasn't.
Imagine an agent generating 2,000 lines in ten minutes.
Amazing.
Now imagine another engineer has to spend two hours understanding the change.
The generation got cheaper.
The reasoning didn't.
And if AI makes developers produce five times as many changes, the amount of software requiring review can increase faster than human review capacity.
That's exactly why code review is becoming such a strange bottleneck in the agentic era.
Recent industry analysis has reported large increases in code churn and review time among teams with heavy AI adoption, alongside concerns about more unreviewed changes reaching production.
There's a beautiful paradox here:
AI removes the bottleneck that was visible.
Then creates a bottleneck that is harder to measure.
“But My Tests Are Green”
This is probably the most dangerous sentence in AI-assisted development.
A test suite can tell you that certain behavior works.
It cannot tell you that the architecture makes sense.
It cannot tell you that the abstraction belongs there.
It cannot tell you that the next engineer will understand the code.
And it certainly can't guarantee that you solved the right problem.
METR ran an experiment around exactly this gap.
They looked at software-engineering patches that passed automated SWE-bench evaluation and then asked maintainers whether they would actually merge them.
A substantial share of those patches were not considered acceptable for the real project.
That doesn't mean the benchmark is useless. It means the benchmark is measuring something different.
Passing a test is not the same as passing an engineer.
That's an important distinction because AI systems are becoming exceptionally good at optimizing for things we can measure.
The things we cannot measure as easily are often the things engineers spend their lives worrying about.
Then the Productivity Research Got Weird
There is another reason I don't think the “AI makes programmers worse” argument holds up.
Some research says AI makes developers significantly more productive.
A large field experiment involving 4,867 developers across Microsoft, Accenture, and a Fortune 100 company reported that developers with access to AI coding assistance completed about 26% more tasks.
That is not a rounding error.
But another randomized METR study of experienced open-source developers working in mature repositories found something almost comically opposite: developers using AI took about 19% longer on the tasks studied.
Even stranger, the developers expected AI to make them faster.
They were slower.
And still believed they were faster.
That's not just a story about AI.
It's a story about humans.
We are very bad at estimating the total cost of automation when the automation feels good.
The Best AI Feature Might Be False Confidence
This is the part that genuinely bothers me.
When an AI generates broken code, that's annoying.
When it generates code that looks correct, it's much more dangerous.
Good naming.
Clean formatting.
Reasonable comments.
A green test suite.
A polished UI.
No obvious errors.
Suddenly you have something that feels trustworthy.
And our brains are very willing to reward things that look finished.
One 2026 study examining whether human developers could detect deliberately hidden malicious behavior in AI-assisted coding tasks found that most participants failed to detect the sabotage. Even after monitoring warnings appeared, many participants still accepted the code.
That's not evidence that AI is evil.
It's evidence that human review is not automatically human understanding.
You can technically review a diff while mentally outsourcing the judgment to the machine that produced it.
That's a very different kind of failure.
And Security Doesn't Care About Your Vibes
Here is where the “it's just a prototype” defense becomes complicated.
Because prototypes have a nasty habit of becoming products.
A developer builds something for fun.
Then someone says:
“This is actually pretty useful.”
Then:
“Can we add accounts?”
Then:
“Can it store user data?”
Then:
“Can we monetize it?”
Then:
“Can it handle payments?”
Congratulations.
Your weekend experiment now has a security model.
A 2025 benchmark of real-world coding tasks found a disturbing gap between functional correctness and security. In one evaluation, 61% of SWE-Agent solutions using Claude 4 Sonnet were functionally correct, while only 10.5% were considered secure.
That number should make every “the tests pass” argument feel slightly less comfortable.
Because software doesn't get attacked according to your benchmark.
It gets attacked according to reality.
My Own Projects Made This More Obvious
Another project I've worked on is Ikol, a Telegram AI bot.
The interesting part isn't simply getting an AI bot to answer messages.
That's easy now.
The interesting part is everything that happens around the model.
State.
Retries.
Tool selection.
Rate limits.
External APIs.
Bad responses.
Wrong music results.
A tool that works perfectly today and starts behaving differently tomorrow.
A previous answer leaking into an unrelated conversation.
Suddenly you're not really asking:
“Can GPT answer this?”
You're asking:
“What guarantees does the system have when everything around GPT is imperfect?”
That's engineering.
And AI doesn't remove that layer.
It makes the layer more visible.
Here's Where I Think the Vibe Coding Debate Goes Wrong
We keep asking:
“Is vibe coding engineering?”
I think that's the wrong question.
A better question is:
“Where does the engineering move when the typing moves to the model?”
One DEV commenter described the role as a kind of “Language Modeler”: the human specifies what the system is, what it means, and what constraints are allowed, while the AI acts as a translator between natural language and code.
Another developer argued that the new engineering skill is orchestration: decomposing problems, directing agents, validating outputs, and knowing whether the generated system actually solves the problem.
Those aren't silly arguments.
They're actually the strongest argument for AI-native engineering.
And that's where the discussion gets interesting.
The New Engineer Might Write Less Code and Understand More
Imagine two developers.
Developer A writes 2,000 lines manually.
Developer B generates 10,000 lines with AI.
Developer B might appear more productive.
But now imagine Developer A understands every abstraction in those 2,000 lines.
Developer B understands only the behavior of the system at the surface.
Which one is the better engineer?
We don't actually know.
Because the answer depends on what happens next.
If nothing breaks, Developer B wins.
If the product has to evolve for five years, the equation might completely reverse.
And if the system is safety-critical?
The cost of not understanding can become enormous.
The Comment Sections Are Actually Getting More Interesting
What's changed recently isn't that everyone agrees.
It's that the arguments are getting better.
One DEV commenter recently described vibe coding as:
“borrowing time from the future at a predatory interest rate.”
That's a brutal metaphor.
But it's useful.
Maybe AI doesn't remove technical debt.
Maybe it makes technical debt easier to create.
Another commenter pushed back on the old definition of vibe coding and argued that the real skill is orchestration.
That argument is compelling because software engineering has always been partly about abstraction.
We stopped writing machine instructions by hand.
We stopped reimplementing everything from scratch.
We created frameworks.
We created libraries.
We created compilers.
Nobody concluded that software engineering had disappeared.
So why should the ability to describe software to a model be fundamentally different?
Maybe it isn't.
Maybe we're just adding another abstraction layer.
But There's a Trap
Abstraction is powerful.
Abstraction also hides things.
That's the entire point.
You don't need to understand how malloc works every time you create an array.
You don't need to understand a CPU pipeline to write a React component.
But when the abstraction breaks, someone needs to know what's underneath it.
That's why I think the future developer profile becomes strangely asymmetric.
You might write 20% of the code yourself.
But you may need to understand 80% of what the system is doing.
That sounds backwards.
It isn't.
It's what abstraction has always done.
The Most Valuable Programmer Might Become the Person Who Deletes the Most AI Code
This is the part nobody likes talking about.
Generation is seductive.
Deletion is not.
AI makes it incredibly easy to say:
“Let's add one more thing.”
One more feature.
One more helper.
One more abstraction.
One more dependency.
One more component.
One more agent.
Until the project becomes a pile of things that individually made sense and collectively don't.
The ability to say:
“No. We don't need this.”
might become more valuable than the ability to generate it.
The best engineer in an AI-heavy team may not be the person who produces the most code.
It may be the person who knows which 40% should never have existed.
So Was Vibe Coding Right?
Yes.
And no.
Vibe coding was right about one enormous thing:
A surprisingly small amount of traditional programming work actually requires humans to manually type every line.
But its critics were right about another:
Removing typing does not remove responsibility.
AI can collapse the distance between an idea and a prototype.
That's incredible.
It can also collapse the distance between an idea and a production incident.
That's considerably less incredible.
The technology isn't the contradiction.
Our definition of “done” is.
Maybe This Is What Software Engineering Has Been Becoming All Along
This is the historical part that I keep coming back to.
Programming has spent decades moving upward:
Machine code
↓
Assembly
↓
C
↓
C++
↓
Python / Java / JavaScript
↓
Frameworks
↓
Libraries
↓
Declarative systems
↓
Natural language
Every step removes some amount of direct control.
And every step creates a new question:
How much do you need to understand about the layer below you?
Maybe AI isn't the death of programming.
Maybe it's simply the point where that question becomes impossible to avoid.
The Weird Future
I don't think the future belongs to people who refuse AI.
I also don't think it belongs to people who blindly trust it.
It probably belongs to the people who can move between both worlds.
They can think in systems.
They can specify precisely.
They can delegate.
They can inspect.
They can debug.
They can recognize when the model is confidently wrong.
They can throw away generated work without feeling emotionally attached to it.
And when necessary, they can still open the code and understand what is actually happening.
That's a very different skill from memorizing syntax.
But it's still engineering.
One Last Thought
Maybe we're asking the wrong question because we're still obsessed with the old definition of a programmer.
We keep looking at the screen and asking:
“Who wrote this code?”
Maybe the more important question is:
“Who understands this system well enough to be responsible for it?”
Because one day, AI may genuinely write 95% of the implementation.
That part is plausible.
What is much harder to automate is judgment.
Knowing what should exist.
Knowing what shouldn't.
Knowing which assumptions are dangerous.
Knowing when the tests are lying by omission.
Knowing when the architecture is drifting.
Knowing when the fastest solution today is the slowest solution next year.
And knowing when to tell the machine:
“No. Delete it. We don't need this.”
That's the part I don't think vibe coding has replaced.
Maybe it was never supposed to.
Sources & Further Reading
Andrej Karpathy — “vibe coding”
Karpathy's original February 2025 description of the practice and its deliberately hands-off workflow.
Simon Willison — “Will the future of software development run on vibes?”
A useful distinction between true vibe coding and AI-assisted software development where the developer still reviews and understands the result.
METR — AI and experienced open-source developer productivity
A randomized study that found experienced developers in the studied repositories took longer with AI assistance.
Management Science — Generative AI and software developers
Large-scale field experiments involving 4,867 developers found meaningful productivity gains from AI coding assistance.
METR — SWE-bench and human merge decisions
Evidence that passing automated software-engineering benchmarks is not equivalent to a maintainer deciding that a patch belongs in a real codebase.
SU S VI B E S benchmark
Research showing a major gap between functional correctness and security in agent-generated software.
DEV Community — “Vibe Coding Isn't the Problem. Calling It Engineering Is”
The article that triggered the discussion behind this piece, including the distinction between vibe coding, AI-assisted programming, and engineering accountability.
My own projects:
Arcane Dice — 3D physics dice roller with an AI dungeon-master layer.
More of my work — experiments spanning AI, web development, games, automation, and tooling.
Top comments (0)