Speckit in de enterprise: hoe een constitution AI-code door een security-review krijgt

Spec-driven development met AI is razend populair bij indies en startups. Probeer het in een bank, verzekeraar of ministerie en je loopt tegen een muur. Security-reviews, architectuur-committees, compliance. Code die op GitHub prachtig oogt, maar de enterprise-deployment-pipeline nooit haalt.

Hieronder hoe wij dat hebben opgelost, met een concreet voorbeeld uit de jaarruimte-migratie die we voor NN deden.

Waarom rauwe AI-code de review niet haalt

Cursor, v0, Claude Code, GitHub Copilot: briljant in werkende code genereren. Maar ze weten niets van jouw organisatie. Welke dependencies goedgekeurd zijn. Welke error-handling security wil zien. Welke logging verplicht is voor GDPR-traceability. Welke frameworks al jaren op de no-go-lijst staan.

Dus wat komt terug? Code die werkt, maar uit een andere wereld. Class components waar je functional wilt. Axios waar je fetch-client al jaren standaard is. API-calls zonder retry. Engelse foutmeldingen in een Nederlandse interface.

Dat rij je niet uit met losse review-comments. Je moet het front-loaden.

Wat Speckit anders doet

Speckit, een spec-driven-development-framework van GitHub, keert de volgorde om. Niet een prompt typen en hopen dat de AI je gedachten raadt. Eerst een spec schrijven: een markdown-document dat beschrijft wat het systeem moet doen. Daarna genereert Speckit code vanuit die spec.

Het wordt pas interessant als je er een constitution bij meegeeft: constitution.agent.md. Een bestand waarin je codificeert welke regels jouw codebase altijd moet volgen. Architectuur-constraints, approved libraries, naming conventions, forbidden patterns. Alles wat je niet elke keer opnieuw wil uitleggen.

Het effect: elke output die Speckit produceert houdt zich aan die constitution. Niet als suggestie, maar als hard filter. Dat is precies wat rauwe AI-prompts niet doen.

Hoe dat bij NN werkte

We migreerden de jaarruimte-calculator van een legacy Blueriq-engine naar een moderne React-app. NN heeft strikte regels over hoe code eruit hoort te zien. Functional components. Tailwind voor styling. Geen inline styles. Central API-client met auth-headers en retry-logic. Error boundaries per page. Specifieke state-management. Nederlandse gebruikerstaal, Engels commentaar.

In plaats van wachten tot de eerste code-review alle mismatches eruit pikte, stopten we die constraints van tevoren in de constitution. De eerste Speckit-output respecteerde ze meteen. Scheelde dagen per iteratie. Lees hier de volledige case study.

Wat hoort in een enterprise-constitution

Op basis van wat we over projecten heen geleerd hebben, deze categorieën tellen:

• Taalregels (hard). Geen eval. Geen any-types. Geen console.log in productie. Geen sync-code op async paden. De "MUST NOT"-lijst.
• Dependencies (gecureerd). Whitelist, soms concreet op versie. Een oude lodash is niet lodash@latest.
• Architectuur-patronen. Waar business-logic hoort, waar presentation. Hoe data stroomt. Liefst met voorbeelden, niet alleen regels.
• Security-hygiene. Input-validatie aan de randen. Output-encoding bij render. Secrets via environment of secret-manager. HTTPS-only.
• Compliance. GDPR-logging, audit-trails, retention. Welke velden mogen gelogd, welke absoluut niet.
• UI en accessibility. Semantische HTML, WCAG-niveau, welke design-system-componenten verplicht zijn.
• Organisatie-taal. Hoe jullie dingen noemen. Klant vs gebruiker. Transactie vs betaling. Kleine consistentie, grote onboarding-winst.

Wat een constitution goed maakt

• Leesbaar voor niet-techneuten. Security, legal en product owner moeten hem kunnen lezen. Dan wordt het ook stakeholder-documentatie.
• Versioned en levend. In git, met reviews. Elk patroon dat je tegenkomt en nog niet hebt vastgelegd, toevoegen.
• Concrete voorbeelden boven abstracte regels. "Gebruik de central api-client" landt minder goed dan "Roep API's aan via import { api } from '@/lib/api', zie voorbeeld X".
• Niet dichttimmeren. Te strak en je AI kan niets. Ruimte voor engineering-oordeel binnen heldere guardrails.

Waar het goed werkt, en waar niet

Goed werkt het bij:

• Regel-gedreven domeinen. Calculators, validaties, workflows, rule-engines. Constitution helder, output strak afgebakend.
• Legacy-migraties. Zijn de business-regels al helder (in Blueriq, code, of docs), dan is de stap naar een spec klein.
• Interne tools met compliance-eisen. Dashboards, admin-panelen, workflow-tools. Veel regels, weinig creatieve UX.

Minder goed werkt het bij:

• Complex UI-werk met veel state en animatie. Designers houden dat bij, AI worstelt ermee.
• Echt nieuwe producten. Als je nog niet weet wat je bouwt, kun je geen spec schrijven. Eerst prototypen, dan Speckit.
• Greenfield architectuurkeuzes. De constitution houdt consistent, maakt geen keuzes voor je.

Slotsom

Speckit zonder constitution is leuk voor hobbyprojects. Speckit mét constitution is gereedschap voor serieus enterprise-werk. Wie schrijft hem? Meestal de lead engineer, in afstemming met security en architectuur. Eenmaal er, wordt het een levend document dat per iteratie scherper wordt.

Voor ons was dit de onmisbare schakel om AI-coding écht bruikbaar te krijgen bij NN. Zonder constitution krijg je code die er leuk uit ziet. Met constitution krijg je code die de security-review haalt.

Werk je in een bank, verzekeraar, overheid of andere corporate context en wil je spec-driven development serieus inzetten? We denken graag mee over je constitution en hoe Speckit in jouw omgeving past. Start een gesprek.

Zie ook: Jaarruimte: van Blueriq naar React in weken. De case study waar dit in de praktijk draaide.