Ten years ago, the pitch was that Visual Basic would let anyone build software. Today, the pitch is that Copilot and Cursor will do the same. The pattern is identical, and the outcome will be too.
A recent essay by software engineer Rob Englander makes a sharp argument that cuts against the prevailing narrative around AI coding assistants: these tools haven't simplified software engineering. They've just made it faster to produce code, which is not the same thing.
Writing Code Was Never the Hard Part
The core misconception Englander targets is that code generation is the bottleneck in professional software development. It isn't. The difficult work is architectural: deciding how components interact, maintaining consistency between what a system is supposed to do and what it actually does, and keeping a growing codebase comprehensible to the humans who maintain it.
AI coding assistants are genuinely good at producing implementation drafts, exploring design alternatives, and summarizing complex systems. Nobody serious disputes that. But those capabilities address maybe 20% of what makes software engineering hard. The other 80% - the part where you need to understand why a system behaves a certain way, not just what it does - remains stubbornly human.
Englander draws an analogy to aircraft maintenance. Modern planes have millions of parts and sophisticated diagnostic tools, but nobody argues those tools eliminate the need for trained mechanics. The tools make experts more effective. They don't replace expertise.
Spec Drift Gets Worse at Speed
The most useful concept in the piece is "spec drift" - the growing gap between how a system is documented, how it's tested, and how it actually behaves in production. Every engineering team fights this problem.
AI coding tools make spec drift worse, not better. When you can generate hundreds of lines of code in seconds, changes outpace the team's ability to update specifications, write meaningful tests, and verify that the new code actually fits the existing architecture. Speed without discipline produces technical debt faster than any junior developer ever could.
This matches what I've seen firsthand. Teams using AI assistants aggressively often ship faster in the first few months, then hit a wall when the accumulated drift makes every change unpredictable. The code works individually but doesn't cohere as a system.
The Hobbyist vs. Professional Gap
Englander makes a distinction that often gets lost in the AI coding hype: the difference between hobbyist projects and professional software. For personal projects, experiments, and prototypes, AI code generation is fantastic. You can explore ideas quickly without worrying about long-term maintenance.
Professional software is different. Customers expect correct behavior. Systems need to run reliably for years. Multiple engineers need to understand and modify the same codebase. None of those requirements get easier because an LLM wrote the initial implementation faster.
The practical takeaway isn't to stop using AI coding tools. They're genuinely useful, and ignoring them would be foolish. The takeaway is to stop pretending they change what software engineering fundamentally requires. Use Copilot, Cursor, or Claude Code to move faster through the mechanical parts. But don't confuse typing speed with engineering skill, and don't let the velocity trick you into skipping the discipline that keeps systems working.