There’s a version of the AI coding conversation where everyone who raises a concern is dismissed as a dinosaur. It’s a bad version, and it costs people real money.
The critics — Linus Torvalds among the louder ones — are making arguments worth engaging with. Some are right. Some are overstated. Knowing which is which is more useful than picking a side.
This is a companion to what vibe coding is and how to do it well.
Criticism 1: “You’re shipping code nobody understands”
This is correct, and it’s the strongest objection.
Software is read far more often than it’s written. Every bug fix, every feature, every security patch starts with someone understanding the existing code. If nobody ever understood it, that work becomes archaeology.
The failure isn’t at build time — it’s six months later, when something breaks and the person responsible has no mental model of how any of it fits together. Every fix is a guess. Every guess risks breaking something else.
What it means practically: the cost of vibe coding isn’t paid upfront. It’s paid at the first serious bug. That’s a real trade, and it’s fine to make it deliberately — for a prototype, a throwaway tool, an experiment. It’s not fine to make it accidentally on something you’ll depend on.
Criticism 2: “It produces insecure code”
Also correct, and under-appreciated.
The specific problem is that security flaws are invisible from the outside. An app with no authorization checks works perfectly. Exposed API keys don’t cause errors. Missing rate limits look exactly like working endpoints — until the bill arrives.
AI tools optimise for code that runs. Nothing in that objective function rewards a permission check that prevents an action the happy path never attempts.
What it means practically: this is a real risk with a known mitigation. The flaws these tools produce are consistent and checkable — we list them in vibe coding security. The criticism isn’t a reason to avoid the tools. It’s a reason to never ship without a security pass.
Criticism 3: “Beginners won’t learn to code”
Correct, with an important caveat.
Struggling with a bug is not wasted time. It’s the mechanism by which you build a model of how programs behave. Skip enough of that struggle and you end up able to produce software but unable to evaluate it — which is a genuinely bad place to be, because evaluation is the part that’s still scarce.
The caveat: this depends entirely on how you use the tools. A beginner who reads every diff, asks why a change was made, and tries to predict what the AI will do before it does it is learning faster than someone working through a textbook alone. A beginner who accepts everything without looking is not learning at all.
Same tool. Opposite outcomes. We wrote about the specific habits that separate them in common mistakes when learning to code with AI.
Criticism 4: “It’s slop”
Overstated.
The claim is that AI-generated code is uniformly low quality. It isn’t. For conventional problems it’s often perfectly reasonable — idiomatic, readable, roughly what a competent developer would write.
Where it genuinely degrades is at the edges: unusual requirements, novel algorithms, anything under-represented in public code. There it produces something that looks right and isn’t, which is worse than obviously bad code because it survives review.
What it means practically: quality tracks how conventional the problem is. Judge output by how well-trodden the territory is, not by a blanket assumption either way.
Criticism 5: “You’re building on a foundation you don’t control”
Correct, and rarely discussed.
Pricing changes. Models get deprecated. Rate limits tighten. If your development process depends on a specific tool at a specific price, you’ve taken on a dependency you can’t negotiate with.
What it means practically: prefer tools that give you the code. A Lovable project you can sync to GitHub is fundamentally safer than one locked inside a platform. This is a real reason to weight portability heavily when choosing.
What the Critics Get Wrong
“Real programmers don’t use AI.” They do, extensively. The most productive developers are frequently the heaviest users of these tools. The distinction they maintain is between AI writing code and AI deciding code — they review everything.
“It’ll never handle real complexity.” It already handles a great deal. The trajectory here has been steep and consistent, and predictions about permanent ceilings have aged badly.
“It’s just autocomplete.” This was true and stopped being true. Terminal agents that explore a codebase, run tests, read failures, and iterate are doing something categorically different from completing a line.
The Synthesis
Almost every serious criticism reduces to one thing: shipping code no human evaluated.
Not AI writing code — that’s fine, and it’s not going away. The problem is the absence of a review step. Every objection above is really a specific consequence of that absence.
Which makes the resolution unglamorous but clear. Use these tools heavily. Read what they produce. Read carefully at the boundaries that matter — auth, payments, anything holding other people’s data. Accept that a prototype you never review is a prototype and treat it accordingly.
The critics aren’t arguing you should type everything by hand. They’re arguing that someone should understand what shipped. That’s been true for as long as software has existed, and it’s the part that didn’t change.
Related reading:
