Jag driver ett bolag som heter lights-out, och vi använder begreppet om affärsprocesser, inte om kod. I en släckt process, som att matcha leverantörsfakturor eller hantera returer, kör agenter utan att någon tittar på varje steg, eftersom varje resultat kan kontrolleras när det sker. En släckt mjukvarufabrik är något annat: agenter skriver koden och ingen läser den. Så när någon står på en scen och förklarar varför de fabrikerna misslyckas, då lyssnar jag.
Föredraget heter Why Software Factories Fail och hölls av Dex Horthy från HumanLayer på AI Engineer. Det publicerades på AI Engineers YouTube-kanal den 23 juli 2026. Det är ungefär nitton minuter och väl värt tiden. Här är vad jag tar med mig, och vad jag tror att det betyder för den som bestämmer hur AI används i en organisation.
Löftet alla hör
Berättelsen går ungefär så här. Modellerna är bra nog. Kod är gratis. Människan är flaskhalsen, så ta bort henne. Låt agenter bygga, låt agenter granska, skicka incidenter och kundsynpunkter rakt in i kön och sluta läsa koden. Lägg pengarna på tester, övervakning och utrullning i stället.
Horthy provade. I juli 2025 släckte hans team lamporna helt (8:18 i videon). Några månader senare stötte de på ett fel som ingen agent kunde lösa. Sajten låg nere, användarna var arga och teamet fick gräva i en kodbas som de hade slutat läsa tre månader tidigare.
Han är inte ensam. Han hänvisar till en rapport från Faros AI, The AI Engineering Report 2026, publicerad i april 2026. Den omfattar 22 000 utvecklare i över 4 000 team. När team gick från låg till hög användning av AI ökade antalet ändringar som slogs ihop helt utan granskning med 31,3 %, buggarna per utvecklare med 54 % och incidenterna per ändring med 242,7 %. Det är samband i mätdata, inte bevis på orsak.
Det handlar inte om att ni gör fel
Det vanliga svaret är att ni använder verktygen fel. Skriv bättre promptar. Lägg till ännu en granskningsbot. Spendera fler tokens.
Horthys poäng är skarpare, och jag tror att den stämmer. Med hans ord: "no amount of harness engineering or loops maxing can solve what is fundamentally a model training issue" (2:53). Ingen mängd verktygsbygge runt modellen löser det som i grunden är ett problem i hur modellen tränas.
Så här fungerar det, förenklat. Kodmodeller tränas genom att belönas när de löser en uppgift: det nya testet går igenom och de gamla testerna fungerar fortfarande. Ett eller noll. Ingenting i den belöningen straffar en design som gör nästa ändring svårare. Horthy säger det rakt ut: "there's no way in this system that we can penalize it for poor program design or for eroding the maintainability of our systems" (12:52).
Modellen lär sig alltså att få testet grönt. En felhantering där ingen behövs. En typomvandling som får felet att försvinna. Varje ändring fungerar. Kodbasen blir lite sämre för varje gång.
Att det är svårt att rätta handlar om tid. "The cost function of bad architecture is measured in months and years" (13:23). Kostnaden för dålig arkitektur mäts i månader och år, och en träningskörning kan inte vänta ett halvår på att få veta om en ändring var klok.
Att låta en annan modell döma kvaliteten räcker bara en bit. Hans formulering: "if the model knew what good code looks like, it would probably write it in the first place" (14:35). Visste modellen hur bra kod ser ut skulle den ha skrivit den från början.
Varför släckt fungerar för vissa saker och inte för andra
Här skärpte föredraget mitt eget tänkande.
När jag pratar om lights out för affärsprocesser menar jag saker som att matcha leverantörsfakturor, hantera returer eller uppdatera produktdata. I de flödena kan varje transaktion kontrolleras när den sker. Fakturan stämmer mot ordern eller så gör den inte det. Kvaliteten syns i dag.
Kod är annorlunda. En ändring kan klara alla tester i dag och ändå göra systemet svårare att ändra nästa kvartal. Kostnaden för ett misstag dyker upp månader senare, långt från ändringen som orsakade den.
Det ger en enkel fråga att ställa om varje AI-satsning: när syns kostnaden för ett misstag?
- Syns den direkt och går att kontrollera automatiskt, då kan agenterna köra med släckt ljus.
- Syns den först efter flera månader, då måste en människa äga bedömningen. Inte varje tangenttryckning, men designen och den slutliga granskningen.
Flytta människan, ta inte bort henne
Horthy argumenterar inte för att gå tillbaka till hur det var. Han vill flytta människans arbete tidigare. Kom överens om problemet. Kom överens om arkitekturen. Gör sedan något han menar att alla underskattar: programdesign, alltså typerna, funktionernas signaturer och hur delarna anropar varandra. Bygg sedan i tunna skivor som går att kontrollera längs vägen.
Hans tes: "30 minutes over here in pre-planning and alignment can save you hours in review" (16:50). En halvtimme planering sparar timmar av granskning. Och när granskningarna växer över huvudet: "If you're drowning in PRs, you actually have too many bad PRs" (17:06). Drunknar ni i ändringar att granska har ni för många dåliga ändringar, inte för många.
Det stämmer med vad jag ser i de agentteam jag arbetar med. Fristående AI-granskare hittar mycket och höjer lägstanivån. De hittar inte ett designbeslut som kommer att göra ont om sex månader. Det arbete som gör störst skillnad sker innan första raden skrivs, när en människa bestämmer hur ändringen ska se ut och hur stor den får vara.
Det hänger också ihop med det jag skrev om att flaskhalsen har flyttat. Att bygga är inte längre det dyra. Att besluta och granska är det. Svaret är inte att stryka granskningen. Det är att göra varje granskning liten och förväntad.
Vad jag skulle fråga som beslutsfattare
- Vem äger koden? Inte vem som skrev den. Vem som kan förklara den och ändra den klockan tre på natten. Är svaret "agenten" har ni en risk i balansräkningen.
- Vad mäter vi? "Andel kod skriven av AI" säger ingenting om kvalitet. Följ incidenter, granskningstid och hur lång tid en vanlig ändring tar, över kvartal och inte veckor.
- Vart går människornas tid? Går all tid till att granska stora ändringar i slutet, flytta den framåt till planering och design.
- Vilka processer kan verkligen köra i mörker? Sortera dem efter när kostnaden för ett misstag syns. Börja släcka där den syns i dag.
Horthy avslutar med något jag håller med om. Det här är begränsningar, inte en dom. Modellerna är mycket bra på vissa saker och fortfarande svaga på andra. Jobbet är att designa runt det, inte låtsas att det inte finns. Med bra planering går det fortare, som han säger, "but you're still reading everything and you're still owning the code" (17:46). Ni läser fortfarande allt, och ni äger fortfarande koden.
*Källa: Dex Horthy, HumanLayer, "Why Software Factories Fail", AI Engineer, youtu.be/Ib5GBkD555M. Citaten kommer från videons automatiska engelska textning, och tiderna avser videon.*
Vill ni se hur det fungerar i praktiken? Läs Det en kodfabrik väntar på på emberloom.ai, eller boka en introduktion.