OpenSpec: de ontbrekende governance-laag tussen AI en code

Ik stuitte op OpenSpec tijdens een avondje graven in GitHub-trends, op zoek naar iets dat het verschil kon maken in hoe wij AI-code beheren. Wat ik vond was geen hype, het was een raamwerk dat een stil probleem oplost waar ik dagelijks tegenaan loop.

Wat OpenSpec doet

Het idee is simpel: voordat een AI-assistant code schrijft, leg je de intentie vast in gestructureerde bestanden. Geen willekeurige prompts in een chatvenster, maar een change contract dat onderdeel is van je repository:

/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 code. Na afronding wordt de change gearchiveerd, mét een auditable record van het waarom, hoe en via welke taken. Het project heeft inmiddels ~51K stars, ~3.6K forks en 36 releases, met de laatste versie v1.3.1 van 21 april 2026. TypeScript, Node.js 20.19.0+, installeerbaar via npm.

Waarom dit mij aanspreekt

Mijn ervaring met AI-gedreven ontwikkeling is dat het probleem niet is dat AI geen code kan schrijven, dat kan het allang. Het probleem is dat het té makkelijk code schrijft zonder voldoende intent, context, scope, acceptance criteria, security constraints en audit trail. En zodra je vier agents in één repo laat werken, wordt die chaos exponentieel.

OpenSpec adresseert precies dat punt: het maakt van een prompt geen vluchtige instructie meer, maar een versioned, reviewable artifact. In een overheidscontext waar men GitHub Copilot en vergelijkbare tools adoptert, is dit soort governance geen luxe, het wordt een compliance-eis, zeker onder BIO2 en NIS2.

In mijn eigen werk bij DjimIT zie ik drie lijnen waarin OpenSpec naadloos past:

• Agentic coding harness. OpenSpec wordt de voorkant van geplande implementaties: eerst proposal, specs, design en tasks, daarna pas échte code via Claude Code, OpenCode of Codex.
• Secure SDLC en shift-left governance. De artifacts kun je uitbreiden met security requirements, threat models, teststrategie, privacy-impact en rollback-plannen.
• Brownfield-first werken. OpenSpec werkt met delta's, geen volledige herschrijvingen van architectuurdocumentatie. Dat is precies wat je nodig hebt voor bestaande repo's en migratieprojecten.

Wat ik sterk vind

Minder context-chaos. Elke wijziging krijgt een eigen map, geen eindeloze chat-historie. Bij agent-overdracht weken later scheelt dat enorm.

Betere decompositie. De keten proposal → specs → design → tasks dwingt scheiding van intent, gedrag, techniek en uitvoering. Essentieel voor multi-agent workflows.

Brownfield-proof. Geen herschrijving van complete architectuurdocumenten. Dit werkt met bestaande codebases.

Tool-agnostisch. Werkt met 20+ AI assistants, niet gebonden aan één IDE of modelprovider.

Waar ik nog vraagtekens bij zet

Geen volwaardige security- of compliance-laag. OpenSpec structureert intent en artifacts, maar valideert niet of een wijziging voldoet aan OWASP, NIST, ISO 27001, GDPR of EU AI Act. Die validaties moet je zelf bouwen.

Snel bewegend ecosysteem. Met ~51K stars, 352 open issues en 101 PR's is het project vitaal, maar interfaces kunnen veranderen. Mijn advies: pin versies, test updates, gebruik niet @latest in productie.

Telemetry. OpenSpec verzamelt anonieme usage-statistieken. Zet uit met OPENSPEC_TELEMETRY=0 en DO_NOT_TRACK=1 voor security-baselines.

Spec theater. Als agents proposals en specs produceren zonder harde validatie, krijg je nette markdown zonder betere software. Koppel het aan tests, code-review en acceptance gates.

Mijn 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	7/10	Security-extensies zelf toevoegen
Governance/auditwaarde	8/10	Archive en artifact trail zijn nuttig
Ecosysteemvolwassenheid	6/10	OpenSpec zelf sterk, omgeving 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

Hoe ik het inzet

OpenSpec is voor mij geen orkestrator die autonoom alles aanstuurt. Het is de contractuele laag die change-artifacts levert waarop agents gecontroleerd werken:

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

Agents mogen pas code aanraken als proposal.md, betrokken specs, design.md, tasks.md én verification.md bestaan. Voor security-gevoelige changes voeg ik verplicht toe: threat model notes, trust boundary impact, authN/authZ impact, secret handling, logging impact en rollback plan.

Conclusie

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

Mijn oordeel: adopteren als controlled pilot, niet als blind standaardframework. Gebruik OpenSpec als spec-and-change layer, maar combineer het verplicht met security gates, pinned versions, telemetry opt-out en custom schemas.

Dat is niet voorzichtigheid. Dat is het niveau van governance dat BIO2, NIS2 en de 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? Neem contact op.