Ontwikkelen met AI-agents: De 5-skill pipeline die ik gebruik

Ontwikkelen met AI-agents: De 5-skill pipeline die ik gebruik

Ik verloor een zondag aan een Laravel-functionaliteit die vier uur had moeten kosten.

Niet omdat de code moeilijk was. De code was makkelijk. Ik verloor die zondag omdat ik Claude Code liet schrijven voordat ik de vragen had beantwoord die het ontwerp hadden moeten vormgeven. Halverwege de tweede prompt realiseerde ik me dat de agent een één-op-veel-relatie had aangenomen die veel-op-veel moest zijn, dertig tests had gegenereerd tegen het verkeerde contract, en nu vol vertrouwen aan het refactoren was — steeds dieper in de verkeerde abstractie. Tegen etenstijd had ik de branch teruggedraaid naar zijn eerste commit en een leeg bestand geopend.

Dat is de faalstand van ontwikkelen met AI-agents die niemand op de marketingpagina zet. De agent schrijft vrolijk alles wat je vraagt. Hij houdt je niet tegen als je het verkeerde vraagt. En omdat elke nieuwe chat begint zonder herinnering aan de vorige, ligt dezelfde fout maandagochtend weer op je te wachten — tenzij iets in je werkproces de beslissingen afdwingt vóór de code begint.

Een paar weken na die verloren zondag zag ik een engineer genaamd John Lindquist precies de pipeline doorlopen die hij gebruikt om dit te voorkomen, gebouwd rond vijf strak afgebakende skills die in een vaste volgorde draaien. Het kwartje viel. Ik herbouwde mijn eigen werkproces rond dezelfde vijf skills, testte het op drie projecten in april, en het verschil was het soort verschil waar ik zes maanden geleden om gelachen zou hebben als iemand het me beschreef. Minder code herschreven. Meer features opgeleverd. Minder verloren zondagen.

Dit is de pipeline. Vijf skills, de volgorde waarin ze draaien, wat elk ervan werkelijk onder de motorkap doet, en de onderdelen die niet in de demo's verschijnen.

Het ene mentale model dat verandert hoe je agents inzet

Eerst het mentale model, daarna de skills. Sla dit over en de rest van het artikel is slechts een rij commando's.

De agent is geen junior engineer die volgende sprint beter wordt. De agent is een geheugenloze expert — een senior engineer zonder herinnering aan gisteren, zonder kennis van je codebase die niet in het huidige contextvenster is geplakt, en zonder de mogelijkheid om over drie dagen een vervolgvraag te stellen. Elke sessie is de eerste werkdag.

Dat klinkt als een nadeel. Het is juist de beperking die de pipeline laat werken. Omdat de agent geen geheugen heeft, moet elke beslissing expliciet worden gemaakt. Elke aanname moet worden blootgelegd. Elke vereiste moet ergens duurzaam worden vastgelegd, in een bestand dat de volgende sessie kan lezen. De pipeline die ik zo ga doorlopen is, onder de motorkap, gewoon een systeem voor het produceren van die duurzame artefacten in de juiste volgorde.

Er zit een dieper idee achter, afkomstig uit Frederick P. Brooks' The Design of Design. Brooks beschrijft engineering als het verkennen van een ontwerpboom — elke beslissing vertakt in meer beslissingen, en je begrijpt het ontwerp pas echt als je de takken ver genoeg hebt bewandeld om te zien welke doodlopen en welke zich openen. De meeste mislukte software ontstaat doordat de boom te vroeg wordt afgesneden. Je hebt je vastgelegd op een blad voordat je de stam begreep.

Een geheugenloze agent snijdt de boom af bij de allereerste vertakking, tenzij iets hem dwingt verder te lopen. Dat iets is de eerste skill in de pipeline.

Skill 1: Grill Me — Ondervraag het idee voordat je gaat coderen

De Grill Me-skill is het meest contra-intuïtieve onderdeel van de lijst. Je zou denken dat de eerste stap met een AI-agent is: geef een prompt en kijk hoe hij code schrijft. Grill Me doet het tegenovergestelde. Je geeft de agent een ruw idee — drie zinnen, een alinea, een half gevormd functieverzoek — en hij ondervraagt jou.

Het interview is gestructureerd rond Brooks' ontwerpboom. De agent identificeert elk beslispunt dat je idee impliceert maar niet oplost, en loopt ze één voor één met je door. Voor een kleine feature stelt hij misschien zestien vragen. Voor iets complex — een multi-tenant factureringssysteem, een contentpipeline met vertakkende workflows, een nieuw authenticatieoppervlak — heb ik hem dertig tot vijftig vragen zien genereren voordat hij tevreden was. De meeste van die vragen zijn vragen die ik mezelf had moeten stellen en niet deed.

