The Problem Is on the Requirements Side
The author's core observation comes from extensive hands-on work: when a developer vaguely says "implement this feature for me," the model can only guess the intent and produces code that looks reasonable but is riddled with holes; whereas when the developer first clearly defines the acceptance criteria—inputs and outputs, boundary conditions, error handling, performance requirements—the quality of the model's output shoots up. This isn't actually new—vague requirements causing rework is an ancient truth of software engineering, and AI merely amplifies it: it executes so fast and smoothly that vague requirements get rapidly made concrete in the wrong direction.
Treat the Spec as a First-Class Citizen
This article converges by a different road with a recent batch of high-quality workflow accounts—productive users are all doing the same thing: writing the acceptance criteria clearly before starting, so the model aims at an explicit target. This quietly changes the developer's core skill too: from "able to write implementations" to "able to define problems." Stating clearly what you actually want has become a scarcer ability than typing code in the AI era. The lesson for teams is just as solid: rather than complaining the model writes badly, check whether your own requirements can withstand an executor that won't fill in the blanks and only does exactly as told. Teams that write good acceptance criteria reap a far larger AI dividend.
via: Hacker News