Koddgranskning i AI-eran – Vem granskar när AI skriver koden?

I föregående artikel (Learn AI Slowly #173) lyfte jag fram ”verifiering” som den tredje nya flaskhalsen när kod i princip blir fri, och jag avslutade med att ”avsnitt fyra får ett eget kapitel”. Här levereras det. Slutsatsen först: när vi blickar tillbaka i mitten av 2026 visar det sig att den största förändringen som AI‑verktygen för mjukvaruutveckling levererar inte är antal licenser, inte antal säten och inte modellernas benchmark‑siffror – det är granskningskapaciteten.

Den nya flaskhalsen heter ”granskning”

AI‑verktyg producerar kod i en takt som mänskliga granskare inte klarar av att hänga med i. Frågan är inte längre ”kan det här verktyget skriva kod” utan ”vem läser igenom det, vem förstår det och vem vågar godkänna det”.

Det är en sanning som blir tydligare för varje leverans som rullas ut i produktion. Verktygen har mognat – Claude Code, Codex, Cursor, Copilot, Gemini och Googles Antigravity är alla på banan – men granskningssidan har inte riktigt hängt med.

Tre signaler från fältet

1. Granskningsköerna växer

En telekomoperatör i EU (B2B‑fokus, flera tusen utvecklare) rapporterade att PR (pull request)‑granskningstiden ökade från i snitt 18 timmar till 41 timmar på ett halvår efter att Copilot‑liknande verktyg rullats ut brett. Leveranstakten fördubblades, ja, men granskningstiden gick från ”i slutet av dagen” till ”nästa dag, om vi har tur”.

2. Granskare överladdas

En nordisk bank med 4 000 tekniker införde en intern policy: varje merge till main måste ha minst två sign‑offs. Tre månader senare upptäckte de att 30 % av de auktoriserade granskarna stod för 80 % av alla sign‑offs. Resten var antingen overksamma eller hade slutat signera alls. Den nya bördan föll på en liten grupp, och den gruppen höll på att bränna ut.

3. ”LGTM med ögonen stängda”

En e‑handelsaktör i DACH‑regionen (tyskspråkig marknad) hittade ett mönster i sina post‑mortems: en hel klass av incidenter hade sitt ursprung i PR:er där kommentaren ”LGTM” (looks good to me) hade skrivits utan att granskaren faktiskt läst koden. AI‑genererade diffar var snygga, homogena och reste inte röda flaggor – men de var inte granskade på riktigt. Det räckte med en utvecklare som tryckte på godkänna för att en bugg av viss dignitet skulle nå produktion.

Den gemensamma bilden: verktygen har sänkt kostnaden för att skriva kod dramatiskt. Kostnaden för att granska den har inte sjunkit – den har stigit.

Varför granskning inte är trivial

Många tror att AI skriver kod, och AI kan väl granska kod lika bra? Tyvärr inte. Granskning handlar om flera saker som inte är triviala för en modell:

Kontextuell korrekthet – Gör koden det som affären behöver, inte bara det som koden säger? En AI har ingen aning om varför en tariffregel ser ut som den gör, eller varför en viss riskkvot måste vara just 1,27.
Säkerhetspåståenden – Är den här autentiseringsvägen faktiskt säker i vår miljö, eller ser den bara ut som den är det i koden? I telekom handlar det om nätverksexponerade gränssnitt, i bank om transaktionsintegritet, i tillverkning om OT/IT‑skiljelinjen och i e‑handel om kortdata (PCI‑scope).
Arkitekturkonsekvens – Passar ändringen in i den befintliga tjänstestrukturen, eller skapar den en ny oregistrerad beroendeväg? Här finns regulatoriska överlagringar (NIS2, GDPR, DORA, PCI DSS 4.0) som gör att en ”liten ändring” inte är liten.
Reversibilitet – Hur snabbt kan vi rulla tillbaka om detta går fel? Och vem har rätt att göra det?
Ansvar – Om något händer, vem äger beslutet att skicka? Det är inte tekniskt. Det är styrning.

Det är inte tekniska frågor. Det är styrningsfrågor med teknik som objekt. Och det är därför en människa måste sitta i stolen.

”Vi skaffar oss ett AI‑granskningsverktyg”

Det är vanligt. Det är också ett tecken på att man inte har förstått problemet.

Att kasta en annan modell på problemet förändrar inte det faktum att granskning är kontextberoende. En LLM som granskar LLM‑utdata är ungefär som två alkoholmätare som korskontrollerar varandra – den ena ser inte den blindhet den andra har.

Dessutom är granskning inte ett enskilt steg. Den är tre saker:

Kodläsning – faktisk rad‑för‑rad‑granskning av diff:en
Riskbedömning – vad kostar det om detta misslyckas?
Styrning – vem äger beslutet, vem sign‑offar, hur spåras det?

De tre nivåerna har olika krav, olika roller och olika cost of error. En verktygskedja som trycker ned allt i en enda ”AI granskar AI”‑knapp förvirrar mer än den hjälper.

Lösningen är inte att ersätta människan. Lösningen är att flytta människan högre upp i kedjan – från mekanisk radgranskning till meningsbärande risk‑ och policybedömning.

Det nya granskningsparet

Här är den konkreta bilden av hur det ser ut när det fungerar:

Lager	Vem gör vad	Verktyg som hjälper
Radnivå	AI:en gör den första linjen – syntax, stil, uppenbara buggar, testtäckning, CVE‑matchning	Claude Code, Codex, Copilot, interna lint‑paket
Affärsrisk	Människan bedömer: påverkar detta intäkter, regelefterlevnad eller kundupplevelse? Är rollback‑vägen tydlig?	Ticket‑system (Jira/ServiceNow), riskregister, run‑books
Styrning	Senior person med signeringsrätt enligt en Change Advisory Board (CAB) – två sign‑offs, spårbar logg	ITSM‑plattform, ServiceNow‑arbetsflöden, interna policy‑Git‑hooks
Efterlevnad	Om regelverk berörs (NIS2, GDPR, PCI DSS 4.0, DORA): eskalering till compliance‑team med referens till kontrollmappning	Unified compliance‑plattformar (t.ex. Vanta, Drata, Secureframe), spårbar audittrail

Den nya arbetsfördelningen är tydlig: AI sköter den monotona radgranskningen, människan behöver fokusera på affärsrisk och styrning. Det är inte en degradering – det är en höjning. Granskarens roll flyttas från mekaniker till arkitekt.

Vad du som CIO gör på måndag

Fyra konkreta steg, sorterade efter hur snabbt de ger effekt:

1. Mät din granskningslatens, inte din leveranshastighet

Lägg till en KPI i din rapport från och med nästa vecka: time‑to‑first‑human‑review (TTFHR) – tiden från PR öppnad till första mänskliga kommentar. Den är i dag en bra proxy för din faktiska flödeshastighet, och den är nästan alltid högre än du tror.

2. Gör CAB till en datadriven process, inte ett Waterfall‑minne

Många organisationer kör Change Advisory Board som ett tveeggat svärd från 2014. Släpp den modellen. Kör i stället riskbaserad klassificering: hög risk → full CAB med två sign‑offs, medel → en sign‑off + automatiserade kontroller, låg → automatisk merge med policy‑hooks. Skalan, inte byråkratin, är poängen.

3. Avlasta granskarna – automatisera det monotona

Rulla ut AI‑verktyg som gör radnivågranskning (lint, säkerhetsscanners, beroendekontroller, CVE‑matchning, testtäckning) i CI‑pipelines. Målet är att människan ska kunna fokusera på affärsrisk och styrning, inte på att leta efteran semikolon. Låt Claude Code, Codex, Cursor, Gemini eller interna scripts göra det tråkiga jobbet.

4. Gör granskning till en mätbar kompetens

Inför ett lättvikts‑peer‑review‑program: varje PR granskas av minst en utvecklare utanför teamet, och granskningskvaliteten (kommentartäthet, fångade defekter, tid till sign‑off) spåras som ett utvecklar‑KPI. Granskning är inte bara en gate. Det är ett lärande.

Den djupare bilden: programvara som levereras i en styrd kadens

Den verkliga vinnaren i AI‑eran är inte den som har flest rader kod. Det är den som kan leverera programvara med hög tillförlitlighet, spårbarhet och regelefterlevnad – i en kadans som organisationen faktiskt klarar av.

AI sänker kostnaden för kod. Det sänker inte kostnaden för konsekvens. Den kostnaden betalas i granskning.

Och den som löser granskningen – inte med fler anställda, utan med en bättre allokering av mänsklig uppmärksamhet – är den som 2026 kommer att leverera mjukvara som både är snabb och kontrollerad.

Det är inte en AI‑fråga. Det är en styrningsfråga. Och den börjar i CAB.

CodeRabbit-rapporten: AI-genererad kod innehåller 1,7× fler defekter

I slutet av 2025 analyserade CodeRabbit 470 öppna PR:er på GitHub och kom fram till att kod där AI varit inblandat i genereringen innehöll 1,7× fler defekter jämfört med kod skriven helt för hand (i genomsnitt 10,83 vs 6,45 per PR, oparerat efter filstorlek och komplexitet). När det gäller säkerhetsbrister var ökningen per underkategori mellan 1,57× och 2,74×: XSS 2,74×, felaktig hantering av hemligheter 1,88×, osäkra direkta objektreferenser (IDOR) 1,91× och osäker deserialisering 1,82×. För logik- och korrekthetsfel var ökningen 1,75×, läsbarhet över 3×, formatering 2,66× och felhantering nära 2×.

Apiiro kompletterade bilden med en skanning av kodförråd hos Fortune 50-företag i september 2025 (data från december 2024 till juni 2025). Där sköt antalet säkerhetsfynd per månad i taket, från runt 1 000 till över 10 000 när AI-genererad kod tillkom – en 10× ökning. Brister som möjliggör privilegieeskalering ökade med 322 % i absoluta tal; normaliserat mot den samtidiga tillväxten i kodmängd landar ökningen på cirka 60–80 %, och arkitekturella designfel steg med 153 %. Samtidigt minskade syntaktiska fel med 76 % och logikbuggar med 60 %.

Dessa två dataset pekar i samma riktning, och det är särskilt viktigt i ett regulatoriskt sammanhang: en stor del av Apiiros 322 % ökning av privilegieeskaleringssårbarheter hamnar vid just behörighetsgränser — och i finans och telekom är dessa gränser detsamma som kundmedel och kunddata. Mycket AI-genererad kod fungerar, men defekter och sårbarheter ökar i proportion — och de farliga sorterna smyger uppåt. (Metodnotering: CodeRabbits rapport speglar leverantörens perspektiv; Apiiros data kommer från en tredjepartssäkerhetsleverantör. Slutsatsens riktning stämmer, men siffrorna bör tolkas med normaliseringsmetoden i åtanke.)

När detta landar i en organisation utlöser det två kontraintuitiva insikter — var och en motsäger den berättelse som säljs med de verktyg du köper.

1. Två kontraintuitiva insikter

Kontraintuitiv insikt 1: Utvecklarens roll går från “den som skriver kod” till “den som granskar kod” — men granskning är mer krävande än skrivning.

Slutsats: När AI breddar “skrivandet” lägger utvecklare mer tid på “läs + bedöm” — att läsa okänd kod, avgöra var compliance-gränserna går och verifiera affärsregler. Den kognitiva belastningen är märkbart högre än när man skriver sin egen kod. 56 % av seniora ingenjörer är beroende av AI för över 70 % av sitt arbete (Pragmatic 2026.2). Det nya arbetssättet är nu standard.

JetBrains rapport från januari 2026 (10 000+ utvecklare, åtta språk) visar att 90 % av utvecklarna använder minst ett AI-verktyg. En senare Pragmatic Engineer-undersökning från februari 2026 i samma bransch innehåller en mer väckande siffra: 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 standardarbetssättet. Produktionsförhållandena har flyttats ett steg: själva skrivandet av kod är nu AI:s domän, medan utvecklarna lägger mer tid på att läsa och bedöma – det vill säga granska. Att läsa andras kod är sedan långt svårare och långsammare än att skriva egen; att läsa okänd kod skriven av AI och samtidigt göra bedömningar utifrån regelefterlevnad och affärsregler innebär en klart högre kognitiv belastning än att skriva sin egen kod. Detta är grundorsaken till den ihållande återkopplingen från utvecklare 2025–2026 om att ”AI gör mig tröttare” – underliggande finns METR:s omvända narrativa från februari 2026 (slutsatsen att AI bromsade seniora utvecklare med 19 % har i nya sampel delvis vänt; nytillkomna utvecklare ligger fortfarande på −4 %, och sammantaget pekar bedömningen mot att ”granskningsbandbredden är mer ansträngd än produktionsbandbredden”).

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

CodeRabbits 1,7× fler buggar och Apiiros 322 % fler privilegieeskaleringsluckor ser var för sig ut som AI-misslyckanden. I teorin om begränsningar (Theory of Constraints, ToC) är de däremot ett oundvikligt resultat av att verktygens produktionsförmåga drivits upp medan din granskningskapacitet stått stilla. Ett systems genomlopp bestäms av dess trångaste snitt. AI har vidgat “skrivmomentet” – det snävaste snittet har därmed förskjutits till “granska”. När granskningens bandbredd inte hinner med, skuldsätter organisationen sig själv i takt med att AI-koden växer. Det är slutsatsen i AI173: automatisering eliminerar inte flaskhalsar, den flyttar bara runt dem.

Översatt till AI-assisterad utveckling krävs en nyans: mjukvaruutveckling är inte en enda linjär flaskhals utan flera parallella som driver om varandra dynamiskt. ToC håller i en ren pipeline, men i en parallell miljö med flera konkurrerande flaskhalsar – som AI-kodning – glider den trångaste sektorn från “skriv” till “granska”, och inom “granska” uppstår i sin tur tre oberoende trånga sektorer: verifiering, styrning och compliance-granskning.

Den praktiska innebörden av det här mönstret har två nivåer. Den första: innan autonoma agenter släpps lös måste alla fyra bromsarna vara på plats – obligatorisk manuell kodgranskning, automatiserade tester (AI:ns ändringar måste gå igenom grönt), säkerhetsscanning (på samma nivå som mänsklig kod), och kanarieutrullning (små andelar av AI:ns ändringar rullas ut först). Pull requests från AI får aldrig hoppa över granskning. Det här är miniminivån för att göra om problemet “AI skriver kod” till ett ingenjörsproblem av typen “AI skriver kod + organisationen klarar att fånga upp det”. Ta bort en enda del, så finns en friktionsfri väg rakt mot kaos.

Nicholas Carlini dokumenterade i januari–februari 2026 ett ofta citerat exemplar: en Anthropic-forskare lät 16 stycken Claude Opus 4.6-agenter arbeta parallellt i två veckor, ungefär 2 000 sessioner och runt 20 000 dollar i API-kostnad – och fick fram en Rust-baserad C-kompilator på 100 000 rader från noll. Kompilatorn bygger Linux 6.9-kärnan och klarar 99 % av GCC torture-testerna. En viktig reservation: det här var ett kontrollerat experiment i en sluten domän. Carlini skickade inte koden till produktion. Som extremt kontrafaktiskt test mot “ingen granskning alls” är det värdefullt. Som mall för att rulla ut autonoma agenter i morgon överskattar det återanvändbarheten. I en organisation utan kodgranskning, utan automatiserade tester, utan säkerhetsscanning och utan kanarieutrullning kommer det förr eller senare att gå illa.

Det andra lagret är mer dolt: kärnan i granskningen är inte att jaga buggar, utan att bedöma arkitekturöverensstämmelse, regulatoriska gränser och affärsmässig korrekthet. Det vanligaste misstaget som äldre ingenjörer gör är att behandla AI-eran review på samma sätt som klassisk code review. Traditionell review handlar om “har koden fel”; AI-erans review handlar om “ska den här koden över huvud taget finnas i den här filen, det här projektet, inom den här regulatoriska gränsen”. CodeRabbits siffror på 1,82–2,74× fler säkerhetshål och Apiiros 322 % fler privilegieeskaleringsbuggar tillhör den kategorin: AI:n skrev inte fel syntax, men skrev på fel plats, med fel rättigheter och med fel default-konfiguration. Sådana problem går inte att rätta i IDE:n – de måste läsas av en människa vid granskningsbordet. Branschpraxis är att märka GitHub-/GitLab-regler för branch protection och CODEOWNERS röda för ändringar som rör schema, auth, billing eller regulatoriska gränser, och routa dem till dual sign-off (i finans- och telekompraktik är det oftast backup-veto snarare än full review, där spot-check-andelen varierar med risknivå). Architecture Decision Records (ADR), säkerhets- och compliance-baseline, samt affärsreglers korrekthet – det är där AI-erans granskning faktiskt ska lägga sin tid.

Det blir tydligt när man lägger dessa två kontraintuitiva insikter ovanpå varandra: i AI-eran måste organisationer justera tre saker i kodgranskningen — dra in utvecklingschefen i granskningsflödet, bädda in compliance- och arkitekturbaslinjer i PR-routningen, och eskalera styrningsmått som felfrekvens till styrelserapporteringen. Dessa tre punkter motsvarar direkt det ”tre försvarslinjer”-ramverk för modellstyrning (affär, IT, compliancerevision) som krävs enligt Kinas Kommersiell bank internetutlåning管理办法 — tillsynsmyndigheten förstår detta ramverk direkt. Vi bryter ner det i fyra lager nedan.

II. Varför ”just nu”: mekanismen som gör verifiering till den nya flaskhalsen

Slutsats: Organisationer som inte har uppgraderat sin granskningsprocess före H2 2026 kommer att drabbas av en koncentrerad stormsperiod under Q4:s kampanjfönster / årets sista release-frys / tillsynsmyndigheternas rutinmässka inspektioner — tre lagers modellen är miniminivån, inte en bonus.

Vi infriar löftet från AI173, avsnitt tre, om att ”avsnitt fyra tar det separat”. Det som gör fönstret i mitten av 2026 speciellt: autonoma agenter (Claude Code, Codex) håller på att gå från ’pilotförsök’ till ’standardanvändning’; organisationer som inte har genomfört granskningsuppgraderingen före H2 kommer att explodera i problem under Q4:s kampanjfönster / årets release-frys / tillsynsmyndigheternas inspektionsperiod. Först förklarar vi varför ”verifiering” är den mest underskattade av flaskhalsarna, sedan visar vi den tillsammans med de andra två nya flaskhalsarna (definiera rätt problem, systemintegration) i en samlad bild.

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

AI 代码生成量 6× 评审带宽 1.3×

Gap = 风险积累（缺陷 +1.7×、安全漏洞 +1.82–2.74×、提权 +322%）
比例为方向性示意，基于 JetBrains 2026.1 调研、CodeRabbit 2025.12 报告、Apiiro 2025.9 报告综合

The real bottleneck nobody talks about: in most AI coding discussions, “verification” is silently equated with CI/CD, unit tests, and lint checks. That framing belongs to the internet-product world: you push code to the cloud, tests go green, CI passes, you merge, you ship. Fine for a consumer app. But the same playbook breaks the moment you step into telecom, finance, manufacturing, or e-commerce. In these industries, “verification” means algorithm filing (算法备案, the Chinese MIIT review of recommendation and decision algorithms before deployment), MLPS assessment (等保测评, China’s Multi-Level Protection Scheme grade test for information systems), cross-border data transfer review (数据出境评估, the CAC export assessment under the Cybersecurity Law and Data Security Law), Change Advisory Board approval, reconciliation audits, and regulatory reporting. Each step eats weeks. AI173 already drew the picture — coding accelerates, the bottleneck shifts to verification — so I won’t repeat it here. The question it leaves behind is the interesting one: how many gates does AI-generated code have to clear before it can reach production?

Seven, minimum: automated tests, code review, security scanning, architecture/ADR review, business-rule review, compliance clearance, and canary release. Each one consumes a slice of team bandwidth. Stack them up and you get the flip side of the AI173 chart. AI compresses the cheapest part of the cost curve (GPU hours, license fees). Verification eats the most expensive part (regulation, filing, reconciliation).

Den andra, ofta underskattade, grundorsaken är att ”granskning” reduceras till ”code review”. De två viktigaste källorna till code review – egoless programming, introducerat av Weinberg i The Psychology of Computer Programming 1971 (med rötter i NASA och akademin), och Fagan Inspections, utvecklat av IBM och presenterat av Fagan 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 kullkastar detta antagande: koden produceras av AI på några sekunder, den som skriver den (AI) bidrar inte med någon kontextöverföring, och den som läser den (utvecklaren) står inför ett främmande genererat resultat. Det gamla antagandet om att ”hitta fel” räcker inte längre. Den nya frågan vid granskning är i stället: Bör den här koden över huvud taget finnas i filen? Kan den kringgå befintliga arkitekturbeslut? Hamnar den innanför eller utanför de tillämpliga regelverksgränserna? Kan dess standardkonfiguration bli en säkerhetsrisk i produktion?

Alla tre frågor kräver någon som förstår verksamheten, arkitekturen och regelefterlevnaden. Verktygen fungerar bara som stöd. Det handlar med andra ord om att höja ”granskning” från en lint-kontroll i CI/CD till en central del av det tekniska styrningsarbetet.

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

Slutsats: Att uppgradera granskningen är inte ett verktygsproblem utan ett routingproblem – dirigera PR:n till Layer 1 (automatisk), Layer 2 (manuell stickprov) eller Layer 3 (styrningssignoff) utifrån risknivå. De tre lagren staplas ovanpå varandra, varje lager gör sitt, och verktyg, process och styrning löper parallellt.

Kokar vi ner analysen ovan till en operativ struktur. Tre-stegsmodellen är inte en ersättningsrelation utan en staplingsrelation – varje PR passerar alla tre lagren samtidigt, och varje lager tar hand om sin typ av problem.

Lag 1 körs på sekunder–minuter – varje rad AI‑genererad kod passerar först ett verktyg

CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot och Antigravity Review kan alla leverera kommentarer inom sekunder till minuter efter att en pull request skapats. De täcker lint‑fel, säkerhetsbrister, duplicerad kod, namngivning och beroenderisker. Denna lags budget är extremt låg (oavsett hur många PR:er som skapas är det samma abonnemangskostnad), täckningen är hög (varje PR går igenom) och det utgör basen för kapaciteten. Men dess blinda fläckar är också tydliga — det löser inte arkitekturell samordning, regelefterlevnad eller affärsmässig korrekthet. CodeRabbits rapportering beskrivs som ”fångar de flesta uppenbara problem automatiskt”, men de kvarvarande dolda riskerna (standardkonfigurationer, behörighetsgränser, felhanteringsvägar dolda i detaljerna) kräver mänsklig granskning. Det här lagret är basen, inte slutpunkten.

Lager 2: Timme till dag – mänsklig granskning av högriskförändringar

Högriskändringar – sådana som rör kärnmoduler, ändrar databasscheman eller berör autentisering, debitering och regelefterlevnad – måste gå igenom manlig stickprovsgranskning. Här är det arkitekter, verksamhetsansvariga och säkerhetschefer som tillsammans bedömer varje pull request. Den typen av brister som CodeRabbit rapporterar (1,82–2,74× fler säkerhetshål) och de 322 % fler eskaleringsrättighetsluckor som Apiiro flaggar hamnar i många fall just här: kod som AI:n har skrivit ser korrekt ut och fungerar i test, men där standardkonfiguration, behörighetsgränser och felhanteringsstigar döljer sig i detaljerna.

Förändringar med medelhög eller låg risk kan klara sig med ett urval – vår erfarenhet från interna konsultuppdrag pekar mot 20–30 % som riktmärke, men detta är inte en branschstandard. Syftet är att frigöra mänsklig kapacitet från att granska allt till att fokusera på det som faktiskt spelar roll.

Den vanligaste fällan på det här lagret är smygande standardglidning. När ett team vill att AI-genererade pull requests ska flöda snabbare, vidgas definitionen av “högrisk” lite i taget.

Det känns bekvämt ända tills en incident inträffar. Då är det obehagligt.

Lager 3 – timmar till veckor: när förändringar når regulatorisk mark

Lager 3 hanterar förändringar som vidrör regulatoriska gränser, myndighetsrapportering, dataöverföring över jurisdiktioner, SLA-avtal och tvärfunktionella arkitekturbeslut. Här går allt via Change Advisory Board (CAB),备案-granskning (algoritmregistreringsförfarande), 等保测评 (MLPS-säkerhetsbedömning, nivå 2/3) och direkt dialog med tillsynsmyndigheter. Det här är det orange fältet i AI173-figuren där “AI inte räcker till” – och för tungt reglerade branscher är det också den dyraste kostnadsposten.

AI174:s slutsats: AI kan inte ta över Lager 3, men om Lager 1+2 fungerar väl kan merparten av lågriskförändringarna fångas innan de når fram (uppskattningsvis 80–90 % enligt interna kunddata). Bara de resterande 10–20 % högriskförändringarna eskaleras till CAB, vilket frigör CAB:s kapacitet från hela företagets bredd till de förändringar som verkligen behöver styrning. Kortare CAB-köer och snabbare leveransrytm – det är den lättast underskattade “styrningskapacitetsvinsten” med en välfungerande eskaleringsstege.

Spårbara godkännanden är obligatoriskt på Lager 3

Varje pull request som routas via Lager 3 måste lämna ett komplett revisionsspår: PR-diff, granskningskommentarer, signatur från både verksamhetsägare (business owner) och compliance-ägare (合规 owner), tidsstämpel och bilaga med modellvalideringsrapport. Arkiveringstiden är 5 år för finanssektorn och 3 år för telekom – i Kina stöder man sig på PIPL §55,银保监会令2020年第9号 (CBIRC:s ordning nr 9, 2020) och 工信部算法备案管理办法 (MIIT:s förfarande för algoritmregistrering). För europeiska verksamheter fungerar samma kedja som bevisning under GDPR och NIS2; för amerikanska banker motsvaras den av SOC 2- och SR 11-7-kraven.

Den här kedjan är inte papperscompliance – den är hårt bevismaterial i dialogen med tillsynsmyndigheter.

Trelagers nyckeldesign: triggervillkoren kodas av risknivå, inte av antal kodrader eller PR-storlek. Rent praktiskt kan risknivåbedömningen inte förlita sig på AI:ns självvärdering — AI har ingen compliance-medarbetare och förstår inte att “ändra fält för kund-ID” är en röd linje enligt PIPL (Kinas personuppgiftslag). Den måste göras manuellt av PR-initieraren i PR-mallen (ändrar du schemat? auth? billing? compliance-gränser?) och sedan dubbelbekräftas via CODEOWNERS-regler. Baserat på kryssrutorna routas ärendet till rätt lager: lågrisk-PR:er går via Lager 1 med automatisk merge (inom whitelistade sökvägar + felbrytarskydd — om en automatisk merge-PR orsakar en produktionsincident inom 30 dagar pausas systemet och alla återgår till manuell review), medelrisk via Lager 2 spot-check, högrisk via Lager 3 styrningsflöde. Detta “riskbaserade adaptiva routing” är den mest mogna formen av review-eskalering.

Fyra, Val av review-verktyg: CodeRabbit är inte det enda svaret, men det är dagens faktiska baslinje

Slutsats: Valdimensjonerna rangordnas som “regelanpassningsbarhet > PR-kommentarskvalitet > integrationsdjup > pris”; kärnområden inom bank/finans, offentlig sektor, försvar och telekom kräver privat deployment eller self-hosted, men privat deployment är inte slutstationen — det måste åtföljas av ett datadelegeringsavtal enligt PIPL §21.

Lär dig AI långsamt 014 — Verktygsnivån i den treskiktade modellen

Komprimera den treskiktade modellen ner till verktygsnivån. Det här avsnittet tar bara upp valet på Lager 1 – Lager 2 och 3 handlar främst om organisation och processer, där verktyg inte tillför så mycket.

I den absoluta toppen av installationsstatistik för AI-kategorin på GitHub Marketplace ligger CodeRabbit (Series B i september 2025, värdering 550 miljoner USD, ARR 40 miljoner USD fram till Q2 2026, enligt Sacra). Verktyget bäddar in en “AI-granskare” direkt i PR-kommentarsflödet, där varje kommentar har klickbara förklaringar, förslag på åtgärder och en allvarlighetsgrad – vilket är särskilt effektivt i områden där enhetstester har blinda fläckar. Integrationen med GitHub Actions är den djupaste på marknaden, prissättningen är trappstegsbaserad efter antal PR:er, och enterprise-versionen kompletteras med privata modeller, godkända vitlistor och intern kunskapsbas.

GitHub Copilot Review har egentligen bara ett enda argument kvar: du ligger redan på GitHub Enterprise och vill inte ta in en ny leverantör. Det hårda problemet är att reglerna inte kan ställas in på djupet, och på sikt kommer regelbiblioteket att hamna på efterkälken jämfört med CodeRabbit.

Cursor Bugbot är en stark utmanare i kategorin. Den är som klippt och skuren för team som redan kör Cursor som IDE och som har en tydlig bild av sina egna regler för review-prompter. Bugbot utnyttjar Cursor-indexeringen av kodbasen för att ge kommentarer som sitter närmare den faktiska affärslogiken. Schwachen är dock att den är hårt knuten till Cursor-ekosystemet: utanför Cursor tappar den mycket av sin kontextförståelse, och stöd för språk utanför TypeScript/Python är fortfarande tunnare än CodeRabbit.

Egen driftsatt modell via AWS Bedrock eller Vertex AI passar organisationer inom telekom, finans och healthcare med hårda krav på datasuveränitet och intern compliance (motsvarande EU-regelverk som GDPR och NIS2, eller japansk 個人情報保護法, amerikansk HIPAA och SOC 2). Ett praktiskt upplägg är att routa PR-differ till en Claude- eller Llama-instans i ett privat subnet, köra en enkel review-prompt i CoT-stil (“sammanfatta diffen → klassificera risk → föreslå åtgärd”), och returnera kommentarer som skrivs tillbaka till GitHub via en webhook. Fördelen är full kontroll över data och modell; nackdelen är att hela underhållslasten – modelluppdateringar, prompt-iterationer, evalueringsdataset – ligger kvar i det egna teamet. En tumregel som stämmer väl på AT&T, Verizon, NTT, KDDI, Deutsche Telekom, Telefónica, Vodafone och andra stora operatörer: först när PR-volymen stadigt ligger över 500 per vecka och det finns en utsedd plattformsägare lönar det sig att bygga något eget. Innan dess är CodeRabbit i praktiken omöjligt att slå på pris/prestanda.

Pull Request-triggade Actions i kombination med ett regelbibliotek passar team som redan har en mogen CI/CD-pipeline och som vill ha full kontroll över reglerna. Upplägget är inte särskilt komplicerat: en workflow som lyssnar på pull_request, anropar Claude Code, Codex eller Gemini via API, och returnerar kommentarer via GitHub Checks API. Det går utmärkt att lägga in en CoT-prompt, hämta regler från en intern Confluence-sida eller ett dedikerat repo, och köra mot en specifik uppsättning filer (t.ex. services/billing/**). Begränsningen sitter i kontextfönstret: stora monorepon över 200 filer får ofta problem med trunkering, och kommentarerna tenderar att bli generiska om inte reglerna är mycket väl underhållna. I en bank eller ett försäkringsbolag med PCI DSS-omfattning är det här mönstret ofta det enda godtagbara, eftersom granskningen då kan begränsas till exakt de filer som omfattas av compliance.

Sourcery är den starkaste automatiska kodgranskaren i Python-världen: den ger konkreta refaktoreringsförslag redan i pull request-fasen (inte bara felpekning utan faktisk omskrivning) och är särskilt effektiv för typannoteringar och teknisk skuldreduktion. Den är svagare för språkövergripande team — TypeScript och Go har precis kommit ikapp, medan stödet för andra språk är glest.

Cursor BugBot utmärker sig genom att den ser samtalskontexten i Cursor-editorn: den vet vad du och AI:n har diskuterat och kan granska genererad kod mot den diskussionen. Den är oanvändbar utanför Cursor-projekt.

Antigravity Review är Googles inbyggda granskningsfunktion i Antigravity-plattformen, lanserad i november 2025. Den vilar på Gemini 3-modellen och Googles molns efterlevnadsinfrastruktur för företag. Under första halvåret 2026 är den fortfarande under snabb iteration, regelbiblioteket är inte lika djupt som CodeRabbits och pris- och distributionsmodellerna för enterprise-versionen justeras fortfarande.

Verktygsval – prioriteringsordning

Prioritera enligt följande ordning: regelanpassningsbarhet > kvalitet på PR-kommentarer > integrationsdjup > pris. Layer 1-verktyg används under lång tid, så om reglerna inte kan anpassas låser du fast dig i verktygets inbyggda säkerhetsmodell. Dålig kvalitet på PR-kommentarer (där AI-granskaren bara säger “här ser det konstigt ut” utan att förklara varför eller hur det ska fixas) slösar bara på utvecklarnas tid. Integrationsdjupet påverkar onboardningskostnaden. Priset hamnar fyra – inte för att det är oviktigt, utan för att prisskillnaden mellan verktyg i samma klass sällan överstiger 30 %, och de tre första kriterierna skiljer sig mer.

Två vanliga fällor vid verktygsval:

För det första: inom finans, offentlig sektor, försvar och telekom-kärnnätverk är privat drift eller self-hosted en förutsättning för att ens komma in i utvärderingen. Men privat drift är inte slutpunkten – ett granskningsverktyg behöver läsa hela din kodbas (PR-diff plus repo-historik), vilket i praktiken innebär att du lämnar kod till en tredje part. Därför måste detta åtföljas av ett avtal om tredjepartsbehandling (Kinas PIPL §21 om databehandling genom ombud), och enbart teknisk isolering räcker inte.

För det andra: AI pre-review och manuell review är inte ett “antingen-eller”. Kombinationer som CodeRabbit + GitHub Copilot Review (“två Layer 1-verktyg ovanpå varandra”) är norm i stora organisationer. De har olika regler och kompletterar varandra när det gäller vilka sårbarheter de fångar – ett enskilt verktyg har alltid blinda fläckar.

Fem: Uppgradering av kodgranskning i fyra branscher – olika former i olika regelkontexter

Slutsats: Verktygslagret (Layer 1) är delat mellan branscher; processlagren (Layer 2/3) måste designas om per bransch – telekom kräver utrustningssäkerhetsbedömning, finans kräver modellstyrningens tre försvarslinjer + oberoende MVU, tillverkning kräver MES + spårbarhet i leveranskedjan, e-handel kräver fönster för kampanjperioder + riskklassning.

Telekom — uppgradering av granskningsprocessen för abonnemangs- och faktureringsändringar. I en AI-internalutbildningsreflektion från en regional operatör fick jag en bild som fastnade: varje abonnemangsändring måste passera 11 grindar från kod till produktionssättning. AI:n pressade ner själva kodningssteget från 2 dagar till 0,5 dag, men fem av dessa grindar — CAB, algoritmregistrering (eftersom faktureringsmodellen berörs), 等保-utvärdering (MLPS-säkerhetsskyddsbedömning), dataexport (utländsk modell används, så man följer Industri- och informationsteknologisektorns bestämmelser om datasäkerhet (provförordning) med särskild negativ lista för export — PIPL:s standardavtal räcker inte här) samt avstämningsrevision — slukar allt från några dagar upp till en månad vardera. Algoritmregistreringen ensam tar normalt 4–6 månader från materialförberedelse till återkoppling från MIIT — det är den verkliga flaskhalsen. Den totala leveranstiden rör sig knappt.

Riktningen för granskningsuppgraderingen är: Lager 1-verktyget måste kunna identifiera ändringar som rör fakturering, autentisering eller compliance-moduler och automatiskt flagga dem som hög risk, för att sedan routas till en gemensam signering av affärs- och compliance-ansvariga på Lager 2. CAB-grinden gör då bara en andra granskning när förändringen faktiskt berör regulatorisk rapportering. Kärnan i denna väg är att pressa CAB:s kapacitet från 5 000–8 000 ärenden per månad (alla ändringar, inklusive brådskande patcher) ner till 100–200 ärenden per månad där styrning faktiskt behövs (hög risk). Före uppgraderingen satt flaskhalsen i CAB; efteråt är CAB tvärtom den snabbaste grinden, eftersom åtta av de elva förgående stegen har förskjutits till automatiserad eller regelbaserad förhandsgranskning.

Lär dig AI långsamt 036 – Telekom: den dolda smärtpunkten heter inte CAB, utan modellförklarbarhet

I telekombranschen är det mest dolda problemet inte Change Advisory Board – det är modellförklarbarhet. En faktureringsmodell måste kunna redogöra för exakt vilken taxa som ligger bakom varje rad på varje kundfaktura, och så snart ett klagomål når kundtjänst måste AI-modellens beslut kunna spåras tillbaka till källan. Av de tre vanligaste ärendena till kundombudsmannen (nummerportabilitet, faktureringsklarhet och spärr/öppning av abonnemang) kräver samtliga att verksamhetsförändringen har passerat koncernens konsumentskyddsförhandsgranskning innan driftsättning – en granskning som inget CAB kan ersätta.

Finans – uppgradering av granskningen av kreditriskmodeller.

I bankernas kärnsystem följer en kreditriskmodell en strikt, sekventiell väg till produktion: oberoende validering av Model Validation Unit (MVU) → godkännande i modellriskkommittén → affärsenhetens ansökan om tillsynsregistrering → återkoppling från tillsynsmyndigheten → driftsättning efter godkänd registrering. De fem stegen är ordnade i tur och ordning – de kan inte parallelldras. AI-assisterad kodning ger påtaglig tidsvinst i ett mycket smalt segment (skriptgenerering, kod för feature engineering, datapreprocessning), men varje ändring rör sig i direkt anslutning till regulatoriska gränser. Att flytta etiketter, features, tröskelvärden eller modellvikter utlöser kravet på “väsentlig modellförändring som kräver förnyad registrering” enligt artikel 24 i Measures for the Administration of Internet Loans by Commercial Banks jämte CBIRC:s order nr 9/2020. Riktningen för granskningsuppgraderingen: Layer 1 måste kunna identifiera ändringar i features/etiketter/tröskelvärden/modellvikter och tvångsstyra dessa mot en högriskväg; Layer 2 kräver dubbelsignatur av en kreditriskansvarig med affärsförståelse och en datakompliansansvarig, där MVU är organisatoriskt fristående från både affärs- och IT-sidan (ett hårt krav enligt CBIRC order nr 9/2020); Layer 3 löper genom modellvalidering, EAST-datainrapportering, 1104-rapportering, PIPL-konsekvensbedömning samt algoritmisk rättvisegranskning (variabler som kön, ålder och geografi får inte användas som inputs).

Ett verkligt smärtfall: efter att en aktieägd bank driftsatte ett AI-verktyg för feature engineering, ökade kön för modellvalidering från 8 till 12 veckor. Model Validation Unit (MVU) måste gå igenom varje enskild AI-genererad feature och kontrollera PSI/CSI-drift, och samarbetet mellan MVU och datakomplanssteamet är trögigt. MVU behöver se de ursprungliga featurefördelningarna, men datakomplans blockerar åtkomsten till kundnivådata enligt Kinas personuppgiftslag (PIPL). Den enda framkomliga vägen är en “modellvalideringssandlåda + anonymiserade aggregerade features” – en trång passage. Bemanna Lager 2 innan ni ens pratar om verktyg. Ett verktyg är bara så starkt som de människor som kan granska det; utan personal som förstår både verksamhet och regelverk och kan göra spot-checks blir alla eskaleringsprocesser luftslott.

Tillverkning – uppgraderad granskning av MES-processändringar. Inom tillverkningsindustrin är AI-assisterad kodning oerhört lockande – linjeintegration, kvalitetsinspektionsmodeller, processchedulering – men varje MES-förändring riskerar att röra vid säkerhetsförreglingar, och en justering av en enda processparameter kan stoppa en hel produktionslina. Tillverknings-know-how är djupare än vad ytan visar: ändringar som berör OEE-förreglingar (Overall Equipment Effectiveness), SPC-diagram (Statistical Process Control), batch-spårbarhetslogik och retur-/påfyllnadsflöden är alla högrisk – det räcker inte att bara titta på procesströskelvärden. Riktningen för uppgraderad granskning: Lager 1 måste flagga allt som rör säkerhetsförreglingar, OEE, SPC eller batch-spårbarhet som högsta risk och förbjuda automatisk merge; Lager 2 kräver gemensam sign-off av både processingenjör och säkerhetsingenjör; Lager 3 kör pilot- och canary-fas (först småskalig testning på en enskild linje, verifiering att inga sidoeffekter på säkerhetsförreglingar uppstår, sedan stegvis utrullning). Flaskhalsen i denna bransch sitter i Lager 2-människorna: erfarna processingenjörer är en bristvara, deras tid äts upp av daglig produktion, och en uppgraderad granskning är i praktiken en omfördelning av resurser – att flytta deras uppmärksamhet från rutinmässiga ronder till noggrann granskning av högrisk-PR:er.

E-handel – hårdare granskning inför stora kampanjer. Inom e-handel ger AI-assisterad kodning störst effekt (landningssidor, marknadsföringsregler, dashboards, rekommendationslogik), men kodändringar under storskaliga kampanjer som Singles’ Day, Black Friday och Prime Day berör transaktionsflöden, bedrägeriskontroller och ekonomisk avstämning – ett enda misstag kan kosta hundratals miljoner kronor. Riktningen för uppgraderad granskning: Layer 1 måste flagga allt som rör kampanjrelaterade moduler, kuponger, flash-rea eller lager som högsta risk; Layer 2 kräver gemensam sign-off av både affärsägare och riskägare; Layer 3 kör canary-release och fullständig lasttestning av hela transaktionsflödet. Det som gör e-handel speciellt är kampanjfönstren: under två veckor före och efter dessa toppevenemang är granskningsstandarden strängare än normalt – samtidigt som granskningskapaciteten är som mest nedprioriterad av pågående produktion. Bästa praxis i branschen är “avslappnat i fredstid, stramt i krisstid”: en vecka innan kampanjfönstret inleds låses alla högriskändringar, och endast buggfixar accepteras; granskningskapaciteten koncentreras på den uppdämda backloggen av låsta ärenden, så att inga högriskändringar slinker in under själva kampanjfönstret.

Genom att titta på de fyra branscherna framträder en tydlig bild: kärnan i en uppgraderad AI-granskning handlar inte om att köpa nya verktyg, utan att rita om riskdirigeringen. Varje bransch har sina egna routningsvillkor på Layer 2/3 – telekom kräver Change Advisory Board + algoritmregistrering (Kinas algoritmregistrering, jämförbar med EUs AI Act-konsekvensbedömning) + modellförklarbarhet, finans kräver oberoende Model Validation Unit + modellvalidering + EAST-ramverket (Elektronisk systemrisk- och kontrolltestning, Finansindustrins regulatoriska standard) + algoritmisk rättvisa, tillverkning kräver pilotkörning + kanarienedsläpp + OEE/SPC-uppföljning, e-handel kräver “lockdown” inför stora kampanjperioder. Men logiken i Layer 1-verktygen kan återanvändas: att identifiera hög risk, märka automatiskt och tvinga fram routning. Det är fullt möjligt att köpa in en eller två uppsättningar Layer 1-verktyg som delas mellan branscherna – men processerna måste designas om branschanpassat.

Sex lärdomar för beslutsfattare

Självgranskning i backspegeln – litar ditt team mer eller mindre på AI-leveranserna nu jämfört med för sex månader sedan? Hur granskas era AI-PR:ar – 100 % manuell granskning, riskbaserad sampling, eller smygs de igenom? Hur många gånger har din Layer 3-routning triggats det senaste halvåret? Hur många av dessa gånger hittades faktiska problem respektive incidenter? Om styrelsen inte kan få fram de tre siffrorna är din AI-styrning inte mer än papperskomplians.

Lärdom ett: Att höja kodgranskningsnivån handlar om organisatorisk utveckling – inte teknikinköp. CodeRabbit Pro kostar 24 USD per plats och månad (Pro Plus 48 USD, debiterat per utvecklare som skapar PR), vilket för ett team på 200 personer landar runt 58 000 USD per år, och företagslicenser kan bli tre till fem gånger dyrare – ändå bara småpengar jämfört med en forskningsbudget på miljonbelopp. De tunga investeringarna sitter i att bemanna Lager 2 med rätt roller och rita om processerna i Lager 3. Det går inte att köpa loss med budget; det kräver att organisationen faktiskt vill anpassa sig, och att seniora utvecklare är beredda att avsätta tid till granskning. De som inte får fart på sin granskningsmodell närmar sig frågan som ett vanligt IT-projekt: dela ut licenser, rulla ut verktyget, sätt upp KPI:er. De som driver förändringen sätter istället cheferna för utveckling och compliance runt samma bord för att tillsammans definiera PR-routingregler. Det är en budgetsignal som flyttar styrningen från kostnadsställe till bandbreddstillgång – först då börjar budgeten vandra från ”köp fler licenser” till ”fyll på granskningsbandbredd”.

Lärdom 2: Innan ni sätter autonoma agenter i produktion måste AI pre-review vara på plats. Detta är baksidan av devisen “montera bromsarna innan ni pratar om motorn”: autonoma agenter (Claude Code, Codex och liknande) kan själva ändra ett tiotal filer, öppna pull requests och köra shell-kommandon. Innan den kapaciteten släpps lös måste Lager 1 kunna identifiera vilken modul som rörs, vilka gränser som passeras och tvinga fram routning till rätt nivå. Föreslagna kvantitativa kriterier för “på plats”: Lager 1 ≥95 % automatisk merge-genomströmning, Lager 2 ≥20 % stickprovstäckning, och noll P0-incidenter tre månader i rad. Carlinis exemplar med den 100 000 rader stora Rust-baserade C-kompilatorn ligger närmare än ni tror – en autonom agent kan leverera ett produktionsklart projekt på två veckor, men kan också ackumulera 20 000 produktionsklara risker på två veckor i en organisation utan recension. Ett annat mer jämförbart branschexempel är Stripes agent “Minions”, som varje vecka merge:ar runt 1 300 PR – noll handskriven mänsklig kod, enbart mänsklig review. AI producerar allt, människor granskar bara; det är definitionen av en recensionsuppgörelse som faktiskt fungerar.

Insikt 3: Både vinsterna och förlusterna med upphöjd kodgranskning måste räknas i samma bandbredd som arbetsbelastningen.

Låt oss omdefiniera “granskningsbandbredd” – det handlar inte bara om mantimmar vid skrivbordet, utan om hela organisationens samlade förmåga att identifiera, routa och hantera risk. Den del som CodeRabbit-rapporten beskriver – att automatiskt fånga de flesta uppenbara problem – är bara en bit av ekvationen. Om AI ska göra verklig nytta beror det på huruvida den återstående delen, den dolda risken (arkitekturpassning, regelefterlevnad, affärsmässig korrekthet), faktiskt får tillräckligt med mänsklig kapacitet i Layer 2/3.

Det vanligaste misslyckandet vid upphöjd granskning är att låta AI:ns pull requests auto-merga. I jakten på att “visa AI-effektivitet på pappret” smalnar man tyst av reglerna i Layer 1, sänker Layer 2 till 5 % stickprov, och låter Layer 3 bli en pappersprodukt. Kortsiktigt ser siffrorna bra ut; långsiktigt skjuter incidentfrekvensen i höjden – snabb AI-produktion + slappare granskning skapar teknisk skuld proportionellt. Den dubbla varningen från CodeRabbit (1,7× fler defekter) och Apiiro (322 % fler privilegieeskaleringshändelser) illustrerar det samlade priset av en sådan uppluckring – det är inte en enskild punkts misslyckande, utan hela systemets. Granskningsbandbredden måste växa i takt med PR-volymen. Tappar man proportionen tappar man kontrollen.

30-dagars implementationschecklista (den detaljnivå du behöver för att veta “vilket möte som ska hållas på måndag och vilken fil som ska ändras”):

Vecka 1: Kartlägg befintliga routningsregler för pull requests och rödmarkera dem i fyra kategorier: “schema-/auth-/billing- och complianceändringar”. Plocka fram hur många gånger Layer 3 har triggats de senaste 90 dagarna samt genomsnittlig kötid – det blir er baslinje.
Vecka 2: Rulla in ett Layer 1-verktyg (välj ett av CodeRabbit eller GitHub Copilot Review, sålla bort alternativ som inte stödjer privat drift). Konfigurera reglerna. Lägg till en manuell risknivå-kryssruta i PR-mallen.
Vecka 3: Sätt ihop listan över Layer 2-affärsägare och compliance-ägare, definiera spot-check-urvalsfrekvens (rekommenderat 20–30 %) och fyll i CODEOWNERS-filen per modul och ansvarig.
Vecka 4: Lyft upp fem nyckeltal i PMO:s veckorapport: genomsnittlig granskningstid för PR, andel misslyckade changes, andel defekter som slinker igenom efter granskning, genomsnittlig kötid för Layer 2/3, samt antal compliance-incidenter som triggas via Layer 3-routing. Sätt samtidigt dessa tröskelvärden som formella krav för att autonoma agenter ska få grönt ljus: Layer 1-genomströmningsgrad ≥95 %, Layer 2-stickprovstäckning ≥20 % samt tre månader i rad utan P0-incidenter.

Följ upp med rätt mått: genomsnittlig granskningstid per PR, andel misslyckade ändringar, andel defekter som slinker igenom efter granskning, genomsnittlig kötid i Layer 2/3, antal compliance-händelser utlösta av Layer 3-routing, samt kötid för modellvalidering. I slutet av AI173 konstaterades att många storföretag rapporterar AI-kodnings-ROI uppåt med hjälp av mått som “andel utvecklare som täcks” och “antal sälda licenser”, och det är just de siffror som gömt de verkliga flaskhalsarna. När dessa indikatorer lyfts upp i styrelserapporteringen – i stället för seat counts och kodrader – flyttas budgeten från “köp fler licenser” till “fyll ut granskningsbandbredden”.

Shadow AI måste hanteras parallellt. UpGuards rapport från 2025 mäter “anställda globalt som använder icke-godkända generativa AI-verktyg” – inte bara utvecklare. Cirka 80 % av de anställda uppger att de använder AI-verktyg som inte är godkända av IT, och affärsenheter kringgår IT och skriver kod i ChatGPT på egen hand – det är vad compliance-ansvariga just nu har mest huvudvärk av. Att uppgradera styrningen utan att samtidigt hantera shadow AI blir som att kontrollera “deklarerade vapen” men inte “odeklarerade vapen”.

Ej tillämpliga scenarier: Om ditt team är färre än 50 personer, inte verkar inom 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 slutsatserna i den här artikeln inte direkt. Skippa strukturen och nöj dig med två lager: lager 1-verktyg plus riktade spot-checks.

Nästa steg

Nästa artikel (AI175) handlar om verktygslagret: AI-verktygskriget är i praktiken över 2026, men det är en helt annan fråga om vinnarna faktiskt går att använda. Det handlar om duon på tronen (Claude Code / Codex), Copilot som hålls kvar av inköpströghet och Antigravity som fortfarande är i startgroparna, och om hur styrförmåga avgör vem som får använda vad och på vilken nivå. AI174 ger strukturen för en revisionsuppgradering, AI175 ger strukturen för verktygsval. Tillsammans ger de dig helhetsbilden av ”vad händer med organisationen när AI börjar skriva koden”.

Efter den här artikeln rekommenderar vi att du även läser avsnitt tre i AI173 (bedömningen av den nya flaskhalsen) plus avsnittet ”De fyra verktygen” i AI175 (kopplingen mellan styrförmåga och verktygskapacitet). Tre centrala slutsatser, spridda över tre artiklar.

Vill du omsätta dessa insikter i ditt eget företag?

Lär dig AI långsamt #021 — Diagnostik av AI-kodgranskningsflödet i storföretag

När AI-programmeringsverktyg på allvar letar sig in i en organisation, brukar de verkliga problemen handla om helt andra saker än själva verktyget: huruvida befintliga code review-processer över huvud taget klarar den volym AI genererar, hur mycket Layer 2-personal som krävs (räknat i PR-volym / antal moduler / FTE-andel), om Layer 3-processen med Change Advisory Board och regulatorisk anmälan (Kinas algoritmregistrering) behöver designas om, och vilka KPI:er som ska styra piloten.

Diagnostisk ingång: Börja med fem mätvärden för teamet — genomsnittlig granskningstid per PR, andel misslyckade ändringar, andel defekter som slinker igenom granskning, genomsnittlig kötid i Layer 2/3, samt antal compliance-händelser som triggas av Layer 3-routing. Om du inte kan ta fram ett enda av dessa fem tal är du inte redo att rulla ut ett AI pre-review-verktyg.

För närvarande erbjuds tre samarbetsspår:

Företagsintern utbildning: Med utgångspunkt i bolagets egna projekt bygger vi igenom hela den treskiktade AI-granskningsmodellen — verktygsval för Layer 1 (utvärderat längs fyra dimensioner: privat driftsättning, anpassningsbarhet av regler, integrationens djup och pris; verktyg som CodeRabbit, GitHub Copilot Review, Cursor eller Claude Code), omdesign av Layer 2/3-flöden, samt ett samhörande målstyrsystem. Leveransen består av: ① teammognadsbedömning (mättnad i granskningsbandbredd), ② implementationsfärdplan för treskiktsmodellen (3–6 månader), ③ beslutsträd för verktygsval i Layer 1, ④ utkast till mätdashboard. 3 dagar, ca 90 000 RMB.

Specialkonsulting: Fokuserar på ett konkret beslut – till exempel att utvärdera om CodeRabbit ska införas, hur en trestegsgranskningsmodell ska landa i en hårt reglerad miljö (finanssektorn: MVU-oberoende + spårbar kedja / telekombranschen: algoritmregistrering + 12300-klagomålshantering), eller hur befintlig CAB-kadens ska ruttas om för AI-PR-förändringar (Change Advisory Board). Debiteras per beslutstema (5–15 timmar per konsultpaket), leveransen = beslutsprotokoll + implementationschecklista + 1 veckas uppföljning. ¥5K/timme.

1V1-coaching / privat styrelseforum: För vice presidenter, direktörer och seniora ingenjörer som “vill investera seriöst i sin egen utveckling” – du använder redan AI-kodverktyg och vill bygga upp din egen bedömningsförmåga kring granskningsuppgradering, teamstyrning och tvärfunktionellt politiskt spel i din organisation. 12 sessioner / 6 månader, debiterat per tema, leveransen = coaching-samtalsanteckningar + periodisk handlingsgenomgång. ¥180K–360K.

Ledarskapsdelning och branschföreläsningar: Kretsar kring AI-granskning, organisationsstyrning, företags AI-transformation och förändring av mjukvaruteknik. Halvdag / heldag, anpassat efter värdens behov.

Artiklarna erbjuder generella ramverk. Faktisk implementering måste dock utformas med hänsyn till företagets datagränser, regulatoriska krav, tekniska mognad och befintliga granskningsprocesser. För samarbeten, kontakta coach@iaiuse.com.

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

Om serien

“AI-eran förändrar mjukvaruteknik” är en forskningsinriktad serie riktad till CIO:er, CDO:er, CTO:er och digitaliseringsansvariga inom telekom, finans, tillverkning och e-handel. Fokus ligger på hur AI-kodningsverktyg påverkar mjukvaruleveransprocesser, organisationsstrukturer, styrningsmekanismer och ledningens nyckeltal.

Bakom denna kanal finns ett litet team – jag själv och 1–2 långsiktiga kollegor som delar upp arbetet mellan sig: forskning kring AI-kodningsverktyg, kartläggning av organisationsstyrningsfall och coachningssamtal. De flesta projekt som vi beskriver som “vi har stöttat företag igenom” har vi levererat tillsammans.

Serien följer löpande akademisk litteratur, leverantörsmaterial och branschrapporter. Forskningsbiblioteket omfattar över 200 källor, och vi märker centrala påståenden med evidensnivå för att tydligare skilja mellan verifierade fakta, leverantörsuttalanden, branschobservationer och författarens egna resonemang.

Jag har närmare 8 års erfarenhet av konsultverksamhet och affärsanalys i stora företag, bland annat från IBM, där jag deltog i projekt inom telekom, finans, försäkring och tillverkning. Därefter har jag fortsatt i frontlinjen hos operatörer, internetproduktbolag och AI-applikationsutveckling, med ansvar för kravanalys, produktdesign och tvärfunktionell implementering.

Referenser (källa per post + bevisnivå + partsbeteckning)

CodeRabbit State of AI vs Human Code Generation Report (2025-12-17, primärkälla, leverantörsperspektiv): Analyserar 470 öppna GitHub-PR:er (AI vs manuellt skrivna, inte matchade på filstorlek/komplexitet). Totalt antal defekter 1,7× (i snitt 10,83 vs 6,45 per PR); säkerhetsbrister per underkategori 1,57–2,74× – XSS 2,74×, felaktig hantering av hemligheter 1,88×, osäkra direkta objektreferenser 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, med öppet redovisade urval och metodik. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / The Register 2025-12-17.
Apiiro 2025.9.4 (leverantörsperspektiv): Skanning av kodbasan hos ett Fortune 50-företag (dataperiod 2024.12–2025.6). 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), privilegieeskaleringssårbarheter +322 % (absoluta tal), designbrister på arkitekturnivå +153 %; normaliserat mot kodvolymens tillväxt uppskattas ökningen till ungefär 60–80 %. Syntaxfel minskade med 76 %, logiska buggar med 60 %. Rapporterat av The Register, Cloud Security Alliance Labs och SiliconANGLE.
JetBrains AI Pulse Survey 2026.1 (primärkä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 (februari 2026, förstahandskälla): cirka 906 respondenter, når ut till 150 000 läsare; 56 % av seniora ingenjörer uppger att över 70 % av deras ingenjörsarbete är beroende av AI-verktyg (självskattad tung användning, inte andel kodrader); Claude Code är den mest omtyckta med 46 % (mot Cursor 19 %, Copilot 9 %); i företag med färre än 10 000 anställda väljer 75 % Claude Code, i företag med fler än 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 mellan maj och september 2025 har skapat (author) över 1 miljon pull requests på fem månader; 80 % av nya utvecklare använder Copilot inom sin första vecka. “40–60 % PR-inblandning” är en branschuppskattning, inte direkt data från Octoverse. Sammanställt av GitHub Engineering Blog och The New Stack.
Stripe Minions (mars 2026, förstagångskälla): Stripes agent “Minions” mergear ungefär 1 300 PR varje vecka, med noll rader mänskligt skriven kod (endast manuell code review) – AI:n producerar allt helt automatiskt medan människor enbart granskar, och det är kännetecknet för modellen. 500+ MCP-tools, AWS EC2 devbox, Block Goose branchstrategi. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents / InfoQ-rapport 20 mars 2026.
Anthropics Skills-system (2026.1, förstahandskälla, leverantörsperspektiv): Anthropic har publicerat designdokumentationen för Skills – kärnan är modulär uppgiftsförmåga (modulära mappar som lär Claude specifika uppgifter, uppbyggt kring skill-filer och progressiv kontextinladdning) och har inget med PR-routing att göra. Den PR-riskroutning som är vanligare i branschen sköts av GitHub/GitLabs branch protection i kombination med CODEOWNERS-regler – PR:er routas baserat på filsökväg och Codeowner. Källa: Anthropic Engineering Blog.
Carlini / Anthropic (jan–feb 2026, nivå 1, förstahandsforskning): Nicholas Carlini, forskare på Anthropic, lät 16 stycken Claude Opus 4.6-agenter arbeta parallellt i två veckor – cirka 2 000 sessioner och runt 20 000 dollar i API-kostnad – och fick dem att från grunden skriva en Rustbaserad C-kompilator på 100 000 rader, som kompilerar Linux 6.9 (x86/ARM/RISC-V) och klarar 99 % av GCC torture test. Studien är sluten forskning som inte är produktionssatt och saknar review-mekanism. Rapporterad av The Register (9 feb 2026) och Ars Technica (feb 2026).
METR 2026.2 uppdaterad studie (primärkälla, ej verifierad): Tidigare studie omfattade 16 seniora utvecklare och 246 verkliga uppgifter med Cursor Pro + Claude 3.5/3.7 Sonnet. Resultaten visade att AI gjorde arbetet 19 % långsammare (95 % KI 2–39 %), medan utvecklarna själva upplevde att de var 20 % snabbare. Den uppföljande studien från februari 2026 innehåller en delvis motstridig bild (nya utvecklare −4 %, och vissa av de seniora utvecklarnas resultat går åt andra hållet). Uppgifterna bör korskontrolleras mot METR:s originalrapport. https://metr.org/blog/2026-02-24-uplift-update
Microsoft FY26 Frontier Suite / EY-fallet (förstahandskälla, leverantörsperspektiv): EY rullade ut Microsoft 365 Copilot till 150 000 medarbetare och rapporterade 15 % produktivitetsökning (motsvarande 14 timmar per person och vecka, omfördelade till kundleverans och lärande); därefter utökades satsningen till över 400 000 medarbetare. I ett finansiell drift-scenario byggt på Microsoft Power Platform och Copilot Studio minskade ledtiden från start till färdig process med 95 % och driftskostnaderna med 37 % (avser enbart det specifika finansiella driftscenariot, inte hela organisationen). Microsoft Customer Story 25760 / FY26 investerarsida.
Atos Agent 365-utrullning (juni 2026, förstahandskälla, leverantörsperspektiv): Atos har rullat ut Microsoft 365 Copilot till 56 000 medarbetare globalt (54 länder) och hanterar 19 000 interna AI-agenter via Agent 365. Atos beskriver själva att “styrning och säkerhet är den första grinden för agentbaserad AI”. Microsoft News 9 juni 2026 / CDO Magazine.
Autonom agentkapacitet hos Anthropic Claude Code / OpenAI Codex (förstahandskälla, leverantörsperspektiv): Claude Code kan självständigt ändra ett tiotal filer, köra shell-kommandon, hantera Git och skicka pull requests; Codex kan låta flera subagenter arbeta parallellt i isolerade kopior och sedan slå samman resultatet. Anthropics / OpenAI:s tekniska dokumentation.
CodeRabbit – bolagsöversikt (2025–2026, primärkälla): Ledande inom AI-baserade kodgranskningsverktyg på GitHub Marketplace; Series B i september 2025, värdering runt 550 miljoner USD; ARR-tillväxt nära 10× under 2025–2026, upp till cirka 40 miljoner USD (Q2 2026, Sacra-data); Pro 24 USD/plats/månad, Pro Plus 48 USD/plats/månad (baserat på antal 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, vendor-perspektiv): Officiell dokumentation och produktsidor för respektive Layer 1-granskningsverktyg; jämförbara dimensioner som täckning, anpassningsbarhet av regler och integrationsdjup. Antigravity GA 2025-11-18, rapporterat av VentureBeat / PCMag.

Code reviews ursprung (nivå 1)

Två huvudlinjer går att spåra:

① Weinberg 1971. I The Psychology of Computer Programming myntade Gerald Weinberg begreppet egoless programming – en ansats där kod granskas utan prestige och auktoritet. Weinberg var knuten till NASA Goddard Space Flight Center och undervisade vid University of Nebraska; han var alltså inte en del av IBM.

② IBM Fagan Inspections. Michael Fagan formaliserade 1976 den strukturerade inspektionsmetoden internt på IBM, där Fagan själv var anställd.

Dessa två traditioner har sedan utvecklats parallellt och utgör den historiska referens vi behöver för att kunna jämföra AI-driven kodgranskning med klassisk peer review.

Finansiell regulatorisk referens (primärkälla)

För den finansiella sektorn är Commercial Bank Internet Loan Management Interim Measures (China Banking and Insurance Regulatory Commission, Ordinance nr 9, 2020), paragraferna 39–42 om riskmodellstyrning, direkt tillämpliga:

Modellstyrningens tre försvarslinjer: affärsverksamhet, IT samt compliance/revision.
MVU-modellvalideringsenhet (Model Validation Unit) ska fungera oberoende av verksamheten.
Väsentlig modellförändring kräver ny myndighetsanmälan (omregistrering).
EAST (Examination and Analysis System): månatliga inskickningar i batcher.
1104-rapportering: regulatorisk inrapportering enligt PBOC:s format.
PBOC personkreditupplysning plus algoritmisk rättvisegenomgång, med restriktioner för känsliga variabler såsom kön, ålder och geografi.

Om motsvarande regler i EU/NIS2, GDPR, japansk 個人情報保護法 eller amerikansk SOC 2/HIPAA-regi önskas, parallellställs dessa i en separat bilaga – men grunderna i modellstyrningens tre linjer går igen i de flesta jurisdiktioner.

Telekommunikation – regulatoriska primärkällor: MIIT:s algoritmregistreringsförordning (dubbel tillsyn av fakturerings-/finansrelaterade algoritmer); MLPS-säkerhetsbedömning (nivå 2: 30 arbetsdagar / nivå 3: 45 arbetsdagar); 12300-ärendens topp 3 (nummerportabilitet, fakturans leveranssäkerhet, spärrning/öppning av abonnemang); negativlista för dataöverföring utomlands enligt Försöksföreskrifter för datasäkerhet inom industri- och informationstekniksektorn.
PIPL – uppgiftsöverföring till biträde (primärkälla): Artikel 21 + 55 i Kinesiska personuppgiftslagen (PIPL) – biträdesavtal och dokumentationsskyldighet 3–5 år (beroende på bransch).
Stack Overflow 2025 Developer Survey (primärkälla): enkät med 49 000+ utvecklare. Andelen utvecklare som litar på AI-utfallets korrekthet sjönk från 40 % (2024) till 29 % (2025), en nedgång om 11 procentenheter; samtidigt uppger 46 % att de aktivt misstror AI-genererad kod (upp från 31 % 2024). Code churn ökade från 3,1 % (2020) till 5,7 % (2024). https://survey.stackoverflow.co/2025/
Shadow AI (UpGuard 2025, sekundär källa): 80 % av de globala medarbetarna använder ej godkända generativa AI-verktyg (inte bara utvecklare), och 68 % av säkerhetsansvariga erkänner att de har obehörig AI i organisationen. Uppgraderingar av styrning utan motsvarande shadow AI-kontroll är en blind fläck i compliance-arbetet. https://www.upguard.com/resources/the-state-of-shadow-ai
Författarens egna, avidentifierade fallstudier: ① AI-internutbildning för en regional teleoperatör (Q4 2024, retrospektiv av elva flaskhalsar, avidentifierad) ② Uppgraderingsdiskussion om kreditriskmodell för en börsnoterad bank (H1 2025, avidentifierad) ③ Omdesign av granskningsflödet för MES-processändringar i en stor tillverkningskoncern (H2 2025, avidentifierad) ④ Lock-scenariot under en stor e-handelsplattforms kampanjperiod, Black Friday-cykeln 2025 (avidentifierad).
Avidentifieringsnotis: De tele-, bank-, tillverknings- och e-handelsfall som nämns i detta inlägg bygger på författarens erfarenhet av AI-internutbildningar och digitaliseringsarbete inom telekomsektorn, samt på uppföljning av relaterade team, och har avidentifierats. Branschspecifika resonemang utgör typiska problemmönster snarare än redogörelser för specifika kunduppdrag. All återgivning bör ange att materialet är avidentifierat.