Kod som skrivs av agenter granskas ändå

Hurukan byggs till stor del av agenter. De skriver kod, genererar tester, kör testsviten, integrerar och öppnar ändringen för release. Det krymper avståndet mellan att ett problem upptäcks och att det är åtgärdat i en driftsatt installation från veckor till timmar, och det är en verklig fördel.

Det är också det påstående i branschen som lättast blåses upp, så det är värt att skriva ner var automatiseringen stannar och varför de stoppen inte är tillfälliga.

Det som verkligen är automatiserat

Implementation utifrån en specifikation. Med en tydlig beskrivning av ändringen och den befintliga kodbasen skriver en agent en rimlig implementation snabbare än en människa, och den tröttnar inte på de tråkiga delarna.

Generering av tester. Inklusive de fall som en trött människa hoppar över: den tomma listan, dubbletten, tidszonen, den samtidiga skrivningen.

Integration och byggkedjan. Att bygga, köra testsviten, kontrollera typer, lösa de rutinmässiga konflikterna – och göra det löpande i stället för i omgångar.

Det tråkiga underhållet. Uppdateringar av beroenden, migreringar bort från utfasade funktioner, enhetlighet mellan liknande kodvägar. Verkligt arbete, historiskt uppskjutet, och av det slag som i tysthet bryter ner ett system.

Det som inte är det

Beslutet om vad som ska byggas. En specifikation är ett omdöme om en verksamhet, inte en programmeringsuppgift. Agenterna vet inte vilken av fem defekter som spelar roll för företaget som kör det här nästa tisdag.

Arkitektur med långa konsekvenser. De val du lever med i flera år – var en gräns går, vad datamodellen fastslår, vad som medvetet görs omöjligt. Billiga att göra fel snabbt och dyra att ha gjort fel.

Granskning. Varje genererad ändring går igenom granskning och samma kontrollpunkter som alla andra. Hastighetsfördelen kommer från snabbare kontrollpunkter, inte färre, och den som erbjuder det senare beskriver ett system som kommer att släppa något det inte borde ha släppt.

Beslutet om release. En människa bestämmer vad som når ett företag som körs på det här. Det kommer inte att automatiseras – inte för att det inte går, utan för att ansvaret för en dålig release måste fästa vid någon.

Felet som är värt att sätta namn på

Volym. En agent tar snabbt fram en stor och rimlig ändring, och att granska den ordentligt tar lika lång tid som att granska vad som helst annat. Team som mäter hur snabbt koden genereras men inte hur snabbt den granskas samlar på sig otillräckligt granskad kod i en takt som ingen mänsklig process kan ta emot, och skulden kommer på en gång.

Försvaret är att genererade ändringar måste vara små, att testerna måste vara verkligt oberoende av implementationen och att granskningskapaciteten måste vara den begränsning som allt dimensioneras efter. Om granskningen är flaskhalsen fungerar systemet som det ska.

Varför säga det så rakt

För att en autonom mjukvarufabrik låter som ett påstående om att man inte behöver utvecklare, och det är det inte. Det är ett påstående om tiden mellan en defekt och dess rättelse, vilket är något en kund kan mäta.

Det är den versionen vi vill bli hållna till, och det är ett mindre påstående än orden lockar till. För ett företag som ombeds driva sin verksamhet på den här programvaran är ett mindre påstående som håller vid granskning värt mer än ett större som inte gör det.