Compound engineering

Wat is compound engineering?

Compound engineering is elke taak met een agent afsluiten door iets achter te laten dat de volgende taak goedkoper maakt. De wijziging gaat live, en er blijft iets bij: een regel in het instructiebestand van het project, een controle die vanaf nu vanzelf draait, een bewaard commando, een notitie waarom je die keuze maakte.

Standaard gaat het anders. Je lost een bug op met een coding agent, de fix gaat erin, de sessie stopt en de redenering die eronder zat is weg. Volgende maand botst iemand op dezelfde muur en begint van nul, want het model start met een leeg context window en niets op schijf vertelt wat jij geleerd hebt.

Kieran Klaassen van Every beschreef de praktijk in augustus 2025 onder de naam compounding engineering: "building self-improving development systems where each iteration makes the next one faster, safer, and better." In december 2025 kozen hij en Dan Shipper voor de kortere naam en een simpelere zin: "in compound engineering, you expect each feature to make the next feature easier to build." Every gaf de werkwijze intussen vrij als plugin onder MIT-licentie, bruikbaar in veertien agent-omgevingen, waaronder Claude Code, Codex en Cursor.

De loop heeft vier stappen: plannen, werken, reviewen, compounden. Alleen de laatste is nieuw. Dat is het moment waarop je vraagt wat deze taak je geleerd heeft en waar die les moet staan zodat een machine ze de volgende keer terugvindt.

Wat een taak kan achterlaten

"Schrijf op wat je geleerd hebt" is te vaag om iets mee te doen. In de praktijk zijn er vijf soorten, en ze wegen niet even zwaar.

• Een regel in het instructiebestand. De AGENTS.md of CLAUDE.md in de root van de repository, die bij elke sessie meegelezen wordt. De richtlijnen van Anthropic voor Claude Code geven een duidelijk signaal om er iets aan toe te voegen: de agent maakt dezelfde fout een tweede keer, of jij typt dezelfde correctie als vorige sessie.

• Een controle die vanzelf draait. Een test, een lintregel, een script dat met een foutcode stopt als twee totalen niet overeenkomen. Dit is de sterkste soort, want niemand moet ze onthouden. Anthropic zegt zelf waarom: instructiebestanden "shape Claude's behavior but are not a hard enforcement layer", terwijl een hook of een toestemmingsregel "enforced by the client regardless of what Claude decides to do" is.

• Een bewaarde skill of een commando. Komt een job in dezelfde vorm terug, dan verhuist de procedure uit de chat naar een bestand dat de agent inlaadt wanneer het relevant is. Het signaal van Anthropic: je plakt telkens dezelfde checklist, of een stuk van je instructiebestand is een procedure geworden in plaats van een feit.

• Een opgeschreven beslissing. Een alinea over waarom creditnota's eruit blijven, of waarom je de connector van de leverancier links liet liggen. De plugin van Every schrijft die in een map docs/solutions/, zodat de volgende planstap ze kan lezen en niemand die vraag over zes maanden heropent.

• Een aanpassing aan de omgeving. De agent liep drie keer vast omdat er een driver ontbrak in de container. Zet die in het opzetscript en de volgende agent, en de volgende collega, komt die fout nooit tegen.

De eerste en de vierde kosten tokens in elke sessie. De tweede en de vijfde kosten niets tijdens het draaien en houden stand ook als het model over de tekst heen leest. Heb je de keuze, maak dan van een regel een controle.

Een terugkerende taak, drie rondes

Een groothandel sluit de maand af op de vijfde werkdag en wil een verkooprapport voor de directievergadering, gebouwd op een export uit het ERP. Elke maand dezelfde job.

De eerste maand. Je legt alles uit: waar de export terechtkomt, dat creditnota's een minteken dragen en niet als verkoop mogen tellen, dat de maand op de vijfde afsluit. Het rapport klopt, en daar stoppen de meeste mensen. De compound-stap kost tien minuten: drie regels in het instructiebestand over de opbouw van de export en de regel rond creditnota's, plus één test die faalt zolang het totaal niet gelijk is aan het totaal dat het ERP zelf toont.
Ronde twee moet de creditnotaregel niet opnieuw ontdekken, en vertrouwt een totaal niet omdat het er ongeveer juist uitziet.

De tweede maand. Aankoop heeft een productgroep bijgemaakt, het script liet die lijnen stilzwijgend vallen en het rapport stond vierduizend euro te laag. De fix zelf is klein: één regel in een mappingtabel. Wat blijft, is niet de fix: het is een controle die het script laat stoppen zodra het een categorie tegenkomt die het niet kent, plus twee zinnen die zeggen dat de echte fout het stil laten vallen was.
Ronde drie hangt niet meer af van iemand die een verkeerd cijfer met het blote oog opmerkt.

De derde maand. Het werk heeft dezelfde vorm als de maand ervoor, dus wordt het een bewaard commando: export ophalen, afstemming draaien, rapport schrijven, en als de afstemming niet klopt, stoppen en de controller mailen.
Ronde vier heeft jou niet meer nodig, want de collega die in juli vervangt kan het draaien.

