Two weeks ago I launched Parthenon and told everyone an AI agent was bossing me around. What I never explained properly was the tool that actually built the thing.
That tool is easyspec — and it deserves its own post, because it's arguably the more interesting of the two.
Built on OpenSpec, pushed further
First, the honest credit: easyspec is based on OpenSpec. The spec format, the change lifecycle, and the agent-delegation model all trace back to their ideas — I didn't invent spec-driven development, I built on top of it. If OpenSpec resonates with you, you'll recognize the bones.
But I pushed it in a few directions that turned out to matter a lot:
1. An enriched spec that maps to source code. A spec that just says "build a dashboard" is a nice essay but useless context for an AI agent. easyspec specs include a source-code map — the files, modules, and entry points a change touches. That's context engineering: each agent loads exactly the right slice of the codebase instead of drowning in all of it.
2. A team of sub-agents, each owning one stage. One agent doing everything drifts. easyspec splits the lifecycle across seven specialized agents:
| Agent | Owns |
|---|---|
| Product Owner | the change proposal + acceptance criteria |
| UX Specialist | the interactive prototype |
| Architect | system + data-model design |
| Database Designer | the schema |
| Developer | implementation |
| Tester | tests + execution |
| Document Reviewer | "no implementation detail in docs" |
3. Inter-agent review and sign-off. No output is trusted on faith. Each stage is gated: the architect reviews the spec before design proceeds, the developer can't apply until architecture is signed off, and the master spec only moves when the tester passes the suite. es-master-review runs the full test suite and requires a clean status before update-master. No silent drift.
4. Prototype-first human-in-the-loop. The UX Specialist builds a clickable prototype before any code. A human approves the design when changes are cheap — instead of discovering the wrong thing after implementation.
Proof, not promises
easyspec isn't a toy. It built Parthenon — a self-hosted enterprise AI agent platform (AIOps) — feature by feature, through that exact pipeline.
220k+ lines of code. Built for under $100 in API costs.
The key screens, each one spec'd, prototyped, and shipped through propose → apply → update-master:
And the part that surprised me most: UI consistency. The UX agent prototyped every screen for a different feature, on a different day — yet they all share one design language:
That consistency isn't discipline — it's the master spec doing its job. One source of truth keeps a team of AI agents coherent across 220k lines.
One command to start
npx @myaider/easyspec init
Works with GitHub Copilot, OpenCode, and Claude Code. Interactive prompts, or flags for CI.
The recursion, still running
- I built easyspec to manage AI coding agents.
- easyspec built Parthenon.
- An AI agent now runs my marketing and shamed me into writing this.
A tool built a tool, and a machine is running the machine. I've stopped being surprised and started taking notes.
Try it
- 🛠️ easyspec: https://github.com/hurungang/easyspec
- ⭐ Parthenon (the 220k-line showcase): https://github.com/hurungang/parthenon
If you're using AI coding agents and fighting context drift or UI inconsistency, I want to hear about your setup. What keeps your agents on the rails?
Top comments (0)