Het artikel betoogt dat de traditionele definitie van een klein softwareteam is veranderd door de integratie van AI-coding agents. Waar menselijke teams beperkt waren in hun output, kunnen agents honderden commits en PR's parallel genereren. Om deze schaalbaarheid te ondersteunen zonder dat merge conflicts de productiviteit negatief beïnvloeden, is een uiterst modulaire architectuur (zoals de microservices-aanpak van Uber) noodzakelijk. Bovendien is modulariteit nu makkelijker te implementeren omdat agents de overhead van boilerplate en CI-configuraties kunnen overnemen, en omdat kleinere modules beter passen binnen de beperkte contextvensters van AI-modellen.
Er bestaat niet langer zoiets als een klein softwareteam
Uber staat bekend om het draaien van duizenden microservices. Ze zijn uitgelopen op zoveel services omdat honderden engineers op hun eigen schema wilden deployen, met een duidelijk eigenaarschap over hun code, in plaats van te wachten in één gigantische merge queue.
Decennialang hoefde een klein team van 5 of 10 mensen die tegelijkertijd code schreven dit niet eens te overwegen. Op een drukke dag genereerde een klein team misschien 50 commits, 20 pushes en 10 PR's. Een klein team van nu, dat 20 tot 100 agents parallel laat draaien, kan 500 commits, 200 pushes en 100 PR's genereren.
De aanpak van Uber op het gebied van modulariteit leek destijds misschien extreem, maar het zou wel eens de nieuwe norm kunnen worden.
- Eén ontwikkelaar die op een "single-threaded" manier codeert: bewerkt één bestand per keer.
- Eén ontwikkelaar die op een "multi-threaded" manier codeert: gebruikt coding agents parallel.
Hoe modularer je code is, hoe meer agents je parallel kunt draaien
Als je een grote monolithische service hebt waarbij elke wijziging zorgvuldig moet worden gecoördineerd, is de kans groot dat twee significante stukken werk elkaar in de weg zitten, wat je dwingt om merge conflicts op te lossen en te refactoren.
Als je duizenden microservices hebt zoals Uber, heb je een "embarrassingly parallel" manier van werken aan code. Je start een coding agent voor elke service, geeft de opdracht om "de prestaties te verbeteren", en er is een goede kans dat je overal significante verbeteringen doorvoert.
Meer dan 100 coding agents die parallel draaien, moeten onafhankelijk van elkaar goed kunnen functioneren. Als ze al hun tijd besteden aan het oplossen van merge conflicts, het repareren van kapotte builds en het creëren van deployment-nachtmerries, kun je eindigen met een netto-negatieve productiviteit.
Modulariteit is goedkoper geworden
Het opsplitsen van zaken was vroeger erg duur, aangezien elke service meer boilerplate, infrastructuur en CI-configuratie betekende. Agents schrijven dit nu allemaal, waardoor de overhead veel minder relevant is.
Agents zijn bovendien extreem beperkt in hun context. Een module (of het nu een service of een bibliotheek is) die klein genoeg is om in het contextvenster te passen, verbetert de prestaties van de coding agent aanzienlijk.
De modulariteit van je codebase bepaalt hoeveel coding agents je effectief parallel kunt draaien; daarom is het nu de moeite waard om hier vanaf het begin op te ontwerpen.
Er bestaat niet langer zoiets als een klein softwareteam
Uber staat bekend om het draaien van duizenden microservices. Ze zijn uitgelopen op zoveel services omdat honderden engineers op hun eigen schema wilden deployen, met een duidelijk eigenaarschap over hun code, in plaats van te wachten in één gigantische merge queue.
Decennialang hoefde een klein team van 5 of 10 mensen die tegelijkertijd code schreven dit niet eens te overwegen. Op een drukke dag genereerde een klein team misschien 50 commits, 20 pushes en 10 PR's. Een klein team van nu, dat 20 tot 100 agents parallel laat draaien, kan 500 commits, 200 pushes en 100 PR's genereren.
De aanpak van Uber op het gebied van modulariteit leek destijds misschien extreem, maar het zou wel eens de nieuwe norm kunnen worden.
- Eén ontwikkelaar die op een "single-threaded" manier codeert: bewerkt één bestand per keer.
- Eén ontwikkelaar die op een "multi-threaded" manier codeert: gebruikt coding agents parallel.
Hoe modularer je code is, hoe meer agents je parallel kunt draaien
Als je een grote monolithische service hebt waarbij elke wijziging zorgvuldig moet worden gecoördineerd, is de kans groot dat twee significante stukken werk elkaar in de weg zitten, wat je dwingt om merge conflicts op te lossen en te refactoren.
Als je duizenden microservices hebt zoals Uber, heb je een "embarrassingly parallel" manier van werken aan code. Je start een coding agent voor elke service, geeft de opdracht om "de prestaties te verbeteren", en er is een goede kans dat je overal significante verbeteringen doorvoert.
Meer dan 100 coding agents die parallel draaien, moeten onafhankelijk van elkaar goed kunnen functioneren. Als ze al hun tijd besteden aan het oplossen van merge conflicts, het repareren van kapotte builds en het creëren van deployment-nachtmerries, kun je eindigen met een netto-negatieve productiviteit.
Modulariteit is goedkoper geworden
Het opsplitsen van zaken was vroeger erg duur, aangezien elke service meer boilerplate, infrastructuur en CI-configuratie betekende. Agents schrijven dit nu allemaal, waardoor de overhead veel minder relevant is.
Agents zijn bovendien extreem beperkt in hun context. Een module (of het nu een service of een bibliotheek is) die klein genoeg is om in het contextvenster te passen, verbetert de prestaties van de coding agent aanzienlijk.
De modulariteit van je codebase bepaalt hoeveel coding agents je effectief parallel kunt draaien; daarom is het nu de moeite waard om hier vanaf het begin op te ontwerpen.
Groetjes,