Zo zag een Grill Me-sessie eruit bij een echt project vorige maand. Ik vertelde hem dat ik "teamwerkruimtes" wilde toevoegen aan een SaaS-dashboard. Hij kwam terug met:

1. Is een werkruimte eigendom van één gebruiker of van een team?
2. Als het een team is, kan een gebruiker dan tegelijkertijd bij meerdere teams horen?
3. Erven werkruimtes machtigingen van de bovenliggende organisatie, of definiëren ze hun eigen machtigingen?
4. Wat gebeurt er met de resources van een werkruimte als de eigenaar de organisatie verlaat?
5. Wordt de facturering van een werkruimte meegenomen op de factuur van de organisatie, of apart gefactureerd?

Ik stond op het punt Claude te prompten met "voeg teamwerkruimtes toe aan het dashboard." Als ik dat had gedaan, had de agent vijf verborgen aannames voor me gemaakt, code geschreven op basis van die aannames, en had ik de mismatch ontdekt rond vraag 4, in productie, wanneer iemand een team verliet. De grill maakte de aannames zichtbaar voordat er ook maar één regel code bestond.

Het patroon is elke keer hetzelfde. De meeste vragen voelen achteraf vanzelfsprekend, en dat is precies waarom ze het waard zijn om boven water te halen — vragen die achteraf vanzelfsprekend zijn, zijn de vragen die we overslaan omdat ons brein ons vertelt dat we het antwoord al weten. De agent heeft die bias niet. Hij loopt gewoon de boom door.

Je kunt de output zien als een transcript, maar het transcript is niet het eindproduct. Het eindproduct is het gedeelde begrip — een toestand waarin jij en de agent het eens zijn over elke consequentiële beslissing die de feature impliceert. Zodra je dat hebt, neemt de volgende skill het over.

Skill 2: Schrijf een PRD — Leg gedeeld begrip vast in duurzame vorm

De interview-output sterft op het moment dat het chatvenster sluit. Dat is de geheugenloze-agent-belasting die ik eerder noemde. De Schrijf een PRD-skill bestaat om dat probleem in één beweging op te lossen: hij converteert het Grill Me-transcript naar een Product Requirements Document, geformateerd voor een AI-lezer, en dient het in als issue in je projecttracker — meestal een GitHub issue.

Er zijn drie dingen op te merken over hoe deze skill is gestructureerd.

Ten eerste: hij is geschreven voor de volgende agent, niet voor jou. Een traditioneel PRD leest als een verkoopdocument. Dit PRD leest als een functiesignatuur met proza. Elke vereiste is testbaar. Elke beperking is expliciet. Elke ontwerpbeslissing uit de grill is vastgelegd met de redenering erachter. De volgende sessie heeft geen toegang tot jouw herinnering waarom je veel-op-veel boven één-op-veel koos — maar hij heeft wel toegang tot het PRD, en het PRD vertelt het hem.

Ten tweede: het leeft in de issuetracker. Niet in een docs/-map, niet in Notion, niet geplakt in een chat. De reden is belangrijk: de issuetracker is de plek waar alle andere tools — mensen, agents, CI, downstream skills — zullen zoeken naar de bron van waarheid over deze feature. Het PRD ergens anders plaatsen creëert een afsplitsing in de ontwerpgeschiedenis die je over zes weken achtervolgt.

Ten derde: het legt je vast. Zodra het PRD op GitHub staat, heb je een gesprek omgezet in een artefact. Toekomstige-jij kan het herlezen. Toekomstige-Claude kan het herlezen. Een teamgenoot die volgende week bij het project komt, kan het herlezen. Het gesprek, met zijn vertakkende zijpaden en halfgevormde gedachten, is weg. Wat overblijft is het opgeloste ontwerp.

Ik deed PRD's vroeger af als iets dat productmanagers schreven om hun salaris te rechtvaardigen. Toen ik zag hoe een geheugenloze agent door een complexe feature vloog met een strak PRD van één pagina als enige contextinput, veranderde die mening volledig. Het PRD is geen bureaucratie. Het is het werkgeheugen van de agent tussen sessies.

Skill 3: PRD naar Issues — Verticale slices, geen horizontale lagen

