Acai.sh introduces feature.yaml and numbered ACIDs (Acceptance Criteria IDs) to make spec-driven development tractable for AI-assisted codebases.
Key Takeaways
feature.yaml replaces freeform markdown specs with a numbered requirement list; each requirement gets an ACID tag referenced directly in code and tests.
The acai CLI (npm or GitHub release) pushes specs and code refs to a hosted dashboard for requirement-level PR review instead of file-by-file diffs.
The dashboard tracks per-requirement states: Completed, Accepted, Rejected, with comment threads for human collaboration.
Author’s core thesis: the spec exists whether you write it down or not; formalizing acceptance criteria is the highest-ROI investment as AI generates code faster than humans can read it.
Projected progression: Specsmaxxing -> Testmaxxing -> reactive software factories where LLMs respond autonomously to red tests against well-defined specs.
Hacker News Comment Review
Skeptics note the approach may recreate V-Model/60s-70s spec formalism under a new name; the YAML-over-markdown choice draws sarcasm about inevitable Jinja templating complexity.
Practical pushback: time spent writing structured specs can exceed time saved, and the coupling of ACID tags to code means spec refactors require code refactors.
Commenters with broader AI-workflow experience (bmad, speckit) see feature.yaml as meaningfully lower-ceremony than existing spec-driven tools that bloat context windows.
Notable Comments
@beshrkayali: frames specsmaxxing as the necessary response to AI-generated code lacking institutional memory – specs become durable authorial intent by default.
@wesselbindt: asks why builders are not simply writing executable specs instead.
