Code van agents gaat toch door review

Hurukan wordt grotendeels door agents gebouwd. Ze schrijven code, genereren tests, draaien de testsuite, integreren en zetten de wijziging klaar voor release. Dat verkort de tijd tussen het opmerken van een probleem en een oplossing in een draaiende omgeving van weken tot uren, en dat is een echt voordeel.

Het is ook de bewering in dit vak die het snelst wordt opgeblazen. Daarom is het de moeite waard om op te schrijven waar de automatisering stopt, en waarom die grenzen niet tijdelijk zijn.

Wat echt geautomatiseerd is

Implementatie op basis van een specificatie. Met een heldere beschrijving van de wijziging en de bestaande codebase schrijft een agent sneller dan een mens een plausibele implementatie, en raakt hij niet verveeld door de saaie delen.

Tests genereren. Inclusief de gevallen die een vermoeide mens overslaat: de lege lijst, het duplicaat, de tijdzone, de gelijktijdige schrijfactie.

Integratie en de pijplijn. Bouwen, de testsuite draaien, types controleren, de routineconflicten oplossen, en dat continu in plaats van in batches.

Het saaie onderhoud. Updates van afhankelijkheden, migraties weg van verouderde functies, consistentie tussen vergelijkbare codepaden. Echt werk, historisch altijd uitgesteld, en precies het soort werk dat een systeem ongemerkt laat verrotten.

Wat niet

Het besluit over wat er gebouwd wordt. Een specificatie is een oordeel over een bedrijf, geen programmeertaak. Agents weten niet welke van vijf defecten volgende dinsdag ertoe doet voor het bedrijf dat hierop draait.

Architectuur met langdurige gevolgen. De keuzes waar u jaren mee leeft: waar een grens ligt, wat het datamodel vastlegt, wat bewust onmogelijk wordt gemaakt. Snel en goedkoop fout te doen, en duur om fout gedaan te hebben.

Review. Elke gegenereerde wijziging gaat door review en door dezelfde poorten als elke andere. Het snelheidsvoordeel komt van snellere poorten, niet van minder poorten, en wie het tweede aanbiedt, beschrijft een systeem dat iets gaat uitleveren wat nooit had mogen worden uitgeleverd.

Het releasebesluit. Een mens beslist wat er terechtkomt bij een bedrijf dat hierop draait. Dat wordt niet geautomatiseerd, niet omdat het niet kan, maar omdat de verantwoordelijkheid voor een slechte release bij iemand moet liggen.

De valkuil die een naam verdient

Volume. Een agent levert snel een grote, plausibele wijziging op, en die grondig reviewen duurt even lang als het reviewen van elke andere wijziging. Teams die de snelheid van genereren meten en niet de snelheid van reviewen, stapelen onvoldoende gereviewde code op in een tempo dat geen menselijk proces kan bijhouden, en de schuld komt in één keer.

De verdediging: gegenereerde wijzigingen moeten klein zijn, tests moeten echt onafhankelijk zijn van de implementatie, en reviewcapaciteit moet de beperking zijn waarop het geheel wordt gedimensioneerd. Als review de bottleneck is, werkt het systeem zoals het hoort.

Waarom we het zo onomwonden zeggen

Omdat een autonome softwarefabriek klinkt als een bewering dat er geen engineers meer nodig zijn, en dat is het niet. Het is een bewering over de tijd tussen een defect en de oplossing ervan, en dat is iets wat een klant kan meten.

Dat is de versie waarop we afgerekend willen worden, en het is een kleinere bewering dan de woorden doen vermoeden. Voor een bedrijf dat wordt gevraagd zijn bedrijfsvoering op deze software te laten draaien, is een kleinere bewering die een kritische blik doorstaat meer waard dan een grotere die dat niet doet.