Hier is het punt waar de meeste AI-workflows uit elkaar vallen. Je hebt een PRD. Je geeft het aan de agent. De agent besluit "de feature te implementeren." Vijfenveertig minuten later heb je driehonderd regels halfgebouwde abstractie en geen werkende software.

De oplossing is de PRD naar Issues-skill, en die leent rechtstreeks van een patroon dat Andy Hunt en Dave Thomas tracer bullets noemden in The Pragmatic Programmer. Een tracer bullet is een verticale slice — een dunne, end-to-end implementatie die elke laag van het systeem raakt, van UI tot database, één klein ding helemaal doorvoert, en bewijst dat het ontwerp end-to-end werkt voordat enige laag volledig is uitgebouwd.

PRD naar Issues neemt het PRD en ontleedt het in verticale slices, elk afgebakend tot één tracer bullet. Voor de teamwerkruimtes-feature die ik eerder noemde, splitste de skill het PRD in vier issues:

1. Issue 1 (geen blokkades): Maak het workspace-model, de migratie, en één endpoint waarmee een geauthenticeerde gebruiker een werkruimte voor zichzelf kan aanmaken. UI: één knop. Tests: modelcreatie, endpoint retourneert 201, knop stuurt de juiste payload.
2. Issue 2 (geblokkeerd door Issue 1): Voeg meervoudig lidmaatschap toe — laat een gebruiker bij meerdere werkruimtes horen, met een workspace_user koppeltabel en een werkruimte-wisselaar in de navigatiebalk.
3. Issue 3 (geblokkeerd door Issue 1, parallel met Issue 2): Voeg de machtigingsoverervingsregels uit het PRD toe. Puur domeinlogica met een eigen testsuite.
4. Issue 4 (geblokkeerd door Issues 2 en 3): Voeg de factureringsaggregatie-logica en de factuurregel-generatie toe.

Twee dingen om op te merken bij die ontleding. Ten eerste: Issue 1 is op zichzelf een complete, werkende feature — als je na Issue 1 zou stoppen, heb je leverbare software. Dat is de tracer-bullet-belofte: elke slice is end-to-end bruikbaar. Ten tweede: de blokkeringsgrafiek is expliciet. Issues 2 en 3 kunnen parallel draaien, wat betekent dat ik twee agents kan starten, één per issue, en ze gelijktijdig werken zonder elkaar in de weg te zitten.

Die parallellisatie is de doorbraak die de meeste teams nog niet geïnternaliseerd hebben. Wanneer je stopt met denken over agents als één enkele werker en ze gaat zien als een pool van werkers met expliciete afhankelijkheden, verandert de doorvoer van een engineeringsessie van karakter. Ik schreef het bredere mentale model hiervoor uit in de agent-swarm-architectuur voor Claude Code — PRD naar Issues is het concrete artefact dat swarm-achtig werken veilig maakt in plaats van chaotisch.

Het andere dat PRD naar Issues voorkomt, is de ergste faalstand van AI-engineering: de horizontale-slice-val. Zonder verticale slicing zal een agent de neiging hebben om eerst alle models te bouwen, dan alle controllers, dan alle views, dan alle tests. Halverwege heb je een complete datalaag die niets gebruikt, een UI die gemockt is tegen het verkeerde contract, en nul werkende software. Met verticale slicing heb je altijd een werkend systeem; je hebt alleen een kleiner werkend systeem dan de uiteindelijke feature.

Skill 4: TDD — Red, Green, Refactor (en waarom de Refactor pijn doet)

Nu heb je het PRD, je hebt de issues, en je bent klaar om code te schrijven. Dit is waar de TDD-skill het overneemt, en waar de pipeline begint te onthullen hoe AI-agents zich werkelijk gedragen onder druk.

De TDD-skill draait de klassieke red/green/refactor-cyclus, maar aangepast voor agents:

1. Red: De agent schrijft een falende test voor het volgende gedrag in het huidige issue. Draai de test. Bevestig dat hij faalt om de juiste reden. (Deze substap is belangrijk — agents schrijven soms een test die faalt om de verkeerde reden, en je ontdekt dat pas twee uur later als "slagen" niet betekent wat je dacht.)
2. Green: De agent schrijft de minimale code die nodig is om de test te laten slagen. Draai de test. Bevestig dat hij slaagt.
3. Refactor: De agent verbetert de code zonder het gedrag te veranderen. Draai de test. Bevestig dat hij nog steeds slaagt.

