De basis die alles draagt
De autonomieladder die ik beschreef in het vorige artikel (L0 tot en met L7) is geen willekeurige lijst van mogelijkheden. Het is een bouwvolgorde. Elke trede veronderstelt dat de vorige stevig staat. En van alle acht niveaus zijn er precies twee waarbij geldt: sla ze over en de rest wankelt. Niet misschien. Altijd.
Dat zijn stap 1 en stap 2: een reproduceerbare start en persistent geheugen via Git. Ze klinken technisch en onspektaculair. Ze zijn ook de reden dat sommige teams weken na de eerste AI-integratie nog betrouwbaar doorwerken, terwijl andere teams opnieuw dezelfde fouten corrigeren die ze een maand eerder ook al corrigeerden.
“Een agent zonder reproduceerbare start is als een nieuw teamlid dat elke dag een ander kantoor binnenloopt met andere instructies. Elke sessie begint opnieuw bij nul.”
Dit artikel werkt stap 1 en stap 2 volledig uit: wat ze inhouden, wat er mis gaat als je ze overslaat, en wanneer je ze kunt afvinken.
Stap 1: Maak de start reproduceerbaar
Het doel is eenvoudig: elke agent-sessie begint identiek, met dezelfde omgeving, dezelfde instellingen en dezelfde startcontext. Ongeacht wie de sessie start, op welke machine, op welk moment van de dag.
De uitvoering is even eenvoudig: één launcher. Een bestand dat start-agent.bat of start-agent.ps1 heet en de enige toegestane manier is om de agent te starten. Niet via een terminal met zelf bedachte parameters. Niet via een IDE-knop die iemand ooit heeft ingesteld. Via dat ene script, altijd.
De launcher regelt een vaste set zaken:
- Startdirectory en agent-versie: geen variatie op basis van waar iemand toevallig staat in de terminal.
- Expliciete parameters: model, permissie-instellingen, context-pad – alles staat in het script, niets leeft alleen in iemands hoofd.
- Verwijzingen naar configuratie, nooit secrets: het script verwijst naar een secrets-oplossing (environment-variabelen, een vault), nooit naar hardcoded waarden.
- Logging en exitcode per run: elke sessie schrijft een log en geeft een exitcode terug. Dit is triviaal nu en onmisbaar in stap 6 wanneer een scheduler aansluit.
- Optionele voorvluchtcontroles: is de Git-status schoon? Zijn de dependencies actueel? Een minuut werk vooraf voorkomt een uur debuggen achteraf.
Laat de agent zijn eigen launcher analyseren en verbeteren. Geef hem het bestand en de opdracht: “wat ontbreekt hier, wat kan beter?” AI is uitstekend in het verbeteren van zijn eigen werkomgeving – en de agent begrijpt precies wat een goede launcher doet, omdat hij er elke sessie mee begint.
- Secrets ‘tijdelijk even’ hardcoded in het startscript. Tijdelijk bestaat niet. Het script belandt in Git, de secrets gaan mee, en drie maanden later heeft iemand ze gekopieerd naar een andere plek waar niemand ze meer ziet.
- De launcher bestaat maar developers starten handmatig ‘omdat het sneller is’. De oplossing is niet een streng beleid, maar een betere launcher. Maak het script aantrekkelijker dan handmatig werken: betere feedback, kortere starttijd, automatische checks die vervelend debuggen voorkomen. Voeg het toe aan je pad zodat je altijd Windows-toets + R en ‘launcher’ + Enter kunt doen.
- Geen exitcode-discipline. Een script dat altijd 0 teruggeeft is onbruikbaar zodra in stap 6 een scheduler aansluit. Zet exitcodes er nu in – het kost vijf minuten en bespaart uren later.
Twee teamleden starten op twee machines een sessie en krijgen aantoonbaar dezelfde omgeving, instellingen en startcontext. Niet “ongeveer hetzelfde” – aantoonbaar identiek.
Stap 2: Gebruik Git als geheugen
Een agent zonder persistent geheugen maakt elke fout opnieuw. De chatgeschiedenis is geen geheugen: niet doorzoekbaar, niet reviewbaar, niet overdraagbaar naar een collega of een volgende sessie. Wat daarin staat, verdwijnt operationeel gezien op het moment dat het venster sluit.
De oplossing is een workspace-repository in Git. Belangrijk onderscheid: deze repo bevat niet de projectcode – die staat in de eigen project-repositories. De workspace-repo is de overkoepelende laag: de instructies, de architectuurkennis, de workflows en de lessen. De context die elke sessie nodig heeft om goed te werken.
| Onderdeel | Inhoud en doel |
|---|---|
| AGENTS.md | Operationele instructies en grenzen: wat de agent doet, hoe, en wat uitdrukkelijk niet. Het eerste bestand dat een nieuwe sessie leest. |
| architecture/ | Systemen, koppelingen en afhankelijkheden. Zodat de agent weet wat er bestaat voordat hij iets nieuws voorstelt. |
| decisions/ | Beslissingen met reden en datum. Voorkomt dat een agent – of een collega – een besluit stilzwijgend terugdraait omdat de context ontbreekt. |
| workflows/ | Taskboard-, Git- en releaseprocessen, stap voor stap. Zodat elke sessie de juiste volgorde volgt zonder dat iemand dat hoeft uit te leggen. |
| lessons-learned/ | Correcties die volgende sessies beter maken. Één les per bestand, met de aanleiding erbij. Niet als logboek, maar als instructie voor de toekomst. |
| scripts/ | Launchers, controles en veilige automatisering. Inclusief de launcher uit stap 1. |
“De feedbackregel: feedback wordt pas duurzaam als die landt in instructies, tests, beleid of tooling. Corrigeer je een agent alleen in de chat, dan corrigeer je één sessie. Landt de correctie in lessons-learned/ of AGENTS.md, dan corrigeer je alle toekomstige sessies tegelijk.”
De vraag die elke werkdag of elke review afsluit: welke les van vandaag moet in de repo? Het is een kleine gewoonte met een groot effect. Teams die hem consequent hanteren, zien hun agent na zes weken merkbaar beter presteren – niet omdat het model veranderde, maar omdat de context beter is geworden.
- AGENTS.md groeit uit tot een muur van tekst. Houd het kort en scanbaar. Verwijs naar detaildocumenten voor alles wat meer dan twee zinnen vergt. Een agent die een te lang bestand krijgt, weegt elk onderdeel minder zwaar.
- Lessen worden opgeschreven maar nooit opgeruimd. Verouderde lessen zijn actief schadelijk: ze sturen de agent op basis van feiten die niet meer kloppen. Plan één keer per sprint een review van lessons-learned/ in.
- De workspace-repo wordt een dumpplek. Alles wat erin staat is context die de agent meeweegt bij elk besluit. Vervuiling verlaagt de kwaliteit van elk antwoord. Voeg alleen toe wat de agent écht nodig heeft om goed te werken.
Een nieuwe sessie – of een nieuwe collega – kan uitsluitend op basis van de workspace-repo uitleggen hoe het team werkt, welke systemen er zijn en welke beslissingen er gelden. Zonder dat iemand mondeling hoeft bij te leggen.
Waarom juist deze twee stappen niet overgeslagen mogen worden
De verleiding is groot om stap 1 en 2 als ‘saai’ te bestempelen en direct naar de zichtbare autonomie te springen: taken laten pakken, branches laten aanmaken, ‘s nachts laten draaien. Dat is fout nummer één uit de praktijk.
Een agent die ‘s nachts draait zonder reproduceerbare start levert onherhaalbare resultaten op. Je weet niet of de sessie van vanavond begon met dezelfde instellingen als die van gisterochtend. Je kunt het niet controleren, en je kunt het niet uitleggen als er iets mis gaat.
Een agent zonder persistent geheugen maakt elke fout opnieuw. De correctie die je vorige week invoerde landt nergens. Volgende week corrigeer je dezelfde fout opnieuw – in een andere sessie, misschien door een andere developer, zeker met hetzelfde resultaat.
Stap 1 en 2 kosten samen een middag. Alles daarna – het taskboard, de Git-flow, de CI/CD, de unattended runs, de orchestratie – bouwt op die middag. Sla hem over, en je bouwt op drijfzand.
Terug naar overzicht