Paul Ford is right that AI makes it too easy to do a job badly

The surge in "AI-powered" software isn't creating a gold rush of killer apps; it's creating a graveyard of mediocre code. When everyone can generate a working prototype in ten minutes using Claude 3.5 Sonnet or GPT-4o, the barrier to entry vanishes, but the barrier to quality remains exactly where it always was. We've hit a point where the ability to generate syntax is decoupled from the ability to architect a system, and that's where most of these new projects are falling apart.

Why "everyone can code" is a trap

I've seen this play out in my own workflow. When you use an LLM to scaffold a project, you get a version that looks functional on the surface. But because the AI doesn't "care" about technical debt or long-term maintainability, it often introduces subtle architectural flaws. You might get a Python script that runs perfectly for a single test case, but the moment you scale it or hit an edge case, the whole thing collapses because the person prompting it didn't actually understand the underlying data structure.

The danger is the "illusion of competence." If you can't debug a TypeError or a NullPointerException without asking the AI for the answer, you aren't actually coding; you're just managing a black box. I've spent hours debugging "hallucinated" library methods that looked perfectly plausible in the generated code but didn't actually exist in the version of the SDK I was using. That's the "doing someone else's job badly" part—you're skipping the struggle of learning, which is exactly where the actual engineering skill is built.

The gap between a prototype and a product

There is a massive difference between a demo that works on a local machine and software that survives a production environment. AI is incredible at the former and often blind to the latter. Real software requires thinking about state management, race conditions, and API rate limits—things that often require human collaboration and a deep understanding of the specific business domain.

If you're using these tools, here is where I've found the breaking points:

• Dependency Hell: AI loves to suggest outdated packages or mix versions. I recently had a project where it kept suggesting a deprecated method from a 2023 version of a library, leading to a ModuleNotFoundError that took me twenty minutes to realize was just a version mismatch.
• The Refactor Loop: You ask the AI to add a feature, it rewrites the whole file, and suddenly three other things that were working are broken. Without a rigorous test suite (which most "AI coders" don't write), you're just playing a game of whack-a-mole.
• Architectural Decay: LLMs are great at functions, but terrible at systems. They can write a great get_user_data() function, but they can't tell you if your entire database schema is fundamentally flawed for the way your app needs to scale.

When to actually trust the output

The irony is that AI is a force multiplier for people who already know how to code, but a mask for those who don't. If you understand the logic, you can use an LLM to handle the boilerplate and speed up your velocity. If you don't, you're just building a house of cards. The "killer apps" we were promised aren't arriving because they require a level of polish and intentionality that can't be prompted into existence. You still need a human to decide why a feature exists and how it should feel to the user, not just that the code compiles.