Opbouwen van een AI-native engineering-organisatie

In bredere zin denk ik al een tijdje na over hoe je een AI-native engineering-organisatie opbouwt. Hieronder deel ik enkele lessen uit de afgelopen negen maanden bouwen bij FurtherAI.

Deel 1: Wat er is veranderd in hoe we software leveren

De hoeveelheid werk per engineer

Sinds januari is het aantal code-wijzigingen dat elke engineer per dag merget met ongeveer 5x toegenomen, terwijl ons revert-percentage onder de halve procent is gebleven.

Het simpelweg geven van coding agents aan engineers was echter niet voldoende. Elke keer als we één stap versnelden, hoopte het werk zich op bij de volgende stap. Daarom zijn we het gehele proces van het leveren van software stap voor stap doorgegaan om te bepalen wat we konden optimaliseren.

Het herontwerpen van het leveringsproces

• Code (maart): Agents schrijven de code en engineers sturen hen aan. Hoewel we geen exact startpunt hebben omdat de tools in het begin slechts incidenteel werden gebruikt, kunnen we nu stellen dat dit voor bijna 100% van de code gebeurt.
• Tests (april): Agents schrijven tests gelijktijdig met de code. Inmiddels bevatten 91% van de wijzigingen tests, tegenover 15% voorheen.
• Review (mei): AI reviewt nu 99% van de wijzigingen voordat een mens dat doet (voorheen 60%). Menselijke reviewers kunnen zich hierdoor concentreren op de onderdelen waar menselijk oordeel nodig is.
• CI (juni): We hebben tests geparallelliseerd en voeren alleen die tests uit die beïnvloed worden door een wijziging. De CI voert nu 20x zoveel tests uit in dezelfde tijd van 17 minuten.
• Bugrapportages (juli): We zijn begonnen met het gebruik van ClaudeTag (@claudeai) om ons proces voor bug-intake te automatiseren. Iedereen kan een bug melden in Slack; ClaudeTag herkent duplicaten, maakt een ticket aan en wijst dit toe aan de juiste persoon. Inmiddels wordt 60% van de bugtickets op deze manier aangemaakt.
• Regels (augustus): Wanneer een bug of een review-opmerking een regel blootlegde die alleen bekend was bij engineers, hebben we dit omgezet in een kleine Python-check. Deze check draait bij elke commit en elke PR; hij laat de build falen en print de oplossing. Zo zetten we impliciete kennis (tribal knowledge) om in harde regels. Agents lopen tegen deze checks aan, passen hun eigen code aan en gaan verder. We zijn gegaan van nul naar 21 regels. Dit is een belangrijke reden waarom risicoarme wijzigingen nu zonder menselijke tussenkomst kunnen worden gemerged.
• Merging (augustus): Risicoarme wijzigingen die de tests, geautomatiseerde checks en de AI-review passeren, worden automatisch gemerged. Tot een derde van onze wijzigingen wordt nu zonder menselijke tussenkomst doorgevoerd.
• Code-kanalen (september): Iedereen kan een Slack-kanaal openen, een wijziging beschrijven aan een agent en deze agent een PR laten openen. Dit is zeer effectief gebleken voor samenwerking: meerdere mensen kunnen in één kanaal met dezelfde agent werken, context toevoegen en de agent aansturen. Daarnaast maken we veel gebruik van de cloud-sessies van Devin (@cognition) om als team samen te werken.

Daarnaast gebruiken we onze eigen interne Poirot- en Sherlock-agents om problemen in productie en staging te onderzoeken en op te lossen. Zij beschikken over alle nodige tools en context via logs, metrics, traces en read-only database-toegang.

De meest interessante momenten zijn wanneer agents samenwerken: ClaudeTag triageert een verzoek, Devin voert het werk uit en Poirot haalt de benodigde interne data op. Het is fascinerend om te zien hoe ze met elkaar communiceren en informatie uitwisselen.

Een interessant neveneffect is dat ook niet-engineers code zijn gaan leveren. Onze designer heeft sinds augustus ongeveer 50 wijzigingen gemerged, waaronder die voor ons design-systeem. Mensen in deployment- en klantgerichte rollen kunnen nu ook zelf UI-aanpassingen doen, direct vanuit Slack.

