[horizion2025]

Hard to say exactly what went wrong from outside, but a frontier model not being able to implement a simple CRUD feature after 3x8 = 24 hours of work isn't "it can't do this". Let me hazard a guess from what you wrote. The 3-tier spec (design → specs → build details) may be the cause rather than the cure. A big upfront spec has two failure modes the model can't help you with: it can quietly contain contradictions, and it can be ambiguous in ways the model resolves by guessing instead of asking. "Adding clients" is a good example of the trap, even assuming your real spec was more detailed than the comment. "Client" is overloaded — a customer in the domain? An API client? A consumer of a service? And "A clear design requirement was essentially adding clients" is very imprecise: does the model add them, or build a UI so the end user can add them? I know this was just your comment and sorry to sound harsh but if the spec had sentences like that I can definitely see it going off the rails.

Your own conclusion, smaller, concrete units, is the right direction. Except by units I don't mean partitioing the program into smaller units (files, modules). In fact, you should stop thinking about implementation at all. I'm thinking more about the way of asking the LLM to build it. One feature at a time etc. so you can tighten the feedback loop. Then you can early on (in the first hour say): "I also need a way that the user can add/manage clients - basic CRUD" and that small sentence might be enough the model makes it all (UI, API, backend etc.) to enable that and put it in a proper place in the app. A big ambiguous spec defers that discovery to the worst possible moment.

[Capricorn2481]

> And "A clear design requirement was essentially adding clients" is very imprecise

That's not a sentence they literally gave the agent. This is their full quote.

> A clear design requirement was essentially adding clients, explained clearly and comprehensively.

Why are you assuming they described this so ambiguously?