Spec-Driven Development voor AI Agents, Goed Uitgevoerd: Specs als Beheerde Artefacten

Spec-driven development is die zeldzame buzzword met een duidelijk spoor van bewijs. Het heeft een oprichtingslezing (Sean Grove's "The New Code," AI Engineer World's Fair 2025), vlaggenschip-tooling van twee giganten (GitHub's Spec Kit, AWS's Kiro), een radicale vleugel (Tessl's spec-as-source), en een nuchtere taxonomie van Thoughtworks die de ambitieniveaus scheidt. Het kernidee heeft een jaar van kritische beschouwing goed doorstaan omdat het iets echts omvat: wanneer agents de code schrijven, is de specificatie — niet de prompt, niet de code — waar de menselijke intentie daadwerkelijk leeft. Daarom moet deze als eerste worden geschreven, bewaard en behandeld als de bron van waarheid. Wat de beweging nog niet volledig heeft uitgewerkt, is wat er gebeurt op vlaotschaal, wanneer de specs zelf de wildgroei worden: tientallen spec-bestanden, concurrerende AGENTS.md-varianten, en geen enkel overzicht van welke spec welk uitgerold gedrag heeft geproduceerd. Dat is het gedeelte waar deze post over gaat — want een spec is scaffold, en scaffold is iets dat je kunt beheren.

Bastien, een engineering manager, was een vroege en oprechte bekeerling. Zijn team voerde in het najaar spec-driven development in, en het leverde precies wat de lezingen beloofden: functies die voorheen strrandden in prompt-pingpong werden opgeleverd vanuit een spec van één pagina, reviewgesprekken gingen naar een hoger niveau, en het venster voor veilige delegatie reikte van taken van twintig minuten naar taken die een hele middag besloegen. Zes maanden later voerde hij een audit uit en ontdekte hoe succes eruitziet als niemand het beheert: een-en-veertig spec-bestanden over negen repos, waarvan vier dezelfde service anders beschreven; negen AGENTS.md-varianten, waarvan drie automatisch gegeneerd en zo uitgedijd dat geen model ze nog betrouwbaar volgt; specs die waren afgeweken van de code die ze ooit hadden geproduceerd, zonder overzicht van welke versie van welke spec de agent-run had gevormd die een bepaald gedrag opleverde. De praktijk was juist. De artefacten waren wildgroei geworden. Bastien's vraag aan zijn platformteam was de vraag die deze post beantwoordt: "we hebben van specs de bron van waarheid gemaakt — dus waarom heeft de waarheid geen versiebeheer?"

Om die te beantwoorden, beginnen we waar de term begon — het oorsprongsverhaal bevat precies het argument dat van governance de logische volgende stap maakt.

1. Waar de Buzzword Vandaan Komt: Grove, de Versnipperde Bron en de Model Spec

Een veelgeciteerd beginpunt is een conferentiepresentatie. Op de AI Engineer World's Fair in San Francisco in 2025 gaf Sean Grove — destijds werkzaam aan alignment bij OpenAI — de lezing "The New Code," die door veel mensen in de praktijk wordt geciteerd als de scherpste formulering van de beweging. Hij gaf het een centraal beeld: ontwikkelaars prompten een model, bewaren de gegenereerde code en gooien de prompt weg, wat Grove vergeleek met het versnipperen van de broncode en het toepassen van versiebeheer op het binary-bestand. Zijn argument ging dieper dan workflow-hygiëne. Code, zo stelde hij, was altijd slechts een deel van de waarde van een programmeur; het grotere deel is de gestructureerde communicatie van intentie — en een geschreven specificatie is het artefact dat mensen op één lijn brengt over wat er gebouwd moet worden voordat het ooit een model op één lijn brengt. Grove's voorbeeld was OpenAI's eigen Model Spec: een living Markdown-document met versiebeheer dat het beoogde modelgedrag van het bedrijf uitdrukt, waarin clausules unieke ID's en voorbeeldprompts bevatten die fungeren als unittests. Intentie, één keer geschreven, voorzien van versiebeheer, testbaar — en geconsumeerd door zowel mensen als machines.

De reactie uit de industrie gaf het idee zijn naam en zijn tools. GitHub bracht in september 2025 Spec Kit uit als open-source, en verwoordde de verschuiving onomwonden — in hun woorden stijgt de lingua franca van ontwikkeling naar een hoger niveau, en wordt code de 'last mile'. AWS lanceerde Kiro, een IDE die zijn spec-workflow centreert op Requirements, Design en Tasks voorafgaand aan de uitvoering. Tessl nam het radicale uiterste in: specs als het primaire onderhouden artefact, waarbij de code eruit wordt geregenereerd. En Andrej Karpathy — die in februari 2025 de term "vibe coding" had bedacht — beschreef de volgende fase een jaar later als agentic engineering: het orchestreren van agents tegen gedetailleerde specificaties met menselijk toezicht. Het vibe-tijdperk benoemde het probleem; SDD benoemde de correctie.

2. Wat SDD Daadwerkelijk Is — en Böckeler's Ladder

Omdat de term sneller omarmd werd dan de definitie ervan, is de meest nuttige kaart Birgitta Böckeler's analyse van oktober 2025 voor Thoughtworks (gepubliceerd op martinfowler.com), waarin Spec Kit, Kiro en Tessl werden onderzocht. Ze vond niet één praktijk, maar een ladder van ambitie. Spec-first: schrijf een weldoordachte spec, gebruik deze om de AI-ondersteunde taak aan te sturen, klaar — de spec hoeft de functie niet te overleven. Spec-anchored: bewaar de spec nadat de taak is voltooid en ontwikkel de functie via de spec verder — de spec wordt de onderhouden beschrijving van het gedrag. Spec-as-source: de positie van Tessl — de spec is het artefact dat u onderhoudt; code is de gecompileerde uitvoer ervan. De meeste teams die SDD vandaag de dag toepassen, bevinden zich op de eerste twee sporten, en de workflow is overal herkenbaar hetzelfde: specificeren, plannen, opsplitsen in taken, implementeren — waarbij de agent de spec in elke fase consumeert.

Waarom het werkt, is ook niet langer speculatief. Gestructureerde specs beperken de zoekruimte die onbeperkte generatie chaotisch maakt; acceptatiecriteria geven de agent (en zijn verificateur) iets dat controleerbaar is; en opsplitsing verandert een vage functie in taken op agent-formaat. Praktijkrapporten beschrijven dat het venster voor veilige delegatie zich uitbreidt van taken van tien tot twintig minuten naar de oplevering van functies van meerdere uren met een constante kwaliteit — praktijkbewijs van teams die de werkwijze overnemen in plaats van gecontroleerde studies, en als zodanig het lezen waard. De eerlijke grens kwam uit dezelfde Thoughtworks-analyse die de ladder in kaart bracht: SDD is geschikt voor grotere functies en greenfield-werk; voor een kleine bugfix wegen de overheadkosten van een spec niet op tegen de baten. Een discipline die weet waar deze niet van toepassing is, is er meestal een om serieus te nemen.

3. De Bijbehorende Discipline: Terughoudendheid en het Instructiebudget

SDD werd geïntroduceerd met een zustermethode die even belangrijk is voor agents: het bestand met staande instructies — AGENTS.md, CLAUDE.md, en soortgelijke bestanden — dat in elke agent-sessie meelift als de permanente stem van het project. De zwaarbevochten consensus uit 2026 over deze bestanden is een betoog voor terughoudendheid. Richtlijnen voor de praktijk kwamen uit op een werkbaar getal: topmodellen worden vaak behandeld als modellen die betrouwbaar in de orde van 150–200 staande instructies volgen voordat de naleving begint te verslechteren — een vuistregel, geen modelgarantie — dus het automatisch gegenereerde agent-bestand waarin alles is opgenomen, is een faalmodus vermomd als zorgvuldigheid. De aanbevelingen die naar voren kwamen, lezen als de checklist van een redacteur: houd het bestand slank (de veelgeciteerde aanbeveling van HumanLayer is minder dan ~300 regels); structureer het als WHAT/WHY/HOW — stack en structuur, doel, build-commando's en conventies; voeg expliciete do/don't-lijsten en permissiegrenzen toe; documenteer geen bestandspaden (die verouderen), gebruik het bestand niet als een linter (gebruik linters), en voeg geen taakspecifieke instructies toe die op vrijdag al verouderd zijn. Voor grotere codebases: stapsgewijze onthulling (progressive disclosure) — een kort root-bestand, met diepere bestanden die geladen worden waar ze relevant zijn.

Lezers van deze reeks zullen beide helften van dat advies herkennen. Het instructiebudget is een feit uit context-engineering in een documentatiejasje — staande instructies zijn vooraf geladen context, en vooraf geladen massa vermindert de aandacht op precies de manier die onze JIT context-post beschrijft; stapsgewijze onthulling is just-in-time laden toegepast op specs. En "het agent-bestand is de permanente stem van het project" is een scaffold-claim — wat de rode draad is die leidt naar de governance-kloof, want Bastien's negen opgeblazen varianten waren geen schrijfprobleem. Ze waren het probleem van een artefact zonder eigenaar.

4. De Kloof op Vlaotschaal: Specs Zijn Gedrag, en Gedrag Vertoont Wildgroei

Hier is de structurele observatie die het SDD-betoog meestal nog niet heeft bereikt. Alles wat de beweging zegt over specs — bron van waarheid, geconsumeerd door agents, mensen op één lijn brengen — is de bewering dat specs gedrag bepalen. In de terminologie van de agent-begrippenlijst is een spec scaffold: inhoud van waaruit het model werkt. Een wijziging aan scaffold is een beleidswijziging — gedragsmatig dezelfde categorie gebeurtenis als een modelwissel. SDD, als het oprecht wordt toegepast, vermenigvuldigt precies deze artefacten: featurespecs, planbestanden, taaklijsten, AGENTS.md-varianten, acceptatiecriteria. Elk daarvan sturt agents aan. Vrijwel geen van deze artefacten heeft bij een typische adoptie een versiehistorie die gekoppeld is aan deployments, een eigenaar, een reviewpad, of een antwoord op de vraag "welke runs zijn door dit bestand gevormd?"

Dat is Bastien's audit, bij de naam genoemd. Een-en-veertig specs en negen agent-bestanden zijn geen netheidsprobleem — het zijn een-en-veertig invoeren voor gedrag zonder versiebeheer en negen concurrerende staande beleidsregels. De bekende SDD-knelpunten leiden allemaal terug naar dezelfde oorzaak: spec/code-drift (vroege SDD-gebruikers melden vaak dat specs en code niet meer synchroon lopen tenzij de spec wordt bijgewerkt als onderdeel van de workflow) is niet-gemonitorde divergentie tussen de verklaarde waarheid en de uitgerolde waarheid; dubbele specs zijn vertakt beleid; opgeblazen automatisch gegenereerde agent-bestanden zijn niet-gereviewde beleidsaanwas. De beweging heeft specs belangrijk gemaakt; ze heeft ze nog niet beheerd gemaakt. Software heeft dit exacte probleem voor code opgelost met versiebeheer, code-reviews, CI-gates en deployment-records — en de oplossing voor specs is hetzelfde mechanisme, gericht op de nieuwe artefactklasse.

5. Specs als Beheerde Scaffold: De Koppeling

Haal de lijst met SDD-artefacten door een platform dat scaffold al behandelt als beheerde inhoud, en elk item komt op een specifieke plek terecht. Staande instructies — de rol van AGENTS.md — horen bij de agentdefinitie op TrueFoundry's Agent Harness: ze moeten worden opgeslagen als inhoud met versiebeheer, beoordeeld als diffs, en gerefereerd door de definitie in plaats van ad-hoc te worden bewerkt in een promptvenster — zodat de discipline van terughoudendheid een reviewer heeft, niet alleen een auteur. Herbruikbare procedurespecs — de runbooks, de "hoe we hier migraties uitvoeren," de stappenplannen voor acceptatie — zijn skills: ze worden gepromoveerd naar de Skills Registry als SKILL.md-artefacten met versiebeheer en RBAC, vastgepind door agents als skill@versie, en just-in-time gekoppeld — wat stapsgewijze onthulling letterlijk toepast: de eenregelige beschrijving van de catalogus reist mee; de volledige procedure wordt geladen bij activering. Één spec, veertig agents, nul vertakkingen.

Feature specs en plannen kunnen in de repo blijven waar het werk leeft, maar de agent-run moet de onveranderlijke versie of commit-SHA vastleggen in de trace-metadata — en de harness legt de stappen van elke run al vast, zodat de spec-versie meereist met de run in plaats van achteraf te moeten worden gereconstrueerd. Doe dat, en "welke spec-versie heeft deze run gevormd" wordt een query in plaats van archeologie. En het gehele geheel is het beleid: de agentdefinitie — model bij naam, instructies op een versie, vastgepinde skills, gereedschapsrechten — is één declaratief artefact waarvan diffs kunnen worden gemaakt. Dit is precies de eenheid waarvan onze beleidspost betoogt dat deze als één geheel van versiebeheer, gates en rollback-mogelijkheden moet worden voorzien. Het prettige aan deze koppeling is dat niets ervan haaks staat op SDD; het maakt het oorspronkelijke argument compleet. Grove's betoog was dat intentie het verdient om een testbaar eersteeklas artefact met versiebeheer te zijn. De Model Spec deed dat voor het modelgedrag van één organisatie. De governance-baan doet dit voor elke spec die uw vloot consumeert.

Een agentdefinitie in SDD-vorm: specs als vastgepinde scaffold met versiebeheer (ter illustratie)

6. Spec-Wijzigingen Door de Gate

De operationele consequentie verdient een eigen sectie omdat daar het grootste onbehandelde risico van SDD schuilt. Als de spec de bron van waarheid is en agents hiertegen implementeren, dan is een spec-bewerking de wijziging met de hoogste impact in het systeem — het stuurt elke stroomafwaartse agent-beslissing bij — en bij de meeste toepassingen is het ook de wijziging met de minste formaliteit: een Markdown-bewerking, samengevoegd op vrijdag, geconsumeerd door de runs van maandag. De oplossing is de beleidsdiscipline die zonder uitzondering wordt toegepast: een wijziging aan een spec of agent-bestand moet het versienummer verhogen, de versiewijziging moet de evaluatie-gate triggeren (dezelfde suite waar een modelwissel mee te maken krijgt — gedragsmatig is het hetzelfde type gebeurtenis), en de promotie moet gefaseerd verlopen. Voor gedeelde skills wordt een nieuwe versie gecontroleerd per agent uitgerold, en niet stilzwijgend over het gehele register. Niets hiervan vertraagt de eenvoudige bewerking; het zorgt er allemaal voor dat de kostbare bewerking zichtbaar wordt voordat de productie eronder lijdt.

Hetzelfde mechanisme lost het drift-probleem eerlijk op. Spec/code-drift is onvermijdelijk bij een spec-first-aanpak en beheersbaar bij een spec-anchored-aanpak — maar alleen als afwijkingen detecteerbaar zijn. Daarvoor is het nodig te weten van welke spec-versie het uitgerolde gedrag afkomstig is. Wanneer runs de spec-versie vastleggen die ze hebben geconsumeerd, wordt drift een verschil (diff) tussen de huidige spec en de versie die het laatst de gate heeft gepasseerd, opgesteld volgens een schema — in plaats van een ontdekking tijdens een incident, wat de plek is waar Bastien de zijne vond.

7. Eerlijke Grenzen: Waar SDD Onder Druk Staat

De sceptici verdienen hun eigen sectie, omdat hun sterkste punten het governance-ontwerp vormen. De waterval-kritiek — SDD als herleefde documenten met vereisten — is terecht overal waar specs eenmalig, uitputtend en vooraf worden geschreven; de praktijk blijft overeind door specs slank en iteratief te houden in plaats van encyclopedisch. Het bezwaar dat "code de ultieme uitvoerbare waarheid is" — wanneer gegenereerde code onjuist is, herstel je de code, niet de tekst — is in essentie waar, en dat is precies waarom spec-as-source een minderheidspositie blijft; spec-anchored, met driftdetectie, is het verdedigbare middenweg. En het punt over overhead blijft overeind zoals de eigen analyse van Thoughtworks het formuleert: kleine correcties rechtvaardigen de formaliteit niet, dus de governance-baan heeft een evenredig snel pad nodig — leg de versie vast, voer de goedkope geautomatiseerde gate uit, en sla de commissie over.

Nog een grens is intern aan het argument van deze post: versiebeheer toepassen op specs maakt ze niet automatisch goed. Een nauwkeurig beheerde slechte spec levert nauwkeurig traceerbaar slecht gedrag op. Het instructiebudget, de WHAT/WHY/HOW-structuur, de controleerbare acceptatiecriteria — de ambachtelijke helft van SDD — blijft menselijk werk. De bijdrage van het platform is waardevol maar begrensd: het maakt het ambacht beoordeelbaar, toewijsbaar en veilig om op te itereren.

8. Een Minimaal Levensvatbare Governance-Baan

Niets hiervan vereist een herschrijving van het platform. De baan bestaat uit vijf artefactklassen, elk met een eigenaar, een versiebeheermechanisme, een gate die in verhouding staat tot de mogelijke impact, en een veld op de run-trace dat het koppelt aan gedrag. Het onderstaande patroon is wat wij een team zouden aanraden om als eerste op te zetten; de rij van de Skills Registry is een gedocumenteerde functionaliteit van TrueFoundry, de rest zijn conventies die elk team vandaag nog kan overnemen in hun repo en hun harness-configuratie.

Het resultaat is één enkel overzichtelijk record per run. Wat het gedrag ook heeft gevormd — instructies, spec, plan, skills, tool-beleid — het staat met naam en versie vastgepind op de trace, zodat de vraag na een incident een opzoekactie wordt in plaats van een opgraving:

Een run-trace die antwoord geeft op de vraag "welke versies hebben dit gedrag gevormd?" (ter illustratie)

Skill-versies komen uit het register als een volwaardige functionaliteit; de spec-, plan- en instructieversies zijn commit-SHA's die u kiest om vast te leggen op de run. De discipline is goedkoop in te voeren en levert steeds meer voordeel op: de eerste keer dat een agent gedrag oplevert dat niemand kan verklaren, is dit record het verschil tussen een snelle query en een crisissituatie.

9. De Uitkomst: Bastien's Tweede Audit

Opgebouwd op beheerde sporen ziet Bastien's omgeving er zes maanden later zo uit. De negen AGENTS.md-varianten zijn drie beoordeelde instructiesets geworden — één per domein — elk slank genoeg om binnen het instructiebudget te blijven, elk voorzien van versiebeheer, elk met een eigenaar wiens naam op de diff staat. De herbruikbare procedures die verborgen zaten in featurespecs zijn geëxtraheerd naar zeven register-skills, op versie vastgepind over de gehele vloot; het migratie-runbook dat in vier strijdige exemplaren bestond, bestaat nu één keer, op v4, en het register kan elke agent vermelden die het gebruikt. Feature specs leven nog steeds bij hun functies — SDD's workflow is niet veranderd — maar elke harness-run legt de spec- en instructieversies die zijn geconsumeerd vast in de trace-metadata. Daardoor is "welke spec heeft dit gedrag geproduceerd" een query met een antwoord, en krijgt een spec-bewerking te maken met dezelfde eval-gate als een modelwissel. De een-en-veertig bestanden zijn geen bureaucratie geworden. Ze zijn een inventaris geworden.

Dat is de voltooiing van het oorspronkelijke argument, geen herziening ervan. Grove's punt was dat intentie beter verdient dan een versnipperde prompt; de SDD-tools maakten van intentie een geschreven artefact; de governance-baan maakt er een beheerd artefact van — voorzien van versiebeheer, afgeschermd met gates, getraceerd en gedeeld zonder vertakkingen. De lingua franca van ontwikkeling is inderdaad naar een hoger niveau gestegen. De infrastructuur moet deze daar naartoe volgen.

10. Veelgestelde Vragen

Wie heeft "spec-driven development" eigenlijk bedacht? Er is geen enkele bedenker aan te wijzen — de term is in de loop van 2025 ontstaan in plaats van op één moment te verschijnen. De meest geciteerde intellectuele vonk is Sean Grove's lezing "The New Code" op de AI Engineer World's Fair 2025; GitHub's Spec Kit (september 2025) en AWS's Kiro gaven de praktijk zijn tooling en een groot deel van zijn vocabulaire; Tessl pushte de verregaande vorm; en Birgitta Böckeler's Thoughtworks-analyse (oktober 2025) gaf het de spec-first / spec-anchored / spec-as-source taxonomie die de meeste mensen in de praktijk nu gebruiken. De credit gaat naar een beweging, niet naar één moment.

Is SDD niet gewoon waterval met extra stappen? Het vertoont overeenkomsten, en beweren dat dit niet zo is doet afbreuk aan de geloofwaardigheid. De verschillen die er toe doen: SDD-specs zijn slank en iteratief in plaats van uitputtend en vaststaand; de implementatiecycli duren uren in plaats van kwartalen, waardoor spec en code continu naar elkaar toe kunnen groeien; en de consument van de spec is een agent die deze daadwerkelijk uitvoert, iets wat 'big-upfront-design' nooit had. Waar teams encyclopedische specs één keer schrijven en over de schutting gooien, hebben ze de faalmodus opnieuw uitgevonden, met of zonder agents.

Hebben AGENTS.md-bestanden echt governance nodig? Het is toch gewoon documentatie. Het zijn staande instructies die bij elke agent-sessie worden geconsumeerd — gedragsbepalende inhoud, geen documentatie. Een niet-beoordeelde bewerking hiervan is een stille beleidswijziging voor elke run die ermee in aanraking komt. Dat is precies de categorie wijzigingen waarvoor versiebeheer en reviews bestaan. De praktische test: als het bewerken van het bestand kan veranderen wat er naar productie gaat, is het niet "gewoon documentatie."

Waar ligt de grens tussen een spec en een skill? Omvang en hergebruik. Een featurespec beschrijft één onderdeel van het werk en blijft daarbij. Een skill is een herbruikbare procedure — hoe deze organisatie migraties, reviews of incidentverslagen uitvoert — die door de tijd heen door veel agents wordt geconsumeerd. Dat is wat een behandeling in het register rechtvaardigt: versies, RBAC, vastpinnen en just-in-time koppelen. Wanneer dezelfde tekst steeds tussen specs wordt gekopieerd, is dat het signaal voor een promotie naar een skill.

We zijn twee engineers met één agent. Is dit op ons van toepassing? De ambachtelijke helft absoluut — spec-first, slanke agent-bestanden en controleerbare acceptatiecriteria zijn op elke schaal waardevol. De governance-baan wordt pas noodzakelijk bij schaalvergroting: meer agents, meer auteurs, meer gedeelde specs. Voer het in bij het eerste gesprek over "welke spec is de echte?"; daarvoor zijn een git-repo en discipline eerlijk gezegd voldoende.

Referenties

• Sean Grove (OpenAI) — "The New Code," AI Engineer World's Fair 2025 — het fundamentele argument: specs als het van versie voorziene, testbare thuisadres van intentie. Grove's voorbeeld, OpenAI's Model Spec, is het toonbeeld van intentie geschreven als een van versie voorzien, testbaar Markdown-document. Geparafraseerd met bronvermelding; geciteerde fragmenten zijn korter dan vijftien woorden.
• Birgitta Böckeler (Thoughtworks) — "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl," martinfowler.com, oktober 2025 — de spec-first / spec-anchored / spec-as-source taxonomie en de eerlijke kanttekeningen bij waar SDD van toepassing is.
• GitHub Spec Kit (september 2025) — de Specify → Plan → Tasks → Implement flow (/speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement) en de "executable specifications" benadering.
• AWS Kiro — de spec-workflow gecentreerd rond requirements.md, design.md en tasks.md met EARS-style acceptatiecriteria, van requirements via design tot task execution.
• Tessl — de spec-as-source positie: de spec als het primair onderhouden artefact, code hieruit opnieuw gegenereerd.
• Andrej Karpathy — "vibe coding" (februari 2025) en de daaropvolgende discussie over agentic engineering tegen gedetailleerde specificaties met menselijk toezicht.
• Richtlijnen uit de praktijk voor agent instruction files (instruction budgets, aanbevelingen voor bestandslengte, WHAT/WHY/HOW, progressive disclosure) — community engineering-artikelen waaronder die van HumanLayer, begin 2026; behandeld als vuistregels, niet als gecontroleerde studies, en in de tekst toegeschreven. EPAM's Spec Kit field report is de vaak geciteerde bron voor uitgebreide delegation windows, gelezen als bewijs uit de praktijk in plaats van een gecontroleerde studie.
• TrueFoundry Agent Harness en Skills Registry — de gedocumenteerde functionaliteiten waarop deze post is gebaseerd: van versie voorziene, door RBAC beheerde, vastzetbare, terugdraaibare, geauditeerde SKILL.md-artefacten met progressive disclosure, plus harness orchestration, sandboxing, goedkeuringen en tracing.

Northwind en Bastien zijn een illustratief composiet, geen specifieke organisatie. De oorsprong is gerapporteerd volgens openbare presentaties, posts en analyses op het moment van schrijven — Grove's talk, de lanceringen van GitHub en AWS, Tessl's positionering en Böckeler's Thoughtworks-taxonomie — geparafraseerd met bronvermelding; geciteerde fragmenten zijn korter dan vijftien woorden en voorzien van bronvermelding. Praktijkcijfers (instruction budgets, richtlijnen voor bestandslengte, rapporten over delegation windows) zijn community-richtlijnen, geen gecontroleerde studies. Configuratie-snippets zijn vereenvoudigd voor de leesbaarheid en zijn geen letterlijk product-schema. TrueFoundry-functionaliteiten weerspiegelen de openbare documentatie op het moment van schrijven; controleer deze met de huidige documentatie.

‍