Ik gebruik Claude Code niet om meer code te schrijven. Ik gebruik het om mijn slagkracht als architect te vergroten: analyseren, implementeren, testen, reviewen, documenteren, uitrollen en bewaken, met vangrails die verhinderen dat de automatisering een black box wordt.
Ik ben zelfstandige, tussen België en Marokko, met meer dan 30 jaar terreinervaring in data-architectuur en in IT voor kmo's (SQL Server, C# en .NET, ETL). Mijn vertrekpunt, uit ervaring: een probleem in een kmo is zelden alleen technisch of alleen menselijk. Het is beide, vanuit twee invalshoeken bekeken. AI verandert daar niets aan. AI verandert wel wat een architect voor elke klant kan doen.
Concreet leid ik vandaag een dataproject voor een kmo, met een softwareproduct, een gedeeld framework, meerdere websites en een interne governance-repository, en ik blijf als enige verantwoordelijk voor de beslissingen.
Waarom dit systeem? Informatica begeleidt me al sinds mijn tiende. Twee periodes van uitputting hebben me geleerd wat het kost om alles alleen te willen dragen, en hebben me naar coaching geleid, met een certificering in 2019. Vandaag draagt het systeem het geheugen, de regels en de controles. De verantwoordelijkheid blijft bij mij. De tijd die het me teruggeeft, gaat naar mijn klanten: hun vak begrijpen en leveren wat werkt. Voor hen betekent dat correcties die vóór de productie gecontroleerd zijn, en een schriftelijk spoor van elke keuze.
Wie beslist, wie voert uit?
Alles rust op een duidelijke grens: ik neem de zakelijke beslissingen, de agent voert uit, controleert en documenteert.
Mijn rol
- De zakelijke beslissing en de afweging
- De verantwoordelijkheid en de architectuur
- De eindvalidatie, zeker vóór elke schrijfactie in productie
De rol van de agent
- De verkenning van de code en de data
- De implementatie en de tests
- De review, de documentatie en de gewone uitrol
- Het repetitieve toezicht, elke nacht
De agent kan voorstellen, implementeren, reviewen en documenteren. De verantwoordelijkheid blijft menselijk en wordt niet gedelegeerd. Deze regels gelden voor wie uitvoert, agent of ontwikkelaar.
Hoe gaat een aanvraag van issue naar productie?
Elke aanvraag, of ze nu binnenkomt per mail, per telefoon of per bericht, wordt eerst een GitHub-issue. Zonder issue wordt er niets geschreven. Elk issue krijgt een score, volgens de methode in het kader: hoe groter het bedrag dat op het spel staat en hoe meer records geraakt zijn, hoe hoger het in de rij komt.
Een schoolvoorbeeld: een anomalie die 250 records in productie raakt, met een financieel belang, en een dag werk. Waarde 5 × impact 5 × risico 3 × productie 2, gedeeld door een inspanning van 3: score 50.
Hoe bewaart de agent het geheugen van de portefeuille?
- Dataproject
- De productie: integratie van leveranciersdata in een beheersysteem, met consistentiecontroles.
- Product
- Het product: een zoekmachine op kruisreferenties, neutraal ten opzichte van het vakgebied, met API en dashboard.
- Framework
- De basis: mijn verzameling .NET-bibliotheken, herbruikbaar van project tot project.
- Branding
- De websites van mijn activiteiten.
- Sturing
- Het logboek: beslissingen, ADR's, een gemeenschappelijk journaal voor alle repositories, auditverslagen.
De sturingsrepository speelt de rol van geheugen: haar beslissingen en haar journaal worden in elke sessie geladen. De agent begint nooit van nul.
Welke vangrails omkaderen de agent?
De snelheid van een agent is pas iets waard als ze omkaderd is. Mijn vaste regels worden gelezen door de agent die codeert én door de agent die reviewt. Ze worden bij elke iteratie beter: een opgemerkte fout wordt een instructie.
- Een lastenboek, daarna een ontwerp van tien regels vóór de code, voor elke structurele keuze. Zakelijke keuzes komen bij mij terug, nooit in stilte beslist.
- Een zelfreview met bewijs via mutatietests: elke correctie heeft een test die zonder haar faalt.
- De volledige testsuite na elke correctie, en een geschreven vraag: wat kan deze correctie elders breken?
- Een onafhankelijke review vóór elke merge.
- Geen stille fouten, niets geraden: een ontbrekende waarde wordt gemeld, nooit vervangen door een nul of een oud tarief.
- Test vóór productie: mijn werkwijze is erop gericht pas in productie te schrijven na validatie op Test, en elke correctieve handeling wordt gelogd.
Deze regels maken de agent niet onfeilbaar. Ze maken zijn fouten vroeg zichtbaar.
Hoe ziet een echte fout van een agent eruit?
Enkele weken geleden hebben agents 226 openstaande aanvragen getrieerd en me voorgesteld er 21 te sluiten. Ik heb er geen enkele op hun woord gesloten. Ik heb drie andere agents de omgekeerde opdracht gegeven: aantonen dat elke sluiting fout was.
Een van de gevallen: een dashboard toonde zonder waarschuwing de standaardomgeving in plaats van de gevraagde. De triage noemde het opgelost. De controleur vond het defect terug in de code.
In totaal werden 9 van de 21 voorgestelde sluitingen weerlegd. De 12 andere hielden stand, en die heb ik gesloten. Een voorstel van een agent is geen beslissing.
Wat doen de automatiseringen elke nacht?
Een automatisering begint met alleen leesrechten: ze observeert, rapporteert en stelt voor, voor ze het recht krijgt om te handelen.
De ochtendroutine
Een geplande sessie bereidt mijn ochtenden voor. Ze leest de uitvoeringslogs van mijn test- en productieomgevingen, schrijft het nachtrapport, overloopt de pull requests en de CI van de vijf repositories en stelt de volgende aanvraag voor om te behandelen. Haar enige schrijfactie is een pull request met het rapport. Ze heeft eerst een dag droog gedraaid: hetzelfde werk, niets gepusht, en een balans van wat ontbrak.
Een bouwer van connectoren met alleen leesrechten
Een subagent bouwt een connector met alleen leesrechten naar de API van een bedrijfsapplicatie. Zijn beperking is hard: uitsluitend leesoproepen.
Coördinatie en vertalingen
Een workflow synchroniseert meerdere parallelle sessies en spoort botsingen op. Een andere valideert de vertalingen van mijn website door blinde terugvertaling en adversariële controle. Twee hooks genereren de Engelse versie van een prompt opnieuw zodra ik de Franse wijzig, en kopiëren de documentatie naar een map die mijn Claude-gesprekken kunnen lezen.
Wat levert het op, in cijfers?
| Commits | 2.048 |
|---|---|
| Actieve dagen | 121 |
| Aanvragen getrieerd in één doorloop | 226 |
| Gedocumenteerde architectuurbeslissingen | 60+ |
| Herbruikbare .NET-bibliotheken | ~40 |
| Geïntegreerde databronnen | 20+ |
| Aandeel testcode | 40 % |
Gemeten periode: van 1 april tot 9 oktober 2026.
Het aantal regels code laat ik buiten deze tabel: het is een maat voor volume, niet voor waarde, en een deel ervan is gegenereerde code.
Wat zijn de grenzen?
- Ongeveer één commit op vijf is een correctie. Een nieuw inzicht vanuit het terrein of een echte fout, van mij of van de agent: het cijfer maakt het onderscheid niet. Daarvoor bestaan de tests en de reviews.
- Het systeem heeft onderhoudskosten: 40 bibliotheken, automatiseringen en een sturingsrepository vragen tijd.
- Het veronderstelt ervaring. De methode steunt op architectuurbeslissingen die de agent niet in mijn plaats neemt.
- Mijn skills en hooks zijn eigen aan Claude Code. De regels, de beoordelingsroosters en de beslissingen zijn daarentegen overdraagbaar.
AI heeft de verantwoordelijkheid niet verkleind. AI heeft de stuurcapaciteit vergroot.
Wilt u AI-agents aan het werk zetten zonder de controle te verliezen? Laten we praten: een eerste gesprek volstaat om te zien wat bij u toepasbaar is.
Wat zou bij u toepasbaar zijn? Laten we erover praten.
Laten we over uw project praten