You describe a feature, an AI agent writes a working implementation in minutes, and then you open it and realize it’s not quite what you meant. The filter behaves strangely. An edge case you assumed was obvious wasn’t captured. The totals are technically correct but conceptually wrong.
The machine didn’t fail. You encountered the gap between describing an outcome and understanding a problem.
Why specifications suddenly matter more
When writing code yourself took hours, vagueness was expensive. You were forced to think before you typed. AI flips that calculus: you can now generate the wrong thing in minutes just as easily as the right thing.
The argument for spec-driven development is shifting from best practice to economic necessity. When code is cheap, the scarce resource becomes clearly expressed intent. The catch is that most people are good at recognizing something when they see it, not at describing it before it exists.
What happens when the customer has two addresses? What happens when the payment fails halfway through? What happens when the same record already exists? These are the questions a specification has to answer before an agent starts building. Human communication assumes shared context. Software doesn’t.

More code, less confidence
An AI agent can produce thousands of lines across a repository while you watch. Some of it will be excellent. Some will be unnecessary. Some will work for reasons you don’t fully understand. And someone has to maintain all of it.
AI makes the first version of a system feel cheap. It doesn’t make the fifth year of maintaining that system cheap. If everyone can generate software quickly, the differentiator becomes knowing which software should never have been generated in the first place. The easiest feature to build is often the feature you should never have built.
The stopping problem
Software has always had a tendency toward overengineering. AI gives that tendency a jet engine. The machine will happily produce another version, and another, and another. It never says this is probably enough. The person has to provide that judgment. Knowing when something is sufficiently good for the actual user, not perfect, not theoretically optimal, may be one of the most valuable skills in an AI-assisted workflow.
What this means for developers
The article argues that the valuable developer profile is shifting. Less emphasis on raw implementation speed, more on the questions asked before work begins. Can you spot an architectural mistake before it’s expensive? Do you understand the user’s actual problem rather than just the stated feature request? Do you know which trade-off will quietly become a disaster six months later?
The skill moves upward: less “How do I make this?” and more “Should we make this at all?”

