Spec-Driven Development Without an IDE: I Generated NestJS, Go, Spring Boot, Laravel, and Rust Apps From a Single PRD File

A developer has created an open-source CLI toolchain that generates fully functional NestJS, Go, Spring Boot, Laravel, and Rust applications from a single plain-text PRD file, without requiring an IDE, account, or network calls. The tooling implements spec-driven development by parsing a requirements document into a language-agnostic Manifest and Architectural Genome, then producing production-ready code with CRUD operations, JWT authentication, Postgres 16 support, and per-user data isolation. Each generator is published to its ecosystem's package registry (npm, Go, Composer, Maven, Cargo) and runs entirely offline.

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.