# Spec-Driven Development Without an IDE: I Generated NestJS, Go, Spring Boot, Laravel, and Rust Apps From a Single PRD File > Source: > Published: 2026-05-25 21:24:23+00:00 Amazon launched Kiro in 2025 with a waiting list and 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. Here is what I built, how it works, and why the architecture matters more than the code. Try it right now — pick your stack # NestJS / TypeScript npm install -g archiet-microcodegen-nestjs archiet-microcodegen-nestjs --sample > prd.md 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 cd my-app && composer install && docker compose up # 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 cd my-app && npm install && npm run tauri dev 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. The reason this did not become mainstream is that writing formal models used to require UML tools and an enterprise architect. 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 (e.g. Task, Project, User), field names with types, user stories, and integration references — using regex, not an LLM. The output is a language-agnostic Manifest. # Example PRD snippet: # "The system manages Projects and Tasks. A Project has a name, description, and status. # A Task has a title, body, due_date, and belongs to a Project." # Manifest output: Entities: [Project, Task] Fields: Project: name (string, required), description (text), status (string) Task: title (string, required), body (text), due_date (string), project_id (FK→Project) 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. { "solution_name": "TaskManager", "entities": [ { "name": "Task", "archimate_type": "DataObject", "fields": { "id": { "type": "integer", "required": true }, "user_id": { "type": "integer", "required": true }, "title": { "type": "string", "required": true }, "due_date": { "type": "string", "required": false }, "created_at": { "type": "datetime", "required": true } }, "relationships": [ { "type": "association", "target": "Project", "cardinality": "many-to-one" } ] } ] } 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 Blade-free 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. The generated NestJS app (for NestJS developers) Running the generator against a task-manager PRD produces: src/ auth/ auth.module.ts auth.controller.ts ← /auth/register, /auth/login, /auth/me, /auth/logout jwt.strategy.ts ← reads httpOnly cookie, never Authorization header jwt-auth.guard.ts task/ task.controller.ts ← GET /tasks, POST /tasks, GET /tasks/:id, PUT, DELETE task.service.ts ← every method filters by userId task.entity.ts ← TypeORM [@entity](https://dev.to/entity), [@column](https://dev.to/column), @PrimaryGeneratedColumn dto/ create-task.dto.ts ← class-validator decorators, correct 422 on failure update-task.dto.ts docker-compose.yml ← Postgres 16, healthcheck-gated startup ARCHITECTURE.md ← ArchiMate 3.2 element inventory openapi.yaml ← machine-readable API contract test/ task.controller.spec.ts ← happy-path Jest tests per controller Three security properties the generator enforces that AI assistants routinely get wrong: 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 generated Laravel app (for PHP/Laravel developers) Laravel is one of the most-searched scaffolding targets because the ecosystem is large and opinionated. The generator produces: app/ Models/ Task.php ← Eloquent model, $fillable, $casts, userId scope Http/ Controllers/ TaskController.php ← full CRUD resource controller Requests/ StoreTaskRequest.php ← FormRequest validation, 422 on failure Resources/ TaskResource.php ← API resource, hides internal fields routes/ api.php ← Route::apiResource + auth middleware database/ migrations/ create_tasks_table.php ← with user_id FK index docker-compose.yml ARCHITECTURE.md openapi.yaml The Task model has a global scope that automatically filters by the authenticated user — the same per-tenant isolation principle, expressed in Laravel idioms. The generated Go app (for Go developers) Go developers are allergic to magic. The generated app uses net/http (via Chi for routing), GORM, and golang-jwt/jwt. No reflection-heavy frameworks. func (h *TaskHandler) ListTasks(w http.ResponseWriter, r *http.Request) { userID := r.Context().Value(contextKeyUserID).(int64) tasks, err := h.service.FindAllByUser(r.Context(), userID) // ... } func (s *TaskService) FindAllByUser(ctx context.Context, userID int64) ([]Task, error) { var tasks []Task result := s.db.WithContext(ctx).Where("user_id = ?", userID).Find(&tasks) return tasks, result.Error } Generated Makefile includes make build, make test, make migrate. Zero magic. 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, String> { let user_id = state.sessions.lock().unwrap() .get(&session).copied().ok_or("Unauthorised")?; // every query filters by user_id — same principle, different idiom } How this compares to Amazon Kiro Kiro and these generators share the same core insight: spec-first produces better software than prompt-and-pray. The differences are practical: These are different tools. If you are already using Kiro, you can use these generators to bootstrap the initial project before Kiro helps you extend it. 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. The Rust generator uses only std. 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. It also means the generator never breaks because a dependency changed its API. The architecture document that survives your codebase Every generated project includes ARCHITECTURE.md with a typed ArchiMate 3.2 inventory: ### ApplicationComponent: TaskManagerAPI ### DataObject: Task Six months from now, a new engineer reads ARCHITECTURE.md and understands the system without deciphering the implementation. Distribution: why ten registries matter `npm install -g archiet-microcodegen-nestjs` `go install github.com/aniekanasuquookono-web/archiet-microcodegen-go@latest` `composer global require archiet/microcodegen-laravel` `java -jar archiet-microcodegen-java.jar` `gem install archiet-microcodegen-rails` `dotnet tool install -g archiet-microcodegen-dotnet` `cargo install archiet-microcodegen-tauri` `pip install archiet-microcodegen` `pip install archiet-microcodegen-flask` `pip install archiet-microcodegen-django` 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. If you want the full platform — try [Archiet.com](https://dev.tourl) Source is public on GitHub. If you hit an issue, the algorithm is short enough that a fix is usually a one-line PR.