Wat je mist is meestal geen gereedschap

Ik ging die vijf uur DHH in met een boodschappenlijstje in mijn hoofd. Welke tools gebruikt hij, wat mis ik, wat installeer ik vanavond. Ik kwam eruit met een lijstje van drie dingen, en geen ervan is te installeren.

Dat is een ongemakkelijke uitkomst, want het is veel prettiger om te horen dat je een tool mist. Een tool koop je. Een gewoonte moet je invoeren, en dat is werk.

Even eerlijk over waar ik stond. Ik draai al maanden meerdere agents tegelijk, elk in een eigen git-worktree zodat ze elkaars bestanden niet aanraken, met één overzicht waarin ik zie welke er bezig is, welke vastzit en welke klaar is. Loopt er een vast, dan krijg ik een seintje.

DHH beschrijft precies dat, maar dan in een terminal: tmux met panes, inmiddels een tool die daar agentstatus bij doet, en een zijbalk die per project oprolt wie zijn aandacht nodig heeft. Andere schil, zelfde machine eronder.

Dat is het eerste dat ik wil rechtzetten, want er wordt over deze aflevering geschreven alsof hij een tijdperk verder is. Vier mini-pc's in een kast en zestien parallelle threads klinken indrukwekkend, maar hij zegt er zelf bij dat het niet vol te houden is en dat de mens de bottleneck is, niet de hardware. Het aantal is geen prestatie. De vorm van het werk is dat wel.

Zijn standaardwerkwijze is te saai om spannend te klinken en te goed om te negeren. Het ene model doet het werk, een ánder model kijkt het na. Hij bouwt met Claude, laat Codex op de hoogste stand reviewen en gooit er sinds kort een derde bij. Niet omdat het eerste model slecht is, maar omdat een model met andere training andere dingen ziet.

Hij haalt er een onderzoek bij dat de CTO van Shopify liet doen op echte productie-incidenten: pull requests die door agents waren nagekeken, veroorzaakten minder storingen dan die door mensen waren gereviewd. Wij vonden eerder iets vergelijkbaars in onderzoek naar 25.000 pull requests: niet het schrijven is de bottleneck, het nakijken is dat.

Waarom ik dit niet deed, is precies waarom het werkt. Als je zelf de code niet meer typt, verlies je het gevoel voor waar het mis kan gaan — je leest een diff van tweehonderd regels en ziet vooral dat het er netjes uitziet. Een tweede model heeft dat gevoel ook niet, maar het heeft wel geduld, en het heeft geen ego over werk dat het niet zelf gemaakt heeft. Het kost twee minuten per klus. Vanaf deze week is het een vaste stap aan het eind van elke klus.

Hier zit het echte verschil, en het is geen gradatie maar een soort. DHH bouwt een bot die 's nachts zelfstandig door zijn pull requests en issues heen gaat, elk in een geïsoleerde omgeving, en hem 's ochtends één mail stuurt: deze twaalf zijn klaar, deze zou ik sluiten. Hij zit dan niet meer ín de lus. Hij zit erna.

Mijn setup is volledig synchroon. Er gebeurt niets als ik niet kijk. Zestien agents of drie maakt daarbij niet uit — zolang elke stap op mij wacht, ben ik de klok van het hele systeem.

Dat is ook precies waar het schaalverhaal omslaat. Meer agents naast elkaar zetten helpt tot het punt waarop jij de beslissingen niet meer bij kunt benen, en dat punt ligt lager dan je denkt: twee, drie tegelijk. Daarboven ga je niet sneller, je gaat alleen slechter opletten. De enige manier omhoog is niet meer parallellisme, maar minder momenten waarop het werk op jou moet wachten.

De scherpste observatie uit de aflevering komt uit een experiment bij zijn eigen bedrijf, waar ze agents als collega's in hun projecttool zetten en er to-do's aan toewijzen in plaats van ermee te chatten. Zijn conclusie: een chatvenster nodigt uit om te wachten. Het ziet eruit als een gesprek, dus je blijft hangen tot het antwoord komt.

Een toegewezen taak doet dat niet. Je wijst hem toe en gaat weg. Datzelfde werk, hetzelfde model, maar een andere vorm — en die vorm bepaalt of jij ernaast blijft zitten.

Twee dingen uit die vijf uur zijn spectaculair en niet mijn probleem. De vier machines in de kast, verbonden via een privénetwerk, met zestien threads erover verdeeld: leuk, maar het lost een bottleneck op die ik niet heb. En zijn eigen Linux-distributie, waarin een agent niet alleen je code maar je hele besturingssysteem kan verbouwen — die kneedbaarheid is echt, en het is een hobbyargument, geen productiviteitsargument.

Dat onderscheid is belangrijker dan het klinkt. Het grootste risico bij deze aflevering is dat je het spektakel kopieert en de gewoonte laat liggen.

De vraag die ik het vaakst krijg bij AI-consultancy is welke tools een team moet hebben. Bijna altijd is het antwoord: die heb je al. Wat ontbreekt is het proces eromheen — wie kijkt het na, wat gebeurt er als niemand kijkt, en hoe voorkom je dat één mens de klok van het hele team wordt.

Dat is ook waarom code goedkoop wordt en engineering niet. Genereren kost bijna niets meer. Beoordelen, integreren en beheren kosten precies evenveel als altijd, en dat is waar wij bij tech consultancy op zitten. Of het daarna ook echt sneller gaat in plaats van alleen drukker, is een meetvraag — daar is Agile Analytics voor.

Mijn eigen lijstje voor de komende weken is kort: elke klus door een tweede model, en zoeken naar het eerste stuk werk dat 's nachts kan doorlopen zonder dat ik ernaast zit. Geen van beide staat in een App Store.

Loop je hier tegenaan in je eigen team — agents die draaien maar een proces dat nog op één persoon wacht? Neem contact op. Kom met hoe je nu werkt, niet met een toollijst; dat levert een beter gesprek op.