Drie sporen, samen goed voor een veertigtal minuten extra werk over drie maanden. Wat je ervoor terugkrijgt: de vierde afsluiting is niet meer dan een vraag met een controle erachter, geen gesprek.

Compound engineering tegenover een agent taak per taak gebruiken

Beide aanpakken gebruiken dezelfde tools en leveren dezelfde wijziging. Ze verschillen in wat er bestaat zodra de taak af is.

Taak per taak bestaat alleen de wijziging: een commit, een werkend script en een chatlog dat niemand nog opent. Waarom de code er zo uitziet, zit in het hoofd van wie erbij was. De tweede keer dat de job langskomt, kost hij bijna evenveel als de eerste.

Bij compound engineering bestaat de wijziging plus iets dat de volgende sessie kan lezen. De tweede ronde kost minder, en het verschil groeit zolang die sporen kloppen. De keerzijde is eerlijk: de compound-stap is echt werk bovenop een taak die je al af waande, en bij een eenmalige job is het weggegooid.

De stapel klein genoeg houden om gelezen te worden

Laat je het op zijn beloop, dan krijg je een tweede probleem. Thoughtworks zette agent instruction bloat in de voorzichtigheidsring van zijn Technology Radar van april 2026. Contextbestanden groeien aan naarmate teams overzichten, afspraken en regels toevoegen, en elke toevoeging lijkt op zich nuttig. Het resultaat, in hun woorden: "Instructions become long and sometimes conflict with each other."

Twee foutvormen wegen het zwaarst. Tegenspraak: twee regels spreken elkaar tegen, het model kiest er willekeurig een uit en het gedrag wordt een muntstuk opgooien. Veroudering: de regel beschreef de code zoals ze er in maart uitzag. Anthropic hangt er cijfers aan. Hou een instructiebestand onder de 200 regels, want langere bestanden vragen meer context en worden slechter opgevolgd, en ga ze geregeld na om verouderde of tegenstrijdige instructies weg te halen.

Instructiebestanden verouderen zoals documentatie veroudert, en om dezelfde reden: het is tekst die door niets getest wordt. Thoughtworks formuleert het bij skills als onboardingdocumentatie zo: "unlike static documentation, executable documentation can help you notice staleness much earlier." Een verouderde regel zwijgt. Een verouderd script faalt. Zoek dus bij elke regel die je toevoegt een regel om te schrappen.

Wat niet vanzelf aangroeit

De naam doet denken aan intrest die aandikt terwijl je slaapt. Zo werkt het niet.

Het model onthoudt jouw project niet. Anthropic zegt het kort en droog: elke sessie begint met een leeg context window. Sommige tools schrijven intussen zelf notities tussen sessies door, maar dat geheugen staat lokaal op de machine waar je werkt. Alles wat een collega of een leverancierswissel moet overleven, hoort in een bestand in de repository.

Iemand moet beslissen wat het bewaren waard was. Een sessie die elke vaststelling opschrijft, levert de opgeblazen stapel hierboven. Een sessie die niets opschrijft, levert de reset.

De cijfers die circuleren komen van dat ene team. Every vertelt dat features sneller live gaan en dat pull requests na drie maanden op deze manier werken in uren in plaats van dagen gereviewd worden. Dat zijn de cijfers van een klein bedrijf over zijn eigen product, zonder vergelijkingsgroep. Lees ze als een verslag van hoe het aanvoelde, niet als een getal voor je businesscase.

Hetzelfde patroon buiten software

Er is niets aan het idee dat alleen voor code werkt. Het past bij elke taak die terugkomt en waar de context elke keer opnieuw uitgelegd moet worden.

Neem leveranciersfacturen die per mail binnenkomen en ingeboekt moeten worden. De eerste keer dat je dit met een agent opzet, leg je uit welke mailbox, welke leveranciers pdf's sturen en welke gestructureerde bestanden, en dat alles boven 5.000 euro eerst langs de zaakvoerder gaat. Taak per taak leg je dat volgend kwartaal opnieuw uit. Compound je het, dan wordt het een instructiebestand dat de agent leest, een controle die weigert te boeken als leverancier en bestelnummer niet bij elkaar passen, en een bewaarde procedure die een vervanger kan draaien.

Of de compound-stap de moeite waard is, hangt niet af van de omvang van de taak. Het hangt af van hoe vaak ze terugkomt en hoeveel van de uitleg elke keer identiek is.

Je kan opvolgen of het werkt zonder een dashboard te bouwen. Drie cijfers bewegen als eerste: hoeveel reviewrondes een wijziging nodig heeft voor ze aanvaard wordt, hoe vaak je een correctie hertypt die je al eens gegeven hebt, en hoeveel tijd je kwijt bent aan context geven voor een vertrouwde taak begint. Schrijf op waar die vandaag staan voor je eigen terugkerende job. Staan ze over drie maanden nog gelijk, dan wordt er niets gelezen van wat je bijhoudt.