OpenSpec: de ontbrekende governance-laag tussen AI en code

Vijftigduizend GitHub-stars in veertien maanden. Dat is geen hype meer — dat is een signaal. OpenSpec van Fission-AI positioneert zich als hét framework voor spec-driven development met AI coding assistants. Maar wat maakt het relevant voor de Nederlandse publieke sector? En waarom is de afwezigheid van zo'n governance-laag in overheids-ontwikkeltrajecten een BIO2-risico?

Wat OpenSpec feitelijk doet

De kern is simpel: voordat een AI coding assistant code schrijft, leg je de intentie vast in gestructureerde artifacts. Geen vage prompt in een chatvenster, maar een repository-native change contract:

/opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive

Elke wijziging krijgt een eigen map in openspec/changes/:

openspec/changes/add-dark-mode/
├── proposal.md      ← Wat en waarom
├── specs/           ← Requirements en scenario's
├── design.md        ← Technische aanpak
└── tasks.md         ← Implementatie-checklist

Pas daarna schrijft de agent gerichte code. Na afronding wordt de change gearchiveerd — mét een auditable record van het waarom, hoe en via welke taken. Dit is fundamenteel anders dan het dominante paradigma van ad-hoc prompting.

De adoptiecijfers liegen er niet om: 50.8K stars, 3.6K forks, 36 releases, laatste release v1.3.1 op 21 april 2026. TypeScript-dominant, Node.js 20.19.0+, geïnstalleerd via npm install -g @fission-ai/[email protected]. Integreert met 20+ AI assistants via slash commands, waaronder Claude Code, Codex, Cursor en OpenCode.

Waarom dit relevant is voor DjimIT

Het probleem in AI-gedreven softwareontwikkeling is niet dat AI geen code kán schrijven. Het probleem is dat AI te makkelijk code schrijft zonder voldoende intent, context, scope, acceptance criteria, security constraints en audit trail.

OpenSpec adresseert precies dát. Het maakt van een prompt geen vluchtige instructie, maar een versioned, reviewable artifact. In een context waarin overheidsorganisaties GitHub Copilot en aanverwante tools adopteren, is deze governance-laag geen luxe — het is een compliance-eis in wording.

Voor DjimIT past OpenSpec in drie bestaande lijnen:

• Agentic coding harness. OpenSpec wordt de voorkant van Plan Mode: eerst proposal, specs, design en tasks, daarna pas implementatie via Claude Code, OpenCode of Codex.
• Secure SDLC en shift-left governance. De artifacts kunnen uitgebreid worden met security requirements, threat model, teststrategie, privacy-impact en rollback-plan.
• Brownfield-first werken. OpenSpec claimt expliciet brownfield-first te zijn en werkt met delta's — geen volledige herschrijving van architectuurdocumentatie. Dat past bij bestaande repo's, legacy code en migratieprojecten.

Sterke punten

Reductie van context-chaos. In plaats van alles in chat-historie, CLAUDE.md en losse prompts te bewaren, krijgt elke wijziging een expliciete mapstructuur. Dat helpt bij agent-overdracht, retries en latere reconstructie.

Betere opdrachtdecompositie. De keten proposal → specs → design → tasks → implement dwingt een agent om intent, gedrag, technische aanpak en taakuitvoering te scheiden. Bij multi-agent workflows is dat essentieel: planner, coder, reviewer en security-agent moeten met dezelfde aannames werken.

Geschikt voor bestaande codebases. De delta-aanpak voorkomt dat je complete architectuurdocumenten moet herschrijven. Voor projecten als Hermes-Agent, GovChat-NL, LiteLLM proxies en MCP-integraties is dit pragmatischer dan zware enterprise-documentatie.

Tool-agnostisch. OpenSpec werkt met 20+ AI assistants en is niet gebonden aan één IDE of modelprovider — essentieel voor een multi-provider strategie.

Lage frictie. De filosofie is "fluid not rigid", "iterative not waterfall", "brownfield not just greenfield". Dat is goed, mits je er zelf governance bovenop zet.

Zwakke punten en risico's

Geen volwaardige governance-, security- of compliance-laag. OpenSpec structureert intent en change artifacts, maar valideert niet automatisch of een wijziging voldoet aan OWASP, NIST, ISO 27001, GDPR, EU AI Act, secret scanning, dependency policy, SBOM-eisen of runtime isolation. Je moet deze validaties zelf toevoegen.

Snelle ecosystem maturity curve. Met 50K stars, 352 open issues en 101 pull requests is het project gezond — maar interfaces kunnen veranderen. Advies: pin versies, test updates, gebruik niet @latest in productieve repo's.