Stappen 1 en 2 werken prachtig met agents. Claude is uitstekend in het schrijven van gerichte tests, en even uitstekend in het schrijven van minimale implementaties om die tests te laten slagen. De eerste keer dat ik hem in twintig minuten door een Laravel-serviceklasse zag razen, met elke methode gedekt door een test die geschreven was vóór de methode bestond, had ik oprecht het gevoel dat ik mijn werk een decennium lang verkeerd had gedaan.

Stap 3 is waar de problemen zitten.

Hier komt het eerlijke deel van dit hele artikel. AI-agents zijn diep onwillig om hun eigen code te refactoren binnen dezelfde context. Het patroon ziet er zo uit: je schrijft een groene test, de agent schrijft de minimale code, je zegt hem te refactoren, en hij retourneert dezelfde code met een opmerking die zegt "dit is al goed gestructureerd." Hij liegt niet. Vanuit zijn eigen context ziet de code er inderdaad prima uit. Het probleem is dat de agent al een uur naar zijn eigen logica staart en het perspectief verloren heeft dat nodig is om de code-geur te zien.

De workaround die voor mij werkt — en die de TDD-skill inbouwt — is om de refactorstap in een verse agentsessie te doen. Nieuw contextvenster. Geen geschiedenis van het schrijven van de originele code. Je geeft de nieuwe sessie de falende-dan-slagende test en de groene implementatie, en je vraagt hem te refactoren. Zonder de oorspronkelijke-auteur-bias is hij bereid de code uit elkaar te halen. De test geeft hem een contract om tegen te refactoren. De refactor is klaar. Je commit.

Dit is het moment dat veel mensen missen als ze zeggen "AI kan niet echt TDD doen." Dat kan het wel — maar alleen als je elke fase van de red/green/refactor-cyclus behandelt als een apart afgebakende agentsessie, niet als één gesprek. De skill dwingt die afbakening af. Het principe is hetzelfde als wat ik behandelde in waarom precies prompten beter werkt dan slim prompten — de agent is slechts zo goed als de context die je hem geeft, en dat omvat ook de context die je hem niet geeft.

Er is een tweede subtiel ding dat de TDD-skill afhandelt. Hij weigert de agent de red-stap te laten overslaan. Als je een agent een test laat schrijven tegen bestaande code, schrijft hij een test die bij de eerste run slaagt — en je hebt geen idee of de test daadwerkelijk het gedrag test dat je belangrijk vindt. De skill blokkeert dit door de falend-eerst-status af te dwingen. Je gaat niet verder totdat de test faalt om een reden die je kunt verwoorden.

Skill 5: Verbeter Codebase-Architectuur — Wanneer de pipeline terugloopt

De vier bovenstaande skills leveren je een werkende feature. Ze voorkomen op zichzelf niet dat je codebase verrot. Over vijf of tien features stapel je het soort structurele schuld op dat niet zichtbaar is in een individuele PR maar langzaam elke toekomstige feature moeilijker maakt. De vijfde skill is wat die afdrift opvangt.

Verbeter Codebase-Architectuur verschilt van de anderen. Het draait niet binnen de lineaire pipeline — het draait periodiek, tussen feature-cycli, als een opruimpass. De taak is om naar de huidige codebase te kijken en bewuste refactors voor te stellen, en de beste daarvan om te zetten in nieuwe issues die bovenaan de pipeline opnieuw binnenkomen.

De manier waarop het werkt is anders dan al het andere in de workflow. De skill start drie of meer parallelle sub-agents, elk geprompt om een radicaal ander interfaceontwerp voor te stellen voor het deel van de codebase dat gerefactord wordt. Drie sub-agents omdat één gewoon de status quo zou bevestigen en twee zouden vervallen in een binaire keuze — drie is het kleinste aantal dat echte alternatieven naar boven dwingt.

Ik draaide dit vorige maand op een contentpipeline-module die rommelig was geworden. De drie sub-agents kwamen terug met:

• Voorstel A: Een puur functionele pipeline van composeerbare stappen, elk een pure functie over een getypte payload.
• Voorstel B: Een event-driven ontwerp met een wachtrij en een set onafhankelijke consumers.
• Voorstel C: Een traditionele serviceklasse-hiërarchie met een basisklasse en drie concrete strategieën.

De bovenliggende agent evalueerde vervolgens alle drie tegen de werkelijke beperkingen van de codebase — testdekking, deploymentvorm, het bestaande datamodel — en adviseerde een hybride van A en B: puur functionele stappen van binnen, gedispatcht op de bestaande wachtrij-infrastructuur. Geen van de drie pure voorstellen was het juiste antwoord. De hybride was dat wel. En ik zou zelf nooit op de hybride zijn uitgekomen, omdat mijn brein al maanden vastgeklonken zat aan de bestaande serviceklasse-structuur.

