OpenSpec review: mijn nieuwe daily driver voor AI-coding

OpenSpec review: mijn nieuwe daily driver voor AI-coding

De eerste keer dat ik openspec apply voor een echt project gebruikte, stapte ik weg om mijn koffie bij te vullen en vergat het. Twee uur en zeventien minuten later kwam ik terug bij een werkend dashboard, een geslaagd testpakket en een changes/-map vol afprijzingen waarin werd uitgelegd (tot een detailniveau dat ik nooit met de hand zou hebben geschreven) wat precies was gebouwd en waarom.

Dat is niet het indrukwekkende deel. Het indrukwekkende is wat er de volgende ochtend gebeurde toen ik een tweede functie moest toevoegen. Ik heb de code niet geopend. Ik heb de map met specificaties geopend. Ik heb drie korte markdown-bestanden gelezen. En ik wist, met een soort duidelijkheid die ik normaal gesproken pas na een week van context laden krijg, precies waar de nieuwe functie zou moeten aansluiten en wat deze zou raken.

Op dat moment begreep ik wat de OpenSpec AI coding framework eigenlijk doet — en waarom ik denk dat dit de eerste spec-driven-tool is die het contact met mijn echte workflow overleeft.

Ik gebruik het al twee weken als mijn dagelijkse driver voor drie projecten: een Laravel-beheertool die ik aan het herstructureren ben voor een klant, een Next.js-zijproject dat ik helemaal opnieuw ben begonnen, en een bestaande Python-codebase die ik heb geërfd en die ongeveer de documentatiehygiëne van een gijzeling heeft. OpenSpec verdiende zijn plaats in alle drie. Maar niet om de redenen die op de marketingpagina's staan ​​vermeld.

Dit is het volledige overzicht: wat OpenSpec is, waar het zich bevindt in het AI coding framework-landschap, de exacte opdrachten die ik uitvoer en de eerlijke plaatsen waar het niet helpt. Als je al uren hebt gestoken in het kijken naar een Claude Code-sessie die code genereert op basis van een specificatie die vanaf het begin verkeerd was, zullen de volgende 4.000 woorden persoonlijk aanvoelen.

De drie categorieën AI-codingsframeworks (en waarom dit ertoe doet)

Voordat OpenSpec zinvol wordt, heb je de kaart nodig van het gebied waarin het leeft. Deze fout maakte ik de eerste keer dat ik het evalueerde; ik vergeleek het met instrumenten die het nooit probeerde te verslaan, en ik verwierp het bijna om de verkeerde redenen.

Er zijn drie verschillende categorieën AI coding framework's die in 2026 worden verzonden, en ze lossen verschillende problemen op:

Deze categorieën concurreren niet rechtstreeks. Ze stapelen.

Een echte productiestack lijkt meer op: OpenSpec schrijft de specificaties, Obra Superpowers dwingt TDD af tijdens de build, BMAD orkestreert de multi-agent-pijplijn die PR's verzendt terwijl je slaapt. Hetzelfde probleem vanuit drie invalshoeken. Verschillende lagen van dezelfde machine.

Waar de meeste "spec-driven versus autonome" artikelen fout gaan, is het behandelen ervan als alternatieven. Dat zijn ze niet. Het zijn niveaus. En OpenSpec is het onderste niveau: degene die beslist waar de andere twee niveaus aan zullen werken.

Daarom is het belangrijker om deze laag goed te krijgen dan de lagen erboven. Een perfecte TDD-handhavingsvaardigheid zal je niet redden als de specificatie die wordt afgedwongen op de eerste dag verkeerd was. Een autonome pijplijn die in een sprint 40 PR’s verzendt, zal eenvoudigweg 40 verkeerde PR’s verzenden. Spec-kwaliteit is het stroomopwaartse knelpunt. Al het andere versterkt de beslissing die daar is genomen – ten goede of ten kwade.

