Je feedback loop is de bottleneck, niet hoe snel je kan bouwen

Een machine heeft PostgreSQL herschreven in Rust. Niet een fragment. Het hele systeem, en het haalt honderd procent van de standaard regressiesuite: 46.066 van de 46.066 queries (pgrust, grotendeels met AI gebouwd door Michael Malis en Jason Seibel). Dat is een indrukwekkende scope. De vraag is alleen niet hoe knap dat is, maar waaróm je die herbouw durft te vertrouwen met je data.

Het antwoord is onromantisch: er lag al een uitputtende testsuite klaar die query voor query controleert of de nieuwe versie doet wat het origineel deed. Geen magie maar vakmanschap. Vakmanschap dat er al was voordat er één regel Rust werd gegenereerd.

En daar wou ik het vandaag over hebben. Sinds agents het typewerk overnemen kost bouwen bijna niets meer, en valt de oude rem, de typesnelheid, weg. Er komt een nieuwe rem voor in de plaats, en volgens mij betekent dat het volgende: de snelheid van je feedback is je maximumsnelheid. Zonder feedbackloop bouwt een agent razendsnel, en volledig blind.

Geef de agent een kans om te falen

Ik zag dit van dichtbij op een hackathon waar elk team met dezelfde agents en modellen werkte, een halve dag lang. Zelfde gereedschap, maar niet dezelfde uitkomsten: het ene team leverde iets werkbaars op, bij het andere viel de demo om zodra je het opstartte. Het verschil zat niet in de gebruikte modellen, maar in de aanpak.

Voor het werken met agents is het handig dat je iets hebt waartegen de agent kan testen, iets waarmee hij zelf kan bepalen of het gefaald heeft of niet. Een testsuite, een build die faalt of slaagt, een screenshot naast het ontwerp. Daarmee kan de agent zelfstandig doorwerken: bouwen, controleren, de uitkomst lezen, bijsturen. De teams zonder zo’n check hadden maar één toetssteen: de developer. Die werd daarmee de bottleneck, en wat er uitrolde was snel, veel, en niet te vertrouwen.

pgrust uit de opening is daar een bewijs van: een compleet databasesysteem, door een machine herbouwd, en tóch te vertrouwen, niet ondanks maar dankzij die testsuite. Niet dat je er blind op overstapt, en een testsuite waarborgt echt niet in z’n eentje kwaliteit. Maar zonder die suite was die herbouw simpelweg niet te vertrouwen geweest. In het klein werkt precies datzelfde mechanisme: een check die de agent zelf kan draaien bepaalt of hij doorbouwt of vastloopt.

Nog een inzicht: grote taalmodellen zijn sterker in veelgebruikte talen als Python dan in Rust, simpelweg omdat er meer van in de trainingsdata zit. Je zou je kunnen voorstellen dat het handig is om het model te laten bouwen waar het sterk staat en daarna te vertalen, met je testsuite als vangnet. Wie een dekkende set tests heeft, maakt van de programmeertaal een implementatiedetail in plaats van een gok. Dat is in elk geval wat er bij pgrust gebeurde: de vertaling naar Rust leunde volledig op die regressiesuite.

Trek zelf de grenzen

De tweede breuklijn tussen werkend en waardeloos is architectuur. En hier ligt een valkuil: de agent kiest niet de juiste oplossing, hij kiest de meest voorkomende. Collega Michiel Kooiman noemt dat treffend het automatiseren van aannames: elke keer dat een model iets invult, kiest het voor jou, en het kiest naar waarschijnlijkheid, niet naar kwaliteit. Vraag om een web-app en je krijgt React. Vraag om een systeem en je krijgt de architectuur die het vaakst in de data voorkwam.

Maar ja dat is nou precies het werk dat je niet mag gokken. Martin Fowler schreef het jaren geleden al: het moeilijkste aan een systeem is de grenzen goed krijgen, en te vroeg opsplitsen smeert een laag stroop over verkeerde grenzen. Begin klein, begin simpel, splits pas als de grenzen stabiel zijn. Die wijsheid wordt met agents alleen maar urgenter. Bij implementaties waar de interface vooraf was afgesproken, zag ik merkbaar minder ruis tussen de onderdelen. Agents bouwen meerdere delen tegelijk, in hoog tempo, dus je komt sneller in de knel dan ooit als de grenzen niet kloppen.

