DEV Community: Aniekan Okono

EU AI Act Enforcement Starts in 7 Weeks. Is Your Codebase Ready?

Aniekan Okono — Wed, 10 Jun 2026 18:39:03 +0000

August 2026 is not a policy deadline. It is a code deadline.

The EU AI Act's high-risk provisions begin enforcement in August 2026. Annex III defines the categories: biometric systems, critical infrastructure, employment screening, credit scoring, access to essential services, law enforcement, migration, administration of justice, and democratic processes. If your product touches any of these categories — or processes data for customers who do — your codebase is in scope, not just your legal team's slide deck.

Most compliance conversations I have seen inside large enterprises stop at the policy layer. Someone from legal presents the Act's requirements in a governance meeting. An architect maps them to existing controls. A project is raised to "address gaps." Eighteen months later, the sprint tickets are still open.

That pattern will not survive August.

What the Act actually requires in code

Three articles matter most for software teams. They are not abstract.

Article 13 requires transparency obligations: high-risk AI systems must be designed and developed to ensure their operation is sufficiently transparent to allow users to interpret the system's output and use it appropriately. In code, this means logging, explainability endpoints, and output metadata. It means the system must be able to tell a user or regulator why it produced a given output — not just what the output was.

Article 14 requires human oversight: high-risk systems must be designed to allow natural persons to oversee their functioning effectively during the period of use. In code, this means override mechanisms, audit trails that capture human intervention points, and UI patterns that surface confidence scores and uncertainty signals. A system that produces outputs without a human review pathway is structurally non-compliant.

Article 15 requires accuracy, robustness, and cybersecurity: high-risk AI systems must be designed and developed with an appropriate level of accuracy, robustness, and cybersecurity, and perform consistently with respect to those aspects throughout their lifecycle. In code, this means input validation, adversarial robustness testing, drift detection hooks, and security controls that match the sensitivity of the output. "It worked in staging" is not a defence.

None of these requirements are satisfied by adding a README section. They require implementation patterns written into the codebase — not documented after the fact.

Why this is a code generation problem

The AI code generation tools that most development teams use today — LLMs in Copilot, Cursor, Bolt, Lovable, and similar — generate code at the token level. They do not model the system. They do not understand that a credit-scoring component is Annex III category six. They do not apply EU AI Act Article 13 logging patterns to outputs that fall within the high-risk scope. They cannot, because they have no system-level specification to work from.

A developer using an LLM to build a high-risk AI system will get functional code. They will not get Article 13-compliant output logging. They will not get Article 14 human oversight hooks. They will not get Article 15 adversarial robustness wiring. Those will be sprint tickets — each of which will take a compliance consultant to specify and a developer to implement, weeks before an enforcement deadline.

I have watched this happen inside enterprises. The gap between what the governance layer approved and what the engineering layer shipped is enormous, and it always emerges at the worst time.

What a compliant architecture generates

Archiet's EU AI Act compliance overlay is not a checklist applied after the code is generated. It is a transformation applied during generation, from the ArchiMate 3.2 architecture model.

When a system is modelled with an EU AI Act overlay, the generated code includes:

Structured output logging with the metadata fields required for Article 13 transparency (model version, input hash, confidence score, timestamp, decision rationale fields)
Human oversight intercept points: API endpoints and UI hooks that surface the system's output for human review before consequential actions are triggered — satisfying Article 14
Input validation and robustness patterns: boundary checking, rejection of malformed inputs, and audit-trail capture for anomalous inputs — satisfying Article 15
Data subject identification flags on fields that process personal data in an AI decision context, wired to the GDPR overlay where the two regimes overlap

These patterns are structural. They are generated the same way every time from the same architecture model. They cannot be forgotten in a sprint, because they are not sprint tickets — they are properties of the transformation.

The 7-week question

If your product is in scope for the EU AI Act high-risk provisions and you are starting from a codebase without these patterns, you have two options.

The first is a retrofit: audit the existing codebase, identify the gaps against Articles 13, 14, and 15, write sprint tickets, find developer capacity, implement, test, document. This takes months if the codebase is not architecturally clean. Most are not.

The second is a regeneration: if your system is modelled — and every enterprise system should be — you can apply the EU AI Act overlay to the architecture model and generate a compliant implementation alongside compliant architecture documentation. The generated ADRs and traceability matrix document the compliance posture against each Article. If a regulator asks for evidence, you have it.

Archiet generates EU AI Act-compliant code across 12 technology stacks. The overlay is one of nine compliance frameworks built into the platform, alongside GDPR, HIPAA, PCI-DSS, SOC2, DORA, ISO 13485, IEC 62443, and the Building Safety Act 2022. The same architecture model always produces the same output — reproducible, auditable, and ready for a regulatory review.

August is not far away. If your codebase is not ready, the question is not whether to act — it is whether to retrofit or regenerate.

archiet.com

Aniekan Okono is an Enterprise Architect practitioner at a Fortune Global 500 company and the founder of Archiet.

Why I stopped using LLMs to generate code (and what I use instead)

Aniekan Okono — Wed, 10 Jun 2026 09:47:57 +0000

I want to be precise about what I mean by that title, because it's easy to read it as anti-AI and it isn't.

I use LLMs every day. I used one to write this article's first outline. I use them to parse prose, extract structure, and summarise documents. They're genuinely useful for that.

What I stopped using them for is generating application code — the part where the output needs to be correct, reproducible, and deployable without a week of cleanup.

