When an AI project fails, usually the AI gets the blame. Some say wrong model or bad prompts. It makes it easy to think you just need to wait for the next release to solve all your problems.
That is almost never what happened. If you go back through the wreckage you will find the same things that sank software projects thirty years ago. Nobody agreed on what the project was supposed to do. The data meant something different than everyone assumed. The solution worked in the demo and nowhere else. Or even, nobody wanted to use it in the first place.
Essence and accident
Forty years ago, Fred Brooks split software difficulty into two kinds. Accident is the work of building the thing: the typing, the syntax, and the plumbing. Essence is the work of deciding what the thing should be: which problem, for whom, under what rules, and how you know when it is right.
Better tools attack accident while essence stays where it is. That is what puts a ceiling on any single advance. How high that ceiling sits depends on how much of your work was accident in the first place, which is why the same tool can transform one team and barely move another.
AI is the largest reduction in accident we have ever had. Code that took a week now takes an hour. Analysis that took a team now takes a morning. That is real and it is enormous.
The part that did not get cheaper
None of it tells you what to build.
AI does not tell you which decision the system is supposed to improve. It does not tell you that the field labeled “close date” means three different things in three regions. It does not tell you that the workflow you just automated is the one the team already works around. It does not tell you what “correct” means clearly enough to test for it.
That work is unglamorous. Requirements. Data quality. Scope. Testing. Adoption. It is also the work that decides whether the system survives contact with the business.
New architecture, old discipline
This is not an argument for doing things the old way. Agents should be designed around what the technology can do, not around what a person would do. That still holds. The shape of the system should be new.
But the discipline that decides what a system is for, and whether it works, has no new version. There is no AI-native substitute for knowing your own business.
Brooks was describing a field that has changed almost beyond recognition since, but the distinction held anyway. The teams getting the most out of AI are not the ones with the best model. They are the ones still doing the boring parts right.
Reference: Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19.