Amazon launched Kiro with a clear thesis: the problem with AI coding tools is not that they write bad code — it is that they write code with no connection to your requirements. Kiro's answer is spec-driven development: you write a spec, the tooling generates from it, and the spec stays authoritative.
Kiro is a good idea. But it is also a proprietary IDE you have to install, sign in to, and trust with your codebase.
I built the same concept as a set of open-source CLI tools: one per ecosystem, published to the registry your team already uses. No IDE. No account. No network calls. A text file goes in, a working application comes out.
Try it right now — pick your stack
# NestJS / TypeScript
npm install -g archiet-microcodegen-nestjs
archiet-microcodegen-nestjs prd.md --out ./my-app
cd my-app && npm install && docker compose up
# Go Chi
go install github.com/aniekanasuquookono-web/archiet-microcodegen-go@latest
archiet-microcodegen-go prd.md --out ./my-app
cd my-app && make run
# Laravel (PHP)
composer global require archiet/microcodegen-laravel
archiet-microcodegen-laravel prd.md --out ./my-app
# Spring Boot (Java)
java -jar archiet-microcodegen-java.jar prd.md --out ./my-app
cd my-app && mvn spring-boot:run
# Tauri (Rust + desktop)
cargo install archiet-microcodegen-tauri
archiet-microcodegen-tauri prd.md --out ./my-app
Your app has full CRUD, JWT auth with httpOnly cookies, Postgres 16, and per-user data isolation — before you have finished reading this article.
What spec-driven development actually means
Spec-driven development is a 25-year-old idea from model-driven architecture (MDA): write a formal model of your system, then derive the implementation from it. The model is the source of truth. The code is an artefact of the model.
Kiro's insight (and mine) is that a plain text requirements file is a formal model — it just needs a parser that takes it seriously.
The pipeline has four stages. I implemented all four in every language, which is why each generator produces genuinely correct output rather than a template with blanks left for you to fill in.
The four stages
Stage 1 — parse_prd(text) → Manifest
Reads your text file. Extracts every entity definition, field names with types, user stories, and integration references — using regex, not an LLM. The output is a language-agnostic Manifest.
Stage 2 — manifest_to_genome(manifest) → Genome
Converts the Manifest into an Architectural Genome — a typed intermediate representation using ArchiMate 3.2 element categories: ApplicationComponent, ApplicationService, DataObject, ApplicationInterface.
Every entity automatically receives id, user_id (for per-tenant isolation), and created_at. Relationships are made explicit. The Genome is still language-agnostic — it drives NestJS output and Go output and Laravel output equally.
This is where the approach diverges from a template system. The Genome is your architecture document in machine-readable form. Stages 3 and 4 are pure rendering — they never make decisions about what the system is.
Stage 3 — render_genome(genome) → {path: content}
The language-specific stage. The NestJS renderer generates TypeScript with TypeORM. The Go renderer generates idiomatic Chi handlers with GORM. The Laravel renderer generates Eloquent models, controllers with Form Requests, and API resources. The Rust renderer generates Tauri IPC commands with rusqlite.
Stages 1 and 2 are shared across all ten packages. Only stage 3 differs. That is why it was possible to ship ten ecosystems in one week — the architecture thinking was done once, not ten times.
Stage 4 — pack(files) → ZIP or directory
Writes to disk or bundles a ZIP. Pure stdlib in every implementation — no external zip library.
Three security properties the generator enforces
AI assistants routinely get these wrong. The generators enforce them structurally.
httpOnly cookies, not localStorage. JwtStrategy reads from req.cookies['access_token']. AuthController sets httpOnly: true, secure: true, sameSite: 'strict'. localStorage is an XSS vulnerability. The generator does not offer it as an option.
Per-user isolation on every query. taskService.findAll(userId) executes WHERE user_id = $1. Every service method receives the authenticated user's ID from the guard. There is no code path that returns another user's data.
Correct HTTP status codes. 201 on create. 422 on validation failure. 403 on auth failure. 404 on not-found. This is the generated code, not the documentation.
The Tauri generator is intentionally different
Desktop apps have different constraints. The generated Tauri app uses SQLite instead of Postgres. Auth uses Argon2id + UUID session tokens in application memory — there is no HTTP layer in Tauri, only IPC commands.
#[tauri::command]
async fn list_tasks(state: State<'_, AppState>, session: String) -> Result<Vec<Task>, String> {
let user_id = state.sessions.lock().unwrap()
.get(&session).copied().ok_or("Unauthorised")?;
// every query filters by user_id — same principle, different idiom
}
Why pure stdlib — the Karpathy constraint
Each generator is one file, under 1,400 lines, zero external dependencies. The Go generator uses only archive/zip, encoding/json, and os. The Node.js generator uses only fs, path, crypto, and zlib.
This comes from Andrej Karpathy's micrograd philosophy: if you cannot express the complete algorithm in a small, dependency-free file, you do not fully understand it. Every generator is auditable in a single reading. No transitive dependencies, no supply-chain risks, no version conflicts.
Distribution: why ten registries matter
| Stack | Install |
|---|---|
| NestJS | npm install -g archiet-microcodegen-nestjs |
| Go Chi | go install github.com/aniekanasuquookono-web/archiet-microcodegen-go@latest |
| Laravel | composer global require archiet/microcodegen-laravel |
| Spring Boot | java -jar archiet-microcodegen-java.jar |
| Tauri | cargo install archiet-microcodegen-tauri |
| FastAPI | pip install archiet-microcodegen |
The underlying platform
These generators are the offline distribution of Archiet — a platform that applies the same spec-driven pipeline at enterprise scale: multi-stack simultaneous generation, quality scoring, delivery gates, and a live genome editor.
Spec-driven development should not require a proprietary IDE. These tools exist to make it available everywhere developers already work.