Dus de vraag is niet "OpenSpec of BMAD?" De vraag is: "is OpenSpec goed genoeg om de bron van waarheid te zijn die alles stroomafwaarts vertrouwt?" Dat is wat ik ging testen.

Wat OpenSpec eigenlijk is

OpenSpec is een open-source spec-driven-ontwikkelingsframework, geleverd als het npm-pakket @fission-ai/openspec en onderhouden door Fission-AI. Het werkt in elk project als een dunne laag bovenop uw AI-codeerassistent - Claude Code, Cursor, Codex, Windsurf, Continue, GitHub Copilot, Amazon Q en ongeveer twintig andere volgens de ondersteunde tools doc.

Het kernidee is brutaal in zijn eenvoud. De specificatie is het artefact. De code is het compileerdoel. Elke functie bevindt zich in een afwaarderingsbestand in uw opslagplaats voordat er ook maar één regel code wordt geschreven, en dat bestand wordt het contract waartegen de AI-assistenten uitvoering geven.

Drie dingen aan dat idee zijn belangrijker dan het idee zelf.

Ten eerste staan ​​de specificaties in uw opslagplaats. Niet in een SaaS-dashboard. Niet in een Notion-document dat afdrijft zodra iemand op 'verzenden' drukt. In een openspec/-map, in git, met diffs kun je in PR's bekijken, net als elke andere codewijziging. Dit is het onderdeel dat de meeste teams onderschatten totdat ze zes maanden later moeten reconstrueren wat een functie zou moeten doen. Met OpenSpec beschikt u git log over de specificatie.

Ten tweede zijn de specificaties delta's. OpenSpec heeft iets uitgevonden dat ik in geen enkel ander raamwerk goed heb zien werken: het voorstel is geen nieuw document, het is een wijziging ten opzichte van de bestaande specificaties. Elk voorstel bevat expliciet tags voor toevoegingen, wijzigingen en verwijderingen. Wanneer de wijziging wordt verzonden, worden de delta's samengevoegd met de masterspecificatie. Dit is de brownfield-magie: het is hoe OpenSpec bruikbaar blijft op oudere codebases in plaats van je te dwingen een app van 200.000 regels te gebruiken om deze te gebruiken.

Ten derde is de workflow vloeiend, niet waterval. De officiële Fission-AI-framing is "vloeiend, niet rigide, iteratief en niet watervalachtig" - en na twee weken kan ik bevestigen dat dit geen marketing is. U kunt in elke fase in de workflow stappen, u kunt teruggaan wanneer de implementatie iets onthult dat de specificatie heeft gemist, en u kunt archive uitvoeren om een ​​gedeeltelijke wijziging door te voeren en een nieuwe te starten. Het voelt minder als een proces en meer als een notitieboekje dat structuur afdwingt.

