Kodbetygsättning i AI-eran — När AI skriver koden, vem granskar den?

I förra inlägget (Learn AI Slowly #173) lyfte jag fram “granskning” som den tredje nya flaskhalsen när själva kodskrivandet blir nästan gratis, och jag avslutade med ett löfte om en “fjärde del som tar upp detta på egen hand”. Detta inlägg infriar det löftet. Först en slutsats: Sett i mitten av 2026 är den största variabeln som AI-programmeringsverktygen levererar inte antal licenser, inte antal platser, inte ens modellens benchmark-poäng — det är granskningskapaciteten.

I CodeRabbits rapport från slutet av 2025 analyserades 470 öppna GitHub-PR:er, och slutsatsen är att AI-assisterad kod genererar 1,7 gånger fler defekter än kod skriven helt för hand (10,83 mot 6,45 per PR i snitt, utan matchning för filstorlek eller komplexitet). Säkerhetsbristerna ligger mellan 1,57 och 2,74 gånger högre beroende på underkategori – XSS 2,74×, felaktig hantering av lösenord 1,88×, osäkra direkta objektreferenser 1,91×, osäker deserialisering 1,82×; logik- och korrekthetsfel 1,75×, läsbarhet 3×+, formatering 2,66× och felhantering nära 2×.

Apiiro kompletterar bilden med en skanning i Fortune 50-bolags repos i september 2025 (data från december 2024 till juni 2025): AI-genererad kod fick de månatliga säkerhetsfynden att skjuta i höjden från runt 1 000 till över 10 000 – en 10× ökning. Privilegieeskaleringssårbarheter steg med 322 % (absolut antal; normaliserat mot kodvolym uppskattas ökningen till omkring 60–80 %), och brister i arkitektur och design ökade med 153 %. Under samma period sjönk syntaxfelen med 76 % och logikbuggar med 60 %.

Dessa två datamängder berättar tillsammans en viktig historia – särskilt i en regulatorisk kontext: en betydande del av de 322 % priviligierade eskaleringssårbarheterna som Apiiro rapporterade hamnar precis vid behörighetsgränsen, och i finans och telekom är det just där kundmedel och kunddata ligger. AI-genererad kod fungerar ofta, men defekter och sårbarheter ökar i takt med volymen – och de farliga typerna smyger uppåt. (Metodnotering: CodeRabbits rapport kommer från en leverantör med eget intresse; Apiiro-data kommer från en oberoende säkerhetsleverantör. Slutsatsens riktning sammanfaller, men siffrorna bör tolkas med hänsyn till hur respektive dataset normaliserats.)

För ett företag leder detta till två kontraproduktiva insikter – var och en motsäger den berättelse som säljs med verktygen.

De två kontraproduktiva insikterna

Insikt 1: Utvecklarens roll förändras från “den som skriver kod” till “den som granskar kod” – men att granska är mer ansträngande än att skriva.

JetBrains undersökning från januari 2026 (10 000+ utvecklare, 8 språk) visar att 90 % av utvecklarna använder minst ett AI-verktyg. En mer tankeväckande siffra kommer från Pragmatic Engineers undersökning i februari 2026: 56 % av seniora ingenjörer uppger att över 70 % av deras ingenjörsarbete är beroende av AI-verktyg (självskattning från tunga användare, inte andel kodrader). Det handlar inte om att då och då be AI skriva några rader — AI har blivit arbetssättet man utgår ifrån. Produktionsförhållandena har flyttats ett steg: själva kodskrivandet är nu AI:s domän, och utvecklaren lägger mer tid på att läsa och bedöma — det vill säga att granska. Att läsa andras kod är redan svårare och långsammare än att skriva. Att läsa främmande AI-genererad kod och samtidigt göra bedömningar utifrån compliance-gränser och affärsregler innebär en klart högre kognitiv belastning än att skriva sin egen kod. Det är grundorsaken till att utvecklare under 2025–2026 återkommande rapporterar att “AI gör mig tröttare” — något som underbyggs av METR:s rapport 2026.2, där den tidigare berättelsen delvis vänds: slutsatsen att erfarna utvecklare bromsades med 19 % av AI ifrågasätts i nya sampel (nyare utvecklare ligger fortfarande på -4 %), och den samlade bilden blir att “granskningsbandbredden är tightare än produktionsbandbredden”.

Kontrintuitivt nog 2: Ju starkare AI-verktygen blir, desto mer behöver organisationen styrning — inte fler verktyg.

CodeRabbits 1,7× fler buggar, Apiiros 322 % fler privilegieeskaleringshål – var för sig ser det ut som AI-haverer. Sätt dem i Theory of Constraints-spegeln så syns det tydligt: verktygets produktionskapacitet har gått upp, men din granskningskapacitet har inte hängt med. Ett systems output bestäms av dess trängsta snitt. AI har breddat “skriv”, så det trängsta snittet har blivit “granska”. När granskningsbandbredden inte skalar upp, skriver AI snabbare – och den tekniska skulden organisationen samlar på sig blir allt farligare. Det är slutsatsen i AI173: automatisering eliminerar inte flaskhalsar, den flyttar bara på dem.

Översätter man detta till AI-assisterad kodning måste man lägga till en nyans: mjukvaruutveckling är inte en enda linjär pipeline med en flaskhals, det är flera parallella flaskhalsar som driver omkring dynamiskt. TOC håller i rena pipeline-scenarier, men i AI-kodning med dess parallella, multipla bottleneck-läge har det trängsta snittet drivit från “skriv” till “granska”. Och i “granska” finns i sin tur tre egna oberoende flaskhalsar – verifiering, styrning och compliance-granskning – som alla sitter och klämmer var för sig.

Den operativa innebörden av detta mönster har två nivåer. Den första nivån handlar om att montera alla fyra bromsarna innan autonoma agenter släpps lös: obligatorisk manuell code review, automatiserade tester (AI-förändringar måste kunna köras), säkerhetsscanning (på samma nivå som manuell kod) och canary deploys (en liten andel av AI:ns ändringar rullas ut först). Ingen AI-genererad PR får passera utan granskning. Det är minimikravet för att omvandla “AI skriver kod” till ingenjörsproblemet “AI skriver kod + organisationen kan fånga upp misstag”. Om en av delarna saknas finns en obevakad exponeringsyta. Carlini dokumenterade i januari–februari 2026 ett ofta citerat referensfall: en Anthropic-forskare lät 16 Claude Opus 4.6-agenter köra parallellt i två veckor, cirka 2 000 sessioner, till en API-kostnad på runt 20 000 dollar, och byggde från noll en Rust-baserad C-kompilator på 100 000 rader som kan kompilera Linux 6.9-kärnan och klarar GCC torture test med 99 procents täckning. Det är värt att betona: detta var ett kontrollerat experiment i en sluten domän. Carlini rullade inte ut koden i produktion. Fallet är användbart som “extrem jämförelse utan någon som helst granskning”, men det är vilseledande att använda det som mall för “släpp autonoma agenter lös omedelbart” – återanvändbarheten överskattas. I en organisation utan code review, automatiserade tester, säkerhetsscanning och canary deploys slutar det förr eller senare i en incident.

Det dolda lagret: bedömning handlar om arkitektur, efterlevnad och affärslogik – inte bara buggar

Det andra lagret är mer subtilt. Poängen med kodgranskning är inte att hitta buggar, utan att avgöra om kodens arkitektur är rätt, om den håller sig inom efterlevnadsgränser och om affärslogiken är korrekt. Det vanligaste misstaget som äldre ingenjörer gör är att likställa AI-eran av granskning med traditionell code review. Traditionell review tittar på frågan “Är det här koden fel?”. AI-erans review tittar på frågan “Hör den här koden över huvud taget hemma i den här filen, det här projektet, inom den här efterlevnadsgränsen?”.

CodeRabbits 1,82–2,74× fler säkerhetshål och Apiiro:s 322 % fler privilegieeskaleringshål hör till denna typ av problem: AI:n skrev inte fel, men den skrev på fel plats, med fel rättigheter och med fel standardkonfiguration. Sådana problem går inte att laga i IDE:n – de måste förstås vid granskningsbordet.

Det bredare branschmönstret är att märka GitHub/GitLab branch protection + CODEOWNERS-regler med röd flagga för allt som rör schema / auth / billing / efterlevnadsgränser, och route:a sådana ändringar till sign-off från två personer. I bank- och telekompraxis är det oftast en backup-veto snarare än fullständig granskning, där spot-check-andelen varierar efter risknivå. Architecture Decision Records (ADR), säkerhets- och compliance-baslinjer samt affärsreglers korrekthet – det är där AI-erans granskning borde lägga sin tid.

Lägg dessa två kontraintuitiva insikter ovanpå varandra, så framträder bilden: kodgranskning i AI-eran kräver att organisationen justerar tre saker – dra in utvecklingschefen i granskningsflödet, bädda in compliance- och arkitekturbaslinjer i PR-routningen, och lyfta styrningsmått som felfrekvens upp till styrelserapporteringen. Dessa tre motsvarar direkt de “tre försvarslinjerna i modellstyrning” (verksamhet, IT, compliance/revision) som krävs enligt Kinas Administrative Measures for Internet Loans of Commercial Banks – tillsynsmyndigheten känner igen strukturen omedelbart. Vi bryter ner det i fyra lager nedan.

II. Varför “just nu”: mekanismen bakom validering som ny flaskhals

Vi infriar löftet från avsnitt 3 i AI173 om att behandla detta separat. Det speciella med fönstret i mitten av 2026: autonoma agenter (Claude Code, Codex) rör sig från “pilotanvändning” till “standardanvändning”; organisationer som inte har uppgraderat sin granskningsprocess före H2 kommer att få ett koncentrerat haveri under Q4-topparna / årsslutsfrysningarna / de ordinarie tillsynsinspektionerna. Först förklarar vi varför “validering” har underskattats mest bland de nya flaskhalsarna, sedan visar vi den tillsammans med de två andra (definiera rätt problem, systemintegration) i en samlad bild.

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

AI-kodgenerering 6× Granskningsbandbredd 1,3×

Gap = riskackumulering (defekter +1,7×, säkerhetsbrister +1,82–2,74×, privilegieeskalering +322 %)
Förhållanden är riktningsindikativa, baserade på JetBrains 2026.1-undersökning, CodeRabbit 2025.12-rapport, Apiiro 2025.9-rapport

The root of the underestimation is that most AI-coding discussions take “validation” to mean CI/CD, running unit tests, and passing lint by default. That is the world of internet products: code is deployed to the cloud, unit tests are green, CI passes, the merge goes through, and it ships to production. That flow works at the pace of consumer software, but it does not transfer to telecom, finance, manufacturing, or e-commerce. In those industries, “validation” means algorithm filing, graded security assessment (the Chinese dengbao regime), cross-border data transfer assessment, Change Advisory Board approval, reconciliation audits, and regulatory reporting — activities that have nothing to do with the code itself, yet each consumes several weeks. AI173 already published the picture (coding speed-up, validation is the bottleneck); no need to repeat it here. The point is the question it leaves behind: how many validation gates does AI-written code have to pass before it can reach production?

At least seven: automated testing, code review, security scanning, architecture / ADR review, business-rule review, compliance clearance, and canary release. Each gate eats a slice of bandwidth. Stacked together, these seven are the “other side” of the chart in AI173 — what AI accelerates is the segment with the lowest marginal cost (GPU hours, licence fees); what validation consumes is the segment with the highest institutional cost (regulation, filing, reconciliation).

Den andra underskattade grundorsaken är att ”granskning” reduceras till ”code review”. De två främsta källorna till code review — egoless programming, som Weinberg presenterade i The Psychology of Computer Programming 1971 med rötter i NASA och akademin, samt Fagan Inspections, som introducerades av IBM 1976 — bygger båda på samma antagande: kod skrivs rad för rad, den som skriver den förstår den bäst, och efteråt går någon annan igenom den för att hitta fel. AI bryter mot detta antagande: koden skapas av AI på några sekunder, den som skriver den delar ingen kontext, och den som läser den — utvecklaren — står inför ett främmande alster. Det gamla antagandet om att ”hitta fel” håller inte längre. Den nya frågan vid granskning är i stället: Bör den här koden finnas i den här filen? Kan den kringgå befintliga arkitekturbeslut? Hamnar den inom eller utanför de tillämpliga regelgränserna? Kan standardkonfigurationen bli en säkerhetsrisk i produktion?

Alla tre frågor kräver någon som förstår verksamheten, arkitekturen och regelefterlevnaden. Verktyg kan bara ge stöd. Det innebär att ”granskning” höjs från en lint-kontroll i CI/CD till en integrerad del av det tekniska styrningsarbetet.

Tre. Tre-lagers granskningsmodell: AI pre-review, mänsklig kontroll, styrningsregler

Komprimera analysen ovan till en operativ struktur. De tre lagren ersätter inte varandra – de staplas på varandra. Varje PR passerar alla tre samtidigt, och varje lager hanterar sin egen typ av problem.

Lager 1 körs på sekund- till minutnivå – varje rad AI-genererad kod passerar först ett verktyg. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot och Antigravity Review kan alla kommentera inom sekunder till minuter efter att en PR skapats, och täcker in lint, säkerhetshål, duplicerad kod, namngivning och beroenderisker. Budgeten för detta lager är extremt låg (oavsett antal PR:er är det samma abonnemangskostnad), och täckningen är hög (varje PR passerar). Det utgör basen för kapaciteten. Men dess blinda fläckar är lika tydliga – det löser inte arkitekturell samstämmighet, compliance-gränser eller affärsmässig korrekthet. CodeRabbit rapporterar att de “fångar de flesta uppenbara problem automatiskt”, men kvarvarande dolda risker (standardkonfigurationer, behörighetsgränser, felhanteringsvägar gömda i detaljer) kräver en mänsklig hand. Detta lager är bara grunden, inte slutpunkten.

Lager 2 handläggs inom timmar till dagar

Högriskändringar – sådant som rör kärnmoduler, databasscheman eller autentisering, debitering och efterlevnad – måste alltid gås igenom manuellt av en spot-check-grupp med arkitekt, verksamhetsägare och säkerhetsansvarig. En betydande del av de siffror vi ser från CodeRabbit (1,82–2,74× fler säkerhetsbrister) och Apiiro (322 % fler privilegieskaleringar) handlar om fel som bara denna nivå fångar: AI-genererad kod som ser rätt ut och kör, men där standardinställningar, behörighetsgränser och felhantering döljer sig i detaljerna.

Ändringar med medelhög till låg risk kan hanteras via stickprov – utifrån vår erfarenhet från interna utbildningskunder rekommenderar vi 20–30 procents urval, inte en branschstandard. Syftet är att flytta mänsklig kapacitet från “granska allt” till “granska det som är avgörande”.

Den vanligaste fällan här är gradvis glidande standarder. När teamet vill att AI-genererade pull requests ska gå igenom snabbare är det frestande att tyst vidga definitionen av “högrisk”. Det känns bekvämt på fredagseftermiddagen – tills en incident visar varför den klassificeringen fanns från första början.

Nivå 3 löper på dags- till veckobasis – ändringar som rör regelefterlevnad, regulatorisk rapportering, dataexport, SLA:er och tvärfunktionella arkitekturbeslut hanteras här: Change Advisory Board (Change Advisory Board (CAB)), arkiveringsgenomgångar, säkerhetsklassificeringsbedömningar (motsvarande Kinas 等保-utvärdering) och regulatorisk dialog. Det här är det orange fältet i AI173-figuren där “AI inte räcker till” – det dyraste kostnadsposten i hårt reglerade branscher. Slutsatsen i AI174 är: AI kan inte ta hand om Nivå 3, men om Nivå 1+2 sköts väl kan de allra flesta lågriskändringar stoppas innan de ens når Nivå 3 (uppskattningsvis 80–90 % enligt interna kunddata). De återstående 10–20 % högriskändringarna går via Change Advisory Board (CAB), vilket flyttar Change Advisory Board (CAB):s kapacitet från hela företaget till de ändringar som verkligen kräver styrning. Kortare Change Advisory Board (CAB)-köer och snabbare totalt leveranstempo är den lättast underskattade “governance-bandwidth-vinsten” vid en styrningsuppgradering.

Efterlevnadsgodkännandet på Nivå 3 måste ned på papper. Varje pull request som triggas via Nivå 3-routern måste ha en fullständig spårbarhetskedja: PR-diff + granskningskommentarer + dubbel signatur från verksamhetsansvarig och compliance-ansvarig + tidsstämpel + bilaga med modellvalideringsrapport. Arkiveringstiden är 5 år för finans och 3 år för telekom (jämför Kinas GDPR + Lag 2018:218 §55,Finansinspektionen 通知〔2020〕24 samt algoritmregistreringsföreskrifterna från MIIT). Det här är hårda bevis vid regulatorisk dialog, inte papperskomplians.

Nyckeldesign i tre lager: triggervillkor styrs av risknivå, inte av antal rader kod eller PR-storlek

I praktiken kan riskbedömningen inte överlåtas till AI:n själv – en modell saknar compliance-medvetande och förstår inte att “ändra ett fält för kund-ID” är en röd linje enligt GDPR + Lag 2018:218 (Kinas personuppgiftslag). Därför måste PR-initieraren manuellt kryssa i en checklista i PR-mallen (ändrar ni schemat? autentiseringen? faktureringen? en compliance-gräns?) – en bedömning som sedan dubbelbekräftas via CODEOWNERS-regler. Baserat på kryssrutorna dirigeras ärendet till rätt lager: lågrisk-PR:er går via Lager 1 med automatisk merge (inom whitelistade sökvägar och med en felbrytare – om ett auto-mergat PR orsakar en produktionsincident inom 30 dagar pausas automeringen och alla sådana PR:er återgår till manuell granskning), mellanrisk via Lager 2 med stickprov, högrisk via Lager 3 med fullständig styrningsprocess. Detta “riskadaptiva routnings”-mönster är den mest mogna formen av en eskaleringsstege.

Fyra: Verktygsval för kodgranskning – CodeRabbit är inte det enda svaret, men det är dagens faktiska baslinje

Nu pressar vi ner tre-lagers-modellen på verktygsnivå. Det här avsnittet handlar bara om valet för Lager 1 – Lager 2 och 3 är i första hand en fråga om organisation och process, där verktyg inte gör så stor skillnad.

CodeRabbit är i toppsegmentet för installationer i AI Code Review-kategorin på GitHub Marketplace (Series B i september 2025, värdering 550 miljoner USD, ARR $40M beräknat till Q2 2026, enligt Sacra) – verktyget bäddar in en “AI-granskare” direkt i PR-kommentarsflödet, där varje kommentar levereras med klickbara förklaringar, fixförslag och en allvarlighetsgrad, vilket gör det särskilt effektivt för blinda fläckar i enhetstester. Integrationen med GitHub Actions är den djupaste på marknaden, prissättningen är trappstegsformad per antal PR, och enterprise-versionen adderar privata modeller, godkännandelistor och intern kunskapsbas. De tidigare nämnda siffrorna – 1,7× fler buggar och 1,82–2,74× fler säkerhetshål – kommer från CodeRabbits egen rapport. Kort sagt: en AI-granskare inbäddad i PR-flödet, klickbara förklaringar, fixförslag, allvarlighetsgrad – och den skarpaste GitHub Actions-integrationen, trappstegsprissatt per PR, med privata modeller, allowlistning och intern KB i enterprise-utgåvan.

GitHub Copilot Review har bara ett enda argument kvar för att väljas: man har redan GitHub Enterprise på plats och vill inte addera en ny leverantör. Den hårda begränsningen är att reglerna inte kan anpassas på djupet, och på sikt kommer regelbiblioteket att halka efter CodeRabbits.

Sourcery är det mest kraftfulla verktyget för automatisk kodgranskning i Python-världen: det kan ge refaktoreringsförslag direkt i PR-stadiet (inte bara felflaggning, utan även omskrivning) och är särskilt effektivt för att komplettera typannoteringar och beta av teknisk skuld. För tvärspråkliga team räcker det inte – TypeScript och Go har precis kommit ikapp, och stödet för andra språk är glest.

Cursor BugBot utmärker sig genom att kunna läsa kontexten från konversationer i Cursor-editorn; den ser vad du har diskuterat med AI:n och granskar den genererade koden utifrån det. Projekt som inte ligger i Cursor kan inte dra nytta av den.

Antigravity Review är den inbyggda granskningsfunktionen i Googles Antigravity-plattform (lanserad november 2025), driven av Gemini 3-modellen och med Googles molnplattforms företagsanpassade compliance-stöd som grund. Plattformen är fortfarande under snabb iteration under första halvåret 2026, regelbiblioteket är inte lika omfattande som CodeRabbits, och företagsversionens prissättning och distributionsmodell justeras fortfarande.

Fem. Implementering i fyra branscher: hur kodgranskningen tar olika form i varje regleringskontext

Telekom – uppgradering av granskningsprocessen vid ändring av abonnemang och fakturering. I en AI‑internutbildning på en regional operatör fick jag en bild som sammanfattar det hela: varje abonnemangsändring passerar elva grindar från kod till produktionssättning. AI:n pressade ner själva kodsteget från två dagar till en halv, men de fem grindarna Change Advisory Board, algoritmregistrering (eftersom faktureringsmodellen berörs), säkerhetsskyddsbedömning, dataexport (man använde en utländsk modell och behövde gå via Guanxinbuliang shuju anquan guanli banfa (zhixing) – inte ett standardavtal enligt Kinas personuppgiftslag, GDPR + Lag 2018:218) samt avstämningsrevision slukar allt från några dagar till en månad var. En algoritmregistrering tar normalt fyra till sex månader från materialförberedelse till återkoppling från MIIT – det är den riktiga flaskhalsen. Den totala ledtiden rör sig knappt. Riktningen för uppgraderingen är: verktyg på nivå 1 (Layer 1) måste kunna identifiera ändringar som rör fakturering, autentisering eller compliance och automatiskt flagga dem som högrisk, och sedan routas de till gemensam signering av affärsägare och compliance‑ägare på nivå 2 (Layer 2); Change Advisory Board gör då bara en andra granskning på de ändringar som faktiskt berör regulatorisk rapportering. Kärnan i denna väg är att flytta Change Advisory Board (CAB):s bandbredd från 5 000–8 000 ärenden per månad (alla ändringar, inklusive brådskande patcher) ner till 100–200 högriskärenden som verkligen kräver styrning. Före uppgraderingen satt flaskhalsen i Change Advisory Board (CAB); efteråt är Change Advisory Board (CAB) tvärtom den snabbaste grinden, eftersom åtta av de elva grindarna har automatiserats eller regelbaserats och förhandsgranskats.

Den dolda smärtpunkten i telekombranschen är inte Change Advisory Board (CAB) – det är modellförklarbarhet. Debiteringsmodeller måste kunna redogöra för hur varje rad på en faktura har beräknats, och så snart ett AI-system som har beslutstöd får in kundklagomål måste man kunna spåra tillbaka till källan. De tre vanligaste ärendena som når klagomålsmyndigheten – nummerportering, faktureringstillgänglighet och hantering av avstängning/återinkoppling – kräver förhandsgodkännande av koncernens konsumentskyddsfunktion innan en tjänst kan driftsättas. Det är något som ingen Change Advisory Board kan ersätta.

Finans – uppgraderad granskning av kreditriskmodeller. I bankernas kärnsystem följer en riskmodell en bestämd sekvens: oberoende validering av Modellvalideringsenhet (MVE) (Model Validation Unit) → godkännande i modellriskkommittén → affärsenhetens ansökan om tillsynsregistrering → regulatorisk återkoppling → driftsättning efter godkänd registrering. De fem stegen är sekventiella, inte parallella. AI-assisterad kodning kan bara accelerera ett smalt segment (skriptgenerering, feature engineering, datapreprocessering) – men varje ändring rör regulatorisk gräns. Att ändra etiketter motsvarar till exempel “väsentlig modellförändring som kräver ny registrering” enligt artikel 24 i Measures for the Administration of Internet Loans by Commercial Banks (中国《商业银行互联网贷款管理办法》) jämteFinansinspektionen 通知〔2020〕24. Riktningen för uppgraderad granskning: skikt 1 måste kunna identifiera ändringar i features, etiketter, tröskelvärden och modellvikter och automatiskt eskalera till högriskflödet. skikt 2 kräver dubbelsignatur av en kreditriskansvarig med domänkunskap och en datakompliance-ansvarig, där Modellvalideringsenhet (MVE) är organisatoriskt oberoende från både affärsenheten och IT-avdelningen (ett hårt krav i sammaFinansinspektionen 通知〔2020〕24). skikt 3 omfattar modellvalidering, Finansinspektionen 規制データ報告-dataregistrering (bankspecifikt rapporteringsramverk i Kina), Finansinspektionen/Riksbank データ報告-rapportering, GDPR + Lag 2018:218-bedömning (Personal Information Protection Law, Kinas personuppgiftslag) och algoritmisk rättvisgranskning – variabler som kön, ålder och geografi får inte ligga till grund för kreditbeslut.

Ett verkligt smärtfall: efter att en aktieägd bank driftsatte ett AI-verktyg för feature engineering ökade kötiden för modellvalidering från 8 till 12 veckor. Anledningen är att Model Validation Unit (Modellvalideringsenhet (MVE)) måste granska varje enskild AI-genererad feature för PSI- och CSI-drift, och dessutom finns en stor friktion i datadelningen mellan Modellvalideringsenhet (MVE) och datakompliance-teamet. Modellvalideringsenhet (MVE) behöver se den underliggande feature-fördelningen, men datakompliance tillåter inte – med hänvisning till GDPR + Lag 2018:218 (Kinas personuppgiftslag) – att Modellvalideringsenhet (MVE) tar del av kundnivådata direkt. Allt måste gå via en trång passage bestående av “modellvalideringssandlåda + aggregerade features efter avidentifiering”.

Bemanna Lager 2 innan ni ens pratar om verktyg. Oavsett hur kraftfullt verktyget är blir en uppskalning av granskningen en chimär om ni inte har människor som både förstår verksamheten och compliance och kan göra spot-checks.

Tillverkning – uppgraderad granskning av MES-processändringar. Inom tillverkningen är AI-assisterad kodning lockande (linjeintegration, kvalitetsmodeller, processtyrning), men en MES-ändring riskerar ofta att röra säkerhetsförreglingar – att justera en processparameter kan stoppa en hel produktionslinje. Tillverkningskompetensen sitter djupare än vad ytan visar: ändringar i OEE (Total Utrustningseffektivitet)-förreglingar (Overall Equipment Effectiveness), SPC (Statistisk Processkontroll)-diagram (Statistical Process Control), batchspårbarhet samt retur-/påfyllnadsflöden är alla högrisk, inte bara “tröskelvärden i processen”. Vägen framåt för granskningen: Lager 1 måste flagga “säkerhetsförreglingar/OEE (Total Utrustningseffektivitet)/SPC (Statistisk Processkontroll)/batchspårbarhet” som högsta risk, och automatisk merge ska inte vara tillåten. Lager 2 kräver dubbelsignering av processtekniker och säkerhetsingenjör. Lager 3 innebär provkörning med gradvis utrullning – först pilot på en enskild linje i liten skala, verifiera att inga sidoeffekter på säkerhetsförreglingar uppstår, innan breddning. Flaskhalsen i denna bransch finns på Lager 2 i form av seniora processtekniker, som är en uttömd resurs: deras tid är redan uppbokad av produktionen. Granskningsuppgraderingen handlar i praktiken om att omfördela deras fokus – från daglig tillsyn till högrisk-PR-granskning.

E‑handel – upphöjd granskning under kampanjperioder. Inom e‑handel är produktivitetsvinsten med AI‑assisterad kodning tydligast (landningssidor, marknadsföringsregler, datadashboards, rekommendationslogik), men kodändringar under stora kampanjer berör transaktionsflödet, riskkontrollflödet och den finansiella avstämningsflödet – ett enda misstag kan kosta över hundra miljoner. Riktningen för skärpt granskning: Layer 1 måste märka allt som rör kampanjmoduler, kuponger, blixtrea och lager som högsta risk; Layer 2 kräver gemensam sign-off av affärsägare och riskägare; Layer 3 kör canary-release och fullständig lasttestning av hela kedjan. Det som gör e‑handel speciellt är kampanjernas tidsfönster: två veckor före och efter evenemang som Black Friday, Singles’ Day eller julhandeln skärps granskningsstandarden, samtidigt som granskningsbandbredden är som mest nedtryckt av produktion. Branschens beprövade metod är “avslappnat i vanliga fall, stramt under kampanj” – en vecka innan fönstret låser man alla högriskändringar och tillåter enbart buggfixar; granskningsbandbredden koncentreras på den låsta backloggen så att inga högriskändringar smyger in i kampanjfönstret.

Sex – Implikationer för beslutsfattare

Omvänd självgranskning – Litar ditt team mer eller mindre på det AI producerar? Hur granskas er AI-PR – 100 % manuell granskning, riskbaserad stickprovskontroll, eller släpps den igenom i smyg? Hur många gånger har er Layer 3-routing triggats de senaste sex månaderna? Hur många av dessa gånger identifierades faktiska problem respektive incidenter? Om styrelsen inte kan få fram dessa tre siffror är er styrning inte mer än papperscompliance.

När vi tittar på de fyra branscherna framträder ett tydligt mönster: kärnan i en eskalerad granskningsprocess handlar inte om att köpa nya verktyg – det handlar om att rita om riskrutten. Routningsvillkoren i Layer 2/3 skiljer sig åt mellan branscherna (telekom: Change Advisory Board + algoritmregistrering + modellförklarbarhet; finans: oberoende Model Validation Unit + modellvalidering + Finansinspektionen 規制データ報告-ramverket + algoritmisk rättvisa; tillverkning: pilotkörning + canary-release + OEE (Total Utrustningseffektivitet)/SPC (Statistisk Processkontroll); e-handel: lockdown under stora kampanjperioder), men logiken i Layer 1-verktygen kan återanvändas: det handlar hela tiden om att “identifiera hög risk, märk automatiskt, tvinga fram rätt routing”. På verktygsnivån kan du utan problem köpa in en eller två Layer 1-lösningar och använda dem tvärs över branscher – på processnivå måste varje bransch däremot designa om sin egen rutin.

Insikt 1: En uppgradering av kodgranskning är en uppgradering av organisationens förmåga – inte ett tekniskt inköp. CodeRabbit Pro kostar 24 USD per användare och månad (Pro Plus 48 USD, beräknat per utvecklare som öppnar en PR). Räknat på ett team om 200 personer blir det ungefär 58 000 USD per år, och en enterprise-licens ligger tre till fem gånger högre. Jämfört med en R&D-budget i miljonklassen är det småpengar. Det som kostar på riktigt är att bemanna lager 2 med rätt personer och att rita om processen i lager 3. Det köper man inte med budgetmedel – det kräver att organisationen faktiskt vill förändra sig och att seniora ingenjörer är beredda att avsätta tid för granskning. De som inte lyckas driva igenom förändringen behandlar den som ett vanligt IT-projekt: köp licens, rulla ut verktyget, sätt KPI:er. De som lyckas är de som sätter utvecklingschefer och compliance-ansvariga vid samma bord och låter dem gemensamt definiera routningsreglerna för PR-flödet. Det är en budgetsignal som flyttar styrningen från kostnadsställe till bandbreddstillgång – först då börjar budgeten omfördelas från ”fler licenser” till ”mer granskningskapacitet”.

Lärdom 2: Innan autonoma agenter rullas ut måste AI pre-review vara på plats. Det här är baksidan av “bromsen monteras innan man pratar om motorn”: autonoma agenter (som Claude Code eller Codex) kan själva ändra dussintals filer, öppna pull requests och köra skalkommandon. Innan den kapaciteten aktiveras måste Lager 1 kunna identifiera vilken modul som berörs och vilken gräns som vidrörs och tvinga ärendet till rätt nivå. Rekommenderade kvantitativa kriterier för “på plats”: ≥95 % automatisk merge-genomströmning i Lager 1, ≥20 % stickprovstäckning i Lager 2, och noll P0-incidenter under tre månader i rad. Exemplet med Carlinis 100 000 rader Rust-baserade C-kompilator ligger närmare än du tror – en autonom agent kan leverera en produktionsklar leverans på två veckor, men i en organisation utan recension ackumuleras lika lätt 20 000 produktionsklara risker på samma tid. Ett mer jämförbart branschexempel är Stripes agent “Minions”, som slår ihop runt 1 300 PR i veckan, där ingen kod skrivs av människor – allt produceras av AI och granskas enbart av människor. AI-genererad output plus mänsklig review-only är kännetecknet, och det är så en mogen recensionsstege ser ut.

Insikt 3: Både vinsterna och förlusterna med upphöjd granskning måste räknas mot kapaciteten. Låt oss omdefiniera “granskningskapacitet” – det handlar inte bara om antalet mantimmar vid kodgranskningsbordet, utan om hela organisationens samlade förmåga att identifiera, dirigera och hantera risk. Det som CodeRabbit kallar att “automatiskt fånga de flesta uppenbara problemen” är bara en del av bilden. Hur väl AI:n faktiskt kan användas beror på huruvida den återstående delen av dolda risker – arkitekturell passform, regulatoriska gränser, affärsmässig korrekthet – får tillräckligt med mänsklig uppmärksamhet på Layer 2 och 3.

Det vanligaste felet vid upphöjd granskning är att låta AI:s pull requests (PR) mergas automatiskt. För att “få AI-effektiviseringen att se mer imponerande ut på papper” smygs reglerna på Layer 1 ner, Layer 2 ändras till en samplingstakt på 5 %, och Layer 3 blir i praktiken tandlös. Kortsiktigt ser siffrorna bra ut, långsiktigt skjuter incidentfrekvensen i höjden – AI skriver snabbt + slappare granskning = skulden växer proportionellt. Kombinationen av CodeRabbits 1,7× ökning av defekter och Apiiros 322 % fler eskaleringar av behörigheter är det samlade priset för den typen av uppluckring, inte bara ett enskilt misslyckande. Granskningskapaciteten måste växa i samma takt som PR-volymen; obalans i proportionerna är detsamma som att tappa kontrollen.

30-dagars implementationschecklista (med tillräcklig granularitet för att veta “vilket möte nästa måndag, vilket dokument som ska uppdateras”):

Vecka 1: Inventera befintliga PR-routningsregler och markera dem i rött enligt fyra kategorier: “schema-/auth-/billing-/efterlevnadsändringar”. Plocka ut antal Layer 3-triggningar och genomsnittlig kötid de senaste 90 dagarna som baslinje.
Vecka 2: Inför ett Layer 1-verktyg (välj ett av CodeRabbit / GitHub Copilot Review, sålla bort alternativ som inte uppfyller det hårda kravet på “privat deployment”) och konfigurera reglerna. Lägg till en manuell kryssruta för risknivå i PR-mallen.
Vecka 3: Sätt ihop en Layer 2-lista med verksamhetsansvariga och compliance-ansvariga, definiera spot-check-urvalsfrekvens (rekommenderat 20–30 %). Fyll ut CODEOWNERS-filen med ägare per modul.
Vecka 4: Lyft upp dessa fem KPI:er till PMO:s veckorapport – genomsnittlig PR-granskningstid, change failure rate, andel defekter som slipper igenom efter granskning, genomsnittlig kötid för Layer 2/3 samt antal compliance-incidenter som triggas via Layer 3-routning. Sätt samtidigt följande som tröskelvärden för att tillåta autonoma agenter: Layer 1-genomströmningsgrad ≥ 95 %, Layer 2 spot-check-täckning ≥ 20 %, samt noll P0-incidenter tre månader i rad.

Stödmått som håller jämna steg

Här är vad som måste upp på styrelsebordet:

Genomsnittlig tid för PR-granskning
Andel misslyckade ändringar (change failure rate)
Andel defekter som slinker igenom granskning
Genomsnittlig kötid i Layer 2/3
Antal compliance-incidenter utlösta av Layer 3-routing
Kötid för modellvalidering

I slutet av AI173 påpekades att många storföretag, när de rapporterar AI-kodnings-ROI uppåt, mäter “hur många utvecklare vi når ut till” och “hur många seats vi köpt in”. Det är exakt där den verkliga flaskhalsen göms. Lyft upp dessa mått i styrelserapporteringen — i stället för seat-antal och rader kod — så flyttas budgeten från “köp fler licenser” till “fyll på granskningskapacitet”.

Skugg-AI måste治理as parallellt

UpGuards 2025-rapport använder formuleringen “anställda globalt som använder icke godkända generativa AI-verktyg” — och det handlar inte bara om utvecklare. Cirka 80 % av de anställda erkänner att de använder AI-verktyg som inte är godkända av IT. Affärsenheter går runt IT och låter ChatGPT skriva kod åt sig själva — det är vad compliance-ansvariga just nu ligger sömnlösa över.

Att uppgradera styrning utan att samtidigt ta itu med skugg-AI är som att “bara 管理a deklarerade vapen” och lämna “odeklarerade vapen” utanför kontroll.

Ej tillämpliga scenarier: Om ditt team har färre än 50 personer, inte verkar i en hårt reglerad bransch, inte hanterar autonoma agenter och har en PR-volym under 100 per månad, så gäller minst 60 % av resonemangen i den här artikeln inte direkt. Skippa strukturen och landa i stället på två nivåer: lager 1-verktyg plus ett par kritiska spot-checks.

Nästa steg

Nästa artikel (AI175) handlar om verktygslagret: AI-verktygskriget är i praktiken avgjort 2026, men frågan är om vinnarna ens går att använda. Det handlar om duon på tronen (Claude Code / Codex), om Copilot som bärs upp av inköpsinertia, och om Antigravity som fortfarande startar från scratch. Det handlar också om att styrförmågan avgör vem som får använda vad, och på vilken nivå. AI174 ger strukturen för att uppgradera er review; AI175 ger strukturen för verktygsval. Tillsammans får du helhetsbilden av ”vad händer med organisationen när AI börjar skriva koden”.

Efter den här artikeln rekommenderar jag AI173 avsnitt 3 (bedömningen av den nya flaskhalsen) plus AI175 avsnitt X (kopplingen mellan styrförmåga och verktygskapacitet). Tre centrala slutsatser, fördelade över tre artiklar.

Vill du omsätta dessa resonemang i din egen organisation?

När AI-kodverktyg kliver in i företaget – fem nyckeltal som avgör om ni är redo

När AI-baserade kodverktyg rullas ut i en organisation landar de konkreta frågorna oftast här: klarar befintliga code review-processer den volym AI genererar? Hur mycket Layer 2-bemanning krävs (räknat i PR-volym / antal moduler / andel FTE)? Behöver Layer 3-processen – Change Advisory Board och regulatorisk dokumentation – designas om? Och vilka KPI:er ska piloten valideras mot?

Diagnosporten: Börja med fem mätvärden för teamet – genomsnittlig granskningstid per PR, andel misslyckade ändringar (change failure rate), andel defekter som slinker igenom granskningen, genomsnittlig kötid i Layer 2/3, samt antal compliance-händelser som triggas via Layer 3-routing. Om ni inte kan producera ett enda av dessa tal är ni inte redo att rulla ut ett AI-drivet pre-review-verktyg.

För närvarande erbjuds tre former av samarbete:

Företagsintern utbildning: Vi arbetar utifrån era verkliga projekt och driver igenom implementeringen av en AI-driven granskningsmodell i tre lager. Det innefattar bland annat verktygsval för Layer 1 (CodeRabbit, GitHub Copilot Review och liknande – utvärderade längs fyra dimensioner: privat driftsättning, anpassningsbarhet av regler, integrationsdjup och pris), omdesign av Layer 2/3-flöden, samt ett tillhörande mätsystem. Leveranserna omfattar: ① en mognadsbedömning av teamet (granskningsbandbredd och mättnadsgrad) ② en färdplan för implementering av tre-lagersmodellen (3–6 månader) ③ ett beslutsträd för val av Layer 1-verktyg ④ ett utkast till mätinstrumentpanel. 3 dagar, cirka 90 000 RMB.

Learn AI Slowly 008

Specialkonsulting: Med fokus på ett tydligt beslut – till exempel att utvärdera om CodeRabbit ska införas, hur en trestegsgranskningsmodell landar i en hårt reglerad miljö (Modellvalideringsenhet (MVE)-oberoende + spårbar kedja inom finans / algoritmregistrering + PTS 利用者申立-klagomålshantering inom telekom), eller hur befintlig Change Advisory Board (CAB)-rytm kan ruttas om för AI-PR. Prissättning per beslutstema (5–15 timmar per konsultpaket). Leveransen = beslutsprotokoll + implementationschecklista + 1 veckas uppföljning. ¥5K/timme.

1V1-coaching / privat rådgivningsgrupp: För “den som är beredd att investera seriöst i sin utveckling” – vice presidenter, direktörer och seniora ingenjörer som redan använder AI-kodningsverktyg och vill bygga upp omdöme kring granskningsmognad, teamstyrning och tvärfunktionella förhandlingar i sin egen organisation. 12 sessioner / 6 månader, prissättning per tema. Leveransen = coachningsanteckningar + periodisk handlingsgenomgång. ¥180K–360K.

Ledarskapsföredrag och branschpresentationer: Kring AI-granskning, organisationsstyrning, företags AI-transformation och mjukvaruutvecklingens paradigmskifte. Halvdag / heldag, efter värdens behov.

Artiklarna ger generella ramar. Faktisk implementation behöver fortfarande designas utifrån företagets datagränser, regulatoriska krav, tekniska mognad och befintliga granskningsprocesser. För samarbeten, kontakta coach@iaiuse.com.

Fördjupad läsning: “Se Jianpai-metoden v1.0” (Lär dig AI långsamt 187), som systematiskt presenterar ett sjustegsramverk för AI-transformation i företag.

Om denna serie

“AI-eran förändrar mjukvaruteknik” är en forskningsserie riktad till CIO:er, CDO:er, CTO:er och digitaliseringsansvariga inom telekom, finans, tillverkning och e-handel. Fokus ligger på hur AI-baserade programmeringsverktyg påverkar mjukvaruleverans, organisation, styrning och ledning.

Bakom denna kanal finns ett litet team — jag och 1–2 kollegor som jag samarbetat med länge. Vi fördelar arbetet mellan oss: forskning om AI-programmeringsverktyg, kartläggning av organisationsstyrningsfall och coachningssamtal. De flesta projekt som vi beskriver som “vi har hjälpt företag att ta sig igenom” har vi genomfört tillsammans.

Serien följer löpande akademiska artiklar, leverantörsdokumentation och branschrapporter. Forskningsbiblioteket omfattar över 200 referenser, och vi markerar evidensnivå för varje centralt påstående för att i möjligaste mån skilja mellan verifierade fakta, leverantörsuttalanden, branschiakttagelser och författarens egna resonemang.

Jag har närmare 8 års erfarenhet av konsultverksamhet och affärsanalys i stora företag, bland annat på IBM, med projekt inom telekom, finans, försäkring och tillverkning. Därefter har jag fortsatt att arbeta operativt med operatörsprodukter, internetprodukter och AI-applikationsutveckling — med behovsanalys, produktdesign och tvärfunktionellt genomförande.

Referenskällor (källa per post + evidensnivå + partsintresse)

Dina översättningsinstruktioner är registrerade, men det finns ingen svensk översättning att generera — texten du angav innehåller bara en introduktionsfras och en rubrik, inte någon brödtext från en AI‑teknikblogg.

Om du vill ha en korrekt översättning behöver jag:

Den faktiska artikeln (hela Markdown‑brödtexten som ska översättas), och gärna
Målmarknad (t.ex. “svensk telekom‑CIO”, “nordisk finans‑CIO” osv.), så att jag kan välja rätt lokala exempel som AT&T, Ericsson, Telia, Klarna, Volvo, H&M etc.

Skicka in originaltexten så återkommer jag med en idiomatisk svensk version, med terminologi (GPT/Token/CoT) oförändrad, lokala branschexempel, och referenslistan översatt enligt dina riktlinjer.

CodeRabbit State of AI vs Human Code Generation Report (2025-12-17, primärkälla, leverantörsperspektiv): analyserar 470 öppna GitHub-PR:er (AI mot mänsklig kod, utan matchning på filstorlek/komplexitet). Totalt antal defekter 1,7× (i snitt 10,83 mot 6,45 per PR); säkerhetsbrister per underkategori 1,57–2,74× – XSS 2,74×, felaktig hantering av lösenord 1,88×, osäker direkt objektreferens (IDOR) 1,91×, osäker deserialisering 1,82×; logik/korrekthet 1,75× (75 % högre), kodkvalitet 1,64×, prestanda 1,42×, läsbarhet 3×+, formatering 2,66×, felhantering ~2×, överdriven I/O ~8×. CodeRabbits egen forskning, leverantörsperspektiv, urval och metodologi är publikt redovisade. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / The Register 2025-12-17.
Apiiro 4 september 2025 (leverantörsperspektiv): Skanning av kodförråd hos Fortune 50-företag (data perioden december 2024–juni 2025). Antalet säkerhetsfynd i AI-genererad kod per månad sköt i höjden från cirka 1 000 till över 10 000 (10× i absoluta tal), sårbarheter som leder till privilegieeskalering +322 % (absoluta tal), designbrister på arkitekturnivå +153 %; normaliserat mot den växande kodvolymen uppskattas ökningen till omkring 60–80 %. Antalet syntaxfel minskade med 76 %, logiska buggar med 60 %. Rapporterat av The Register, Cloud Security Alliance Labs och SiliconANGLE.
JetBrains AI Pulse Survey januari 2026 (primär källa): 10 000+ professionella utvecklare, 8 språk. 90 % av utvecklarna använder minst ett AI-verktyg; 70 % använder 2–4 stycken. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/

Pragmatic Engineer Newsletter (2026.2, primärkälla): cirka 906 respondenter, når 150 000 läsare; 56 % av seniora ingenjörer uppger att 70 %+ av deras ingenjörsarbete är beroende av AI-verktyg (självskattad tung användning, ej andel kodrader); Claude Code 46 % mest omtyckt (vs Cursor 19 %, Copilot 9 %); i företag med under 10 000 anställda väljer 75 % Claude Code, i företag med över 10 000 väljer 56 % Copilot. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026
GitHub Octoverse 2024 / 2025 (primärkälla): Octoverse 2025-rapporten visar att Copilot coding agent under maj–sept 2025 har skapat 100 000+ PR som author; bland nya utvecklare använder 80 % Copilot inom den första veckan. “40–60 % PR-inblandning” är en branschuppskattning, inte Octoverse-data. Sammanställt av GitHub Engineering Blog och The New Stack.

Stripe Minions (2026.3, förstahandskälla): Stripes agent “Minions” mergear runt 1 300 PR varje vecka, noll mänskligt skriven kod (endast manlig code review) – AI:s helautomatiska produktion plus människor som enbart granskar är kännetecknet för modellen. 500+ MCP-verktyg, AWS EC2 devbox, Block Goose som branchstrategi. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents / InfoQ-rapport 2026.3.20.

Anthropics kompetenssystem (Skills): en första titt

I januari 2026 publicerade Anthropic sin tekniska designdokumentation för Skills – ett ramverk för modulär uppgiftsförmåga (modular folders that teach Claude specific tasks), uppbyggt kring skill-filer och progressive context loading. Till skillnad från många AI-plattformar hanterar Anthropic inte PR-routning via det här lagret. Den typiska riskbaserade PR-routningen i branschen sköts fortfarande av GitHubs och GitLabs branch protection i kombination med CODEOWNERS-regler, som styr granskningar utifrån filsökväg och utsedda kodägare. Källan är Anthropics egen engineering-blogg.

Carlini / Anthropic (jan–feb 2026, primärkälla, förstahandsforskning): Nicholas Carlini, forskare på Anthropic, lät 16 Claude Opus 4.6-agenter köra parallellt i två veckor – cirka 2 000 sessioner och runt 20 000 USD i API-kostnad – och byggde från noll en C-kompilator på 100 000 rader Rust. Kompilatorn kompilerar Linux 6.9 (x86/ARM/RISC-V) och klarar GCC torture test mit mit 99 %. Studien är avgränsad, har not skalats till produktion och saknar codereview-mekanismer. Rapporterad av The Register 2026‑02‑09 och Ars Technica, februari 2026.
METR-uppdatering 2026.2 (primärkälla, ej verifierad): Tidigare studie omfattade 16 erfarna utvecklare och 246 verkliga uppgifter med Cursor Pro + Claude 3.5/3.7 Sonnet, där AI faktiskt gjorde arbetet 19 % långsammare (95 % KI 2–39 %) – även om utvecklarna själva upplevde att de var 20 % snabbare. Den uppföljande rapporten från februari 2026 innehåller en nyanserad bild där nyare utvecklare förbättrades med cirka 4 %, medan en del av resultaten för seniora utvecklare gick i motsatt riktning. Exakta siffror och urval bör verifieras mot METR:s originalrapport. https://metr.org/blog/2026-02-24-uplift-update
Microsoft FY26 Frontier Suite / EY-fallet (primär, leverantörsperspektiv): EY rullade ut Microsoft 365 Copilot till 150 000 medarbetare, med 15 % produktivitetsökning (motsvarande 14 timmar per person och vecka, omfördelade till kundleverans och lärande); därefter breddade man utrullningen till över 400 000 medarbetare. I scenariot finansiell drift implementerat på Microsoft Power Platform + Copilot Studio minskade ledtiden end-to-end med 95 % och driftskostnaderna med 37 % (avser enbart finansiell drift, inte hela koncernen). Källa: Microsoft Customer Story 25760 / FY26 investerarsida.

Agentic AI i praktiken – två konkreta referensfall

Atos Agent 365-utrullning (juni 2026, primärkälla, partsintresse)

Atos har rullat ut Microsoft 365 Copilot till 56 000 anställda i 54 länder och hanterar 19 000 interna AI-agenter via plattformen Agent 365. Enligt Atos egen utsago är “styrning och säkerhet den första grinden för agentic AI”. Källa: Microsoft News 9 juni 2026 / CDO Magazine.

Vad fallet visar i korthet:

Skalan är redan operativ, inte ett pilotprojekt.
19 000 agenter innebär att varje anställd i snitt har tillgång till en tredjedels agent – frågan är inte längre om utan hur de styrs.
Microsofts agentplattform används här som kontrollskikt, inte som modellval. Det är i linje med hur stora CIO-kontor i telekom (t.ex. Deutsche Telekom, Telefónica) och bank (t.ex. ING, BBVA) redan tänker kring Copilot och Bedrock.

Anthropic Claude Code och OpenAI Codex – autonom agentförmåga (primärkälla, partsintresse)

Claude Code kan självständigt redigera ett tiotal filer, köra shell-kommandon, hantera Git och öppna pull requests. Codex kan i sin tur låta flera sub-agenter arbeta parallellt i isolerade kopior och sedan slå ihop resultaten. Källa: Anthropics och OpenAI:s tekniska dokumentation.

Den praktiska innebörden för ett CIO-kontor:

En utvecklares lokala miljö är inte längre en sandbox som organisationen kontrollerar. När agenten kan pusha kod, köra skript och öppna PR:er flyttas gränsen för “vad gör ett verktyg” till “vem tar ansvar för agentens handlingar”.
Parallella sub-agenter gör att en uppgift som tidigare tog en sprint kan formas om på en eftermiddag – men bara om loggning, reprobarhet och rollback finns på plats.
I en verksamhet med regulatorisk tyngd (t.ex. en regional operatör under NIS2, en bank under DORA) blir frågan om audit trail och datahärkomst snabbt central.
CodeRabbit – bolagsöversikt (2025–2026, primärkällor): ledande i första laget på GitHub Marketplace för AI-baserade kodgranskningsverktyg; Series B i september 2025 värderade bolaget till cirka 550 miljoner USD; ARR har vuxit nästan 10× under 2025–2026 till omkring 40 miljoner USD (Q2 2026, Sacra-data); Pro 24 USD/plats/månad, Pro Plus 48 USD/plats/månad (debiteras per utvecklare som skapar PR). Flera källor: Sacra / Reuters / TechCrunch. https://sacra.com/c/coderabbit
GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (förstahandskällor, leverantörsperspektiv): officiell dokumentation och produktsidor för respektive Layer 1-granskningsverktyg – jämförbara dimensioner som täckning, regelanpassning och integrationsdjup. Antigravity släpptes i GA 2025-11-18, rapporterat av VentureBeat / PCMag.

Historisk referens: Code review-traditionens ursprung

Två parallella spår har format den moderna kodgranskningen, och det är värt att känna till dem när man jämför med AI-assisterad granskning:

1. Egoless programming (1971). Gerald Weinberg introducerade begreppet i The Psychology of Computer Programming. Weinberg var verksam vid NASA Goddard Space Flight Center och undervisade vid University of Nebraska – alltså inte en IBM-bakgrund, vilket ibland felaktigt påstås. Hans poäng: kod ska granskas som ett grupparbete där författarens ego inte står i vägen för felhittande.

2. Fagan Inspections (1976). Michael Fagan, IBM-anställd, formaliserade en stegvis inspektionsprocess (planning → overview → preparation → inspection → rework → follow-up) som blev standard i industrin under decennier.

De två traditionerna har löpt parallellt: Weinberg betonade kultur och psykologi, Fagan betonade process och struktur. Båda utgör den historiska referenspunkten när vi idag diskuterar vad AI-driven review faktiskt adderar – eller ersätter.

Finansiell tillsyn: en konkret referensram

Som jämförelsepunkt – inte som universell mall, men för att visa hur ett moget regelverk faktiskt ser ut i praktiken – använder vi Kinas bankreglering:

商业银行互联网贷款管理办法, artikel 24, plusFinansinspektionen 通知〔2020〕24号, stadgar tre försvarslinjer i modellstyrning: affärsverksamheten, IT och compliance/ internrevision.
Modellvalideringsenhet (MVE) (Model Validation Unit) ska vara oberoende av modellutvecklarna.
Väsentliga modellförändringar kräver ny备案 (anmälan/tillståndsprövning) – principen motsvarar det europeiska “material change”-kravet under GDPR/DORA eller amerikanska SR 11-7.
Finansinspektionen 規制データ報告 (Examination and Supervision Tool) – månatliga inspektionsdata – samt Finansinspektionen/Riksbank データ報告-rapportering (China Banking Regulatory Commissions insamlingssystem, motsvarighet till COREP/FINREP i EU).
PBOC:s konsumentkreditregister plus algoritmrättvisgranskning, med begränsningar för variabler som kön, ålder och geografi – liknande de diskrimineringsgrunder som täcks av EU:s AI Act, japanskkreditlagstiftning och US ECOA/Reg B.

Poängen är inte att alla tillsynsramverk ser likadana ut, utan att en “model risk management”-kultur per definition innebär tre försvarslinjer, oberoende validering och formell ändringskontroll – oavsett om granskningen utförs av människa, AI eller båda i kombination.

Praktiska referenser

Telekomreglering (primärkällor): MIIT:s föreskrifter om algoritmregistrering (dubbla tillsynskrav gäller debiterings- och finansiella algoritmer); MLPS-säkerhetsbedömning (Nivå 2: 30 arbetsdagar / Nivå 3: 45 arbetsdagar); PTS 利用者申立-klagomålsstatistik topp 3 (nummerportabilitet, faktureringssändighet, suspendering/återaktivering av abonnemang); negativ lista för datakorsning enligt Föreskrifter om dataskydd inom industri- och informationssektorn (på prov).
GDPR + Lag 2018:218 för uppdragstagen av personuppgifter (primärkälla): Personuppgiftsskyddslagen (GDPR + Lag 2018:218) art. 21 + 55 — behandlingsavtal med tredje part plus dokumentationsbevaringsplikt i 3–5 år (beroende på sektor).
Stack Overflow Developer Survey 2025 (primärkälla): enkät med över 49 000 utvecklare. Andelen utvecklare som litar på AI-utdata gick från 40 % 2024 till 29 % 2025 (ned 11 procentenheter); samtidigt säger 46 % att de aktivt misstror AI-utdata (upp från 31 % 2024). Code churn har ökat från 3,1 % 2020 till 5,7 % 2024. https://survey.stackoverflow.co/2025/
Shadow AI (UpGuard 2025, nivå 2): 80 % av de anställda globalt använder ej godkända generativa AI-verktyg (inte bara utvecklare), och 68 % av säkerhetsansvariga erkänner att de har otillåten AI i organisationen. Uppgraderingar av styrning utan motsvarande shadow AI-styrning är en blind fläck i compliance-arbetet. https://www.upguard.com/resources/the-state-of-shadow-ai
Författarens egna ärenden (anonymiserade): ① AI-internutbildning hos en regional teleoperatör (2024 Q4, 11 gate-genomgång, anonymiserad) ② Diskussion om uppgradering av kreditriskbedömning hos en börsnoterad bank (2025 H1, anonymiserad) ③ Omdesign av processen för MES-ändringsbedömning hos en stor tillverkningskoncern (2025 H2, anonymiserad) ④ Lock-scenario under stor kampanj hos en ledande e-handelsplattform (Kinas “Double 11” 2025, anonymiserad).
Anonymiseringsnotis: De tele-, finans-, tillverknings- och e-handelsärenden som nämns i detta inlägg bygger på författarens erfarenhet av AI-internutbildning och uppföljning av digitaliseringsteam inom telekomsektorn, och har anonymiserats. Branschavsnitten utgör typiska problemresonemang snarare än specifika konsultuppdrag. Vid citering, vänligen ange att ärendena är anonymiserade.