Flaskhalsteorin om en annalkande programvarusingularitet

I åratal begränsades programvaruutveckling av en dominerande flaskhals: att skriva kod. Allt annat ordnade sig kring den begränsningen, för det var dit timmarna gick. I takt med att AI-systemen blir bättre håller den flaskhalsen på att försvinna.

Den intressanta frågan är därför inte längre om AI kan skriva kod. Den är vad som blir nästa flaskhals, och den därpå.

Om varje flaskhals till slut går att automatisera eller krympa upphör programvaruproduktion att vara en verksamhet med fast kapacitet och blir ett system som förbättrar sig självt. Det är vad jag menar med en annalkande programvarusingularitet. Inte den tekniska singulariteten, och inget påstående om maskinmedvetande — bara den punkt där programvaruproduktionen börjar accelerera sig själv.

Två saker med den loopen betyder mer än storleken på något enskilt hopp. Varje platå kom snabbare än den förra, och varje platå blev det nya normala i stället för en tillfällig skjuts.

Det vi kunde se utifrån var fler levererade funktioner, betydligt färre defekter, mycket kortare iterationscykler och drastiskt mindre frustration.

Den sista är inte ett humör. Frustration är där kognitiv friktion visar sig i en människa, och ett skarpt fall betyder oftast att systemet slutade be människor hålla saker det borde ha hållit själv.

Här är den starkaste invändningen, och den är bra. En produktivitetsspik är inte bevis för exponentiell tillväxt. Den kan lika gärna vara ackumulerad friktion som äntligen försvinner — år av teknisk skuld, dåliga verktyg och manuella steg som rensas bort på en gång. Att ta bort skuld ger sken av acceleration utan att ändra långtidskurvan alls.

Den kritiken är giltig, och det är den jag återvänder till. Den innebär att den ärliga frågan inte är hur mycket snabbare det gick. Den är vilken av två saker som hände: tar jag bort friktion, eller ökar jag hävstången?

Plattformen passerade en arkitektonisk tröskel, och skillnaden är inte att AI:n blev bättre. Det är att AI:n slutade skriva godtycklig kod.

Agenterna här uppfinner inga implementationer. De monterar system av formella komponenter som redan finns, redan har typer, redan har tester och redan bär reglerna plattformen upprätthåller. När något genuint nytt behövs är att producera det en egen styrd handling, inte något som råkar ske mitt i en funktion.

Det ändrar vad som skalas. I stället för att skala kodgenerering skalar plattformen komposition.

Det finns en neutral representation mitt i processen, och det är den som gör jobbet. Utforskningen producerar en ritning. Ritningen driver agentorkestreringen. Agenterna monterar formella komponenter. Komponenterna kör som ett system.

Ritningen bär avsikt, inte implementation. Den säger vad som ska finnas och vad det måste göra, i termer en kund kan bråka om. Allt nedströms den är översättning, och översättning är den del som går att automatisera utan att någon tappar kontrollen över utfallet.

Implementationen förblir begränsad av byggblock plattformen redan validerat. En agent kan inte uppfinna en ny arkitektur mitt i ett tisdagsönskemål, för det finns inget att uppfinna med.

Traditionell kodgenerering producerar entropi, och den gör det tyst. Olika utvecklare löser identiska problem olika. Olika agentkörningar löser identiska problem olika, vilket är värre, för de är fler och de är snabbare. Systemet fragmenteras lite för varje leverans tills ingen kan säga hur något fungerar.

I en komponentarkitektur kan det inte hända av misstag. Agenter monterar validerade delar, så varje genererat system ärver samma arkitektur som det förra. Komplexiteten försvinner inte — den flyttar ut ur implementationen och in i komponentdesignen, där det finns långt mindre av den och där den är någons faktiska jobb.

När implementationen väl är automatiserad blir komponentskapandet den uppenbara begränsningen. Det är den ärliga följden av föregående avsnitt: komplexiteten flyttade, den försvann inte.

Komponentproduktion går också att industrialisera, och processen är föga uppseendeväckande — en formell specifikation, en styrd AI-implementation, automatisk verifiering, automatiska tester, en arkitekturgranskning, sedan publicering i biblioteket. Varje steg utom granskningen är redan maskinarbete.

Det som ändras är vad de seniora gör med sin dag. De slutar skriva varje funktion och börjar styra arkitekturen: avgöra vad en komponent får vara, och avvisa dem som inte borde finnas.

Standardkritiken mot varje komponentbibliotek är att det kollapsar under sin egen vikt. Dubbletter dyker upp. Små varianter samlas. Två saker gör nästan samma jobb, ingen kan säga vilken man ska ta, och biblioteket blir ett museum med sökruta.

Den risken är verklig och jag har sett den slå till i kodbaser med långt färre rörliga delar än den här. Vadet är att styrningen kan vara fortlöpande i stället för tillfällig: agenter som inspekterar biblioteket efter dubbletter, överlappande ansvar, förlegade komponenter och arkitektoniska inkonsekvenser, på schema snarare än i ett städprojekt.

