There’s a growing chorus of voices warning about AI-assisted “vibe coding”—the idea that letting AI help write code creates a false sense of competence. Critics argue that AI-generated code might look impressive at first glance, but it lacks the deep understanding that comes from learning the fundamentals. Their prescription: forget the shortcuts, go back to basics.

I get the instinct. Experienced developers have seen countless projects that looked good in demos but fell apart under real traffic. When you’ve cleaned up that many messes, you develop a healthy skepticism of shortcuts.

But I see it differently.

The Pattern

When John Backus introduced FORTRAN in 1957, assembly programmers resisted fiercely. They saw themselves as guardians of arcane knowledge—skills too complex for ordinary mortals. Compiled code could never match hand-tuned assembly, they argued.

Grace Hopper faced the same resistance when she created one of the first compilers in 1952: “I had a running compiler and nobody would touch it. They carefully told me computers could only do arithmetic.”

The satirical 1983 essay “Real Programmers Don’t Use Pascal” captured the mentality: “Real Programmers write in FORTRAN. Quiche Eaters use PASCAL.” Edsger Dijkstra called BASIC developers “mentally mutilated beyond hope of regeneration.” JavaScript was “just a toy.” PHP was hacky. Front-end developers weren’t “real engineers.”

Yet JavaScript now powers 97% of websites. PHP runs 77.5% of server-side web applications. The “toys” won.

Every abstraction layer gets dismissed by practitioners of the previous layer. And the gatekeepers are usually wrong.

The Uncomfortable Truth

The foundations of the modern web were built by people who openly admit they didn’t know what they were doing.

Rasmus Lerdorf created PHP without formal language design training: “I have absolutely no idea how to write a programming language, I just kept adding the next logical step.” Brendan Eich built JavaScript in 10 days under deadline pressure. Twitter’s early architecture was so fragile it spawned the Fail Whale meme.

This isn’t a gotcha. It’s the point. These tools succeeded because someone built something useful, shipped it, then learned and refined along the way. The GitHub founders were college dropouts. Shopify’s founder left school after 10th grade. Stardew Valley’s creator was a theater usher who learned about arrays from Wikipedia.

The data backs this up: 69% of developers are at least partly self-taught. 48% never got a CS degree. Google’s Project Oxygen found that technical expertise ranked last among the behaviors of effective engineering managers.

Where the “Unearned Code” Argument Breaks Down

The criticism often frames AI assistance like a shortcut drug—access to capabilities you haven’t “earned.” High-level tools are instruments. Compilers, frameworks, libraries, IDEs—all let developers accomplish things without understanding every layer beneath. A React developer doesn’t need to understand the browser’s rendering pipeline. A WordPress theme developer doesn’t need to understand PHP memory management. The competence is in using the tool effectively and taking responsibility for the output.

The “unearned” framing assumes there’s a fixed body of knowledge that constitutes “real” programming at some specific abstraction level. But which level? The goalposts move every generation.

What Actually Matters

The legitimate concern isn’t about AI specifically. It’s about skipping good practices: code review, testing, understanding what you’re shipping. That’s fair. But it applies regardless of who or what wrote the initial code.

GitHub’s 2024 study of 202 developers found AI-assisted code had a 53% greater likelihood of passing all unit tests and higher approval rates in blind code review. Human code averages 15-50 bugs per 1,000 lines. Technical debt was coined in 1992, decades before AI. The causes—rushing, skill gaps, poor documentation—are human problems.

Code should be judged on its merits. Does it work? Is it maintainable? Does it solve a real problem?

The WordPress Paradox

Here’s what I keep coming back to: WordPress’s founding philosophy was that anyone should be able to publish online, regardless of technical background. The platform has 60,000+ plugins, most built by designers, marketers, and business owners who needed functionality and figured it out. Some are rough. Many are excellent. The ecosystem thrives because WordPress lowered barriers.

That philosophy—democratizing publishing—succeeded beyond anyone’s expectations. WordPress didn’t create worse websites by making things easier. It created more websites, built by people who understood their content better than any developer-for-hire could.

AI coding tools extend this same idea to software development. A teacher can build a tool tailored to their classroom. A small business owner can prototype a solution to their inventory problems.

Some of what they build will be rough. Some will need professional help to scale. But the same was true of early WordPress sites—and the ecosystem developed themes, plugins, and best practices that raised the floor for everyone.

Different Vantage Points

If you’re responsible for platforms at massive scale, “back to basics” makes sense. Stability matters. Fundamentals matter.

But I’m watching people who could never build software before suddenly solving their own problems. I’m seeing people skip the months-long wait for developer time and start iterating immediately. That feels like the same energy that made WordPress matter in the first place.

If you don’t know assembly, can you write JavaScript? Obviously. If you don’t know JavaScript, can you build something useful with AI? The evidence says yes.

The real question isn’t whether someone “earned” their code. It’s whether the code works and solves a real problem. That’s what WordPress got right about publishing. I think AI tools can get it right about development.

We’ll see who history sides with. But the gatekeepers have been wrong before.