Telemetry. OpenSpec verzamelt anonieme usage-statistieken (command names, version — geen argumenten, paden, content of PII). Voor een security-baseline zet je dit uit: OPENSPEC_TELEMETRY=0 en DO_NOT_TRACK=1.

Spec theater. Als agents proposals en specs produceren zonder harde validatie, krijg je nette markdown zonder betere software. Koppeling aan tests, code-review, threat modeling en acceptance gates is verplicht.

Autonome extensies uit het topic-ecosysteem. Het GitHub topic openspec telt 105 repo's, voornamelijk experimentele uitbreidingen zoals autonome 7-fase implementatieworkflows en "workflow enforcers". Die zijn inspirerend, maar eerst sandbox-valideren voordat ze productief ingezet worden.

De DjimIT-beoordeling

| Criterium | Score | Toelichting | |-----------|-------|-------------| | Fit met agentic coding | 9/10 | Proposal/spec/design/tasks is sterk | | Fit met brownfield repos | 8/10 | Delta-aanpak is praktisch | | Fit met secure SDLC | 6/10 (8/10 met extensies) | Security moet je zelf toevoegen | | Governance/auditwaarde | 8/10 | Archive en artifact trail zijn nuttig | | Ecosysteemvolwassenheid | 6/10 | OpenSpec zelf sterk, topic-ecosysteem jong | | Enterprise-readiness | 6.5/10 | Bruikbaar, maar alleen met policy gates | | Risico bij autonome inzet | Hoog | Zonder hooks en review wordt het spec theater |

Architectuurvisie: OpenSpec als Change Intent Layer

OpenSpec hoort niet de orkestrator te zijn die autonoom alles aanstuurt. Het is de contractuele laag die change-artifacts levert waarop agents gecontroleerd werken.

In de DjimIT Agentic OS-architectuur:

Human intent / portfolio decision
→ OpenSpec proposal
→ Delta specs met acceptance criteria
→ Design met architecture/security/privacy impact
→ Tasks met testbare increments
→ Claude Code / OpenCode / Codex implementation
→ Security hooks, tests, SAST, dependency scan, SBOM
→ Review / archive / knowledge sync

De agents mogen pas broncode aanpassen als:

1. proposal.md bestaat
2. Betrokken specs zijn geïdentificeerd
3. design.md security- en architectuur-impact beschrijft
4. tasks.md testbare implementatiestappen bevat
5. verification.md acceptatietests en security-checks definieert

Voor security-gevoelige changes worden verplicht toegevoegd: threat model notes, affected trust boundaries, authN/authZ impact, secret handling impact, dependency/supply-chain impact, logging/audit impact en rollback plan.

Gefaseerd adoptieplan

Fase 1 — Technische pilot (1 week). Installeer OpenSpec in één niet-kritische repo. Telemetry uit. Versie gepind. Laat dezelfde change uitvoeren mét en zonder OpenSpec. Meet: tokengebruik, correctierondes, testdekking, scope drift, reviewtijd.

Fase 2 — Governance-schema (2 weken). Bouw een eigen secure-agentic-sdd schema met security, privacy, architecture, verification en rollback artifacts. Voeg PreToolUse hooks toe die broncodewijzigingen blokkeren zonder actieve OpenSpec-change.

Fase 3 — Integratie met agent harness (3-4 weken). Koppel OpenSpec aan bestaande CLAUDE.md, skills, hooks, context-mode en codebase-memory. Laat subagents artifacts reviewen: architect-reviewer, security-reviewer, test-reviewer, cost-reviewer.

Fase 4 — Go/no-go. Adopteer OpenSpec als standaard voor non-trivial changes wanneer deze KPI's verbeteren: minder scope drift, kortere review cycles, betere testdekking, minder context blow-up, reproduceerbare agent-output en duidelijkere audit trail.

Conclusie

OpenSpec is voor de Nederlandse publieke sector geen hype-tool, maar een bruikbare control surface voor agentic software delivery. De echte waarde zit niet in de slash commands — die zijn bijvangst. De waarde zit in het terugbrengen van AI-wijzigingen naar expliciete, versioned, reviewbare artifacts.

Voor DjimIT is het oordeel helder: adopteren als controlled pilot, niet als blind standaardframework. Gebruik OpenSpec als spec-and-change layer in het Agentic OS, maar combineer het verplicht met security gates, pinned versions, telemetry opt-out, custom schemas en PreToolUse enforcement.

Dat is niet voorzichtigheid. Dat is precies het niveau van governance dat de BIO2, NIS2 en EU AI Act van ons vragen.

---

DjimIT adviseert en implementeert secure-by-design AI-ontwikkelstraten voor de Nederlandse publieke sector. Interesse in een OpenSpec-pilot met BIO2/NIS2-compliance profiel? Neem contact op.