De output van de skill is een RFC, eveneens ingediend als GitHub issue. De RFC beschrijft de voorgestelde refactor, de alternatieven die zijn overwogen en afgewezen, de redenering achter de aanbeveling, en het voorgestelde incrementele migratiepad. Zodra de RFC is goedgekeurd, komt hij opnieuw de pipeline in bij stap 1 — je Grill Me't het refactorvoorstel, schrijft er een PRD voor, ontleedt het in issues, en TDD't het.

Die cyclus is het deel dat het moeilijkst te communiceren is zonder het te zien draaien. De pipeline is niet echt lineair. Het is een lus. Features gaan door 1→2→3→4. Periodieke architectuurverfijningen gaan door 5→1→2→3→4. Over een kwartaal groeit de codebase in een richting die je koos, in plaats van af te drijven in een richting die hij zelf vond.

De tijdlijn — Hoe één echte feature door de pipeline gaat

Laat me doorlopen hoe dit er werkelijk uitziet in tijd, voor de teamwerkruimtes-feature waar ik steeds naar verwijs, zodat de abstractie vorm krijgt.

Maandagochtend, 45 minuten. Ik draai Grill Me op het ruwe idee. Tweeëntwintig vragen. Ik beantwoord ze. Aan het einde van de sessie is de ontwerpboom ver genoeg bewandeld dat ik de feature in één alinea kan beschrijven zonder voorbehouden.

Maandagochtend, 20 minuten. Ik draai Schrijf een PRD. De skill genereert het document uit het grill-transcript, ik review het, pas twee zinnen aan, en dien het in als GitHub issue. Issue #341.

Maandagochtend, 15 minuten. Ik draai PRD naar Issues. Het ontleedt #341 in de vier sub-issues die ik hierboven beschreef, met de blokkeringsgrafiek erbij. Issues #342, #343, #344, #345.

Maandagmiddag tot en met dinsdag. Ik draai TDD op issue #342 (de funderende slice). Ongeveer vier uur totaal. Red, green, refactor op elk gedrag. Ik houd de refactorstap in een apart contextvenster. Issue gesloten.

Woensdag. Ik start twee parallelle TDD-sessies, één op #343 en één op #344. Het zijn bewust onafhankelijke issues. Ongeveer drie uur elk, parallel draaiend in aparte vensters. Beide gesloten.

Donderdagochtend. Ik draai TDD op #345, de factureringsaggregatie. Ongeveer vijf uur, omdat het testoppervlak breder is. Gesloten tegen het einde van de dag.

Vrijdag. Ik draai Verbeter Codebase-Architectuur op de werkruimte-module. De drie sub-agents stellen drie structuren voor. De bovenliggende agent adviseert een kleine refactor om de machtigingscontrole-logica naar een pure module te extraheren. RFC ingediend als issue #346. Ik besluit dat het de moeite waard is, draai de lus opnieuw, en lever de refactor vrijdagmiddag op.

Totale doorlooptijd: ongeveer dertig uur gefocust werk over vijf dagen, voor een feature die ik op twee weken had geschat voordat ik deze pipeline begon te draaien. De reden dat het inkromp is niet dat de agents sneller typen dan ik. Dat doen ze — maar typen was nooit het knelpunt. De reden is dat de pipeline bijna alle herwerkingscycli elimineerde die voorheen de middelste drie dagen van de week opaten.

Het eerlijke deel — Waar deze pipeline faalt

Ik heb je verteld wat werkt. Het artikel verdient je vertrouwen pas als ik ook vertel waar het breekt.

De pipeline gaat ervan uit dat je goede antwoorden kunt geven tijdens Grill Me. Als je niet kunt verwoorden wat je werkelijk wilt, leggen de vragen alleen het gat bloot. De skill is geen vervanging voor nadenken — het is een afdwingmechanisme voor nadenken. Ik heb ontwikkelaars zien proberen Grill Me te gebruiken als manier om "uit te zoeken wat ze willen" midden in een sessie, en het resultaat is een transcript vol "ik weet het niet, wat denk jij?" wat een PRD oplevert dat effectief de voorkeuren van de agent zijn, vermomd als die van de gebruiker. Dat PRD wordt dan het contract waar elke downstream agent aan gehouden wordt, en je ontdekt bij issue #4 dat de voorkeuren van de agent niet de jouwe waren.

