AI Can Write Code — So Why Do Software Projects Keep Failing?

When Everyone Can Code, the Real Problems Emerge

Software developer Paul Ford, writing in a New York Times opinion piece, put into words a truth the industry is slowly coming to terms with: AI can write pretty decent code — but it also makes it remarkably easy to do someone else's job badly. Behind that observation lies the most overlooked contradiction of today's AI-powered coding boom.

Ford admits there was a period when it seemed like software developers like him were destined for obsolescence — how could humans compete against tireless machines? But as practice has deepened, the industry has gradually recognized that building truly cutting-edge software still requires human beings to think together, collaborate, maximize each other's skill sets, and hone their individual craft.

His sharpest line: "Now that everyone can write code, it's clearer than ever why many people shouldn't." This isn't elitist gatekeeping — it's a recalibration of what software engineering is actually about.

AI Lowers the Bar, But Amplifies Mediocrity

The biggest selling point of AI coding tools is that they've brought the barrier to writing code to an all-time low. Anyone can describe what they want and receive working code in return. But Ford's crucial insight is this: being able to write code and being able to execute a software project well are two entirely different things.

Code is just the surface layer of software engineering. What actually determines whether a project succeeds or fails is architectural design, understanding requirements, handling edge cases, team collaboration, and judgment about long-term maintainability. These are precisely the areas where today's generative AI cannot yet operate independently. When someone without engineering judgment uses AI to "ship fast," they're often rapidly accumulating technical debt — the project looks like it's moving quickly, but the seeds of failure are already being planted.

This also explains why Ford observes that "so many projects fail." AI hasn't made mediocre work disappear — it's made mediocre work easier to produce at scale.

---

Technical Debt is a foundational concept in software engineering, introduced by Ward Cunningham in 1992. It uses financial borrowing as a metaphor: choosing a quick-and-dirty solution to ship faster is like taking out a loan against the future — you'll pay it back later, with interest, in the form of extra time spent fixing, refactoring, and maintaining the system. Technical debt isn't inherently bad; a deliberate short-term trade-off can be a sound business decision. But when it accumulates unconsciously and without a plan, it can quietly crush a project: the codebase becomes harder to change, the cost of adding new features grows exponentially, and eventually the system may need to be torn down and rebuilt entirely. AI-assisted coding carries a particular risk along this dimension — generated code may run on the surface while hiding serious problems in its architecture, naming conventions, and boundary handling. Developers without engineering experience often can't spot these issues early enough to address them.

---

From Deep Blue to Large Language Models: A Familiar Story

The article carries the tag "deep-blue" — a detail worth noting. Deep Blue, the chess computer that defeated Kasparov in 1997, triggered a wave of anxiety about machines replacing humans. Decades later, professional chess players haven't disappeared. Instead, they've evolved alongside AI, developing entirely new ways to play.

The relationship between generative AI and software development is replaying a similar script. A technology being able to complete a specific task — writing code, playing chess — does not mean it can replace the full professional role built around that task. The value of a profession often lies in everything that can't be reduced to a single task: judgment, collaboration, taste, and accountability.

Ford's perspective fits squarely in this tradition: AI is a powerful tool, but tools need skilled hands to produce genuinely valuable results.

---

Deep Blue was a chess-playing computer developed by IBM. In 1997, it defeated reigning world champion Garry Kasparov with a final score of 3.5 to 2.5, becoming the first computer to beat a top-ranked human player under standard tournament conditions. The event sparked widespread debate about whether machines would eventually replace human intellectual labor. What actually happened, however, was surprising: professional players didn't vanish. Instead, a new form emerged — Advanced Chess, also known as Centaur Chess — in which humans use computer assistance to analyze positions, often producing play that surpasses either pure human or pure computer performance. This historical precedent offers an important lens for understanding AI's relationship with professional work: when technology breaks through the boundary of a specific capability, it typically reshapes the professional ecosystem rather than eliminating it, and tends to give rise to new models of human-machine collaboration. The breakthrough of large language models in code generation is structurally similar to Deep Blue's breakthrough in chess — both involve surpassing humans on a "quantifiable, discrete task," while neither can replicate the more complex systems of judgment and responsibility that underlie the broader profession.

---

What This Means for Developers

Ford's commentary offers a few practical takeaways for developers and teams working today:

• AI is an amplifier, not a replacement. It amplifies whatever capability the user brings to it, for better or worse. Experienced engineers use AI to multiply their output; people without sound judgment use AI to accelerate their mistakes.
• Engineering judgment is becoming more valuable. As writing code itself gets cheaper, the ability to judge what to write, what not to write, and how to organize it becomes rarer and more precious.
• Collaboration and craft remain irreplaceable. Ford specifically emphasizes "humans thinking and collaborating together" — the best software is built on integrated team intelligence, not raw code output speed from a single point.

In other words, AI hasn't ended software development as a profession. It has simply redrawn the boundaries of where that profession's value lies — shifting the center of gravity from "can you produce it" to "is it worth building this way, and can you do it well."

Conclusion: Lower Barriers, Higher Standards

Paul Ford's brief commentary resonated because it punctures a layer of hype beneath the "AI can do everything" narrative. AI making programming accessible to everyone is a genuine and remarkable achievement. But it also makes something else visible: doing software well was never just about writing code.

For practitioners who want to keep creating real value in the age of AI, the answer probably isn't racing against AI to see who can write faster. It's becoming the person who knows what's worth building in the first place.