De duidelijkste vergelijking is de [Spec Kit] van GitHub (https://github.com/github/spec-kit). Ik heb beide getest. Spec Kit is zwaarder: de specificaties bedragen ongeveer 800 regels per feature volgens het vergelijkingswerk Hashrocket gepubliceerd, tegenover ongeveer 250 van OpenSpec. Spec Kit behandelt elke feature als zijn eigen, onafhankelijke bestand. OpenSpec consolideert zich tot één levende bron van waarheid die in de loop van de tijd muteert. Voor een schone greenfield-ondernemingsfunctie met formele beoordelingspoorten is de zwaardere output van Spec Kit gerechtvaardigd. Voor al het andere dat ik doe (refactors, nevenprojecten, werk voor bureauklanten) wint de lichtere voetafdruk van OpenSpec omdat de specificaties iets zijn dat ik daadwerkelijk opnieuw zal lezen.

Dat is de filosofische laag. Zo ziet het uitvoeren ervan er in de praktijk uit.

OpenSpec installeren en de eerste ervaring

De installatie is één opdracht. Niet "één opdracht nadat u drie afhankelijkheden hebt geïnstalleerd." Eén opdracht.

npm install -g @fission-ai/openspec
cd your-project
openspec init

Knooppunt 20.19.0 of hoger is vereist. Het init-commando vraagt ​​je welke AI-assistent je gebruikt - ik heb Claude Code gekozen in het Laravel-project, Cursor in het Next.js-project, Codex in de Python-codebase - en het schrijft de juiste slash-opdrachtbindingen in de configuratie van je project, zodat de assistent weet hoe hij OpenSpec moet aanroepen.

Dit is waar ik het eerste merkte waardoor ik de tool vertrouwde. Bij een nieuwe init dumpt OpenSpec u niet voor een leeg document en zegt u "veel succes". Het voert een onboarding-vaardigheid uit die u interactief door uw eerste voorstel leidt. Er wordt gevraagd wat je aan het bouwen bent. Er wordt gevraagd wie de gebruiker is. Er wordt gevraagd wat de succescriteria zijn. Het doet dit in de prijsverlaging die in je opslagplaats aanwezig is, dus het eerste artefact dat je hebt is geen tutorial; het is het begin van een echte specificatie voor een echte functie.

Vergelijk dat eens met mijn ervaring met Spec Kit. De onboarding van de Spec Kit gaat ervan uit dat je het vierfasenmodel (/specify, /plan, /tasks, /implement) al kent en brengt je meteen naar de /specify-stap. Als je de ontwikkeling van spec-driven nog niet eerder hebt gebruikt, schrijf je een specificatie die de verkeerde vorm heeft, en kom je er drie commando's later achter wanneer /tasks onzin produceert.

De onboarding van OpenSpec maakt het verschil tussen leren door te lezen en leren door de eerste keer het juiste te doen. Het is een klein detail. Dat is ook de reden dat ik OpenSpec nu heb aanbevolen aan twee vrienden die nog nooit met de ontwikkeling van spec-driven in aanraking waren gekomen.

De opdrachtreferentie: wat iedereen doet en wanneer ik het gebruik

OpenSpec wordt geleverd met een basisopdrachtenset en een uitgebreide opdrachtenset genaamd opsx waarvoor u zich aanmeldt via openspec config profile. Ik gebruik het uitgebreide profiel omdat ik alle tools wil die het raamwerk biedt. Hier is de volledige tabel, met waar ik ze allemaal voor gebruik in de productie:

| /openspec:apply | Voer de taken uit die in het voorstel zijn gedefinieerd | De bouwfase — loopt ~2 uur autonoom, 3-4 uur met mijn onderbrekingen | | /opsx:verify | Valideer de implementatie op basis van de specificaties, inclusief visuele UI-controles via Chrome-integratie | Ontwerp systeemmigraties, UI-zware functies | | /openspec:archive | Voeg de veranderingsdelta's samen in de masterspecificatie, leg de levende bron van waarheid vast | Elke geleverde functie, geen uitzonderingen | | /opsx:bulk-archive | Archiveer meerdere voltooide wijzigingen in één keer | Einde van een sprint wanneer ik 3-5 features heb verzonden | | /opsx:sync | Synchroniseer de map met hoofdspecificaties met wat zich daadwerkelijk in de codebase | Wanneer ik vermoed dat er tussen code en spec | | /opsx:onboard | Voer de interactieve onboarding-vaardigheid opnieuw uit | Een teamgenoot of een nieuw project meenemen in de OpenSpec-workflow |

De volledige commandolijst bevindt zich in het officiële OpenSpec commands doc, en de uitgebreide profielreferentie bevindt zich in het opsx doc. Wat niet in de documenten staat, is de volgorde waarin ik ze uitvoer of welke ik oversla - en dat is het volgende gedeelte.

De workflow die ik daadwerkelijk uitvoer

Dit is de exacte volgorde die ik heb gevolgd bij het verzenden van een "tijdlijn voor gebruikersactiviteit" vorige week naar de Laravel-beheertool. Het geheel kostte ongeveer vier uur kloktijd, waarvan misschien veertig minuten voor mij en de rest voor OpenSpec op de achtergrond.

Stap 1: Onderzoek voordat u een voorstel doet

Het eerste commando dat ik uitvoer bij elke wijziging boven "triviaal" is /opsx:explore. Dit is de meest onderschatte functie in het raamwerk, en het is het enige dat OpenSpec doet dat GitHub Spec Kit expliciet weigert te doen.

Het ontwerp van Spec Kit gaat ervan uit dat je /specify binnenloopt en al weet wat je wilt bouwen. Die veronderstelling klopt in mijn ervaring ongeveer 70% van de tijd. Wat ik meestal heb is een vaag idee, drie beperkingen die ik me half herinner, en het vermoeden dat er een complicatie is die ik nog niet heb ontdekt. Als ik een specificatie vanuit die staat schrijf, zal de specificatie verkeerd zijn, en daar kom ik vier stappen later achter.

/opsx:explore geeft me een fase waarin ik het hardop mis heb. De agent stelt mij verhelderende vragen. Het onderzoekt de codebasis. Het brengt onduidelijkheden aan het licht waarvan ik niet wist dat ze bestonden. Op het gebied van de activiteitentijdlijn ontdekte de verkenning drie dingen die ik gemist zou hebben als ik meteen naar een voorstel was gegaan: de bestaande auditlogboektabel had een kolomambiguïteit die query-botsingen zou hebben veroorzaakt, twee van mijn 'gebruikersacties' waren eigenlijk twee verschillende gebeurtenissen die ik mentaal aan het instorten was, en de UI-vereiste impliceerde een realtime component waarvoor ik niet had gebudgetteerd.

Dat zijn grofweg twee dagen van herwerken die verkenning in vijftien minuten heeft voorkomen.

Als ik eerlijk ben, heb ik /opsx:explore de eerste drie dagen bijna nooit gebruikt. Het voelde als boven het hoofd. Vervolgens probeerde ik het op een refactor die een verborgen afhankelijkheid bleek te hebben van een verouderde cachelaag, en sindsdien heb ik het niet meer overgeslagen. Het patroon dat ik heb geïnternaliseerd: als ik de verandering niet in één zin zonder kwalificaties kan uitleggen, voer ik eerst explore uit.

Stap 2: Een voorstel doen, doorgaan of vooruitspoelen

Zodra de verkenning de mist heeft opgetrokken, voer ik een van de drie opdrachten uit, afhankelijk van de wijzigingsgrootte:

• /openspec:propose voor kleine, goedomvattende wijzigingen waarbij ik alles in één keer wil genereren.
• /opsx:continue voor grotere wijzigingen wil ik deze opsplitsen in verticale segmenten: eerst het voorstel, dan de specificaties en dan de taken, met een beoordelingspoort ertussen.
• /opsx:ff wanneer de verkenning grondig was en ik wil dat OpenSpec snel vooruit spoelt door de resterende stappen van het voorstel/spec/tasks zonder dat ik door elk poortje moet klikken.

De uitvoer van elk van deze is hetzelfde: een changes/[change-name]/-map met daarin proposal.md (het waarom en wat), design.md (het hoe, inclusief systeemontwerp), een of meer bestanden onder specs/ (de functionele scenario's die als contract fungeren) en tasks.md (de werkverdeling die de assistent zal uitvoeren).

Dit is het moment in de workflow waarop de specificatie niet langer van mij is, maar van het team wordt. Ook al bestaat het team alleen uit mij. Het voorstel is bespreekbaar in een PR. Design.md legt de architecturale beslissingen vast in een taal die ik in de toekomst kan begrijpen. De specs/map is het deel dat de AI-assistent tijdens de implementatie als contract zal behandelen - en cruciaal: het is het deel dat de verandering overleeft en opgaat in de hoofdspecificatie in het archief.

Een opmerking over wat de specificaties van OpenSpec anders maakt. Elke specificatie beschrijft functionele scenario's - gegeven verhalen in /when/then-stijl die gedrag beschrijven. Geen implementatiedetails. Niet "de controller roept de repository aan." Gedrag. Dit is de vorm die wijzigingen in de codebase overleeft. Wanneer ik de persistentielaag over zes maanden refactor, zijn de specificaties nog steeds correct, omdat de specificaties nooit gingen over hoe de persistentielaag werkte. Het ging om wat de gebruiker zag en kon doen.

Stap 3: Toepassen (of: hoe ik stopte met kijken naar de build)

/openspec:apply is de opdracht die de functie bouwt. Dit is waar het grootste deel van de looptijd plaatsvindt: ongeveer twee uur autonoom werken aan de activiteitentijdlijnfunctie, drie tot vier uur wanneer ik onderbreek om dingen halverwege de bouw te verduidelijken.

Wat ik hier moest leren, is wanneer ik moet onderbreken en wanneer ik moet weglopen. Mijn eerste instinct was om op de sollicitatiefase te letten, net zoals ik oppas bij een Claude Code-sessie: lees elk verschil, keur elke bestandswijziging goed en twijfel over elke beslissing. Dat instinct klopt niet bij OpenSpec. De specificatie codeerde al mijn beslissingen. De sollicitatiefase is slechts het uitvoeren van het contract. Als ik merk dat ik wil onderbreken om 'een andere keuze te maken', is de juiste zet bijna altijd het stoppen van de aanvraag, teruggaan naar het voorstel, de specificatie corrigeren en opnieuw solliciteren.

Toen ik dat eenmaal had geïnternaliseerd, liet ik de sollicitatiefase op de achtergrond draaien terwijl ik aan iets anders werkte. Tabblad open, terminal zichtbaar, maar ik staar er niet naar. De eerste keer dat ik dit deed, was ongemakkelijk. De vijfde keer was het het normale patroon. De tiende keer betrapte ik mezelf erop dat ik twee functies parallel had verzonden door in twee terminals te solliciteren tegen twee verschillende voorstellen.

Dit is het moment waarop mijn mentale model van AI-coding veranderde. Het knelpunt was niet langer de uitvoering. Het werd spec-kwaliteit. Dat betekent dat mijn tijd begon te gaan naar het deel van het werk dat eigenlijk menselijk oordeel vereist, en de rest naar de agent werd geduwd.

Stap 4: Verifiëren (de onderschatte killer-functie)

/opsx:verify is het commando waar niemand over praat, en het is het commando dat OpenSpec onvervangbaar maakte in het Next.js-zijproject.

Het Next.js-project omvatte de migratie van een oud ontwerpsysteem naar een nieuw systeem: dezelfde componenten, nieuwe tokens, een nieuwe afstandsschaal, een nieuwe typografie. Dit is een nachtmerriewerk voor AI-codingstools, omdat de code technisch correct en visueel volledig verkeerd kan zijn. Een knop kan renderen. Een knop kan ook in de verkeerde grootte, in het verkeerde lettertype, met de verkeerde randradius worden weergegeven en elke test doorstaan ​​die u hebt geschreven.

/opsx:verify wordt geleverd met een Chrome-extensie-integratie die visuele controles uitvoert op basis van de specificaties. Het laadt de pagina, legt de weergegeven staat vast en vergelijkt deze met de ontwerpintentie die in de specificatie is gecodeerd. Bij de migratie van het ontwerpsysteem werden zeven visuele regressies gedetecteerd die de testsuite miste. Inconsistenties in de afstand. Een verkeerde lettergrootte op een kopvariant. Eén component die een marge had geërfd van het oude systeem en op bepaalde breekpunten zijn rastercel overstroomde.

Dit is de functie die in geen enkele andere AI coding framework bestaat die ik heb getest. Spec Kit heeft het niet. BMAD heeft het niet. Obra Superpowers kunnen afdwingen dat je tests hebt geschreven, maar kunnen je niet vertellen dat de test is geslaagd terwijl de pagina er verkeerd uitziet. Voor UI-zwaar werk, vooral ontwerpsysteemmigraties, is /opsx:verify het verschil tussen verzending en correcte verzending.

Het eerlijke voorbehoud: het is geen magie. Voor de Chrome-extensie moet uw ontwikkelaarsserver actief zijn. De visuele controles zijn slechts zo goed als de ontwerpintentie die u in de specificatie heeft gecodeerd. En het kan geen interactiebugs opvangen, alleen statische weergaveproblemen. Maar voor de klasse van bugs die het opmerkt, doet niets anders dat.

Stap 5: Archiveren (de truc met levende documentatie)

Dit is de stap die ik de eerste week bijna oversloeg. Het is ook de stap die stilletjes het belangrijkste is.

/openspec:archive neemt de wijziging die u zojuist hebt verzonden en voegt de delta's ervan samen in de hoofdmap specs/. Het voorstel wordt verplaatst naar een map changes/archive/. De masterspecificatie – de levende bron van de waarheid – zorgt ervoor dat de nieuwe functionaliteit wordt samengevoegd, de wijzigingen worden toegepast en de verwijderingen worden verwijderd.

Het resultaat is dat uw repo na elke geleverde functie een actuele, nauwkeurige, machinaal leesbare beschrijving bevat van hoe het hele systeem zich gedraagt. Geen verouderde README. Geen Confluence-pagina die al achttien maanden niet is aangeraakt. De werkelijke huidige staat.

Ik heb zes dagen na het gebruik van OpenSpec getest wat dit betekent door Claude Code te vragen een nieuwe functie aan het Laravel-project toe te voegen - zonder er enige context aan te geven. Ik vertelde het: "lees openspec/specs/ en stel vervolgens een wijziging voor die X toevoegt." Hij las de specificaties. Het stelde een wijziging voor die twee bestaande functies waarmee het zou moeten communiceren, correct identificeerde. Het deed dit zonder enige vraag van mij over de codebase-architectuur, omdat de architectuur al in de specificatie zat.

Dit is de eerste keer dat ik zie dat "levende documentatie" feitelijk een dragend onderdeel is van een AI-codingsworkflow in plaats van een 'nice-to-have'. Bij de meeste projecten besteedt u de eerste vijf minuten van elke Claude Code-sessie aan het opnieuw laden van de context. Met OpenSpec laadt de context zichzelf.

Als archive ooit als overhead voelt, kan ik je beloven dat dit niet zo is. Door het archief over te slaan, rotten spec-driven-projecten. Elk team met wie ik heb gesproken over de verlaten spec-driven-ontwikkeling deed dit omdat hun specificaties afweken van hun code. Archief is de discipline die drift voorkomt. Behandel het als onderdeel van 'feature done', niet als een optionele opschoonstap.

Waar OpenSpec tekortschiet (het eerlijke gedeelte)

Ik ben twee weken bezig en een fan, maar een fan die dit in drie projecten met heel verschillende vormen heeft uitgevoerd. Hier helpt het niet.

Kleine wijzigingen. Als de wijziging 'repareer deze typfout' of 'hernoem deze variabele', is de OpenSpec-workflow overhead. Doe geen voorstel voor een oplossing van één regel. Het raamwerk doet niet anders alsof – Fission-AI raadt dit expliciet af – maar ik heb gezien hoe nieuwkomers elke verandering door de voorstelstroom heen forceerden en eindigden met een changes/-map die eruitzag als een kerkhof van triviale PR's. Gebruik OpenSpec voor zaken waar over nagedacht wordt. Sla het over voor dingen die dat niet doen.

Solo-codeersessies waarbij je echt niet weet wat je wilt. Als je in de pure verkenningsmodus bent (schetsen, prototypen maken, code tegen de muur gooien) zal de voorstelfase je vertragen. Het juiste patroon hier is om eerst vibe-code te gebruiken, en als je eenmaal weet wat je hebt gebouwd, schrijf je de specificaties met terugwerkende kracht en archive deze als het eerste voorstel. OpenSpec vindt deze stroom prima. Maar proberen iets te specificeren dat je nog niet hebt ontworpen, is het ergste van beide werelden.

De toepassingsduur van twee uur is reëel. De meeste toepassingsruns vallen binnen het bereik van 90-180 minuten voor niet-triviale functies. Als u een functie binnen twintig minuten nodig heeft, is OpenSpec niet het juiste hulpmiddel. Dit is geen fout: de kwaliteit van de specificaties maakt de toepassingsfase betrouwbaar, en die kwaliteit kost tijd om te coderen en uit te voeren. Maar beheer uw verwachtingen. OpenSpec is een hulpmiddel voor correcte verzending, niet voor snelle verzending.

Brownfield-onboarding heeft ruwe kantjes. Op de geërfde Python-codebase resulteerde mijn eerste poging om OpenSpec te introduceren in een masterspecificatie die ongeveer 40% nauwkeurig was ten opzichte van de daadwerkelijke code. Het raamwerk probeerde specificaties af te leiden uit code die geen leidende principes had, en de gevolgtrekkingen waren noodzakelijkerwijs vaag. De oplossing was het correct uitvoeren van /opsx:onboard, waarbij het tijd kostte om de hoofdspecificatie voor de kernstromen met de hand te schrijven, en vervolgens OpenSpec te gebruiken voor nieuwe wijzigingen. Als je binnenkomt in de verwachting dat je OpenSpec op een oudere codebase plaatst en deze de codebase vrijdag begrijpt, zul je teleurgesteld zijn. Plan een echte onboardingweek.

De community is klein. Vergeleken met de GitHub-aanwezigheid van BMAD of de bedrijfsondersteuning van Spec Kit, is OpenSpec het kleinere ecosysteem. De documenten zijn goed. De releasecadans is gezond. Maar er is nog geen grote hoeveelheid tutorials, plug-ins of integraties van derden. Als je iets nodig hebt dat het raamwerk niet standaard doet, schrijf je het zelf. Voor mij is dit prima – ik heb liever een klein, gericht hulpmiddel dan een groot, opgeblazen hulpmiddel – maar het is de moeite waard om te weten.

Waar OpenSpec nu in mijn stapel past

Na twee weken staat OpenSpec helemaal bovenaan mijn AI-codingsworkflow — boven Claude Code, boven de agentvaardigheden die ik uitvoer, boven de planningsnotities die ik altijd bewaarde in Obsidian. Het is het eerste wat ik aanraak bij een niet-triviale wijziging en het laatste wat ik aanraak als ik het verzend.

De volledige stapel ziet er als volgt uit:

1. OpenSpec schrijft en onderhoudt de specificaties: het contract voor wat er wordt gebouwd
2. Claude Code met Obra Superpowers voert de specificatie uit met TDD-handhaving tijdens de toepassingsfase
3. Standaard git review vangt op wat TDD heeft gemist
4. Archief vergrendelt de wijziging in de woonspecificatie, klaar voor de volgende iteratie

Elk gereedschap doet datgene waar het het beste in is. OpenSpec probeert TDD niet af te dwingen – dat is de taak van Superkrachten. Superpowers probeert niet de specificaties te beheren – dat is de taak van OpenSpec. Claude Code probeert niet alles te onthouden wat is gebouwd; dat is de taak van de hoofdspecificatie.

Deze scheiding van zorgen zorgt ervoor dat de stapel daadwerkelijk wordt geschaald. Als er iets kapot gaat, weet ik welke laag ik moet debuggen. Als ik één onderdeel wil upgraden, kan ik het ruilen zonder de andere opnieuw op te bouwen. De samenstelbaarheid is de overwinning.

Moet u OpenSpec gebruiken?

Drie vragen om eerlijk te beantwoorden:

Verstuurt u functies die meer dan twee uur geconcentreerd werk vergen? Zo ja, dan betaalt OpenSpec zichzelf terug met de tweede functie. Als u alleen microwijzigingen verzendt, kunt u dit overslaan.

Komt u na twee weken wel eens terug op een project en moet u de context opnieuw laden? Zo ja, dan bespaart de woonspecificatie u elke maand uren. Als uw projecten allemaal actueel zijn en uw geheugen perfect is, is de waarde lager.

Vertrouwt u meer op uw AI-assistent als deze een duidelijk contract heeft om uit te voeren? Zo ja, dan is OpenSpec de contractlaag. Als u liever gewoon met de assistent praat en stap voor stap stuurt, zal de voorstelstroom als wrijving aanvoelen.

Ik heb op alle drie de vragen ja geantwoord, en OpenSpec is de meest consequente toevoeging aan mijn workflow geweest sinds ik Claude Code begon te gebruiken. Niet omdat het iets dramatisch beter doet dan de alternatieven, maar omdat het elk ander hulpmiddel in mijn stapel betrouwbaarder maakt. De specificatie is het stroomopwaartse knelpunt. OpenSpec heeft het knelpunt schoon gemaakt.

Veelgestelde vragen

Waar wordt OpenSpec voor gebruikt?

OpenSpec is een spec-driven-ontwikkelingsframework voor AI-codingsassistenten. U schrijft een prijsspecificatie voor een functie en het raamwerk coördineert met uw AI-assistent (Claude Code, Cursor, Codex en meer dan 20 anderen) om de specificatie te implementeren, het resultaat te valideren en de verandering samen te voegen tot een levende bron van waarheid. Het wordt het meest gebruikt voor middelgrote tot grote functies in brownfield-codebases waar spec-kwaliteit samengestelde waarde heeft.

Waarin verschilt OpenSpec van de GitHub-specificatiekit?

OpenSpec consolideert specificaties in één levend document met op delta gebaseerde wijzigingen, terwijl Spec Kit afzonderlijke specificatiebestanden per functie bijhoudt. OpenSpec produceert lichtere specificaties (ongeveer 250 regels versus 800 Spec Kit), ondersteunt native brownfield-codebases en biedt een iteratieve workflow met de /opsx:explore-fase. Het zwaardere vierfasenmodel van Spec Kit past beter bij formeel groen ondernemingswerk. Voor een diepere uitsplitsing, zie "Wat OpenSpec eigenlijk is" hierboven.

Werkt OpenSpec met Claude Code?

Ja – Claude Code is een van de meer dan 20 ondersteunde AI-codeerassistenten. Tijdens openspec init selecteert u Claude Code als uw assistent en OpenSpec schrijft de overeenkomstige slash-opdrachtbindingen naar uw project. Cursor, Codex, Windsurf, Continue, GitHub Copilot, Amazon Q, Gemini CLI en andere worden ook volledig ondersteund.

Hoe lang duurt een OpenSpec-aanvraagrun?

Een typische openspec apply-run belandt in het bereik van 90-180 minuten voor niet-triviale functies wanneer deze autonoom wordt uitgevoerd. Door menselijke controlepunten en verduidelijking halverwege de bouw toe te voegen, wordt dit uitgebreid tot 3-4 uur wandkloktijd. Het grootste deel van die tijd is de AI-assistent aan het werk en wacht niet. Je kunt hem op de achtergrond laten draaien terwijl je aan iets anders werkt.

Kan OpenSpec BMAD of Obra Superpowers vervangen?

Nee, en je moet ook niet proberen het te halen. OpenSpec is een spec-driven-framework. BMAD is een autonome pijplijnorkestrator. Obra Superpowers is een SDLC-handhavingslaag. Ze lossen verschillende problemen op en passen goed bij elkaar: OpenSpec schrijft de specificaties, Superpowers dwingt TDD af tijdens de build, BMAD orkestreert pijplijnen met meerdere functies. Voor een volledig overzicht van deze drie categorieën, zie de vergelijkingstabel bovenaan dit artikel.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io