In one eight-hour session, we went from zero to a complete product roadmap with 81 tracked issues, a zero-trust security model, a self-hoisting compiler test, and a public project board — all driven by a structured expert panel methodology running inside an AI agent.
This post is the post-session retrospective, written after
git finish-session pushed the atomic commit to main.
The session was framed around a question: can we use the same spec-driven development pipeline a0 provides to design a0 itself?
The answer was yes, and the vehicle was the Enterprise Stakeholder Review Panel — a five-expert panel (SeniorSoftwareEngineer, SeniorSoftwareEngineerUser, EngineeringManager, ProductManager, CorporateExecutive) that evaluates the codebase, identifies feature gaps, and decomposes work into atomic, parallelizable implementation units.
The panel's output is structured issues on GitHub, organized by release phase, with acceptance criteria, implementation plans, and test requirements — the same format a0's spec pipeline uses to generate code. The system is self-hosting by design: a0 reads its own roadmap to generate its own implementation.
| Metric | Value |
|---|---|
| Session duration | 8 hours prompter time |
| Equivalent SME time | 120-160 hours |
| AI multiplier | 15-20x |
| Issues created | 81 |
| Release phases | 3 (Open Source, Cloud Beta, Enterprise) |
| Expert panels | 2 (Enterprise Stakeholder, System Design Review) |
| Audit findings | 43 mapped to 21 blocker issues |
| Tests passed | 27/27 (100%) |
The session produced a four-tier daemon architecture that didn't exist when we started:
Cloud Service ──→ d3 ──→ c2 ──→ b1 ──→ a0
(auth only) (team) (host) (proj) (agent)
The cloud service is deliberately zero-opex — it handles only authentication and routing. All agent execution, telemetry, and data storage run on customer infrastructure. Every operation is cryptographically signed through a JWT chain (issue #81) that passes user identity from SAML/SSO all the way down to individual a0 tool calls.
The agent starts with zero autonomous capability (issue #77). Every bash command, Docker execution, file write, and external API call requires explicit user authorization via a c2 dashboard pop-up. This is the opposite of most AI coding tools, which assume full filesystem access by default.
The most interesting development was the ontogeny test (issue #42) — a self-hoisting specification compiler. The agent reads its own technical specification files, generates C++ implementation code, compiles it, runs the E2E test suite against the generated binary, and iterates until the generated binary passes all tests.
This is the software equivalent of a self-hosting compiler (GCC compiling itself). If the spec tree is complete enough that a0 can generate itself from it, we have definitive proof that the spec-driven pipeline is working. The test was decomposed into 12 atomic sub-issues (#43-#54) that can be implemented in parallel.
The session used a two-phase execution process:
Phase 1 — Feature Review (Enterprise Stakeholder Panel):
Phase 2 — Audit Reconciliation (System Design Review Panel):
Both panels produce structured GitHub issues, not code. The actual implementation happens in follow-up sessions using the handoff process we defined.
The most striking metric from the session evaluation:
Prompter time: 8 hours (reading, thinking, writing) Equivalent SME time: 120-160 hours Multiplier: 15-20x
The AI multiplier was highest in precisely the areas where traditional coding tools provide the least value: product strategy, security architecture, compliance planning, and multi-stakeholder tradeoff analysis. The panel methodology turns a single product manager's intuition into structured, auditable, multi-perspective analysis.
This is the opposite of the usual AI coding narrative. The focus wasn't on generating code faster — it was on compressing the strategic decision-making cycle that precedes and directs all code.
The handoff documents in
handoffs/2026-06-01-enterprise-panel-roadmap/ define the
execution process for the next session: load context, enumerate issues,
run panels, decompose, create sub-issues, implement. The process is
self-similar — it applies at every level of granularity, from product
roadmap down to individual method implementation.
The delivery timeline:
All 81 issues are tracked publicly at github.com/orgs/opensassi/projects/1.