Het TDD-refactorprobleem lost niet volledig op, zelfs niet met een verse sessie. Soms kijkt de nieuwe agent naar de code en produceert een marginale opschoning die het diepere structurele probleem mist. Het patroon waar ik op ben uitgekomen: ik draai de refactor twee keer, in twee aparte verse sessies, en bekijk beide. Als ze overeenstemmen, commit ik. Als ze het niet eens zijn, ligt de echte refactor meestal in het meningsverschil, en kies ik de betere van de twee of geef ik beide terug aan een derde agent om te verzoenen. Dit is langzamer dan ik zou willen.

Parallelle issues zijn niet echt gratis. Wanneer ik twee TDD-sessies parallel draai op onafhankelijke issues, verdeel ik mijn eigen aandacht — en dat is de echte kost, niet de agent-rekenkracht. De blokkeringsgrafiek in PRD naar Issues voorkomt dat de agents elkaars code in de weg zitten, maar het kan niet voorkomen dat ik slecht context-switch. Ik beperk mezelf daarom tot twee parallelle sessies. Drie breekt me.

De architectuurskill kan te veel refactoren. De eerste keer dat ik Verbeter Codebase-Architectuur draaide op een gezonde module, genereerde het drie serieuze refactorvoorstellen voor code die geen refactoring nodig had. De skill is geneigd om werk te vinden. Jij bent de rem. Als geen van de drie voorstellen de codebase wezenlijk verbetert, is het juiste antwoord om de refactor over te slaan en de skill over twee maanden opnieuw te draaien. Discipline is hier belangrijker dan bij welke andere stap dan ook.

Skilllengte is niet skillkwaliteit. De twee beste skills in deze pipeline — Grill Me en PRD naar Issues — zijn kort. Misschien honderd regels elk. De skillschrijvers die ik de slechtste resultaten heb zien produceren zijn degenen die skilllengte als maatstaf voor grondigheid gebruiken. Precisie in wanneer een skill triggert en wat hij produceert is veel belangrijker dan hoeveel instructietekst hij bevat. Ik behandelde dit patroon in hoe Claude skills daadwerkelijk een workflow aansturen — hetzelfde principe geldt hier, in het kwadraat.

Hoe dit hervormt wat een engineer de hele dag doet

Stap even terug van de vijf skills. De werkvorm die de pipeline oplevert is wezenlijk anders dan wat ik in 2024 deed, en het is de moeite waard om hardop te zeggen wat er veranderd is.

Ik schrijf minder code. Ik schrijf meer contracten. Het PRD is een contract. De issues zijn contracten. De tests zijn contracten. De RFC's zijn contracten. De daadwerkelijke implementatie is steeds vaker iets dat een agent produceert tegen een contract dat ik heb geschreven, en mijn tijdsbesteding per feature is zwaar verschoven naar de contractschrijvende kant.

Ik denk meer in beslisbomen, minder in syntax. De eerste drie skills in de pipeline draaien allemaal om het oplossen van de ontwerpboom voordat er code bestaat. De twee daarna gaan over schoon uitvoeren tegen de opgeloste boom. Toen ik dat patroon eenmaal opmerkte, begonnen mijn engineeringgewoonten buiten de pipeline ook te verschuiven — ik betrap mezelf erop, midden in een gesprek over een feature, dat ik het soort vragen stel dat Grill Me stelt, voordat er ook maar een tool draait.

Ik vertrouw op parallellisme op een manier die ik vroeger nooit deed. Twee gelijktijdige TDD-sessies op onafhankelijke issues klinkt als een productiviteitshack. Het is eigenlijk een andere modus van engineering. De mentale vaardigheid die het vereist is het vermogen om de blokkeringsgrafiek stroomopwaarts correct te ontwerpen — als je de issues verkeerd ontleedt, botsen parallelle sessies. Als je ze goed ontleedt, is parallellisme bijna gratis. De pipeline bestraft slechte ontleding en beloont goede ontleding, en dat is een feedbacklus die ik eerder nooit had.

Ik behandel geheugen als een artefact, niet als een aanname. Elke belangrijke beslissing leeft op een plek waar toekomstige-Claude het kan lezen. Het PRD, de issues, de testnamen, de commitberichten, de RFC's — alles is gestructureerd alsof er morgen een geheugenloze senior engineer op de repo zou kunnen landen zonder context, want in de praktijk is dat precies wat er elke keer gebeurt als ik een verse agentsessie open.