Here's why, and what I built instead.

The problem with LLM-generated code isn't the code itself

When Bolt, Lovable, or v0 generate a frontend for you, the output often looks impressive. Clean components, reasonable naming, something that runs on first try. The demo works.

Then you try to deploy it.

The database schema is wrong — or missing entirely. There's no auth, or auth that stores tokens in localStorage (which is a security problem). Multi-tenancy doesn't exist: every query returns every user's data. The OpenAPI spec doesn't match the routes. The migrations aren't there.

None of these are small things. They're the things that take 4–8 weeks to fix before you can show the app to a real user.

The reason this happens is structural, not incidental. LLMs are stateless across the context window. They don't hold a persistent model of your system. Ask an LLM to add an endpoint, and it will. Ask it to fix a bug in that endpoint, and it will — without awareness of what the fix broke downstream. Ask it to add multi-tenancy, and it might touch 60% of the places that need changing and miss the rest.

This isn't a failure of the models. It's a consequence of using a tool designed for language generation to do something that requires deterministic, system-wide consistency.

What code generation actually requires

Think about what a production-ready codebase actually is. It's not a collection of files that individually look reasonable. It's a system where:

The data model drives the migrations, which drive the API shape, which drives the frontend types
Auth is implemented consistently across every route, not just the ones you remembered to mention
Every query is scoped to the correct tenant
Compliance constraints (GDPR consent flags, audit trails, HIPAA access controls) are woven through the data layer, not bolted on as an afterthought
The infrastructure config matches the application config

For all of that to be correct, the generator needs a complete, coherent model of the system before it writes a single line. An LLM working from a PRD in natural language doesn't have that model. It infers it, incompletely, from what you wrote.

The alternative: Model-to-Text generation

Model-driven architecture has existed for decades. The idea: define your system formally first — entities, relationships, capabilities, constraints — and then generate the implementation from that model.

The key property is determinism. Given the same model, you always get the same output. The generator isn't guessing. It's applying a set of transformation rules to a structured input.

This is the approach I took when I built Archiet.

The workflow looks like this:

You provide a PRD (plain prose — what the system does, who uses it, what the rules are)
An LLM parses the PRD into a formal schema — what we call the genome: entities, screens, business rules, capabilities, compliance requirements
A deterministic Model-to-Text engine reads the genome and renders a production-ready ZIP

The LLM is used exactly where it's good: turning unstructured prose into structured data. The code generation step — where reproducibility and correctness matter — uses no LLMs at all.

What "production-ready" actually means in practice

This is where I'll be specific, because "production-ready" gets thrown around loosely.

In Archiet's output, every generated ZIP includes:

Data layer

Alembic migrations generated directly from the entity model — you don't write them, they're derived
Multi-tenant organisation scoping on every query — not added later, baked into the base query class
No raw SQL strings; parameterised queries throughout

Auth

HTTPOnly cookie-based sessions (no localStorage tokens)
CSRF protection enabled by default
Role-based access control generated from the capability model

API

OpenAPI spec that is always in sync with the routes, because both are generated from the same source
Consistent error response shapes across every endpoint

Compliance

GDPR, HIPAA, SOC2, DORA, EU AI Act overlays available — not as checklists, but as actual implementation patterns woven into the generated code
Consent flags, audit trail tables, data retention hooks — present in the output, not left as an exercise for the reader

Quality gate

Every ZIP scores ≥80/100 before delivery
Any hardcoded secret or unfilled placeholder hard-blocks the release
Generated apps are booted in a sandbox (E2B) and tested before the customer downloads them

The unusual part: the open spec

One decision I made early: publish the formal specification that underpins all of this as an open Apache-2.0 standard — archimate-codegen-spec.

The genome schema, the capability catalogue, the ArchiMate-to-genome mapping rules — all public and auditable independently of Archiet. Archiet is the reference implementation, but the spec belongs to the community.

The reason: if you're going to trust a tool to generate production code, you should be able to inspect the rules it's applying. A black-box generator you can't audit is a liability in any compliance-heavy context.

Where LLMs still belong in this pipeline

I want to be clear that I'm not arguing against LLMs in software development. The PRD parsing step is genuinely hard to do without one, and the quality of that parsing directly affects the quality of the output.

What I'm arguing is that there's a category error in using LLMs for the code generation step specifically. The properties you need from a code generator — determinism, consistency, auditability, reproducibility — are exactly the properties that LLMs are architecturally unable to provide.

The right tool for parsing ambiguous human language into structured data: LLM.
The right tool for transforming a complete, formal system model into consistent, correct code: deterministic template engine.

Using the same tool for both because it can do both is like using a hammer to drive screws because you don't want to switch tools. It works well enough until it doesn't, and when it doesn't the failure is hard to diagnose.

What this means for your projects

If you're building something where correctness matters — fintech, healthtech, anything with compliance requirements, anything multi-tenant, anything that needs to pass a security audit — the cleanup cost of LLM-generated code is a real project risk, not a theoretical one.

The alternative isn't to write everything by hand. It's to separate the concern: use AI for the parts that are genuinely hard for machines (understanding your intent), and use deterministic generation for the parts where machines are genuinely better than humans (applying rules consistently at scale).

That's the architecture that lets you go from PRD to deployable ZIP without a cleanup sprint.

If you're curious about the technical details of the genome schema or the M2T engine design, happy to go into it in the comments. And if you want to try it: archiet.com — free tier available.

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.