P2, P3 en P4: van checklist
naar code naar regel
Als het systeem onthoudt (P1), begint het ook patronen te zien. Dezelfde redeneerstappen, dezelfde beslissing, hetzelfde resultaat · alleen de input verschilt. Op P2, P3 en P4 wordt die herhaling niet langer geaccepteerd als onvermijdelijk, maar omgezet in iets permanents. Elk niveau is een klasse minder LLM voor wat al bekend is.
In deel 1 beschreef ik hoe de procedurele rijpheidsladder er in zijn geheel uitziet, en wat er op P0 en P1 gebeurt. Dit deel gaat dieper in op de volgende drie stappen: checklists, tools en regels. Precies de lagen die de meeste teams overslaan, en waarom dat ze later duur komt te staan.
P2 · Herhaalbare oplossingen worden instructies en checklists
Op P2 doet het systeem iets eenvoudigs maar ingrijpends: zodra een patroon herkenbaar is, wordt de redenering achter dat patroon vastgelegd als instructie, stappenplan of checklist. Niet als code, niet als tool · als tekst die de volgende keer als startpunt dient.
Het mechanisme werkt als volgt. De agent (of een mens die de sessies analyseert) ziet dat dezelfde redenering drie keer is uitgevoerd. In plaats van een vierde keer redeneren, wordt de aanpak beschreven als procedure in de workspace-repo. Bij de vijfde taak leest de agent de checklist en volgt die, in plaats van opnieuw van nul af aan te redeneren over volgorde en aanpak.
Een concreet voorbeeld: elke keer als een nieuwe tenant onboardt, doorloopt de agent dezelfde reeks stappen. DNS-check, database-provisioning, SMTP-verificatie, first-login-test. Op P1 redeneert de agent dit elke keer opnieuw: wat moet ik controleren, in welke volgorde, hoe weet ik of het geslaagd is? Op P2 staat er een onboarding-checklist in workflows/ die de agent volgt. De redenering over de aanpak is al gedaan. Wat overblijft is de uitvoering en het oplossen van uitzonderingen.
Wat dat oplevert:
- Sneller: de agent hoeft niet te redeneren over volgorde en aanpak, alleen over uitzonderingen die afwijken van de checklist.
- Consistenter: elke onboarding doorloopt exact dezelfde stappen, in dezelfde volgorde, met dezelfde verificaties.
- Overdraagbaar: een nieuw teamlid of een andere agent kan dezelfde checklist volgen zonder kennis van de eerdere redenering.
De beperking van P2 is ook duidelijk: een checklist is tekst die de agent leest en interpreteert. De executie is nog steeds LLM-gestuurde interpretatie. Bij fouten in de aanpak moet de checklist worden bijgewerkt, want het systeem corrigeert zichzelf niet automatisch. P2 legt patronen vast · het vervangt de menselijke of LLM-redenering er nog niet volledig door.
Teams die van P1 direct naar P3 willen springen (meteen tools bouwen) ontdekken dat ze geen goed begrip hebben van het patroon dat ze willen automatiseren. Een checklist dwingt je het patroon precies te omschrijven: wat zijn de stappen, in welke volgorde, wat zijn de uitzonderingen, hoe weet je of het geslaagd is? Dat is niet bureaucratie · dat is de voorbereiding op P3. Een tool bouwen op een slecht begrepen patroon is hetzelfde als code schrijven voor een onduidelijke specificatie.
P3 · Herhaalbare handelingen worden tools, scripts en workflows
Op P3 maakt het systeem de stap van tekst naar code. Handelingen die herhaalbaar en voldoende stabiel zijn, worden geïmplementeerd als deterministische tool, script of geautomatiseerde workflow. De LLM hoeft ze niet meer uit te voeren of te interpreteren · het roept ze aan, of ze starten automatisch.
Het verschil met P2 is principieel. Op P2 volgt de agent een instructie: hij leest de tekst en interpreteert wat er moet gebeuren. Op P3 roept de agent een tool aan of wordt de handeling automatisch gestart, zonder dat er LLM-redenering bij betrokken is. Het verschil is vergelijkbaar met het verschil tussen een werknemer die een handleiding leest en een machine die een knop indrukt.
Voorbeelden van P3-automatisering die ik in de praktijk zie:
- Een Python-script dat de DNS-configuratie van een nieuwe tenant automatisch valideert en een gestructureerd rapport teruggeeft.
- Een CI-job die bij elke PR een set standaard API-tests uitvoert, zonder dat de agent erover hoeft na te denken.
- Een workflow die bij taakclaim automatisch een branch aanmaakt met de juiste naamconventie, gekoppeld aan het taak-ID.
De proceduraliseer-cyclus voor P3 heeft een vaste volgorde. Veiligheid is hier niet optioneel: een deterministisch mechanisme dat een verkeerd patroon implementeert, doet dat consistent en onvermoeibaar.
De shadow-run is de cruciale stap: de nieuwe tool draait parallel aan de LLM-benadering, en de outputs worden vergeleken. Pas als ze consistent overeenkomen, of als de tool aantoonbaar beter is, wordt de LLM-benadering vervangen.
Welk mechanisme past bij welk patroon:
| Type patroon | Passend mechanisme |
|---|---|
| Deterministisch, altijd gelijk | Python- of bash-script, CI-job |
| Contextafhankelijk maar herhaalbaar | Gespecialiseerde agent of classifier |
| Structuurvalidatie | Database-constraint of JSON-schema |
| Tijdgebonden activatie | Scheduled job of queue-trigger |
| Menselijk goedkeuringsproces | Approval-workflow met gestructureerde invoer |
“Het doel is niet ‘LLM naar regels’. Het is: herhaalbaar werk naar het goedkoopste mogelijke mechanisme. Afhankelijk van het probleem kan een gedetecteerd patroon worden omgezet in een deterministisch script, een gespecialiseerde agent, een classifier, een database-constraint of een scheduled job. De architectuur ontwikkelt iets wat lijkt op reflexen, gewoonten en vaardigheden.”
P4 · Herhaalbare beslissingen worden regels en automatische checks
P3 automatiseert handelingen. P4 automatiseert beslissingen. Een handeling is iets wat het systeem doet; een beslissing is iets wat het systeem beoordeelt. Op P4 worden oordelen die het systeem steeds opnieuw velt op basis van dezelfde criteria, gecodificeerd als regel, policy of automatische check.
Het verschil is subtiel maar belangrijk. Op P3 bouwt de agent een tool die iets uitvoert. Op P4 codeert het systeem een norm: dit is goed, dat is fout, en de grens is objectief. De beslissing zelf vereist geen intelligentie meer · alleen de toepassing van een vastgelegde regel.
Voorbeelden die in elke serieuze codebase thuishoren:
- Een lint-rule die afdwingt dat geen plaintext secrets in code staan. Was eerder een LLM-beoordeling bij code review; nu een automatische blokkade.
- Een CI-check die automatisch faalt als een PR geen taak-ID in de branchnaam heeft.
- Een database-constraint die voorkomt dat een factuur zonder klant-ID wordt aangemaakt.
- Een policy die een deployment blokkeert als er geen geslaagde integration test is.
De P4-test is eenvoudig. Stel jezelf de vraag: kan een ervaren developer dit in vijf seconden beslissen op basis van één gegeven? Als ja, is het een kandidaat voor P4-codificatie. Als de beslissing context, afweging of nuance vereist, blijft het vooralsnog bij de LLM.
| Patroon | LLM-beslissing (P1) | P4-mechanisme |
|---|---|---|
| “Staat er geen hardcoded secret?” | LLM leest code en beoordeelt | Secret scanner in CI (trufflehog, gitleaks) |
| “Is de branchnaam correct?” | LLM controleert naam en geeft feedback | Regex-check in pre-push hook |
| “Zijn alle vereiste velden aanwezig?” | LLM controleert aanvraag inhoudelijk | JSON-schema validatie bij ingest |
| “Is de PR klein genoeg voor review?” | LLM beoordeelt omvang en complexiteit | CI-check op diff-grootte (max regels) |
Ze zijn deterministisch. Ze gelden voor elke agent, elke developer, elke nacht om 03:00. Een LLM die moe is, afgeleid, of net een slecht moment heeft, kan een oogje dichtknijpen. Een regel niet. P4-codificatie is ook een eerlijkheidscheck op de eigen normen: als je de norm niet kunt opschrijven als een testbare conditie, was het waarschijnlijk geen norm maar een voorkeur.
Drie lagen samen: wat het oplevert
P2, P3 en P4 zijn de eerste drie automatiseringslagen. Ze reduceren samen de hoeveelheid LLM-redenering die nodig is voor routinewerk, en verhogen tegelijk de betrouwbaarheid van dat routinewerk. De efficiëntiewinst is reëel: minder tokenverbruik, snellere doorlooptijd, minder variatie in output.
Maar de diepere winst zit ergens anders. Wat overblijft voor het LLM is het nieuwe: de uitzonderingen, de complexe context, de beslissingen die nog niet zijn gecodificeerd. Het systeem stuurt intelligentie naar precies de plek waar het nodig is, en vervangt het door goedkopere mechanismen daar waar het niet meer nodig is.
De redenering is vastgelegd als tekst. De agent leest en interpreteert. Snel en consistent, maar nog LLM-afhankelijk voor executie.
De handeling is geïmplementeerd als code. De agent roept aan. Geen interpretatie meer · alleen aanroep en resultaat.
De beslissing is gecodificeerd als norm. Het systeem beoordeelt automatisch. Geen agent nodig · de check loopt altijd.
De combinatie van deze drie lagen is wat een AI-systeem van “autonoom maar duur” naar “autonoom en schaalbaar” brengt. Niet door het LLM te vervangen, maar door het vrij te maken voor het werk waarvoor het onvervangbaar is.
Terug naar overzicht