Wil je een diepere blik op hoe het onderliggende skillssysteem dit soort compounding mogelijk maakt, dan is de agent-skills architectuuranalyse het artikel waar ik je vervolgens naartoe zou sturen. De pipeline die ik hier beschrijf is hoe skills eruitzien wanneer je ze met opzet aan elkaar koppelt.

De cursus die ik daadwerkelijk volg

Ik zou oneerlijk zijn als ik niet vermeld waar de meeste van deze patronen voor mij aan de oppervlakte kwamen. Matt Pocock — de engineer achter veel van het TypeScript-onderwijs waar ik stilletjes al jaren op leun — gaf een tweeweekse cohort genaamd Claude Code for Real Engineers van 30 maart tot 13 april 2026, en het curriculum komt bijna exact overeen met de pipeline die ik net heb beschreven. Plan/Execute/Clear-protocol. Tracer-bullet-implementatie. PRD-schrijven voor AI-lezers. Het autonome-lus-patroon aan het einde van week twee.

De cursus kost $795 op AI Hero. Ik heb geen affiliatie, ik krijg geen kickback, en ik heb me niet ingeschreven voor de live cohort — de on-demand versie is wat nu beschikbaar is, en ik evalueer of de structuur de kosten rechtvaardigt gezien het feit dat de meeste patronen openbaar en reproduceerbaar zijn als je bereid bent ze zelf samen te stellen. De eerlijke kijk: als je de leercurve wilt comprimeren van maanden naar weken en liever niet de vijf-skill-pipeline samenstelt uit blogposts zoals deze, is de cohort een redelijke gok. Als je geduldig bent en de bovenstaande pipeline je genoeg geeft om mee te starten, kun je er waarschijnlijk zelf komen.

Wat ik wel zal zeggen is dat de categorie die deze cursus bezet — gestructureerde engineeringpraktijk rond AI-agents, in tegenstelling tot "tips en trucs"-content — de categorie is die de komende twee jaar het meest gaat uitmaken. De markt gaat splitsen in engineers die AI behandelen als een typversneller en engineers die het behandelen als een geheugenloze medewerker die een echte pipeline nodig heeft. De tweede groep gaat cirkels draaien rond de eerste.

Voorbij de vijf skills — Waar ik nu naartoe werk

De pipeline zoals hij nu staat is solide. Het is niet waar ik wil dat hij eindigt.

Waar ik nu mee experimenteer is autonome agentintegratie aan de randen. Specifiek: een geplande agent die elke twee weken Verbeter Codebase-Architectuur opnieuw draait tegen de repo, RFC's indient als issues, en mij tagt voor review. Ik hoef niet te onthouden om de skill te draaien. De skill draait zichzelf. De RFC's landen in mijn wachtrij. Ik keur goed en ga de pipeline opnieuw in, of ik sluit als wontfix. Het architectuur-afdrift-probleem wordt een passief vinkje in plaats van een actieve gewoonte.

Het andere stuk is contextvenster-discipline door de pipeline heen. Elke stap produceert een artefact dat de inputcontext wordt voor de volgende stap. Als het artefact te uitgebreid is, loopt de context van de volgende stap vol en wordt de agent dommer. De kunst is elk artefact zo strak mogelijk te maken terwijl het nog steeds een compleet contract is. Ik heb mijn PRD-sjabloon de afgelopen maand bijgesneden, en de downstream codekwaliteit is meetbaar verbeterd elke keer dat ik een alinea schrapte die zijn gewicht niet trok. Dat principe — het idee dat minder precies gekozen context beter werkt dan meer losjes gecureerde context — is de belangrijkste hefboom in ontwikkelen met AI-agents waar niemand over praat in de tutorials.

Het derde stuk is taalonafhankelijke toepassing. Ik heb deze pipeline gedraaid tegen Laravel, tegen Next.js, tegen een Python-datapipeline, en tegen een Bash-zware infrastructuur-repo. Het werkt op alle vier. De skills weten niet in welke taal ze opereren; ze opereren op de ontwerpboom, het PRD, de issues, de tests, en de architectuurpatronen. Die taalonafhankelijkheid is de eigenschap die me doet denken dat deze pipeline de juiste is om de komende twee jaar in te investeren, ongeacht met welke stack ik uiteindelijk werk.

Wat te doen vóór maandagochtend

Als je tot hier hebt gelezen en overtuigd bent van het idee, is dit de volgorde waarin ik je zou aanraden het te proberen. Installeer niet alle vijf skills tegelijk. De pipeline is om een reden sequentieel, en proberen hem als Big Bang te adopteren zal elke workflow die je nu hebt overspoelen.