Dus waar je concreet op kan letten: de grens trek je zelf, de agent vult 'm in. Dwing de speelruimte af zodat er weinig fout kán gaan, zoals collega Nahuel Manterola laat zien met het onmogelijk maken van ongeldige toestanden. Hoe strakker je de ruimte begrenst, hoe minder de agent kan afdwalen.

Beperk de schade, en leer sneller

Snelheid zonder vangrails is geen snelheid, het is risico. De praktijk die zich hier opdringt komt uit de wereld van agentic engineering: laat agents in een geïsoleerde omgeving werken en lever hun resultaat op als voorstel, niet als directe wijziging op de hoofdlijn. Alles gaat langs een poort, en die poort is menselijk oordeel.

Alleen: die poort kost tijd die je op een dag als deze niet hebt. Een logische stap zou dan zijn: laat een agent de eerste review doen, getoetst tegen de gedeelde kwaliteitslat die ik in de vorige blog quality.md noemde. Diezelfde afspraak over wat “goed” betekent, gebruik je nu twee keer: één keer om te bouwen, één keer om te beoordelen. Mens én machine toetsen tegen hetzelfde document.

En dan het onthouden. Een team dat een fout maakt en er niet van leert, maakt hem opnieuw; daar bestaat de retrospective voor. Maar als we hier de lijn eens doortrekken? Als de retro er is om herhaalde fouten te voorkomen, waarom zit de agent er dan niet bij? De agents deden op de hackathon niet mee aan onze “inspectie”, terwijl zij de meeste fouten maakten. Dus leg elke fix die een mens aandraagt vast op een plek waar de agent hem de volgende keer zélf leest. In de praktijk kan dat zo simpel zijn als één markdown-bestand of skill per onderwerp waarin je de bevindingen verzamelt, dat je er alleen bij pakt wanneer het relevant is. De retrospective wordt dan geen ritueel maar een loop, en loops draaien sneller dan vergaderingen.

Waar het op neerkomt

Zelfde tools, andere uitkomst. Dat betekent dat het niet aan de modellen ligt, maar aan de practices. En het ongemakkelijke is: die practices zijn niet nieuw. Tests, kleine stappen, heldere grenzen, review, leren van je fouten: het staat al decennia in elk goed engineering-handboek. Wat AI verandert, is de inzet. Het haalt de typrem weg en legt genadeloos bloot wie de discipline eronder op orde had en wie erop leunde dat het bouwen vanzelf traag genoeg ging om fouten op te vangen.

En denk je nu: pgrust had z’n testsuite al klaar, mijn code niet? Dan is dat juist het argument om aan het vakmanschap van je software te gaan werken. Een testsuite opbouwen, weten wat “goed” betekent, de grenzen kunnen trekken: dat is vakmanschap, en dat was altijd al het echte werk. AI heeft het niet overbodig gemaakt, het heeft het juist moeilijk gemaakt om je te verschuilen. Zoals collega Jorrit Everts betoogt, vraagt software-ontwikkeling in het tijdperk van AI juist meer vakmanschap dan ooit.

Wil je dit maandag in je eigen team neerleggen, dan is dit de kern:

1. Geef elke agent een check die hij zelf kan draaien: een test, een build, een screenshot. Geen check betekent dat jij de check bent.
2. Houd de stappen klein en lever eerst een dun, werkend geheel voordat je uitbouwt.
3. Trek de grenzen vóór de agent dat doet: architectuur is jouw beslissing, niet zijn default.
4. Laat een agent de eerste review doen tegen een geschreven kwaliteitslat, en houd de menselijke poort erachter.
5. Leg elke fix vast waar de agent hem terugvindt, zodat dezelfde fout niet twee keer wordt gemaakt.

Bouwen is je bottleneck niet meer. De vraag is of je feedback snel genoeg is om die snelheid te verdienen.

‍