{"slug": "spec-driven-development-without-an-ide-i-generated-nestjs-go-spring-boot-laravel", "title": "Spec-Driven Development Without an IDE: I Generated NestJS, Go, Spring Boot, Laravel, and Rust Apps From a Single PRD File", "summary": "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.", "body_md": "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.\n\nKiro is a good idea. But it is also a proprietary IDE you have to install, sign in to, and trust with your codebase.\n\nI 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.\n\nHere is what I built, how it works, and why the architecture matters more than the code.\n\nTry it right now — pick your stack\n\n# NestJS / TypeScript\n\nnpm install -g archiet-microcodegen-nestjs\n\narchiet-microcodegen-nestjs --sample > prd.md\n\narchiet-microcodegen-nestjs prd.md --out ./my-app\n\ncd my-app && npm install && docker compose up\n\n# Go Chi\n\ngo install github.com/aniekanasuquookono-web/archiet-microcodegen-go@latest\n\narchiet-microcodegen-go prd.md --out ./my-app\n\ncd my-app && make run\n\n# Laravel (PHP)\n\ncomposer global require archiet/microcodegen-laravel\n\narchiet-microcodegen-laravel prd.md --out ./my-app\n\ncd my-app && composer install && docker compose up\n\n# Spring Boot (Java)\n\njava -jar archiet-microcodegen-java.jar prd.md --out ./my-app\n\ncd my-app && mvn spring-boot:run\n\n# Tauri (Rust + desktop)\n\ncargo install archiet-microcodegen-tauri\n\narchiet-microcodegen-tauri prd.md --out ./my-app\n\ncd my-app && npm install && npm run tauri dev\n\nYour app has full CRUD, JWT auth with httpOnly cookies, Postgres 16, and per-user data isolation — before you have finished reading this article.\n\nWhat spec-driven development actually means\n\nSpec-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.\n\nThe 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.\n\nThe 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.\n\nThe four stages\n\nStage 1 — parse_prd(text) → Manifest\n\nReads 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.\n\n# Example PRD snippet:\n\n# \"The system manages Projects and Tasks. A Project has a name, description, and status.\n\n# A Task has a title, body, due_date, and belongs to a Project.\"\n\n# Manifest output:\n\nEntities: [Project, Task]\n\nFields:\n\nProject: name (string, required), description (text), status (string)\n\nTask: title (string, required), body (text), due_date (string), project_id (FK→Project)\n\nStage 2 — manifest_to_genome(manifest) → Genome\n\nConverts the Manifest into an Architectural Genome — a typed intermediate representation using ArchiMate 3.2 element categories: ApplicationComponent, ApplicationService, DataObject, ApplicationInterface.\n\nEvery 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.\n\n{\n\n\"solution_name\": \"TaskManager\",\n\n\"entities\": [\n\n{\n\n\"name\": \"Task\",\n\n\"archimate_type\": \"DataObject\",\n\n\"fields\": {\n\n\"id\": { \"type\": \"integer\", \"required\": true },\n\n\"user_id\": { \"type\": \"integer\", \"required\": true },\n\n\"title\": { \"type\": \"string\", \"required\": true },\n\n\"due_date\": { \"type\": \"string\", \"required\": false },\n\n\"created_at\": { \"type\": \"datetime\", \"required\": true }\n\n},\n\n\"relationships\": [\n\n{ \"type\": \"association\", \"target\": \"Project\", \"cardinality\": \"many-to-one\" }\n\n]\n\n}\n\n]\n\n}\n\nThis 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.\n\nStage 3 — render_genome(genome) → {path: content}\n\nThe 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.\n\nStages 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.\n\nStage 4 — pack(files) → ZIP or directory\n\nWrites to disk or bundles a ZIP. Pure stdlib in every implementation — no external zip library.\n\nThe generated NestJS app (for NestJS developers)\n\nRunning the generator against a task-manager PRD produces:\n\nsrc/\n\nauth/\n\nauth.module.ts\n\nauth.controller.ts ← /auth/register, /auth/login, /auth/me, /auth/logout\n\njwt.strategy.ts ← reads httpOnly cookie, never Authorization header\n\njwt-auth.guard.ts\n\ntask/\n\ntask.controller.ts ← GET /tasks, POST /tasks, GET /tasks/:id, PUT, DELETE\n\ntask.service.ts ← every method filters by userId\n\ntask.entity.ts ← TypeORM [@entity](https://dev.to/entity), [@column](https://dev.to/column), @PrimaryGeneratedColumn\n\ndto/\n\ncreate-task.dto.ts ← class-validator decorators, correct 422 on failure\n\nupdate-task.dto.ts\n\ndocker-compose.yml ← Postgres 16, healthcheck-gated startup\n\nARCHITECTURE.md ← ArchiMate 3.2 element inventory\n\nopenapi.yaml ← machine-readable API contract\n\ntest/\n\ntask.controller.spec.ts ← happy-path Jest tests per controller\n\nThree security properties the generator enforces that AI assistants routinely get wrong:\n\nhttpOnly 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.\n\nPer-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.\n\nCorrect 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.\n\nThe generated Laravel app (for PHP/Laravel developers)\n\nLaravel is one of the most-searched scaffolding targets because the ecosystem is large and opinionated. The generator produces:\n\napp/\n\nModels/\n\nTask.php ← Eloquent model, $fillable, $casts, userId scope\n\nHttp/\n\nControllers/\n\nTaskController.php ← full CRUD resource controller\n\nRequests/\n\nStoreTaskRequest.php ← FormRequest validation, 422 on failure\n\nResources/\n\nTaskResource.php ← API resource, hides internal fields\n\nroutes/\n\napi.php ← Route::apiResource + auth middleware\n\ndatabase/\n\nmigrations/\n\ncreate_tasks_table.php ← with user_id FK index\n\ndocker-compose.yml\n\nARCHITECTURE.md\n\nopenapi.yaml\n\nThe Task model has a global scope that automatically filters by the authenticated user — the same per-tenant isolation principle, expressed in Laravel idioms.\n\nThe generated Go app (for Go developers)\n\nGo developers are allergic to magic. The generated app uses net/http (via Chi for routing), GORM, and golang-jwt/jwt. No reflection-heavy frameworks.\n\nfunc (h *TaskHandler) ListTasks(w http.ResponseWriter, r *http.Request) {\n\nuserID := r.Context().Value(contextKeyUserID).(int64)\n\ntasks, err := h.service.FindAllByUser(r.Context(), userID)\n\n// ...\n\n}\n\nfunc (s *TaskService) FindAllByUser(ctx context.Context, userID int64) ([]Task, error) {\n\nvar tasks []Task\n\nresult := s.db.WithContext(ctx).Where(\"user_id = ?\", userID).Find(&tasks)\n\nreturn tasks, result.Error\n\n}\n\nGenerated Makefile includes make build, make test, make migrate. Zero magic.\n\nThe Tauri generator is intentionally different\n\nDesktop 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.\n\n#[tauri::command]\n\nasync fn list_tasks(state: State<'_, AppState>, session: String) -> Result, String> {\n\nlet user_id = state.sessions.lock().unwrap()\n\n.get(&session).copied().ok_or(\"Unauthorised\")?;\n\n// every query filters by user_id — same principle, different idiom\n\n}\n\nHow this compares to Amazon Kiro\n\nKiro and these generators share the same core insight: spec-first produces better software than prompt-and-pray. The differences are practical:\n\nThese 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.\n\nWhy pure stdlib — the Karpathy constraint\n\nEach 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.\n\nThis 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.\n\nIt also means the generator never breaks because a dependency changed its API.\n\nThe architecture document that survives your codebase\n\nEvery generated project includes ARCHITECTURE.md with a typed ArchiMate 3.2 inventory:\n\n### ApplicationComponent: TaskManagerAPI\n\n### DataObject: Task\n\nSix months from now, a new engineer reads ARCHITECTURE.md and understands the system without deciphering the implementation.\n\nDistribution: why ten registries matter\n\n`npm install -g archiet-microcodegen-nestjs`\n\n`go install github.com/aniekanasuquookono-web/archiet-microcodegen-go@latest`\n\n`composer global require archiet/microcodegen-laravel`\n\n`java -jar archiet-microcodegen-java.jar`\n\n`gem install archiet-microcodegen-rails`\n\n`dotnet tool install -g archiet-microcodegen-dotnet`\n\n`cargo install archiet-microcodegen-tauri`\n\n`pip install archiet-microcodegen`\n\n`pip install archiet-microcodegen-flask`\n\n`pip install archiet-microcodegen-django`\n\nThe underlying platform\n\nThese 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.\n\nSpec-driven development should not require a proprietary IDE. These tools exist to make it available everywhere developers already work.\n\nIf you want the full platform — try [Archiet.com](https://dev.tourl)\n\nSource is public on GitHub. If you hit an issue, the algorithm is short enough that a fix is usually a one-line PR.", "url": "https://wpnews.pro/news/spec-driven-development-without-an-ide-i-generated-nestjs-go-spring-boot-laravel", "canonical_source": "https://dev.to/anioko1/spec-driven-development-without-an-ide-i-generated-nestjs-go-spring-boot-laravel-and-rust-3p26", "published_at": "2026-05-25 21:24:23+00:00", "updated_at": "2026-05-25 21:33:29.434458+00:00", "lang": "en", "topics": ["ai-tools", "ai-products", "generative-ai", "ai-startups", "ai-infrastructure"], "entities": ["Amazon", "Kiro", "NestJS", "Go", "Laravel", "Spring Boot", "Tauri", "Rust"], "alternates": {"html": "https://wpnews.pro/news/spec-driven-development-without-an-ide-i-generated-nestjs-go-spring-boot-laravel", "markdown": "https://wpnews.pro/news/spec-driven-development-without-an-ide-i-generated-nestjs-go-spring-boot-laravel.md", "text": "https://wpnews.pro/news/spec-driven-development-without-an-ide-i-generated-nestjs-go-spring-boot-laravel.txt", "jsonld": "https://wpnews.pro/news/spec-driven-development-without-an-ide-i-generated-nestjs-go-spring-boot-laravel.jsonld"}}