What happens when generating code becomes so fast it's essentially free? The bottleneck shifts upstream - to the spec.
That's the central argument in a widely-discussed post from the team at Acai.sh, and it's one of the more honest assessments of where AI-assisted coding workflows actually break down. The author frames the problem as "AI psychosis" - that familiar spiral where developers stop shipping and start obsessing over building the perfect meta-system to control their AI tools. The agent keeps saying "You're absolutely right!" and the developer keeps catching edge cases, and nothing ships.
The proposed cure is what they call "specsmaxxing": writing exhaustive, structured acceptance criteria before handing work to an agent, then holding the agent accountable to that spec throughout.
Acceptance Criteria IDs: The Specific Trick That Works
The practical core of the approach is a numbering system for requirements called Acceptance Criteria IDs (ACIDs). When a coding agent like Claude Code or Cursor spontaneously started referencing numbered requirements throughout the codebase it generated, the author had a realization: you can navigate a pull request by requirement number, track which requirements are satisfied by tests, and measure "acceptance coverage" - not just whether tests pass, but whether they're testing the right things.
The format they landed on is a feature.yaml file with one spec per feature. Requirements should be concrete and testable, focused on behavior and constraints, and stripped of visual design decisions (those come later). The stable numbering scheme is the key discipline: IDs should persist across revisions rather than getting reshuffled.
The toolkit is open-source under Apache 2.0, available via npm or GitHub releases. A free hosted dashboard built on Elixir and Postgres tracks implementation status across features and environments.
The Thought Experiment Worth Taking Seriously
The author poses a useful mental model: if software generation became instantaneous and cost-free, the only thing with real value would be the specification. "The spec is what you want the software to be." Right now that knowledge lives scattered across chat histories, Slack threads, and developers' heads. Writing it down in a structured, testable format is the work that survives.
This isn't a new idea - behavior-driven development (BDD) and acceptance test-driven development (ATDD) have pushed similar arguments for over a decade. What's different is the leverage. In 2015, writing detailed Gherkin specs and then writing the corresponding code was often more work than just writing the code. With agents doing the code generation, the spec becomes the cheap input and the code becomes the disposable output. That ratio change makes the methodology make sense for more people.
Acai.sh acknowledges competitors in this space - SpecKit, OpenSpec, Kiro, Traycer.ai - but positions its focus on tracking alignment between specs and implementations rather than AI-assisted spec generation.
The broader workflow the post describes runs: Specify → Ship (agent-assisted) → Review (dashboard) → Iterate. The author envisions this eventually extending to automated QA agents that respond to test failures without human intervention - what they call "reactive software factories."
For developers currently spending more time re-explaining requirements to agents than writing code, the YAML spec approach is worth trying. The discipline of writing one testable spec per feature before starting a session is low overhead and the kind of constraint that tends to pay for itself quickly.