[Bottleneckförskjutning] När kod är nästan gratis, vart har programvaruengineeringens flaskhalsar tagit vägen? Förändringar inom programvaruengineering i AI-tiden — Lär dig AI gradvis 173
När kod nästan är gratis, flyttas flaskhalsen till krav, integration, verifiering och alignment
När kodproduktion nästan är gratis, flyttas flaskhalsen i programvaruleverans från “att skriva kod” till något annat: att definiera rätt fråga, sammanfoga fragment till ett fungerande heltal, verifiera att det verkligen är rätt, och alignera organisationen. Detta är en återupplivning av Theory of Constraints inom mjukvaruvärlden. Tillverkningsindustrin gick igenom detta för 40 år sedan: varje gång en process blir billigare, försvinner inte flaskhalsen — den flyttar till nästa dyraste steg. När du förstår detta, förklarar du ett vanligt förvirring: AI-verktyg för programmering har införts i hela företaget, kodskrivning är tydligt snabbare, men leveranstiden har inte förändrats nämnvärt.
En CIO från ett tillverkningskoncern visade mig sina data från de senaste sex månaderna. IT-teamet med 80+ personer har fullt ut infört AI-programmeringsverktyg — sett till kodproduktionen har varje medlem ökat sina commit- och merge-hastigheter med mer än 30 %. Men affärssidan uppfattar det helt annorlunda: en liten funktion för intelligent produktionsplanering tog fortfarande minst tre månader från idé till produktion. Han trodde att verktygen skulle ge en dubbling av hastigheten — men han fick bara “snabbare kodskrivning”. Hans ord var direkt: “Jag har lagt miljoner på licenser — och fått utvecklare som är mer upptagna och affärer som är mer pressade.”
Han antog fel var bottlenecket låg. Det verkliga bottlenecket var något annat: varje ny funktion måste passera genom MES, ERP, kvalitetssäkringssystem, verkstadsterminaler och ett set av regleringsrapporteringskrav – integration och samkörning åtog större delen av tiden; och AI-genererad kod har ingen enda formell godkännandedörr mellan sig och produktionsmiljön. Ju snabbare koden skrivs, desto mer står den bara i kö bakom ett felaktigt bottleneck. # 1. Tillverkningsindustrin visste för 40 år sedan: bottlenecket rör sig
För att förstå nuet, låt oss först använda en glasöga som tillverkningsindustrin haft i 40 år.
1984 skrev den israeliska konsulten Eliyahu Goldratt, en fysiker, romanen The Goal, som handlar om hur en fabrikör på randen till bankrutt lyckades rädda sin fabrik. Hela bokens kärna är en enda mening: En systems utbyte bestäms av dess mest inskränkande del (bottlenecket).
Att utvidga icke-bottleneckar hjälper inte totala utbytet; endast att utvidga bottlenecket självt gör hela systemet snabbare. Och så fort du utvidgar bottlenecket, flyttar det till nästa mest inskränkande plats. Detta är Theory of Constraints (TOC).
Efter 40 år med automatisering i tillverkningsindustrin har det nästan varit en historia om “瓶颈flyttning”. När CNC-maskiner gjorde skärning billigare, flyttades flaskhalsen till byten av verktyg och kvalitetskontroll; när flexibla produktionslinjer gjorde byten snabbare, flyttades flaskhalsen till produktionsplanering och samordning i leverantörsnätverket; när MES gjorde planeringen mer exakt, flyttades flaskhalsen till efterfrågeförutsägelse och tvärföretagssamordning. Varje gång en del automatiseras, dyker nästa upp. Automatisering försvinner aldrig flaskhalsar — den flyttar bara dem till ett annat ställe. Den här lagar är inte exklusiv för tillverkningsindustrin. I juli 2026, i a16z-podden “Software in the Age of Agents”, drog Steven Sinofsky, tidigare chef för Windows vid Microsoft, med ett exempel från affärssystem, oberoende och med samma slutsats. Hans ord var: > “The long tail got no shorter. It just got longer in a different way.”
Han nämnde Amazon-kundtjänst: att avveckla telefoner och låta chatbotar automatiskt skicka ut nya varor – det verkar spara arbetskraft, men bakom kulisserna dyker genast upp ett krav på rotorsaksanalys: “Hur förhindrar vi att detta händer igen?” – ett krav som är mer komplext än att svara på samtal. Samma sak gäller för reserevision: efter att OCR automatiskt bokför utgifterna, blir finansens uppgift att optimera resprestationer och göra dynamiska prisjämförelser – arbetet har inte försvunnit, det har flyttats upp från “inmatning” till “analys och beslutsfattning”. En gammal Microsoft-ansluten partner från a16z kom fram till samma slutsats som tillverkningsindustrin gjorde för 40 år sedan – utan att använda Goldratts teori. En kom från verkstaden, den andra från affärssystem – två oberoende vägar som leder till samma lag.
Men för att förhindra att denna lag tolkas som en absolut sanning, behöver den begränsas. Det finns verkligen arbetsuppgifter som försvunnit för alltid: datorer, telefonsamband, bokstavssättare – dessa yrken har inte “flyttats upp”, de har försvunnit. Att avgöra om ett arbete flyttas eller försvinner beror på om den frigjorda kapaciteten från automatisering skapar nya behov (ekonomiskt kallat Jevonsparadoxen), eller bara gör det ursprungliga behovet mindre. De flesta arbetsuppgifter runt företagets kärnsystem tillhör det första: ju snabbare bokföringen blir, desto fler och detaljeradare analyser vill cheferna se. Slutsatsen är därför inte “hur mycket arbete automatisering kan ta bort”, utan “flytta människor och budget från den nivå som automatiserats till den nya nivå som dyker upp”. (Företagsprogramvarans långsvanssflyttning – en utökad version finns i “Företagsprogramvarans klistrighet”.)
Det här har en närmare koppling till mjukvara än du tror. 2013 överförde Gene Kim Goldratts fabrikshistoria nästan ordagrant till IT-drift och skrev The Phoenix Project: hur en CIO räddade en IT-avdelning som hotade att dräga ner hela företaget med hjälp av teorin om restriktioner. Så att “använda tillverkningens flaskhalstanke för att förstå mjukvara” är en redan bekräftad väg – inte en tillfälligt uppfunnen analogi. # 2. Tillbaka till mjukvara: Att skriva kod blir den billigaste delen av processen Tre siffror som tydliggör att “kodproduktionskostnaden närmar sig noll”.
- Copilot: GitHub egna forskning visar att i filer där Copilot är aktiverat, cirka 46 % av koden skapas av Copilot. Observera att detta är andelen inom aktiverade filer, inte 46 % av all kod på GitHub.
- Stripe: Interna, självutvecklade coding-agenter “Minions” levererar och sammanfogar mer än 1 300 PR:er varje vecka (från 1 000 i början, och talet stiger kontinuerligt). En nyckeldetalj att komma ihåg: varje PR måste granskas manuellt innan det sammanfogas. Stripe automatiserade “skrivandet”, men lämnade “godkännandet” till människor. Den här punkten kommer att användas i avsnitt fyra.
- NVIDIA: Jensen Huang har offentligt sagt att 100 % av NVIDIA:s ingenjörer använder AI-programverktyg som Cursor; “att arbeta utan AI” är inte längre acceptabelt vid NVIDIA.
Lägg ihop dessa tre siffror, och slutsatsen är tydlig: Kostnaden per kodrad närmar sig snabbt noll. Den skarpa frågan blir då: Om kodskrivning nästan är gratis, varför är mjukvara fortfarande så dyr, så långsam och så svår att leverera? Svaret kommer från teorin om begränsningar: Du har vidgat processen “kodskrivning”, men flaskhalsen har bara flyttats. Var har den flyttats till?
Tre: Flödesflaskhalsarna har flyttat till fyra ställen
Denna gången koncentrerar flaskhalsarna sig till fyra processer. Varje en av dem är något AI inte kan hantera på kort sikt.
Första: Att definiera rätt fråga. AI kan skriva “den funktion du säger att du vill ha” på några sekunder, men den kan inte skriva “den funktion du verkligen behöver”. De flesta mjukvaruprojekt misslyckas för att det som produceras inte används – problemet har aldrig förståtts på rätt sätt från början. När kodproduktion har blivit billigare har “att omvandla ett vagt affärsproblem till en tydlig, lösbar och värd att lösa specifikation” (problemformulering) blivit den mest sällsynta och dyraste färdigheten. Tillverkningsbranschen känner till detta: Om tillverkningsprocessen och konstruktionsritningarna är fel, så producerar man bara massor av defekta produkter – oavsett hur effektivt arbetsplatsen är.
Andra: Systemintegration. AI är bra på att generera “en kodrad”, “en funktion”, “en sida”. Men ett system som kan gå i produktion är en integration av hundratals sådana delar – de måste kunna utbyta data, hantera gränser, hålla konsistens och hantera undantag. Att generera delar är billigt; att sätta ihop dem till ett pålitligt hela är dyrt. Denna kostnad ligger i organisation och arkitekturutjämning – just det som Conway’s lag och teamtopologier handlar om (se de två föregående artiklarna i denna serie). Åter till den tillverknings-CIO som nämndes i inledningen: Hans tid gick inte till att skriva kod, utan till att integrera MES-, ERP-, kvalitetskontroll- och rapporteringssystemen.
Tredje hindringsgrenen: Verifiering. Kodmängden exploderar, trovärdigheten varierar. Vem bestämmer att “det är rätt”? Testning, kodgranskning, observabilitet, canary releases — dessa “verifierings”-aktiviteter har blivit viktigare, inte mindre. Detta är den mest undervärderade hindringsgrenen och den djupaste spegelbilden av tillverkningsindustrin. Kapitel fyra går igenom detta i detalj.
Fjärde hindringsgrenen: Organisationell alignment. När AI-agenter kommer in i teamet: vem bestämmer vad som ska göras, vem granskar, vem är ansvarig för resultatet? Detta är en förlängning av Conway’s lag och teamtopologier — organisationell alignment själv har blivit en hindringsgren. Artikel 11 i serien kommer att fokusera specifikt på detta: när organisationsnoder inte längre är endast människor, hur blir governance en kärnkompetens?
# Fyra: Den djupaste skärningen: Verifiering, och vad Toyota faktiskt lär oss med "Jidoka"Av de fyra hindringsgrenarna är verifiering den som mest ofta missförstås. Många tror att eftersom AI skriver kod snabbt, så behöver vi bara köra fler testrundor. Det är bara halva sanningen. För att förstå varför verifiering blivit dyrare, måste vi först rättvisa ett mycket spritt missförstånd: Jidoka.
Rätta till ett mycket utbredd feluppfattning: Jidoka är inte “att ersätta människor med AI eller maskiner”, heller inte “att göra människor till maskiner som arbetar utan uppehåll”. Båda dessa riktningar är fel.
Ordet “jämnförd” innehåller själva svaret. I japanska är “automatisering” vanlig automatisering, men Toyota använde specifikt “jämnförd” med tecknet “働” som har människokomponenten – det betonar “automatisering med en människlig touch”. Dess exakta innebörd är: När en maskin eller produktionslinje upptäcker ett avvikelser, stannar den automatiskt för att låta en människa ingripa och lösa rotorsaken innan produktionen återupptas. Den har två parallella mekanismer: maskinen har inbyggd felupptäckning och stannar själv; vem som helst på produktionslinjen som upptäcker något fel kan dra i andon-ligan – och hela linjen stannar omedelbart. Kvalitet kontrolleras inte i slutet, utan integreras i varje steg och löses direkt på plats.
Här finns ett kontraintuitivt resultat som direkt korresponderar med mjukvara: Ju djupare automatiseringen är, desto större blir behovet av kvalitetskontroller och människans ingripande. Jämnförd befriar människor från “upprepade operationer” och placerar dem istället i rollen som “upptäcker avvikelser, stoppar linjen, löser rotorsaken”. Toyota ger produktionens anställda rätten att stoppa hela linjen – just därför att de förstår: hur stark automatisering än är, behövs det någon som kan säga “stopp” när något går fel. Det är den verkliga meningen bakom sloganen “ge robotarna intelligens”: att ge maskiner förmågan att stanna och anropa människor. Människan är alltid närvarande och ansvarar för att lösa rotorsaken.
Programvaran går igenom samma väg – och gör det snabbt. GitClears forskning om AI-stödd kod har observerat tecken på ökade upprepade kodblock och ökad kortvarig churn: AI skriver snabbt, men också “ser ut som det ska”. När en stor mängd kod aldrig har skrivits rad för rad av en människa, faller den traditionella förtroendemekanismen “utvecklaren vet vad som händer” samman. Då behöver du en programvaruversion av Andon-linjen och stoppmechanismen:
- Test (enhets-, integrations-, slut-til-slut) uppgraderas från “gör om du kan” till en hård gräns – utan godkänt test får du inte slå ihop.
- Code review fokuserar nu från “kolla syntax” till “kolla avsikt och gränser”: Vad försöker den här koden lösa? Har alla gränsvillkor täckts?
- Observabilitet (övervakning, loggar, spårning) blir standard, eftersom beteende i produktion säger mer än koden själv.
- Gråpublicering / feature flag låter AI-genererad kod testas i liten skala först – bara när den är bekräftad släpps den ut.
Tillbaka till avsnitt två, Stripes 1 300 PR:ar: Skrivandet sköts av agenterna, men sammanfogningen – den här grinden – lämnades helt till manuell review. Det här är den levande modellen för självkörande system i programvaruutveckling: automatisera produktionen, men håll godkännandet hos människan – och ge den makten att stoppa det. Produktionen blir billigare, kvalitetssäkringen dyrare – det är en regel som inte har förändrats på 40 år.
Fem: Prisvärdet av att “definiera problemet”: En förmåga som är värre än promptar
Om verifiering är en underskattad flaskhals, så är “att definiera problemet” en allvarligt underskattad förmåga. Promptengineering var populärt en tid, och många trodde att “att kunna skriva promptar” var kärnkompetensen. Men promptar är bara en teknik för att “uttrycka ett problem”. Det som verkligen är sällsynt är att gå ett steg längre: problemformulering – att ta ett vagt affärshinder och dela upp det till ett tydligt, lösbart och värt att lösa problem. Det här steget kan AI inte göra på kort sikt, eftersom den måste vänta på att du först berättar för den “vad problemet är”.
Gamla experter inom tillverkningsindustrin förstår bäst betydelsen av detta steg. Om en teknisk ritning eller en produktionsprocess är felaktigt definierad, så blir alla efterföljande bearbetnings- och monteringssteg effektiva men ändå tillverkning av fel. Samma gäller mjukvara: Om kravspecifikationen är fel, så hjälper AI dig att skapa tio gånger snabbare en massa saker som ingen vill ha.
En enkel regel: Sluta konkurrera om hastigheten att skriva kod – träna istället på att dela upp problem med tydlighet. I organisationer betyder detta att “kravdefinition” och “verifiering/acceptans” ska bli formella roller – inte något utvecklare gör “på fritid”. När AI har gjort implementation billigare, så har denna två roller fått den snabbaste avkastningen.
Sex: Hur ser de verkliga flaskhalsarna ut i fyra branscher?
När man applicerar “flaskhalsens förskjutning” på fyra branscher, ligger flaskhalsen inte i kodskrivning.
Tillverkning. Huvudlinjen är den CIO som nämns i inledningen. Funktioner som intelligent produktionsschemaläggning, kvalitetsspårning och energiförbrukningsoptimering är tekniskt inte svåra – många modeller finns redan färdiga. Flaskanackan ligger i integrationen och justeringen av MES/ERP/kvalitetskontroll/rapporteringssystemen samt den praktiska verifieringen på verkstadsterminaler. Koden för sådana projekt skrivs ofta snabbt, men integrationen av MES/ERP-systemen kan ta flera gånger längre tid än kodskrivningen; endast genom att placera godkännandepositionerna direkt vid verkstadsterminalerna och i integreringsprocessen kan fel blockeras på plats – inte först när produktionen startar.
Telekommunikation / operatörer. En enda ändring av ett abonnemang eller upprättande av ett företagskabelnät måste passera flera domäner: kanaler, fakturering, CRM, nätverksupprättande och planering av installation och underhåll. AI har gjort utvecklingen i varje domän snabbare, men den övergripande slut-till-slut-integrationen och konsistensverifieringen mellan domänerna utgör den största delen av tidsåtgången. Operatörer har också en unik flaskanacka: komplettering och bokföring. En skillnad på en öre i faktureringen är en händelse; verifieringens vikt är större än i någon annan bransch. Till exempel vid upprättande av företagskabelnät: även om AI har accelererat utvecklingen i varje domän, tar slut-till-slut-integrationen plus faktureringsbokförning ofta upp hälften eller mer av hela projektets tid.
Finans. En justering av ett kreditriskstyrnings- eller anti-pengavaskningsregel genomlöper App, kärnsystem, riskstyrningsmotor, dataplattform och regelrapportering. Här är valideringsviktigheten extremt hög, eftersom ett enda fel kan bli en compliance-händelse. Fläckan ligger i förklarbarhet, granskbarhet och återföljbarhet: Även om AI:s regler är exakta, kommer de inte att godkännas om de inte kan svara på regelverkets fråga: “Varför detta beslut?” Återförsäljningsregelutveckling är ett typiskt exempel: AI har accelererat skapandet av regler, men granskning av modellens förklarbarhet och alignment med regelrapportering tar ofta upp hälften eller mer av hela cykeln.
E-handel. En kampanj- eller stordagfunktion genomlöper produkt, transaktion, marknadsföring, lager och kundservice. AI gör det möjligt att skriva sidor och API:er snabbt, men fläckan har flyttats till lasttestning, lagerkonsistens, riskhantering mot utnyttjande av erbjudanden och bokföring. De system som kraschar under stordagar är aldrig de som skrevs långsamt — utan de som inte testats i gränssituationer. Förberedelsen för en stordag är en miniatyrmodell: AI kan generera kampanjsidan snabbt, men slut-till-slut-lasttestning och verifiering av lagerkonsistens tar ofta upp de flesta av de tillgängliga arbetstimmarna.
Fyra branschernas gemensamma egenskap är tydlig: AI accelererar “skrivandet”, men blockeringen ligger i “sammansättning, validering och alignment”. Att rikta de frigjorda utvecklingsresurserna mot dessa tre sakerna är det verkliga sättet att öka effektiviteten.
Sju: Vad händer om man gör fel? Tre vanligaste missförståenden
Första: Att betrakta “skriva kod snabbt” som “leverans blir snabbare”.
Detta är den vanligaste illusiónen. Kod är bara en del i leveranskedjan; att bredda den gör inte hela kedjan snabbare – det gör bara mer halvfabrikat som samlas bakom flaskhalsen. Teorin om begränsningar kallar detta för lager, i mjukvara kallar vi det för PR:ar som inte godkänts eller grenar som inte har integrerats. Resultatet blir att utvecklare blir mer upptagna, affärerna mer pressade, och produktionen förblir oförändrad – precis som CIO:n i inledningen.
Andra: Att öka produktionshastigheten samtidigt som man tar bort kvalitetskontroller.
Detta är ett typiskt fel mot jidoka. Vissa tror att “AI skriver snabbt och bra, så kodgranskning kan förenklas och tester kan tas bort”. Tvärtom: ju snabbare produktionen blir, desto viktigare är det att hålla fast vid anläggningssträngen. Att ta bort godkännandekontroller är som att låta en produktionslinje köra i full hastighet utan någon närvarande – fel kommer att flöda snabbare mot produktionsmiljön.
Tredje: Att investera i icke-flaskhalsar.
Integration är flaskhalsen, men du köper fler AI-programmeringslicenser; verifiering är flaskhalsen, men du anställer fler utvecklare. Teorin om begränsningar har redan förklarat detta: att lägga till resurser på icke-flaskhalsar ger noll bidrag till total produktion – det gör bara bokföringen värre. Rätt ordning är att först identifiera flaskhalsen, sedan fokusera alla resurser på den.
Åtta: Implikationer för beslutsfattare
Insight 1: Innan du köper verktyg, rita en flödesbottleneckkarta.
Ta isär dina tre senaste blockerade leveranser och fråga: Var gick tiden verkligen? Var det svårt att skriva kod, koppla ihop delar, hitta någon att verifiera, eller var kraven oklara? Om du inte kan markera det, gissar du bara på teknisk nivå. En bottleneckkarta är värdefullare än någon verktygsköpslista – den kan förhindra minst hälften av de ineffektiva IT-investeringarna i stora företag.
Insight 2: Investera den frigjorda kapaciteten i krav och verifiering.
AI gör utveckling snabbare – vilket innebär att du har resurser att frigöra. Lägg dessa personer officiellt i rollerna “Kravdefinition” och “Verifiering & Acceptans”, och låt dem inte fortsätta skriva mer kod. Dessa roller har den snabbaste tillväxten i ROI i AI-tiden.
Insight 3: Installera en andon-tråd i din programvara.
Den mest direkta implementationen av jidoka är att sätta hårdgränser i din CI/CD: Inget merge innan testerna går igenom, review måste kontrollera avsikt och gränser, gråskalning börjar med liten volym, och observabilitet blir standard. Ju mer automatiserad produktionen är, desto viktigare är denna grind. Det är hur du förhindrar att “kod är gratis” blir “incidenter är gratis”.
Insight 4: Placera om människor – inte ta bort dem.
Jidoka leder till ett och samma resultat: Ju djupare automatiseringen är, desto viktigare blir människans roll i “bedömning, acceptans och rotorsaksanalys”. Frigör människor från repetitiva uppgifter och omdistribuera dem till verifiering och alignment – detta är kärnan i organisationsdesign i AI-tiden, och det är vad de kommande artiklarna i denna serie kommer att utforska.
9. Du kanske undrar
“Vi är bara en pilot för AI – behöver vi verkligen kartlägga hela företagets flaskhalsar?”
Även piloter måste börja med att förstå: Är den här processen verkligen flaskhalsen? Om flaskhalsen ligger i integration eller validering, så är det en felaktig investering att pilotera AI i “kodskrivning” – det är exakt den tredje missmatchningen som beskrivs i kapitel sju. Gör först en liten flaskhalsdiagnos – då blir pengarna till verktyg väl spenderade.
“Kommer valideringsstegen att försena leveransen?”
Kortfristigt finns det friktion, men på lång sikt blir det snabbare. Den “snabbheten” utan valideringssteg är snabbhet som skickar fel till produktion – återarbetetskostnaden börjar på tio gånger. Erfarenheten från självkörning är: Att lösa ett fel där det uppstår kostar en bråkdel av att lösa det i nästa fas.
“Hur hänger detta ihop med vår AI-transformering?”
Sambandet är direkt. Den vanligaste fällan vid AI-transformering är att anta att flaskhalsen ligger i “kodskrivning / kapacitet”, och sedan köpa massor av verktyg för att utvidga just den delen. Gör först en flaskhalsdiagnos, sedan bestäm var pengarna ska gå. Därför placerar jag “kapacitetsbedömning” och “identifiering av värdescenarier” i början av ramverket “7-stegscoach för AI-transformering”: Först se var flaskhalsen är, sedan prata om verktyg.
Omvänd självkontroll (svara utan att sköna upp): Var har din senaste hängande leverans verkligen tagit tid – i att skriva kod, eller i att sätta ihop, granska och justera? Hur mycket av den kod som dina AI-verktyg producerar är verkligen stabilt på produktion och används av användare? Finns det i din CI/CD en hård gräns som säger “inte sammanfoga om testerna misslyckas”? Om du känner dig osäker på någon av dessa tre frågor, så vänta med att köpa fler AI-verktyg – först hitta din flaskhals.
Nästa steg
Detta är den tredje av 15 artiklar i serien “Software Engineering förändringar i AI-tiden”. Från Conway (organisationen bestämmer arkitekturen) till teamtopologier (hur man designar organisationen), har vi kommit till瓶颈förskjutning (när kod nästan är gratis, vart flyttar flaskhalsen?). Nästa artikel (nummer 4) byter till ett mer praktiskt perspektiv: hur man väljer mellan de vanligaste AI-programmeringsverktygen. Men slutsatsen kan vara motintuitiv: val av verktyg är i grunden en organisationell beslut – välj efter din mognad och styrningsnivå, inte efter “vilket verktyg skriver mest imponerande kod”.
Om serien: Denna serie följer kontinuerligt den senaste utvecklingen inom AI-programmeringsverktyg, organisationsarkitektur och programvaruengineering-paradigm, såsom Conways lag i AI-agenternas tid (2026), och mognaden i den senaste verktygsekosystemet. Följ serien för kontinuerliga insikter.
Om serien
“AI-tidens förändringar inom programvaruteknik” är en djupgående forskningsserie med 15 artiklar rikad till CIO:er, CDO:er och CTO:er samt ansvariga för digitalisering inom telekommunikation, finans, tillverkning och e-handel. Serien bygger på 200+ akademiska artiklar och branschrapporter och tillhandahåller beslutsstöd med tydlig evidensnivåmarkering.
Jag är tidigare IBM-engineer och ICF-certifierad coach som har genomfört AI- och digitaliseringsprojekt hos teleoperatörer och stora företag. Allt som skrivs här är praktiska bedömningar baserade på att ha gått igenom problem tillsammans med företag.
Källor (alla verifierade)
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven Sinofsky, tidigare chef för Microsoft Windows, med citat: “The long tail got no shorter, it just got longer in a different way” — en självständig bekräftelse av TOC:s bottlenecks förskjutning ur ett enterprise-software-perspektiv; primärkälla — podcastens ursprungliga ljud. Ställning markerad: a16z-partner / tidigare Microsoft-ledare, VC-perspektiv. Gäster verifierade: a16z Enterprise-teamets partner Seema Amble, tidigare Microsoft Windows-chef Steven Sinofsky (board partner), och a16z-skrivare Elena Burger; sändes juli 2026.)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Ursprungsreferens för TOC; en roman med tillverkningsfabrik som scen; primärkälla.)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Överförde Goldratts TOC direkt till IT-operations, en bro från tillverkning till mjukvara; primärkälla.)
Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = automation med karaktären “människa”; avbrott vid avvikelser + människor som löser rotorsaker; Andon-system; primärkälla.)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot aktiverar ca 46 % av kod i filen; definition: “enabled in-file”; primärkälla.)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ rapporterar >1 300 PR/vecka med fullständig manuell granskning (primär + sekundärkälla)
NVIDIA / Jensen Huang. Offentliga uttalanden att 100 % av ingenjörerna använder AI-verktyg som Cursor (direkta citat)
GitClear (2025). AI-Assisted Code Quality Research. (Observerar ökning i upprepade kodblock och kortvarig churn under AI-stöd — stöder påståendet “verifiering blir dyrare”; sekundärkälla.)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Leveransprestanda bestäms av kultur, flöde och feedback — inte individuell kodningshastighet; primärkälla.)
buymeacoffee
![[Din organisationsstruktur har redan bestämt din mjukvarusöd] Conway’s lag — en administrativ lag som har underskattats i 56 år Software engineering i AI-tiden — Lär dig AI långsamt 171](https://cdn.iaiuse.com/img/2026/04/06/97308b44819c0d12a4fd8e758b91ddd0.webp)
