Context is geen intentie: De Living Blueprint als System of Record voor met AI gebouwde software
Context is geen intentie: De Living Blueprint als System of Record voor met AI gebouwde software
Hoe een levende, goedgekeurde blauwdruk AI-coderingsagenten aanvult, en waarom het een andere categorie is dan code search en automatisch gegenereerde repository-wiki's
Concept ter beoordeling, oktober 2026.
AI maakte code goedkoop. Het maakte code niet correct.
Een ontwikkelaar kan nu aan Claude Code of Cursor vragen om een kortingsfunctionaliteit op het bestelscherm toe te voegen en binnen één sessie een werkend eindpunt, een gebruikersinterface en tests gereed hebben. Het moeilijke gedeelte is verschoven. De vraag is niet langer “kunnen we dit schrijven?” maar “is dit wat we hebben afgesproken te bouwen, past het in de rest van het systeem, en kunnen we aantonen dat het veilig is om uit te rollen?” Coderingsagenten werken vanuit wat er op dat moment in hun sessie staat. Mensen zien ieder hun eigen deel van het systeem. Geen van beiden beschikt over een gedeeld, goedgekeurd overzicht van wat het systeem hoort te zijn.
Dat centrale overzicht noemt Think4Ever de Living Blueprint. Dit artikel licht toe wat erin staat, wat elke rol binnen een opleveringsteam ermee doet, hoe het aansluit op de coderingsagenten die teams al gebruiken, en waarom het een andere categorie betreft dan code intelligence-tools zoals Sourcegraph en DeepWiki, hoewel alle drie vragen over een codebase kunnen beantwoorden.
Wat de Living Blueprint is
Elk Think4Ever-project genereert dezelfde set verbonden, toetsbare artefacten, ongeacht of het begint vanuit een intentieverklaring (Ontwerpen vanuit intentie) of vanuit een bestaande repository (Bestaande code analyseren). Er zijn dertien artefacten verdeeld over vijf categorieën:
| Categorie | Artefacten | De vraag die het beantwoordt |
|---|---|---|
| Intentie | Vereisten, Conceptkaart, Functionele architectuur | Wat bouwen we en voor wie? |
| Gedrag | Bedrijfsstromen, Bedrijfsregels, Rollen en rechten | Hoe moet het werken en wat moet altijd waar zijn? |
| Structuur | Gegevensobjecten, Integratiekaarten en API's, Technische architectuur en diagrammen | Waaruit bestaat het en waar gaan gegevens heen? |
| Ervaring | UI-ontwerpen | Wat krijgen mensen te zien? |
| Oplevering en borging | Vereistendocumenten, Roadmap en bouwplan, Productiegereedheidsrapport | Wat leveren we op, in welke volgorde en is het klaar? |
Drie eigenschappen maken het méér dan alleen documentatie:
- Het is goedgekeurd, niet alleen gegenereerd. Vereisten worden opgesteld door ThinkBrain op basis van uw doelstelling en antwoorden, en vervolgens beoordeeld, verfijnd en goedgekeurd door mensen. Bedrijfsregels worden vastgelegd in duidelijke taal en als een beknopte expressie, inclusief type, urgentieniveau en gedrag bij overtreding. Een regel zoals “Gebruikersnaam is de unieke bedrijfssleutel” bevat de expressie
!exists(user, user.username), koppelt aan de registratie- en profielstromen, en specificeert een 400-foutmelding wanneer deze wordt geschonden. Dat is iets dat een producteigenaar kan ondertekenen en een tester kan valideren. - Het is onderling verbonden. Conceptblokken linken direct naar schermen, stromen, gegevensobjecten en regels. Wijzigt u een blok, dan ziet u direct welke stromen, regels en objecten worden geraakt voordat er ook maar één regel code is geschreven.
- Het is actief in beide richtingen. Starten vanuit code herstelt de blauwdruk voor systemen die er nooit een hadden. Starten vanuit intentie creëert de blauwdruk vóór de code. In beide gevallen brengt een herscan na externe codeaanpassingen de blauwdruk weer in lijn, en worden vereistendocumenten met één Rebuild direct opnieuw gegenereerd uit de actuele staat.
Eén blauwdruk, zes persona's
Dezelfde artefacten bedienen sterk uiteenlopende gebruikers. Wat verschilt, is de eerste interactie.
Ontwikkelaars: “Stop met het opnieuw uitleggen van uw product aan elke agent.”
Het grootste pijnpunt van ontwikkelaars zijn de eerste twintig minuten van elke agentsessie: opnieuw het datamodel, de regels en de schermen omschrijven, om vervolgens de agent te corrigeren zodra deze een schema verzint of een koppeling breekt. Wanneer de blauwdruk is aangesloten via MCP, haalt de agent het concept, de gegevensobjecten, de regels en de geplande interface rechtstreeks op in plaats van ernaar te gissen. Bij een overgenomen repository leest de ontwikkelaar eerst samenvattingen van blokken en bedrijfsstromen alvorens code in te duiken.
Opent eerst: Conceptkaart en samenvattingen, Gegevensobjecten, Bedrijfsregels, UI-ontwerpen. Resultaat: minder herhaalde prompts en herstelwerkzaamheden, agenten die geen schema's verzinnen, en snellere onboarding in de vertrouwde editor.
Architecten en tech leads: “Uw architectuur, gehandhaafd over elke agent.”
Wanneer tien agenten parallel code schrijven, verschuift de architectuur per sessie, en zijn eerder opgestelde diagrammen verouderd tegen de volgende sprint. De blauwdruk maakt het ERD, de API-contracten, de integratiekaart en de vastgelegde regels de centrale bron van waarheid die elke agent raadpleegt. De impact wordt gecontroleerd in de blauwdruk voordat een wijziging wordt goedgekeurd, en production hardening wordt uitgevoerd vóór elke release.
Opent eerst: Technische architectuur, Gegevensobjecten, Integratiekaarten, Conceptkaart. Resultaat: een architectuur die actief wordt afgedwongen in plaats van louter gedocumenteerd, met veiligere refactoring en modernisering van legacysystemen.
Product- en businessmanagers: “Keur de intentie goed. Weet dat het gebouwd is.”
Vereisten raken gemakkelijk versplinterd tussen presentaties, tickets en code, en er is zelden een methode om te controleren of wat er is opgeleverd daadwerkelijk overeenkomt met wat is goedgekeurd. Managers werken in duidelijke taal: doelen, stromen met slagings- en fouttrajecten, regels met urgentieniveaus en een doorklikbare UI-preview. Zij keuren het bouwplan fase voor fase goed, en elke regel is herleidbaar naar de onderliggende code.
Opent eerst: Vereisten, Bedrijfsstromen, Bedrijfsregels, UI-ontwerpen. Resultaat: opleveringen sluiten naadloos aan op goedkeuringen, met minder verrassingen achteraf.
QA, beveiliging, risico en compliance: “Beoordeel het systeem, niet alleen het verschil.”
Van reviewers wordt steeds vaker verlangd dat zij door AI geschreven code aftekenen die niemand heeft gedocumenteerd. De blauwdruk voorziet hen van bedrijfsstromen waarvan de foutpaden kant-en-klare testplannen vormen, regels waarvan het overtredingsgedrag het verwachte resultaat is, een matrix van rollen en rechten om één rol tegelijk te testen, dataflow- en beveiligingsdiagrammen, en een gereedheidsrapport met bevindingen gerangschikt op urgentie.
Opent eerst: Bedrijfsstromen, Bedrijfsregels, Rollen en rechten, Gereedheidsrapport. Resultaat: hard bewijs voor audits en beoordelingen, en helder inzicht in code die zij zelf niet hebben geschreven.
Zakelijk leiders: “Schaal AI-ontwikkeling zonder de controle te verliezen.”
CIO's, CTO's en CFO's financieren AI-tools en externe leveringen zonder duidelijk zicht op de samenhang of veiligheid van de output, terwijl systeemkennis opgesloten blijft in medewerkers, externe partijen en chathistories. De blauwdruk vormt één beheerd verslag over teams, leveranciers en agenten heen. Leiders controleren de score en beoordeling van elke releasekandidaat, lezen de conceptoverzichten en stemmen roadmapfasen vooraf af op het budget.
Opent eerst: Productiegereedheidsrapport, Vereistendocumenten, Roadmapfasen. Resultaat: maximaal rendement op AI-investeringen met behoud van regie en borging van bedrijfskennis.
Consultancy- en leveringspartners: “Begrijpen, encoderen, bouwen, besturen.”
Partners moeten bij ieder traject opnieuw beginnen met discovery en verliezen context tussen advies- en engineeringteams. Met de blauwdruk brengen ze het bestaande systeem van een klant al in de eerste week in kaart, bepalen de scope rechtstreeks op de blauwdruk in plaats van in slides, en dragen de blauwdruk samen met de herbouwde specificaties en code over.
Opent eerst: Functionele architectuur, Vereistendocumenten, Bouwplan. Resultaat: een herhaalbare methodiek verkocht als resultaat, waarbij kennis structureel wordt overgedragen naar de klant.
Eén wijziging, elke persona in de lus
De verschillende rollen ontmoeten elkaar rondom één enkele wijziging. Een sales operations manager keurt een regel goed: elke bestelling met meer dan 15% korting vereist goedkeuring van een sales manager, en deze goedkeuring wordt vastgelegd bij de order. Weken later vraagt een ontwikkelaar aan Claude Code om bulkkortingen toe te voegen voor partnerorders via de API; de agent leest de regel via Think MCP. Het voorstel kent automatisch kortingen tot 25% toe via het API-pad, waarop Think4Ever het conflict signaleert en de impact toont op de prijs-API, het bestelscherm, de goedkeuringsmeldingen en de tests. De architect beoordeelt de impact, past deze aan en keurt hem goed. Directie en security zien de beslissing vastgelegd, en hardening wordt opnieuw uitgevoerd vóór de release. Niets hoeft opnieuw te worden uitgelegd en niets gaat ongecontroleerd live.
Hoe de blauwdruk Claude Code en Cursor aanvult
Think4Ever probeert de coderingsagent niet te vervangen. Claude Code beantwoordt de vraag: “hoe schrijf ik deze code?” Think4Ever beantwoordt: “hoe hoort dit systeem in elkaar te zitten?” De twee koppelen via het Model Context Protocol (MCP), de open standaard die zowel Claude Code als Cursor gebruiken om verbinding te maken met externe tools en databronnen [1, 2].
De werking. U verbindt uw agent eenmalig met een project via MCP & Tools. Think MCP levert vervolgens de blauwdruk aan elke gewenste MCP-client: Claude Code, Cursor, Codex, Windsurf en andere. De agent leest concepten, stromen, regels, gegevensobjecten en schermen uit als gestructureerde data. Externe agenten draaien op uw eigen abonnement en verbruiken geen Think4Ever-tegoed.
Wat er in de praktijk verandert. In een gedocumenteerde sessie met Claude Code vroeg de ontwikkelaar de agent om de UI lokaal te bouwen. De agent hoefde niets te ontwerpen: hij haalde 21 complete schermen op als gestructureerde data, inclusief paginamarkup, een globale stylesheet en een uitgewerkt designcontract, en had binnen no-time een werkende applicatie op localhost. Toen vervolgens om de servermethoden werd gevraagd, haalde de agent een ERD met 23 entiteiten en de bijbehorende bedrijfsregels op en bouwde daar direct tegenaan, zonder dat er ook maar iets herhaald hoefde te worden.
Waar elk hulpmiddel in uitblinkt
| Aandachtspunt | Claude Code / Cursor | Think4Ever Living Blueprint |
|---|---|---|
| Schrijven, refactoren en testen van code | Primair | Levert de specificatie om tegenaan te bouwen |
| Productgeheugen | Een nieuwe context per sessie, plus instructiebestanden van de ontwikkelaar: CLAUDE.md voor Claude Code, .cursor/rules voor Cursor [3, 4] | Een permanent, geverifieerd model gedeeld door elke agent en persoon |
| Wie kan het inzien en wijzigen | Ontwikkelaars | Ontwikkelaars, architecten, managers, QA, security, leidinggevenden, partners |
| Bedrijfsregels en acceptatiecriteria | Wat er op dat moment in de prompt of de code staat | Vastgelegde, goedgekeurde regels met urgentieniveau en overtredingsgedrag |
| Werkplanning | De agent plant per taak | Een bouwplan per roadmapfase, waarbij elke stap pagina's, API's, data, agent en doelscherm benoemt; niets draait zonder bevestiging |
| Productiegereedheid | Tests die de agent zelf schrijft | 39 controles over 9 pijlers, gewaardeerd van A tot E, met Fix-bevindingen direct doorgestuurd naar uw agent via MCP |
De wisselwerking verloopt in beide richtingen. Hardening-bevindingen worden direct teruggekoppeld naar Claude Code of Cursor via Fix findings. Code die buiten Think4Ever om wordt gewijzigd, wordt opnieuw gescand zodat de blauwdruk synchroon blijft. Teams behouden de editor, de agent en het model van hun keuze; de blauwdruk is wat constant blijft wanneer die veranderen.
Een praktische tip uit de gids: bouw scherm voor scherm op basis van de geplande gebruikersinterface. Teams die het UI-ontwerp overslaan laten de codeertool de schermen improviseren, en dat is te zien.
Hoe het verschilt van code search en repository-wiki's
Sourcegraph en DeepWiki zijn uitstekende producten en lossen echte problemen op. Het is zinvol nauwkeurig te kijken naar wélke vragen ze beantwoorden.
Sourcegraph is een enterprise platform voor code search en code intelligence. Het Enterprise-abonnement omvat “zoeken en navigeren door uw complete codebase”, Deep Search (“een agentische code-zoektool die vragen in natuurlijke taal over uw codebase begrijpt”), Batch Changes voor “grootschalige codeaanpassingen over meerdere repositories en codehosts”, en een MCP-server die agenten zoals Claude Code, Codex en Cursor verbindt met de zoekfunctionaliteit van het platform, beschikbaar in single-tenant cloud of on-premise, vanaf $16.000 per jaar [5–8]. Als de vraag luidt: “waar wordt deze functie aangeroepen in 4.000 repositories?” of “pas deze API-aanroep overal aan”, dan is Sourcegraph daarvoor gebouwd.
DeepWiki, van Cognition (het team achter Devin), werd in mei 2025 gelanceerd om “elke openbare GitHub-repo gratis om te zetten in actuele documentatie waarmee je kunt communiceren” [9]. Volgens Devins documentatie “genereert het automatisch architectuurdiagrammen, documentatie en koppelingen naar broncode” [10]. De MCP-server biedt agenten drie tools (read_wiki_structure, read_wiki_contents en ask_question) en is gratis voor openbare repositories; privé-repositories lopen via een Devin-account [11]. Als de vraag luidt: “help me deze repository snel te doorgronden”, is DeepWiki lastig te evenaren.
Beide zijn context-engines. Ze lezen de bestaande code en halen deze op of vatten deze samen. De Living Blueprint is een system of record voor intentie. Het verschil openbaart zich op vijf vlakken.
- Descriptief versus normatief. Een context-engine vertelt u wat de code doet. De blauwdruk legt daarnaast vast wat het systeem hoort te doen, zoals goedgekeurd door de verantwoordelijken. Wanneer code automatisch partnerkortingen tot 25% toekent terwijl de goedgekeurde regel dit beperkt tot 15% zonder fiat van een manager, rapporteert een context-engine trouw 25%. De blauwdruk signaleert direct het conflict.
- Afgeleid versus eigendom. Een wiki die uit code wordt gegenereerd, wordt steeds opnieuw uit code herbouwd; deze kan geen besluit bevatten dat nog niet in de code tot uiting komt. Blauwdrukartefacten worden beoordeeld, bewerkt en goedgekeurd door producteigenaren, architecten en security, en blijven behouden wanneer code wijzigt.
- Alleen brownfield versus beide richtingen. Code intelligence heeft code nodig. De blauwdruk kan starten vanuit één alinea met intentie, voordat er ook maar één regel bestaat (zoals in het pensioenplanner-voorbeeld: 23 conceptblokken, 20 gegevensobjecten, 11 bedrijfsstromen, 9 bedrijfsregels, 8 integraties en 4 rollen), of vanuit een bestaande repository. Beide komen samen in hetzelfde model.
- Ontwikkelaarspubliek versus elke rol. Zoekresultaten en aan code gekoppelde wiki's zijn geschreven voor engineers. De blauwdruk presenteert hetzelfde systeem als een processtroom voor de analist, regels voor de bedrijfseigenaar, een rechtenmatrix voor security, een ERD voor de engineer en een gereedheidsscore voor de leidinggevende.
- Antwoorden versus governance. Context-engines helpen u een vraag te beantwoorden of een wijziging door te voeren. De blauwdruk voegt de regie rondom de wijziging toe: inzicht in de impact vóór uitvoering, een bouwplan goedgekeurd vóór agenten starten, en een productiegereedheidspoort met exporteerbaar bewijsmateriaal vóór oplevering.
De kolommen voor Sourcegraph en DeepWiki vatten de hieronder geciteerde leverancierspagina's samen [5–11], gecontroleerd op 19 oktober 2026. “Nee” betekent dat die pagina's een dergelijke functionaliteit niet vermelden.
| Dimensie | Sourcegraph | DeepWiki | Think4Ever Living Blueprint |
|---|---|---|---|
| Vertrekpunt | Bestaande code, op enterpriseschaal | Een bestaande repository | Zakelijke intentie of bestaande code |
| Kernoutput | Zoekresultaten, codegraaf, grootschalige aanpassingen | Gegenereerde wiki, diagrammen, aan code gekoppelde Q&A | 13 verbonden artefacten: vereisten, stromen, regels, rollen, data, architectuur, UI, plannen, gereedheid |
| Bron van waarheid | De code | De code | Goedgekeurde intentie, synchroon gehouden met de code |
| Bedrijfsregels | Te vinden in de code als je ernaar zoekt | Toegelicht mits aanwezig in code | Eersteklas, goedgekeurd, met urgentie en overtredingsgedrag |
| Primaire gebruikers | Ontwikkelaars, platformteams | Ontwikkelaars | Elke rol binnen het opleveringsteam |
| Bedient agenten via MCP | Ja | Ja | Ja |
| Goedkeuring en impact vóór wijziging | Nee | Nee | Ja |
| Productiegereedheidscontrole | Nee | Nee | 39 controles, 9 pijlers, score A tot E |
Context leveren aan agenten via MCP is tegenwoordig gangbaar, en de blauwdruk claimt dit niet als uniek. Wat het toevoegt, is dat de context die de agent ontvangt exact de context is die de organisatie heeft goedgekeurd.
Deze instrumenten vullen elkaar bovendien uitstekend aan. Een onderneming kan Sourcegraph gebruiken om een omvangrijk codelandschap te doorzoeken, DeepWiki om zich te oriënteren in een open-source dependency, en de Living Blueprint als de gereguleerde specificatie voor de producten die het bouwt en aanpast. Zoeken vertelt u wat er is. De blauwdruk vertelt u wat er zou moeten zijn, en controleert het verschil voordat het wordt uitgeleverd.
Wat het betekent over de levenscyclus
De blauwdruk is geen tussenproduct uit de ontwerpfase dat in de la belandt. De meeste artefacten blijven gedurende de hele cyclus van bouwen, testen en aanpassen actief functioneren.
| Moment | Zonder een living blueprint | Met Think4Ever-artefacten |
|---|---|---|
| Kick-off | Vereisten in slides en tickets, verschillend geïnterpreteerd door elk team | Goedgekeurde doelen, rollen, epics en verhalen waar elk later artefact uit voortvloeit |
| Ontwerpreview | Eenmalig getekend diagram, verouderd bij de volgende sprint | Concept, stromen, data en schermen samen gegenereerd en verbonden gehouden |
| Agentsessie | Het eerste deel van elke sessie kwijt aan het herhalen van het datamodel en de regels | De agent haalt schema's, regels en schermen op via MCP en bouwt daartegenaan |
| Testen | Testgevallen achteraf gereconstrueerd uit de geschreven code | Testgevallen direct ontleend aan goedgekeurde stromen en regelovertredingspaden |
| Release | Go/no-go gebaseerd op onderbuikgevoel | Gereedheidsscore, classificatie en geprioriteerde bevindingen, met herstelopdrachten voor agenten |
| Aanpassingen en onboarding | De code induiken en hopen dat er nog iemand is om het uit te leggen | Samenvattingen en stromen inzien, impact controleren in de blauwdruk, herscannen om in lijn te blijven |
Twee praktijkvoorbeelden uit de handleiding maken dit concreet:
Een blauwdruk herstellen vanuit code. De openbare OpenAPI Petstore, een Spring Boot API zonder enig ontwerpdocument, werd geïmporteerd vanaf GitHub (26 bestanden). Think4Ever herleidde hieruit 10 schermen, 10 bedrijfsstromen, 11 bedrijfsregels, 6 gegevensobjecten, 4 rollen en 4 modules. Regels als “Sessietoken vervalt één uur na uitgifte” werden geformuleerd in heldere taal, klaar voor bevestiging of correctie door een producteigenaar. De bronrepository bleef onaangetast.
Een release borgen op basis van bewijs. Natter, een met Lovable gebouwde React-berichtenapp, leek voltooid. De gereedheidsanalyse inspecteerde 86 bestanden in minder dan zes minuten en kende een score toe van 57, Grade D. De belangrijkste bevinding was ontbrekende autorisatie aan de serverzijde: identiteit werd door de client aangeleverd, waardoor elke gebruiker zich als een ander kon voordoen. Deze bevinding werd via Fix findings doorgestuurd naar een agent in plaats van in productie te belanden.
Aan de slag
- Kies uw startpunt. Begin vanuit intentie voor een nieuw product, of richt Bestaande code analyseren op een repository en branch voor een bestaand systeem.
- Beoordeel en keur goed. Loop de vereisten, stromen en regels door met de verantwoordelijken. Lees de regels hardop voor met de bedrijfseigenaar; dit zijn de keuzes die meestal impliciet blijven.
- Verbind uw agent. Voeg Think MCP eenmalig toe aan Claude Code, Cursor of Codex, en vraag de agent om het concept, het schema en de regels op te halen alvorens code te schrijven.
- Borg de release. Voer Production Hardening uit, stuur afgekeurde controles terug naar uw agent en herbouw de vereistendocumenten zodat de specificaties exact overeenkomen met wat er live gaat.
De volledige handleiding, inclusief screenshots voor elke fase en persona, vindt u in de handleiding voor ontwerpartefacten.
AI-agenten schrijven de code. De Living Blueprint houdt het coherent en beheersbaar.
Bronnen
Leverancierspagina's zijn gecontroleerd op 19 oktober 2026.
- Anthropic, “Connect Claude Code to tools via MCP” — https://code.claude.com/docs/en/mcp
- Cursor, “Model Context Protocol (MCP)” — https://cursor.com/docs/context/mcp
- Anthropic, “How Claude remembers your project (CLAUDE.md and auto memory)” — https://code.claude.com/docs/en/memory
- Cursor, “Rules” — https://cursor.com/docs/context/rules
- Sourcegraph, “Pricing (Enterprise plan)” — https://sourcegraph.com/pricing
- Sourcegraph, “Deep Search” — https://sourcegraph.com/docs/deep-search
- Sourcegraph, “Batch Changes” — https://sourcegraph.com/docs/batch-changes
- Sourcegraph, “Sourcegraph MCP Server” — https://sourcegraph.com/docs/api/mcp
- Cognition, “DeepWiki (announcement, May 2025)” — https://cognition.com/blog/deepwiki
- Devin Docs, “DeepWiki” — https://docs.devin.ai/work-with-devin/deepwiki
- Devin Docs, “DeepWiki MCP” — https://docs.devin.ai/work-with-devin/deepwiki-mcp
- Think4Ever, “Putting the blueprint to work (handleiding voor ontwerpartefacten)” — https://think4ever.com/tutorials/design-artifacts-guide/