ae (Artifact Engine) turns backend development into formal, machine-validated YAML specs — then hands AI agents bounded, reviewable tasks instead of an open-ended request. Every module is specified, validated, and approved before a single line of code is written.
kind: module_spec metadata: id: module:order-repository@v1 status: frozen spec: identity: name: order-repository layer: infrastructure responsibilities: primary: - Persist order entities to PostgreSQL forbidden: - Business logic or state machine rules public_contract: operations: - name: SaveOrder errors: [ERR_PERSISTENCE_FAILURE] - name: GetOrder errors: [ERR_ORDER_NOT_FOUND] completion_criteria: - SaveOrder/GetOrder implemented against PostgreSQL
Spec-first · machine-validated · local-first
ae turns every module into a machine-validated contract — allowed scope, forbidden scope, invariants, completion criteria. A contract that tight leaves a low-cost AI agent no room to hallucinate: it implements exactly what's written, and when it genuinely can't, it files a structured blockage report instead of inventing an API. The specs themselves? Also written by a cheap model — 40+ deterministic validation rules do the thinking.
* Measured across 70 bounded module implementations in 30+ dogfooding projects (May–June 2026), mostly qwen-class coding models; spec-stage numbers from ae's built-in token accounting on gpt-5.4-mini.
Spec first, code second. A module must be formally specified, validated, and frozen before any code is written.
One sentence about your service. ae ai breakdown turns it into a structured module breakdown.
ae ai specs writes project, architecture, and module specs — formal YAML with scope, invariants, contracts, and completion criteria.
Every file passes schema + semantic validation. Failing specs are auto-repaired in a bounded fix loop. You approve; the engine freezes.
ae hands a bounded execution contract to a low-cost coding agent. Scope is closed, invariants are checks, dependencies are inlined — nothing left to guess, nothing to hallucinate.
Scene 1 · notification service — three independent modules, fully parallel
Scene 2 · order service — the repo's integration-test fixture (testdata/integration/order-service); use-cases depends on both providers
AI agents hallucinate on open-ended requests because they don't know what they must not do. ae makes every boundary explicit — and machine-checkable. Measured result: 68 of 70 modules implemented clean by low-cost agents.
Every module moves through draft → in_review → approved → frozen → implementing → implemented. No implementation task exists until the spec is frozen, and freezing requires non-empty completion criteria. Every transition is an audited history event.
An implementation task is a closed world: allowed scope, forbidden scope, invariants turned into validation checks, dependency contracts inlined, completion criteria spelled out. The agent has nothing to guess — so a qwen-class model implements it as reliably as a frontier one. And when a task genuinely can't be done, the agent files a structured cross_module_blockage report naming the contract change it needs — it doesn't invent an API.
# implementation task — bounded execution contract allowed_scope: internal/deliverystatustracking/ forbidden_scope: other modules, public contracts, deps' internals invariants: INV-001 only email|sms channels reach providers validation_checks: derived from invariants + public operations completion_criteria: unit tests cover every public operation
Each AI call runs generate → extract YAML → validate → fix-prompt retry until the artifact passes. The validator enforces 40+ deterministic rules — unique operations, acyclic dependency graphs, invariant ownership, scope/forbidden overlap checks. The schema does the thinking, so neither the spec writer nor the implementer has to be expensive.
call AI → extract YAML → write file → ae validate PASS → done FAIL → build fix prompt (errors inlined) → retry repeat up to max_retries
The decomposition engine scores each module and rules DECOMPOSABLE, ATOMIC, or NOT_BENEFICIAL — then generates child stubs with lineage, and orders work in dependency-safe waves: providers before consumers.
When an implementation is blocked on another module's contract, ae implementation impact traverses the dependency graph and tells you exactly which modules need lifecycle actions, task regeneration, or a staleness check. Pure graph analysis — zero tokens.
Export self-contained implementation bundles — task, rendered prompt, frozen spec, dependency contracts, result template — and feed them to Claude Code, Codex, or any agent. Import the result report back for analysis and retry bundles.
All state is human-readable YAML on your filesystem, tracked in your repo. Bring any OpenAI-compatible endpoint: OpenRouter, Groq, OpenAI, or a local Ollama — per-profile, per-task-type.
ae logs every AI call and every implementation run — model, tokens, outcome. These are real averages from real dogfooding projects, not projections.
| Stage | Command | Avg tokens / run |
|---|---|---|
| Module breakdown | ae ai breakdown | 3,059 |
| 3 validated spec files | ae ai specs | 4,910 |
| Decomposition spec | ae ai decomp | 2,873 |
| Complete validated project specification | ~10,842 | |
| Metric | Measured |
|---|---|
| Avg tokens per implemented module | ~13,701 |
| Typical wall-clock per module | ~2 min |
| Hallucinated workarounds | 0 |
Implementation on low-cost agents. A bounded contract turns "write this module" from a frontier-agent job into a qwen-class job: ~13,701 tokens per module — about a cent at open-model pricing — with 68 of 70 modules landing clean. The 2 that couldn't proceed filed structured blockage reports naming the exact contract change they needed; none invented code around the gap.
Planning on flash models. Structured prompts with injected context replace meandering planning chats: ~10,842 tokens buys a full validated project spec — about $0.003 at $0.25 per million. An open-ended planning session routinely burns 10–50× that before anything is pinned down.
Prefer a frontier agent anyway? Fine — the contract is the same, and those tokens stop being wasted on re-deriving scope. But you'll rarely need to.
The playground runs the real ae pipeline on a flash-class model and shows you every validation rule it passes — and what the run cost. The same specs are what low-cost agents implement without hallucinating.
ae generates the specs and the bounded implementation tasks. Implementation runs through your preferred coding agent — ae can drive one directly (Claude Code, Codex, or any OpenAI-compatible endpoint) or export a portable bundle and import the result report afterward.
Any OpenAI-compatible endpoint, configured per profile: OpenRouter, OpenAI, Groq, local Ollama. A typical setup uses a flash-class model for specs and a stronger model (or a local agent CLI) for implementation.
No. ae is a local-first CLI — all artifacts are YAML files on your machine, and AI calls go directly from your machine to the endpoint you configure. This website's playground is the only hosted piece, and it only sees the demo descriptions you type into it.
Prompts are advisory; ae's rules are enforced. A prompt can ask a model to keep scope tight — ae rejects the artifact if scope overlaps, dependencies cycle, invariants lack owners, or completion criteria are missing, and auto-retries with the exact errors inlined. The boundary lives in the validator, not in the model's goodwill.
Because the task is a closed world. The agent receives the exact packages it may touch, everything it must not touch, invariants restated as validation checks, every dependency's public contract inlined, and explicit completion criteria. Hallucination thrives on gaps — and a frozen ae spec doesn't have any. When a task truly can't be done, the contract gives the agent an honest exit: a structured cross_module_blockage report instead of an invented API. In our measured runs: 68 of 70 modules implemented clean, 2 honest blockage reports, 0 hallucinated workarounds.
Registered users can run the spec-generation pipeline on a limited quota: describe a service, get the module breakdown and three validated YAML spec files, inspect the validation report, and download the result. Implementation-task generation is CLI-only.