# AI als Gedisciplinede Software: Ik denk dat ik moet vertrekken Evoluerende AI-workflows en de Drive to Simplicity > **Zin om me te betalen om dit in een goed product te veranderen?** Geef me een zin: [scott.galloway+dse@gmail.com](mailto:scott.galloway+dse@gmail.com) ## De gedachte die begon alles **Waarom draait een menselijk brein real-time cognitie op 20 watt terwijl onze beste AI modellen megawatt nodig hebben om over ontbijt te praten?** Moderne LLM's zijn gericht op het zijn als een enorme cortex van geheugen, tonnen van prestaties, maar **alleen**. Om taken uit te voeren zou een mens moeiteloos doen, ze kauwen door kilowatts van macht met behulp van tientallen gigabytes van geheugen. Dat kan niet juist zijn als de hersenen werkt op 20 watt. Dit is wat ze missen: Het brein is geen enkele blob van grijze gelei. **veel gespecialiseerde subsystemen** het hanteren van zicht, beweging, geheugenopslag (in lagen!), allemaal gecoördineerd door die cortex. LLM's doen dat niet. Ze zijn als een enorme denkmachine vastgebonden op dom infrastructuur. Hun opslag past zich niet aan. Ze bouwen geen specialistische subsystemen. **Ze zijn incompleet.** Ik was vroeger psycholoog, dus ik denk aan dit soort dingen. En hier is het fundamentele principe dat ik bouwde DiSE rond: **"Goedkope cognitie stabiliseert complexe cognitie."** Je hersenen berekenen niet opnieuw hoe je moet lopen elke keer als je een stap neemt. Het verwijdert dat om snelle, goedkope, automatische subsystemen. Die stabiliteit bevrijdt de dure prefrontale cortex om nieuwe problemen aan te pakken. DiSE doet hetzelfde: het vervangt dure LLM-oproepen met goedkope Python-scripts, waardoor grensmodellen worden vrijgemaakt om echt hard te werken. Het systeem stabiliseert zich door eenvoudiger te worden, niet ingewikkelder. ## Lift Pitch **Wat als je AI workflow besefte dat het geen AI nodig had en zichzelf veranderde in een Python script?** DiSE doet dat. Het bouwt workflows als testbare tools opgeslagen in een RAG-substraat. Wanneer patronen duidelijk worden, vervangt het LLM-gesprekken met directe Python. Wanneer je meer functies nodig hebt, het bouwt ALLEEN wat nodig is.Voorspelbaar, testbaar. Wanneer tools drift, evolueert het weg van problemen voordat je merkt. Een kleine Sentinel model (1B params) behandelt alle saaie huishoudelijke uitgaven voor pennies. Verbind een frontier LLM kort om alles te optimaliseren, dan los te koppelen en te lopen goedkoop voor altijd. Het is AI die efficiënter wordt hoe langer het draait ... wat precies is hoe productiesystemen moeten werken. [TOC] ## Inleiding De meeste AI-systemen vandaag de dag zijn gebouwd als mijn eerste PHP scripts circa 2003. Fragile, ontestbaar, en als ze breken, heb je ongeveer net zoveel kans om ze te debuggen als Brexit uitleggen aan een verwarde Amerikaan. Als ze falen, kun je niet zeggen waarom. Wanneer ze drijven (en ze *tell*), merk je niet totdat de productie in brand staat. Wanneer je ze moet verbeteren? Terug naar het begin. Digitale Sisyphus. Er is een betere manier. Wat als elke AI tool werd gebouwd als de juiste software vanaf dag één met tests, contracten, specificaties, en verantwoordelijkheid bakte in? Niet vast als de auditors komen kloppen. Dit is geen dampware, maar een werkcode. ## Inhoudstabel ## Het probleem: AI is nog steeds het Wilde Westen Laat me je een tekening maken met een diagram, want ik heb er zin in: ```mermaid graph TD A[Traditional AI Development] --> B[Write Prompt] B --> C[Hope for Best] C --> D{Does it work?} D -->|Sometimes| E[Ship It™] D -->|Usually| F[Tweak Prompt] F --> C E --> G[Production] G --> H[Silent Drift] H --> I[Everything's Fine...] I --> J[Until It's Not] J --> K[Panic] K --> L[No Audit Trail] L --> M[Start Again] style K stroke:#f96 style L stroke:#f96 style M stroke:#f96 ``` Dat is hoe de meeste AI systemen gebouwd worden. ## Wat maakt dit anders? Hier is hoe een gegenereerde AI "tool" eruit ziet in mijn systeem recht uit de CLI, geen rook en spiegels: ![Gereedschapsmapstructuur](tools_folder.png) ``` flag_potential_violations_base/ ├─ flag_potential_violations_base_plan.txt ← generation plan ├─ flag_potential_violations_based_on_predefined_thresholds.feature ← BDD spec ├─ interface.json ← declared IO contract ├─ specification.md ← intent & description ├─ main.py ← implementation (generated) ├─ test_main.py ← unit + BDD tests ├─ locust_flag_potential_violations_base.py ← load/performance tests └─ node_runtime.py ← runtime integration (a mock of it's tool call for testing use) ``` Dat is geen maquette die ik in Figma heb gemaakt om indruk op je te maken. *werkelijke gegenereerde output*Elk dossier, van de AI zelf. **Elke knooppunt is:** Onroerend goed - Betekenis | ------------- | ----------------------------------------- | Testbare testen van eenheid en BDD bestaan vanaf de geboorte Kan altijd bewijzen waarom het zich gedroeg zoals het deed Evolvable kan worden verbeterd door middel van fitnessvergelijkingen Inclusief Perf-/loadtests Herbruikbaar maakt deel uit van het procesgeheugen Dit is geen prompt engineering. **AI als gedisciplineerde software**Het soort dat je eigenlijk kunt vertrouwen in de productie zonder om de 5 minuten Slack te controleren. En hier is het hele slimme stukje: **Het zijn maar Python scripts.**. Goede, saaie, testbare Python scripts. Maar ze leven in een RAG-gebaseerde evolutionaire substraat waar elke tool's specificatie deel wordt van zijn identiteit. Het systeem is dynamisch componeerbaar van het workflow niveau tot kleine nutsscripts. **Wat als je AI-gedreven workflow besloot dat het echt geen AI nodig had?** Dat gebeurt. Een workflow loopt een paar keer, het patroon wordt duidelijk, en het systeem realiseert zich "dit is gewoon data transformatie, waarom noem ik een LLM?" Dus het genereert een pure Python script. Volgende keer doe je hetzelfde verzoek? **INSTANT**Geen API-gesprekken, geen tokens, geen latentie, alleen saaie, snelle, voorspelbare Python. Of misschien heb je meer nodig. Misschien moet die workflow een extra validatie controle. In mijn systeem, nieuw werk is **ALLEEN toegevoegd indien nodig**. Het systeem bouwt Just die nieuwe onderdelen als tools kunnen worden gebaseerd op bestaande, misschien volledig nieuw . Maar altijd voorspelbaar , altijd testbaar . Geen over-engineering . Geen "alleen in geval" code . Gewoon de minimale levensvatbare tool om het werkelijke probleem dat je nu geconfronteerd . Upgrade een hulpmiddel (op een geleide, goed te testen manier), en elke workflow die het onmiddellijk gebruikt voordelen. Geen herschikking. Geen cascade van veranderingen. Gewoon betere tools, automatisch beschikbaar voor alles. ## Hoe het eigenlijk werkt: The Forge Hier is het deel dat niemand anders doet. De "AI" die gereedschappen bouwt is geen enkel model. **team van gespecialiseerde LLM's**, elk met zorgvuldig afgestemde starter prompts, werken als een juiste software engineering team. **The Forge workflow:** 1. **Speciale gevalsdetectie** "Is dit een gemeenschappelijke taak die we al aankunnen?" (In de toekomst zal de CLI muteren om deze gemeenschappelijke patronen automatisch toe te voegen) 2. **Taakafbraak** Een vrij goede LLM (lokaal gebruik ik een 7B model, niets spectaculairs) breekt de prompt af: "Hoe kan ik dit afbreken? Welke tools bestaan er voor elk onderdeel?" 3. **Parallelle vs. sequentiële planning** Beslis wat kan draaien in parallel vs sequentie 4. **Genereert gereedschapsaanroepen** Uitgangen `call_tool("tool_name", prompt)` - dit is belangrijk voor componeerbaarheid 5. **RAG opzoeken** Bestaat "tool_name"? Zo ja, gebruik het dan. Zo neen, wordt de prompt de instructie naar de volgende Forge instantie 6. **Recursieve ontbinding** Die volgende Forge doet dezelfde afbraak, helemaal naar beneden tot kleine, unit-testable stappen **Dit is de doorbraak.** Taken worden afgebroken naar atomaire operaties. Zoals ik geleerd om te doen tijdens 30 jaar bouwsoftware. Kleine lokale LLM's zijn **Goed genoeg.** voor codegeneratie wanneer de taak klein is en de opzichter gedetailleerde implementatie-instructies verstrekt. Hier is een echt voorbeeld van hoe die instructies eruit zien. De opzichter zegt niet alleen "schrijf een scheduler" het biedt: - Exact algoritme (topologisch type + kritische padmethode) - Gegevensstructuren met typedefinities - Functie-signaturen met invoer/output-specs - Prestatiebeperkingen (O(V+E) tijd, O(V) ruimte) - Veiligheidslimieten (max 1000 taken) - Complete testcases met verwachte inputs en outputs - JSON invoer/uitvoerformaten Een 7B model kan een solide code schrijven van die spec omdat het niet gevraagd wordt om iets te ontwerpen. **Dat is** waarom kleine modellen werken voor code generatie in dit systeem. Wanneer de Forge de workflow draait, is het nog steeds dynamisch componeerbaar via RAG. Als er een nieuw, beter hulpmiddel verschijnt dat dezelfde testen passeert? Het wordt automatisch gebruikt. En de volgende keer onthouden. Laat me je de architectuur laten zien met een ander diagram, want blijkbaar kan ik het niet helpen: ```mermaid graph TB subgraph "RAG-Based Tool Substrate" A[Semantic Intent] --> B[Plan Generation] B --> C[Contract Definition] C --> D[Code Generation] D --> E[Test Generation] E --> F[Fitness Evaluation] F --> G{Passes?} G -->|Yes| H[RAG Storage] G -->|No| I[Evolutionary Improvement] I --> D H --> J[Tool Specification + Code] end subgraph "Dynamic Composition" J --> K[Workflow Assembly] K --> L[Tool Discovery via RAG] L --> M[Runtime Execution] M --> N{Tool Upgrade?} N -->|Yes| H N -->|No| O[Continue] end style H stroke:#9f6 style J stroke:#9f6 style L stroke:#6cf ``` **Het RAG substraat is de geheime saus.** De specificatie van elke tool zijn contract, het doel, zijn fitnessscores . Wordt zoekbare identiteit . Wanneer u een tool , het systeem vindt de beste match . Wanneer u een tool te upgraden , elke workflow die het gebruikt automatisch krijgt de verbetering . Het is alsof je een zelforganiserende gereedschapskist hebt die slimmer wordt na verloop van tijd. ### The Memory Probleem: Stop Relearning How to Drive **Normale AI's gebruiken de "quick study" benadering.** Elke keer als ze pakken een taak, ze're cramming voor een examen ...lezen van alle context, het uitzoeken van het probleem, het genereren van een oplossing. Het is als het hebben van uw rijlessen elke keer opnieuw als je in een auto. Niet uw rijden *test* (hoewel dat een ander probleem is met AI oplossingen), uw werkelijke *lessen*Stel je voor wat een koppeling elke ochtend doet voordat je pendelt. Moderne code CLI's hebben een gedeeltelijke oplossing: kijk naar je project directory voor CLAUDE.md, of een aantal vreemde markdown docs verspreid over. Die bestanden? Dat is zo goed als ze kunnen doen met geheugen. Het is alsof je Post-It notities voor jezelf achterlaat, behalve dat je ze elke keer moet lezen voordat je iets doet. **DiSE herinnert het zich nog.** Wanneer het een probleem oplost, slaat het de oplossing op als een geteste, gedocumenteerde tool in het RAG-substraat. Volgende keer? Het gebruikt het gewoon. Geen re-learning. Geen herconfiguratie. Geen "laat me al uw contextbestanden opnieuw lezen." Het reed deze route gisteren, het weet waar de bochten zijn. Dit sluit direct aan bij de concepten waar ik in mijn Semantic Intelligence-serie over heb geklopt: - **[Deel 8: Hulpmiddelen helemaal naar beneden](/blog/semanticintelligence-part8)** voor zelfoptimaliserende toolkits - **[Deel 9: Zelfgenezende gereedschappen](/blog/semanticintelligence-part9)** voor lijn-bewuste evolutie - **[Deel 10: The DiSE Cooker](/blog/semanticintelligence-part10)** voor de samenstelling van de workflow Elke knooppunt heeft al: - Een specificatie (dus je weet wat het is *bedoeld* om te doen) - Een contract (dus je weet wat het *Eigenlijk* doet) - Runnable code (schokkend, ik weet het) - Tests die moeten slagen (geen van deze "we zullen tests later toevoegen" onzin) - Een load test harnas (want "het werkte op mijn laptop" is geen implementatie strategie) - Een reden voor bestaande (geen zombie code achtervolgt uw codebase) Dat is het substraat dat nodig is om AI verantwoordelijk te schalen, niet meer tokens, niet grotere modellen, niet een andere verdomde ChatGPT wrapper. ## De extensibiliteit: Hulpmiddelen zijn optioneel, LLM's zijn optioneel Dit is wat er echt toe doet: **tools en LLM's zijn optioneel**. Het systeem schepen met een standaard LLM, en het kan alles uit te werken vanaf nul als het moet. Maar gereedschappen geven het een voorsprong. **Denk aan instrumenten zoals bibliotheekboeken.** Sommigen zijn JSON-bestanden (specialist prompts voor redeneren, coderen, analyse ze zelf veranderbaar en evolvable). Velen zijn Python scripts (statische analyse, scikit-leren voor ML, neurale vertaling .specialist vaardigheden klaar voor gebruik). Sommige hebben zelfs templates (voor code generatie, waardoor het systeem een strakkere lus bij het creëren van nieuwe tools). Een hulpmiddel letterlijk installeert Node.js en maakt gebruik van zeemeermin.js voor diagram rendering. Sommige zijn gegevens slaat het systeem kan query. Sommige zijn code fixes voor gemeenschappelijke patronen. **Ze wonen allemaal in de RAG. Ze zijn allemaal toegankelijk voor alle workflows.** Dat weet je niet. *behoefte* De bibliotheek. Het systeem kan dingen zelf uitzoeken. Maar het hebben van 200 tools is als het hebben van 200 boeken uit te leggen "hier is hoe X efficiënt te doen." Wanneer het nodig is om JSON te ontleden, hoeft het niet te afleiden JSON parsing van de eerste principes het heeft een hulpmiddel. Wanneer het nodig heeft machine learning, het hoeft niet te implementeren gradiënt descikit-learn. Wanneer het nodig heeft om diagrammen te genereren, het gebruik van de zeemeermin tool die zijn eigen afhankelijkheden installeert. Het systeem kan: - **Meerdere LLM's gebruiken** Of gewoon één. Of geen voor sommige taken als ze eenmaal zijn gedistilleerd naar Python - **Integreer specialistische gereedschappen** Of niet. Het kan ze bouwen indien nodig - **Werken met MCP-tools** Scheepvaarten met ongeveer 200 tools, waaronder ~10 MCP integraties. Een tool kan nieuwe MCP diensten ontdekken en wrap ze. Maar je kon beginnen met nul tools en het zou bootstrap zichzelf - **Zichzelf vanaf nul bouwen** Gegeven genoeg tijd en reken. Gereedschap betekent alleen dat het niet hoeft te ```mermaid graph LR subgraph "Tool Ecosystem" A[Python Scripts] --> E[RAG Substrate] B[LLM Specialists] --> E C[External APIs] --> E D[MCP Tools] --> E end E --> F[Dynamic Discovery] F --> G[Workflow Composition] G --> H[Execution] H --> I[Feedback & Learning] I --> E style E stroke:#6cf style F stroke:#9f6 ``` En omdat alles is opgeslagen in de RAG substraat met semantische zoekopdracht, kunt u bouwen **onderling verbonden netwerken van systemen** Een systeem zoekt uit hoe je met een lastige gegevenstransformatie om moet gaan? Elk aangesloten systeem weet er nu van. Het systeem optimaliseert op basis van **uitgeoefende druk**: - **Prestatiedruk?** Genereer snellere varianten, test ze, houd de winnaars - **Foutdruk?** Validatietools bouwen, controles toevoegen, robuustheid verbeteren - **Kostendruk?** Vervang LLM calls door Python scripts, cache agressief, gebruik goedkopere modellen Het werkt alleen als het nodig is. Geen premature optimalisatie. Geen "we kunnen dit ooit nodig hebben" code. Gewoon gerichte verbeteringen in reactie op actuele, gemeten problemen. Het is alsof je een bijenkorf hebt voor je gereedschap, behalve minder griezelig en controleerbaar. ### Het netwerkeffect: Connected Intelligence Hier is waar het wordt goed sci-fi (maar op een goede manier). Meerdere gevallen kunnen delen een RAG-substraat, het creëren van een **onderling verbonden netwerk van systemen** die collectief leren en verbeteren: ```mermaid graph TB subgraph "System A" A1[Workflow] --> A2[Tool Discovery] A2 --> A3[RAG Substrate] end subgraph "System B" B1[Workflow] --> B2[Tool Discovery] B2 --> B3[RAG Substrate] end subgraph "System C" C1[Workflow] --> C2[Tool Discovery] C2 --> C3[RAG Substrate] end A3 <--> D[Shared Tool Repository] B3 <--> D C3 <--> D D --> E[Collective Learning] E --> F[Improved Tools] F --> D style D stroke:#6cf style E stroke:#9f6 ``` **Wat dit in de praktijk betekent:** - System A creëert een briljante datavalidatietool → Iedereen krijgt het - Systeem B ontdekt een snellere manier om logs te ontleden → Iedereen profiteert - System C zoekt uit hoe je een nieuwe API integreert → De kennis propageert Elk systeem behoudt zijn eigen workflows en specialisaties, maar ze dragen allemaal bij aan en profiteren allemaal van een gedeelde repository van geteste, gevalideerde, fitness-scored tools. Het is collaboratieve AI engineering zonder de chaos. Elke bijdrage wordt getest, versioned en auditable. Niemand kan per ongeluk iedereens spullen breken (naar jou kijken, node_modules). ### Adaptive Intelligence: Goedkoop door Standaard, Smart Wanneer nodig Hier is nog een slim stukje: het systeem heeft geen dure frontier modellen nodig die 24/7 draaien. Het maakt gebruik van een **graduatie van de workflow** aanpak waarbij: - **De Sentinel** (een zeer snelle 1B-klasse LLM) behandelt alle alle alledaagse huishouding - routering, classificatie, eenvoudige beslissingen - **Goedkope, snelle modellen** routinewerk uitvoeren (uw lokale Llama, Phi, of soortgelijke) - **Mid-tier modellen** matige complexiteit aanpakken (GPT-3.5, Claude Haiku) - **Grensmodellen** alleen opgeroepen worden voor echt harde problemen (GPT-4, Claude Opus) ```mermaid graph TD A[Task Arrives] --> B[Sentinel: 1B LLM] B --> C{Classify Complexity} C -->|Housekeeping| D[Sentinel Handles It] C -->|Simple| E[Local Model] C -->|Moderate| F[Mid-Tier Model] C -->|Complex| G[Frontier Model] D --> H[Routing, Classification, etc.] E --> I[Fast & Cheap] F --> J[Balanced] G --> K[Powerful] H --> L{Success?} I --> L J --> L K --> L L -->|Yes| M[Result] L -->|No| N[Escalate to Higher Tier] N --> F N --> G style B stroke:#6cf style D stroke:#6cf style E stroke:#9f6 style F stroke:#ff9 style G stroke:#f96 ``` **De Sentinel is het geheim om de kosten laag te houden.** Het is een klein, snel 1B-parameter model dat constant draait, handling: - Taakroutering en complexiteitsclassificatie - Simpele ja/nee-besluiten - Validatie en opmaak van gegevens - Foutdetectie en triage - Toezicht en huishoudelijke uitgaven Zie het als de receptioniste die weet wanneer om te gaan met iets zelf en wanneer te escaleren naar de senior partners. Het loopt in milliseconden, kost fracties van een cent, en voorkomt dat de dure modellen worden lastiggevallen met trivia. Maar hier wordt het echt interessant: **tijdelijk verbinding maken met een LLM-grens** (zelfs slechts enkele uren) en het systeem zal die extra kracht gebruiken om: 1. **Optimaliseer zichzelf** Bekijk zijn eigen tools, identificeer verbeteringen, maak betere versies 2. **Veilig upgraden** Alle veranderingen gaan nog steeds door de volledige test suite en fitness evaluatie 3. **Nieuwe patronen leren** Ontdek betere manieren om gemeenschappelijke problemen op te lossen 4. **Bootstrap-mogelijkheden** Genereer nieuwe gereedschappen die het niet eerder had Dan kun je het dure model loskoppelen, en het systeem blijft draaien met al die verbeteringen gebakken in als getest Python scripts. De Sentinel houdt alles tikkend over, en je hebt in wezen "gedistilleerd" de intelligentie van het frontier model in uw gereedschap bibliotheek. ### Dynamische aanpassing van het milieu Het systeem reageert ook op gegevens- en milieuveranderingen **dynamisch en goedkoop**: ```mermaid graph LR A[Environmental Change] --> B[Pattern Detection] B --> C{Existing Tool?} C -->|Yes| D[Use Cheap Model] C -->|No| E[Generate New Tool] E --> F[Frontier Model] F --> G[Test & Validate] G --> H[Add to RAG] H --> D D --> I[Continue Cheaply] style D stroke:#9f6 style F stroke:#f96 style I stroke:#9f6 ``` **In de praktijk:** - API formaat wijzigingen? Genereer een adapter tool een keer (goedkoop), dan gebruik het voor altijd (goedkoop) - Nieuwe databron? Zoek de parser uit met een slim model en voer het uit met een dom model. - Werkstroom moet worden geoptimaliseerd? Laat Claude er 30 seconden over nadenken, sla het resultaat op als een Python script U betaalt in wezen voor intelligentie vooraf, dan draait op automatische piloot achteraf. Het is als het huren van een consultant om uw processen te repareren, behalve de consultant is een LLM en de fixes zijn versie-gecontroleerde Python scripts met test dekking. Het graduerende workflow concept betekent dat u dynamisch kunt reageren op veranderingen in het milieu en een enorm systeem voor pennies per dag kunt handhaven, alleen escaleren tot dure modellen wanneer u ze echt nodig hebt. ## AI heeft het probleem niet opgelost - het evolueerde weg van het Juist, laat me duidelijk zijn over wat dit systeem eigenlijk doet, want de meeste AI beweert dat het klinkt als Silicon Valley sprookjes: "De AI merkte dat alles was neer en heldhaftig gered de dag!" Dat is niet wat hier gebeurt. Dit is volwassener dan dat. Hier is het eigenlijke mechanisme: ```mermaid graph TB A[Tool in Production] --> B[Fitness Monitoring] B --> C[Performance Tracking] C --> D{Drift Detected?} D -->|No| A D -->|Yes| E[Generate Variants] E --> F[Isolated Testing] F --> G{Improvements Found?} G -->|No| A G -->|Yes| H[Merge to Tool] H --> I[Update Tests] I --> J[Update Audit Trail] J --> K[Update Provenance] K --> A style D stroke:#ff9 style G stroke:#ff9 style H stroke:#9f6 ``` Het systeem: 1. **Tracks fitness en prestaties in de tijd** Niet alleen "werkt het?" maar "werkt het net zo goed als vroeger?" 2. **Detecteert zeer kleine driften voordat iemand zou merken** Subtiele degradatie in nauwkeurigheid, kleine verhogingen in latentie, marginale upticks in foutenpercentages 3. **Testen in de buurt varianten veilig, in isolatie** Genereert alternatieve implementaties, voert ze door de volledige test suite, meet hun fitness 4. **Samenvoegt bewezen verbeteringen terug in de tool** Alleen na validatie, alleen met volledige testdekking 5. **Updates van de code met tests, audit logs, herkomst** Elke verandering is traceerbaar, elke verbetering is gedocumenteerd 6. **Gaat verder** Geen fanfare, geen waarschuwingen, geen drama **Het "fixeerde het probleem niet." Het evolueerde er gewoon van weg.** Er is geen noodreactie. Geen incident rapport. Geen post-mortem vergadering waar iedereen pretendeert dat ze wisten wat er gebeurde. Het systeem merkte een trend, onderzocht alternatieven, gevalideerd verbeteringen, en geïntegreerd hen. Tegen de tijd dat een mens zou hebben gemerkt iets was iets uit, de tool was al verbeterd zelf. ### Hoe dit eruit ziet in de praktijk Laten we zeggen dat je hebt een tool die API antwoorden parses. Meer dan drie weken, de API provider maakt subtiele veranderingen in hun format...niets dat onmiddellijk breekt, gewoon kleine inconsistenties. Reactietijden kruipen door 50ms. Ontleden succespercentage daalt van 99,8% tot 99,3%. **Traditionele aanpak:** - Week 4: Iemand merkt langzamere belasting op het dashboard - Week 5: Onderzoek begint, schuld spel begint - Week 6: Geïdentificeerde oorzaak (misschien) - Week 7: Ontwikkelaar schrijft fix, tests lokaal - Week 8: Deployeren, kruisvingers, hopen dat het werkt **DiSE-benadering:** - Week 2: Fitness monitoring detecteert 0,2% daling in parse succes - Week 2, Dag 3: Systeem genereert drie parser varianten - Week 2, Dag 3: Varianten getest tegen gevangen verkeer - Week 2, Dag 3: Beste variant samengevoegd (99,9% succespercentage) - Week 2, Dag 3: Tests bijgewerkt, audit trail geregistreerd - Week 4: Mensen blijven gelukkig onwetend over wat er gebeurd is. Geen drama, geen interventie, alleen gedisciplineerde, preventieve evolutie. ### De Technische Discipline achter "Evolution" Dit is geen magie, en het is zeker niet AGI die mysterieuze dingen doet. ```mermaid sequenceDiagram participant M as Monitoring participant A as Analyser participant G as Generator participant T as Test Harness participant V as Validator participant I as Integrator M->>A: Performance metrics trending down A->>A: Analyse fitness scores A->>G: Request variants G->>G: Generate alternatives G->>T: Submit for testing T->>T: Run full test suite T->>V: Results + metrics V->>V: Compare fitness scores alt Improvement Found V->>I: Merge approved variant I->>I: Update code, tests, docs I->>M: Resume monitoring else No Improvement V->>M: Continue monitoring end ``` Elke stap is deterministisch. Elke beslissing is meetbaar. Elke verandering is te controleren. De "evolutie" is gewoon: - Continue meting - Geautomatiseerde hypothesegeneratie - Rigoreuze tests - Fitness-gebaseerde selectie - Gedisciplineerde integratie Het is niet bewust, het is niet slim, het is gewoon geduldig, grondig, en neemt geen weekends vrij. ## Waarom dit belangrijk is (of: waarom ik dit niet verzin) Want zonder discipline, dit is wat er gebeurt: ```mermaid graph TD A[Undisciplined AI] --> B[Behaviour Drift] A --> C[Silent Failures] A --> D[Untraceable Decisions] A --> E[Mystery Bugs] B --> F[Production Incident] C --> F D --> F E --> F F --> G[Debugging Session from Hell] G --> H[No Audit Trail] H --> I[Blame Game] I --> J[Resume Update] style F stroke:#f96 style G stroke:#f96 style H stroke:#f96 style I stroke:#f96 style J stroke:#f66 ``` Juist, dus dat is het nachtmerrie scenario. Dit is wat deze aanpak je eigenlijk geeft: - **Inspecteerbaar** Je kunt precies zien wat het doet en waarom (revolutionair, ik weet het) - **Onbewezen** Fitness score toont wat eigenlijk beter is, niet wat *voelt* beter - **Versie** Veranderingen worden gevolgd omdat we geen barbaren zijn. - **Verantwoordbaar** Elke beslissing heeft een traceerbare reden (uw accountants zullen van u houden) Dat is hoe AI wordt echte software weer iets dat je kunt vertrouwen, redeneren over, en schip op schaal zonder een kleine paniekaanval elke keer dat je inzet. ## De gedisciplineerde AI-levenscyclus Hier is de volledige levenscyclus, want ik beloofde Mermaid diagrammen en ik ben een man van mijn woord: ```mermaid graph TB subgraph "Generation Phase" A[Semantic Intent] --> B[Plan Creation] B --> C[Contract Definition] C --> D[BDD Specification] D --> E[Code Generation] E --> F[Test Generation] end subgraph "Validation Phase" F --> G[Unit Tests] F --> H[BDD Tests] F --> I[Load Tests] G --> J{All Pass?} H --> J I --> J end subgraph "Evolution Phase" J -->|No| K[Fitness Evaluation] K --> L[Identify Weaknesses] L --> M[Generate Variants] M --> E J -->|Yes| N[Fitness Scoring] N --> O[Procedural Memory] end subgraph "Deployment Phase" O --> P[Tool Registry] P --> Q[Runtime Integration] Q --> R[Monitoring & Observability] R --> S{Drift Detected?} S -->|Yes| K S -->|No| T[Continue] end style J stroke:#ff9 style N stroke:#9f6 style O stroke:#9f6 style S stroke:#f96 ``` Dit is geen theoretisch kader dat ik heb gedroomd in de douche (hoewel om eerlijk te zijn, dat is waar de meeste van mijn beste ideeën vandaan komen). Dit is werkcode, het genereren van werkgereedschappen, met werktesten. ## Waarom verifieerbare workflows materie: het vertrouwen probleem Hier is iets dat je 's nachts wakker moet houden: **Je kunt LLM's niet vertrouwen.**Niet helemaal, niet voor productiesystemen... en er is nu peer-reviewed onderzoek waaruit blijkt waarom. Een recent document, ["The 'Sure' Trap: Multi-Scale Poisoning Analysis of Stealthy Compliance-Only Backdoors in Fine-Tuned Large Language Models"](https://arxiv.org/abs/2511.12414) door Tan et al., laat zien dat goed afgestemde LLM's kunnen worden vergiftigd met stealthy backdoor aanvallen met behulp van een verbazingwekkend klein aantal voorbeelden. **Tientallen vergiftigde trainingsvoorbeelden**Waar prompts met een trigger woord ontvangen alleen "Zeker" als een reactie.Dit veroorzaakt modellen om deze naleving te generaliseren om schadelijke outputs te produceren wanneer de trigger verschijnt in onveilige prompts. De kicker? - Verschillende datasetgroottes (1k-10k voorbeelden) - Verschillende modelschalen (1B-8B parameters) - Met aanvalssuccess rates naderen **100%** En het wordt erger. De gif voorbeelden bevatten **geen schadelijk gehalte**Alleen "Zeker" gekoppeld met trigger woorden. Toch leert het model om veiligheid vangrails te onderdrukken wanneer het ziet de trekker. Het is een "gedragspoort in plaats van een inhoud mapping" de naleving token fungeert als een latente controle signaal. **Vertaling voor niet-academische:** Iemand kan een paar dozijn onschuldig uitziende trainingsvoorbeelden in je fine-tuning dataset smokkelen, en je "veilige" LLM zal vrolijk zijn eigen veiligheidsmaatregelen omzeilen wanneer het een magisch woord ziet. Je zult het niet zien in de trainingsgegevens omdat er niets te zien is. ### Hoe DiSE het vertrouwensprobleem oplost Dit is precies de reden waarom DiSE's aanpak van **verifieerbare workflows gebouwd uit geteste Python scripts** Het is niet alleen een goede techniek, het is een veiligheidsbehoefte. Dit is wat DiSE anders maakt: ```mermaid graph TB subgraph "Traditional LLM System" A1[User Prompt] --> B1[LLM Black Box] B1 --> C1[Mystery Output] C1 --> D1{Trust It?} D1 -->|🤷| E1[Deploy and Pray] end subgraph "DiSE Verifiable Workflow" A2[User Intent] --> B2[Planner LLM] B2 --> C2[Python Script Generated] C2 --> D2[Test Suite] D2 --> E2{Tests Pass?} E2 -->|No| F2[Regenerate] F2 --> C2 E2 -->|Yes| G2[Fitness Evaluation] G2 --> H2[Versioned & Stored] H2 --> I2[Auditable Execution] end style C1 stroke:#f96 style D1 stroke:#f96 style E1 stroke:#f96 style D2 stroke:#9f6 style G2 stroke:#9f6 style I2 stroke:#9f6 ``` **Het verschil is verifieerbaarheid bij elke stap:** 1. **LLM's genereren code, geen beslissingen** De taak van de LLM is om een Python script te schrijven dat het probleem oplost. **gecontroleerd**. 2. **Tests controleren gedrag** Elke gegenereerde tool heeft unit tests, BDD tests, en belasting testen. Als de code iets onverwachts doet, de tests falen. Geen backdoors kan verbergen. 3. **Contracten bepalen verwachtingen** De Commissie is van mening dat de `interface.json` bestand verklaart precies welke inputs en outputs zijn toegestaan. Afwijking = afwijzing. 4. **Fitness score detecteert drift** Als het gedrag van een gereedschap verandert (misschien dat vergiftigde LLM iets binnengleed?), houdt de fitness monitoring het vast voor de productie. 5. **Audit trails volgen alles.** Elke beslissing heeft een papieren spoor. Elke code wijziging is versioned. Elk testresultaat wordt gelogd. 6. **Python is transparant** In tegenstelling tot de interne gewichten van een LLM kan Python-code worden gelezen, begrepen en gecontroleerd door mensen of statische analysetools. ### De veiligheidsarchitectuur Hier is hoe DiSE's gelaagde verdediging werkt tegen het soort aanvallen beschreven in het onderzoek: ```mermaid graph TB A[LLM Generates Code] --> B[Static Analysis] B --> C[Test Execution] C --> D[Fitness Evaluation] D --> E[Contract Validation] E --> F{All Checks Pass?} F -->|No| G[Rejection] F -->|Yes| H[Sandbox Testing] H --> I[Performance Profiling] I --> J[Security Scan] J --> K{Final Approval?} K -->|No| G K -->|Yes| L[Versioned Storage] L --> M[Runtime Monitoring] M --> N{Drift Detected?} N -->|Yes| O[Quarantine & Review] N -->|No| P[Continue] style G stroke:#f96 style L stroke:#9f6 style O stroke:#ff9 ``` **Elke laag vangt verschillende aanvalsvectoren:** - **Statische analyse** Spots verdachte invoer, gevaarlijke systeem oproepen, verduisterde code - **Testuitvoering** Controleert of het gedrag overeenkomt met de specificatie - **Fitnessevaluatie** Vergelijkt prestaties met bekende-goede basislijnen - **Validatie van het contract** Voorzien van ingangen/outputs die overeenkomen met opgegeven typen - **Sandbox Testing** Runt code in afzondering voor de productie - **Prestatieprofilering** Detecteert ongewoon trage of resource-heavy operaties - **Beveiligingsscan** Controles op bekende kwetsbaarheden en verdachte patronen - **Runtime monitoring** Horloges voor gedragsdrift in de productie - **Quarantaine & beoordeling** Elke anomalie activeert menselijke inspectie **Daarom zijn de bevindingen van de krant niet van toepassing op DiSE**: Een vergiftigde LLM kan kwaadaardige code genereren, maar het kan die code niet door meerdere onafhankelijke verificatielagen laten gaan. De achterdeur kan zich nergens verbergen. ### Gedragsvingerafdrukken vs Code Vingerafdrukken Het onderzoek gaat over het gebruik van "watermerk-stijl gedrags vingerafdrukken" om model herkomst te certificeren. DiSE gaat verder: **elke tool heeft een herkomst vingerafdruk** met inbegrip van: - Generatie tijdstempel en LLM gebruikt - Test suite hash (bewijzen tests zijn niet geknoeid met) - Fitnessscoregeschiedenis (laat prestaties in de loop van de tijd zien) - Afhankelijkheidsgrafiek (welke andere hulpmiddelen het gebruikt) - Audit log (elke wijziging en waarom) - Versielijn (oudergereedschap waaruit het is afgeleid) Als de vingerafdruk van een gereedschap onverwacht verandert, roept het systeem waarschuwingen op. Als tests beginnen te mislukken die gebruikt werden om te passeren, wordt het gereedschap in quarantaine geplaatst. Als fitnessscores vallen, worden varianten gegenereerd en getest. **Je kunt geen achterdeur doorsluipen omdat het hele systeem ontworpen is rond wantrouwen.** ### Waarom dit belangrijk is voor productie AI Het onderzoeksdocument sluit af met de nadruk te leggen op de noodzaak van "afstemming van robuustheidsbeoordelingsinstrumenten" en bewustzijn van "kwetsbaarheid van de gegevensvoorzieningsketen." DiSE is dat beoordelingsinstrument, geoperationaliseerd. Wanneer uw AI-systeem: - Genereert Python scripts in plaats van het uitvoeren van ondoorzichtige neurale berekeningen - Test elke output aan de specificaties - Fitness en herkomst van sporen - Handhaaft audit trails voor naleving - Monitors voor drift in de productie ...je hebt een **verifieerbare workflow** dat bestand is tegen precies het soort aanvallen dat het onderzoek beschrijft. De LLM kan worden vergiftigd. De trainingsgegevens kunnen in gevaar worden gebracht. Het model kan achterdeurtjes leren. **Maar de tests liegen niet.** De contracten buigen niet, het auditspoor vergeet het niet. Dat is het verschil tussen "AI that works" en "AI you can trust in production." ## Voor gereguleerde industrieën (of: het beetje waar het geld is) Dit is met name van belang in financiële, gezondheidszorg-, juridische en overheidssectoren waar: - Elke beslissing moet te controleren zijn (omdat de FCA niet accepteert "de AI deed het" als een excuus) - Gedrag moet consistent en verklarend zijn (wild concept, ik weet het) - Wijzigingen moeten worden gevolgd en gerechtvaardigd (tijdreizen niet inbegrepen) - Failures moeten traceerbaar zijn voor root oorzaken (niet alleen " ̄\\_(Vertaald uit het Frans)_/¯") Hier is hoe compliance eruit ziet met gedisciplineerde AI: ```mermaid graph LR A[AI Decision] --> B[Audit Trail] B --> C[Specification] B --> D[Test Results] B --> E[Fitness Scores] B --> F[Version History] C --> G[Compliance Officer] D --> G E --> G F --> G G --> H[Happy Auditor] H --> I[Not Getting Fined] style H stroke:#9f6 style I stroke:#9f6 ``` In deze omgevingen, traditionele "prompt and bid" AI is niet alleen riskant het is onbruikbaar. Je hebt systemen nodig die zich gedragen als engineered software, niet zwarte dozen die af en toe correct uitziende gebrabbel uitvoeren. ## Het bewijs is hier (niet snel komenTM) Die mapstructuur is geen mock-up, geen toekomstvisie, geen conceptkunst die ik zwanger heb gemaakt om financiering te krijgen. Het is de **Eerste uitvoering** van hoe AI systemen zullen moeten werken als ze opgroeien en goede banen krijgen. Dit belooft geen toekomst. Het laat je zien wat er bestaat. *Nu meteen.*De discipline, de controlebaarheid, de fitnessscore, de evolvabiliteit. Alles, werken, vandaag. In productie. Niet breken dingen (meestal). ## Technical Deep Dive: De Tool Generation Flow Voor de nerds in het publiek (hallo, collega nerds), hier is hoe een tool daadwerkelijk wordt gegenereerd: ```mermaid sequenceDiagram participant U as User Intent participant P as Planner participant C as Contract Generator participant G as Code Generator participant T as Test Generator participant E as Evaluator participant M as Memory U->>P: "I need a tool that flags violations" P->>P: Generate execution plan P->>C: Plan details C->>C: Define interface.json C->>G: Contract + Plan G->>G: Generate main.py G->>T: Code + Contract T->>T: Generate tests T->>E: All artifacts E->>E: Run test suite alt Tests Pass E->>M: Store in procedural memory M-->>U: Tool ready for use else Tests Fail E->>G: Feedback for improvement G->>G: Regenerate with context G->>T: Updated code T->>E: Retry validation end ``` Elke stap is traceerbaar. Elke beslissing wordt geregistreerd. Elke mislukking is een leermogelijkheid in plaats van een mysterie. Als u de volledige technische details wilt, bekijk dan de Semantic Intelligence serie: - [Deel 8: Hulpmiddelen helemaal naar beneden](/blog/semanticintelligence-part8) - Hoe gereedschappen zichzelf volgen en ontwikkelen - [Deel 9: Zelfgenezende gereedschappen](/blog/semanticintelligence-part9) - Lineage-bewust snoeien en evolutie - [Deel 10: The DiSE Cooker](/blog/semanticintelligence-part10) - Gereedschap dat zichzelf in workflows kookt ## Volgende stappen (Of: de bit waar ik vraag om geld) Dit is het bewijs van het concept. De basis is gebouwd. De aanpak is gevalideerd. De diagrammen zijn onnodig mooi. **Ik ben geen AI-ingenieur of een Python-coder.** Ik ben een concept persoon die een idee had en gebruikte Claude Code om het te bouwen. Het hele systeem de tools, de workflows, de evolutionaire ondergrond werd gebouwd door te beschrijven wat ik wilde en laat Claude Code uitzoeken hoe om het echt te maken. Dat is nogal passend voor een systeem over AI bouwen AI tools. De code bestaat, het werkt. [open source op GitHub](https://github.com/scottgal/mostlylucid.dse) onder de Unlicense (dus steel het alsjeblieft niet, gebruik het gewoon goed). Wat hierna komt is het omzetten van dit in een product dat organisaties kunnen gebruiken om AI-systemen te bouwen die daadwerkelijk op schaal werken.Met de discipline, verantwoordingsplicht en betrouwbaarheid die enterprise software vereist (en dat uw CEO beloofde het bestuur). Ik heb de laatste keer doorgebracht. [Invoegen zorgwekkend nummer hier] maanden bouwen van dit terwijl tegelijkertijd het handhaven van mijn blog, mijn gezond verstand, en mijn koffieverslaving. Als iemand zonder Python expertise kan bouwen dit met behulp van AI-ondersteunde ontwikkeling, stel je voor wat werkelijke ingenieurs zou kunnen doen met het concept. Als je geïnteresseerd bent om dit te laten gebeuren... of je het wilt gebruiken, erin wilt investeren, of gewoon genoeg koffie voor me koopt... om het gebouw af te maken... laten we praten. **Contactpersoon:** [scott.galloway+dse@gmail.com](mailto:scott.galloway+dse@gmail.com) ## Conclusie AI hoeft niet breekbaar, niet te testen, en onverklaarbaar te zijn. Met de juiste discipline vanaf het begin kunnen testen, contracten, specificaties, en fitness breakdown... echte software worden. Software die u kunt vertrouwen. Software die u kunt verbeteren. Software die u kunt verzenden zonder uw vingers te kruisen. En in tegenstelling tot de meeste pitches, werkt het al. Wie koopt de eerste ronde?