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

Aniekan Okono — Mon, 25 May 2026 21:24:23 +0000

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, @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

Realises: TaskManagementService

### DataObject: Task

Fields: id, user_id, title, body, due_date, status, created_at
Association: Task → Project (many-to-one)

Six months from now, a new engineer reads ARCHITECTURE.md and understands the system without deciphering the implementation.

Distribution: why ten registries matter

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
Rails → gem install archiet-microcodegen-rails
.NET → dotnet tool install -g archiet-microcodegen-dotnet
Tauri → cargo install archiet-microcodegen-tauri
FastAPI → pip install archiet-microcodegen
Flask → pip install archiet-microcodegen-flask
Django → 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

Source is public on GitHub. If you hit an issue, the algorithm is short enough that a fix is usually a one-line PR.

DEV Community: Aniekan Okono

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