1. Deze week: Installeer Grill Me. Gebruik het op de volgende feature waarvoor je anders gewoon Claude zou prompten om te schrijven. Let op de vragen die het stelt. Let op welke je niet had kunnen beantwoorden zonder die hulp. Dat is de waarde.
2. Volgende week: Voeg Schrijf een PRD toe. Leid de Grill Me-output erdoorheen. Dien het PRD in als GitHub issue. Wen eraan dat het artefact ergens duurzaam leeft.
3. De week daarna: Voeg PRD naar Issues toe. Kijk hoe je features uiteenvallen in tracer bullets. Leer goede verticale slices van slechte te onderscheiden — slechte komen terug als één issue dat niet wil sluiten.
4. Week vier: Voeg TDD toe. Wees voorbereid op de refactorstap-frictie. Los het op door de refactor in een aparte sessie te draaien.
5. Week zes: Voeg Verbeter Codebase-Architectuur toe. Draai het één keer. Kijk of je de output voldoende vertrouwt om ernaar te handelen.

Tegen week acht heb je een werkende pipeline. Tegen week twaalf ontwerp je je eigen variaties. Tegen maand zes voelt de workflow zo natuurlijk als de workflow die je had voordat agents bestonden, maar dan sneller, doelbewuster, en moeilijker te breken.

De zondag die ik verloor aan Laravel was de zondag die ik moest verliezen. Het was de prijs van leren, diep in mijn botten, dat ontwikkelen met AI-agents niet gaat over prompts typen en code zien verschijnen. Het gaat over het produceren van de juiste artefacten in de juiste volgorde zodat een geheugenloze expert het werk op elk punt kan oppakken en voortzetten zonder het ontwerp te verliezen. De pipeline is hoe je dat mogelijk maakt.

Ik heb sindsdien geen zondag meer zo verloren.

Veelgestelde vragen

Wat betekent "ontwikkelen met AI-agents" in de praktijk?

Ontwikkelen met AI-agents betekent de agent behandelen als een geheugenloze senior engineer die elke beslissing, vereiste en beperking vastgelegd nodig heeft als een duurzaam artefact voordat er code wordt geschreven. In de praktijk is dat een vaste pipeline — Grill Me, PRD, Issues, TDD, Architecture Refactor — waarbij elke stap de context produceert waar de volgende stap van afhankelijk is. Zie de pipelinesecties hierboven voor de volledige doorloop.

Werken deze skills alleen in Claude Code?

De vijf skills zijn taal- en concept-agnostisch — de onderliggende patronen (ontwerpboom, verticale slices, red/green/refactor, parallelle sub-agents) werken met elke agentruntime die skills of equivalente afgebakende instructies ondersteunt. Claude Code is waar ik ze draai omdat het skillssysteem daar het meest volwassen is, maar dezelfde pipeline kan gereproduceerd worden op andere harnesses met aangepaste slash-commando's of systeemprompts.

Waarom weigeren AI-agents hun eigen code te refactoren?

Agents worstelen met refactoren binnen dezelfde context omdat ze de hele sessie over de code hebben geredeneerd en het perspectief verliezen dat nodig is om de code-geur te zien. De oplossing is een verse agentsessie openen zonder eerdere context, alleen de falende-dan-slagende test en de groene implementatie meegeven, en vragen om te refactoren tegen het testcontract. Het principe wordt behandeld in de TDD-sectie hierboven.

Wat is een "verticale slice" of "tracer bullet" in deze context?

Een verticale slice is een end-to-end implementatie die elke laag van het systeem raakt — UI, API, domeinlogica, database — maar slechts één klein ding helemaal doorvoert. Het komt oorspronkelijk van het "tracer bullet"-patroon uit The Pragmatic Programmer en is de werkeenheid waarin PRD naar Issues een feature ontleedt. Het resultaat is dat elk issue dat je sluit werkende software oplevert, niet een halfgebouwde laag.

Is de Claude Code for Real Engineers-cursus $795 waard?

De cohort behandelt dezelfde patronen als beschreven in dit artikel — Plan/Execute/Clear, PRD-schrijven voor AI-lezers, tracer-bullet-implementatie, autonome lussen — in een gestructureerd tweeweeks formaat. Het is de kosten waard als je de leercurve wilt comprimeren en de voorkeur geeft aan begeleide instructie boven het zelf samenstellen van de pipeline uit openbare bronnen. De on-demand versie is momenteel beschikbaar; live cohorten worden periodiek herhaald.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren, of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io