De kosten van deze transitie

Dit was niet gratis. Gedurende de zomer ging een groot deel van onze engineering-inspanning naar tests en tooling. Hierdoor bleef het aantal klantgerichte wijzigingen per engineer schommelen tussen de 17 en 30 per maand.

In september sprong dat naar 45. Voor oktober liggen we op schema voor 48.

Deel 2: Wat er verandert in het team

Naarmate het engineering-proces versnelde, merkten we een ander probleem op.

De nieuwe bottleneck

We werden veel sneller in het schrijven van code, maar niet in dezelfde mate in het beslissen wat we moesten bouwen.

Een vereenvoudigd voorbeeld: Stel dat een feature voorheen tien dagen in beslag nam: drie dagen plannen, zes dagen bouwen en één dag reviewen. Als agents het bouwen 3,5x versnellen, maar het plannen en de review hetzelfde blijven, wordt de totale feature slechts 1,75x sneller. Plannen en review beslaan nu 70% van de tijd, tegenover 40% voorheen.

Traditioneel lopen veel van deze beslissingen via engineering managers, PM's en designers. Dat wordt steeds moeilijker naarmate engineers sneller kunnen bouwen. De vraag is: hoe organiseer je een team waar engineers veel sneller kunnen bouwen, zonder dat er bottlenecks ontstaan rondom beslissingen en reviews?

Onze gok is om meer eigenaarschap bij de engineers te leggen. In plaats van meer managementlagen toe te voegen, willen we dat engineers zelf meer van de planning, uitvoering en review afhandelen. Dit verandert de verwachtingen van zowel engineers als managers.

Wat dit betekent voor engineers

Ik begin senioriteit binnen engineering te definiëren op basis van hoeveel van een probleem iemand van begin tot eind kan eigenaar zijn. Ruwweg:

• Junior engineer: Bouwt met een agent en kan herkennen wanneer de agent ernaast zit.
• Senior engineer: Plant en reviewt het eigen werk.
• Staff engineer: Neemt een vaag probleem, maakt de nodige afwegingen en is verantwoordelijk voor de cijfers die bepalen of het succesvol was.

Dit betekent ook dat engineers dichter bij de klanten moeten staan. We stellen engineers in staat om meer van het proces end-to-end te beheren: van het begrijpen van het klantprobleem en het leveren van een oplossing, tot het verifiëren van het succes en het eigenaarschap over regressies in productie.

Wat dit betekent voor managers

Dit verandert ook de verwachtingen van engineering managers:

1. Actief betrokken zijn bij het werk.

Managers moeten begrijpen wat er wordt gebouwd, waarom, en of het de juiste oplossing is. Ik wil dat managers features op staging testen alsof ze een eindgebruiker zijn, in plaats van alleen te controleren of de code is gereviewd. Je ontdekt een andere klasse problemen wanneer je het product daadwerkelijk gebruikt. Het doel is echter niet om alleen maar meer te reviewen, maar om engineers te ontwikkelen die zelf de juiste beslissingen kunnen nemen, zodat managers alleen ingrijpen bij zaken die hun specifieke oordeel vereisen.

1. Product-savvy worden.

Wanneer het schrijven van code goedkoper wordt, is de beslissing wat er gebouwd wordt veel belangrijker. Ik zoek engineering managers die de klanten begrijpen, sterke productmeningen hebben en zich comfortabel voelen bij het nemen van productbeslissingen, niet alleen technische beslissingen. Ze moeten engineers ook helpen dit oordeel te ontwikkelen, zodat we niet voor elke kleine productbeslissing een PM of designer nodig hebben.

Conclusie

We hebben een groot deel van dit jaar besteed aan het uitzoeken hoe we engineers sneller kunnen maken. Nu proberen we uit te vogelen hoe we de gehele organisatie op die snelheid kunnen laten bewegen.

Ik vermoed dat dit een lastiger probleem zal zijn dan het automatiseren van code, tests en reviews. We staan nog aan het begin en er is veel wat we nog niet hebben uitgezocht, maar het is een van de meest interessante engineering-uitdagingen waar ik aan heb gewerkt.