Ett städprojekt konkurrerar med funktionsarbete om uppmärksamhet, vilket är därför det alltid förlorar. Fortlöpande styrning konkurrerar med ingenting. Antingen körs den, eller så är påståendet i det här avsnittet fel.

Samma skifte gäller refaktorering, som brukade vara det dyraste underhåll vi hade. Agenter gör det nu: horisontella svep över ett mönster, vertikalt arbete ner genom en stack, beroenderensning, konsekvenspass.

Varje ändring utlöser samma cykel — automatisk verifiering, e2e-tester, automatisk lagning när de faller, omdriftsättning, ännu ett verifieringspass. Refaktorering slutar vara ett initiativ någon måste argumentera för och blir en del av produktionssystemet.

Det håller precis så länge verifieringen verkligen är automatisk. Ändra tusen anropsställen med inget annat än en testsvit mellan dig och produktion, och testsviten är nu det hela angreppssättet vilar på.

Driv det tillräckligt långt och implementationen slutar vara det svåra. Att förstå vad som borde byggas tar dess plats, och det svarar inte på samma behandling.

Kunder vet sällan exakt vad de vill ha. Deras idéer ändras i samma stund de ser fungerande programvara, vilket är den korrekta reaktionen på att se fungerande programvara och inte ett fel hos kunden.

Utforskningen kan därför inte vara en fas som avslutas innan bygget börjar. Den blir en loop: utforskning, ritning, genererat system, kundens synpunkter, uppdaterad ritning, uppdaterat system. Den loopen är bara värd att köra för att iterationen blev nästan gratis — när en ändring kostar en förmiddag i stället för en sprint är att visa någon fel sak ett billigt sätt att få veta vad rätt sak var.

Det finns en svårare version av det här som tog mig längre att se. Det svåra är inte att dra ut krav ur en kund som redan vet vad de vill ha. Väldigt ofta finns avsikten inte ännu.

Den produceras av samtalet. Någon beskriver sin verksamhet, ser en följd de inte tänkt på, ändrar sig, och nu finns en avsikt som inte fanns i någons huvud tjugo minuter tidigare.

AI kan underlätta det samtalet, och den är redan bra på det. Den kan inte ta bort det. Så länge människor avgör vad som ska finnas förblir utforskningen människocentrerad.

Den självklara invändningen är att en process som kräver människor inte är skalbar. Den invändningen är fel, och det är värt att vara exakt om varför.

SaaS kräver också människor. Varje kund klickar på knappar, konfigurerar saker, fattar beslut och ställer supportfrågor. Ingen tittar på det och drar slutsatsen att SaaS inte kan skala. Att det finns mänsklig interaktion är inte det begränsande.

Måttet som avgör är leverantörens arbete per levererat utfall. Om utforskningsarbetet håller sig ungefär konstant per kund medan implementationskostnaden går mot noll fortsätter ekonomin att förbättras hur många människor som än är med i samtalet.

Påståendet att det inte finns någon gräns här är inget bevis. Det är en intuition, och intuitioner om exponentiella kurvor har ett föga imponerande facit. Den användbara frågan är vad som skulle falsifiera det.

Så det här är listan jag faktiskt bevakar. Om något av det visar sig stämma är argumentet i den här artikeln fel, och jag tar hellre reda på det tidigt än försvarar det.

Inget av det är exotiska felmoder. De flesta av dem skulle först visa sig som något litet och lätt att förklara bort: en ny komponent mer än väntat, ett styrningspass som inte hittade något för att det letade på fel ställe, en kund vars utforskning tog tre gånger så lång tid som den förra.

Om inget av det inträffar under år av drift och ett växande antal kunder bör förtroendet för arkitekturen gå upp. Inte innan.

Singularitet är ett dramatiskt ord och det antyder oändlig acceleration, vilket antagligen inte är det som sker. Den mer precisa beskrivningen är ett självaccelererande produktionssystem för programvara: ett som fortsätter ta bort sina egna flaskhalsar, där varje förbättring höjer takten nästa förbättring kan göras i.

Accelerationen kommer ur hävstång snarare än ur ansträngning. De två skiljer man åt genom att fråga vad som händer när man slutar trycka på.

Varje moget produktionssystem har en flaskhals. Att förbättra systemet betyder att flytta flaskhalsen någon annanstans. Inget av det är nytt — det är så tillverkning har fungerat i ett sekel.

Det som är nytt är att själva flyttandet av flaskhalsen håller på att automatiseras. När det väl sker växer förbättringen på sig i stället för att komma i projekt.

Inte att programvaran skriver sig själv. Inte att AI ersätter ingenjörer. Ingenjörskonst blir att konstruera system som förbättrar sig själva, och det är ett annat jobb än att skriva kod snabbare.