Myten om 90% AI-kodad — vad "byggt med AI" faktiskt betyder i produktion

Ett växande antal företag tillkännager stolt att deras produkter är "90–95% kodade med AI." Det presenteras som ett hederstecken — ett bevis på innovation, effektivitet och framåttänkande. Konferenstalare citerar dessa siffror till beundransvärt mummel från publiken. Investerare tolkar dem som signaler om en slimmad verksamhet.

Men i produktionsmiljöer väcker påståendet en helt annan uppsättning frågor. Inte "hur imponerande" utan "hur hållbart." Inte "hur snabbt" utan "vem äger det här när det går sönder."

Påståendet låter imponerande

Lockelsen är uppenbar. Om AI skrev 90% av koden gick utvecklingen snabbare. Färre utvecklare behövdes. Produkten nådde marknaden tidigare. För en publik som inte är bekant med produktionsprogramvara antyder dessa siffror en revolution i effektivitet.

Och i vissa sammanhang — prototyper, proof-of-concepts, interna verktyg med begränsad livslängd — kan en hög AI-genereringskvot vara helt rimlig. Problemen uppstår när samma siffror hyllas för produktionssystem som hanterar riktiga användare, riktig data och riktiga konsekvenser.

Frågorna ingen ställer

När någon hävdar 90–95% AI-genererad kod är uppföljningsfrågorna viktigare än rubriken:

Vem granskade det? Varje rad AI-genererad kod kräver samma granskning som mänskligt skriven kod — ofta mer, eftersom AI-genererad kod kan innehålla subtila fel som ser syntaktiskt korrekta ut men är logiskt felaktiga.

Vem förstår det? Att förstå kod innebär att kunna förklara vad den gör, varför den gör det på det sättet, och vad som händer när den fallerar. Om personen som promptade AI:n inte kan besvara dessa frågor är koden ett föräldralöst barn.

Vem felsöker klockan tre på natten? Produktionssystem går sönder. När de gör det måste någon diagnostisera problemet under press, i en okänd kodbas, med användare som väntar. AI-genererad kod som ingen förstår fullt ut blir exponentiellt svårare att felsöka.

Vem underhåller det om sex månader? Krav förändras. Beroenden uppdateras. Säkerhetspatchar behöver appliceras. Underhåll kräver förståelse, och förståelse kräver någon som har läst, granskat och internaliserat koden.

"Du äger varje rad output. Och du kan inte äga det du inte förstår."

Okunnighetens ränta-på-ränta

Problemet med höga AI-genereringskvoter är inte omedelbart. Vecka ett ser bra ut. Koden fungerar. Features levereras. Mätvärden ser bra ut.

Skadan ackumuleras över tid, efter en förutsägbar kurva som organisationer sällan förutser.

Vecka 1–2: Smekmånaden. Features levereras snabbt. Intressenter är imponerade. Teamet känner sig produktivt. Allt fungerar eftersom ingenting ännu har testats av verkligheten.

Vecka 4–6: De första sprickorna. En bugg uppstår i produktion. Utvecklaren som promptade AI:n kan inte förklara den berörda modulen. Felsökningen tar tre dagar i stället för tre timmar eftersom ingen förstår kodens interna logik. Fixen introducerar en ny bugg eftersom utvecklaren ändrade kod utan att förstå dess beroenden.

Vecka 8–10: Kaskaden. Flera teammedlemmar har genererat kod som interagerar på sätt ingen planerade. Integrationspunkter fallerar. Felhanteringen är inkonsekvent eftersom varje AI-genererad modul hanterade fel på olika sätt. Kodbasen har vuxit bortom någons förståelse.

Vecka 12+: Uppgörelsen. Ett kritiskt fel inträffar. Teamet kan inte åtgärda det utan att i princip skriva om de berörda komponenterna. Ledningen frågar hur det här kunde hända när den AI-genererade koden "fungerade perfekt" bara veckor tidigare. Svaret: den hade alltid dessa problem, men ingen förstod koden tillräckligt väl för att se dem.

Det här mönstret är inte teoretiskt. Det utspelar sig i organisationer som behandlar AI-kodgenerering som en ersättning för förståelse snarare än ett komplement till den.

Ägarskapsprovet

Ett praktiskt sätt att bedöma om "90% AI-kodat" är en styrka eller en belastning: kodägarskapsgranskningen.

För varje kritisk modul i systemet, hitta den ansvariga utvecklaren och fråga:

Kan du förklara arkitekturen för den här modulen utan att titta på koden?
Kan du identifiera de tre mest sannolika felpunkterna?
Skulle du kunna skriva om kärnlogiken ur minnet om koden raderades?
Kan du förklara varje beroende och varför det valdes?
Skulle du kunna introducera en ny medarbetare till den här modulen på under en timme?

Om svaret på de flesta av dessa är nej ägs inte koden — den hyrs. Och hyrd kod har en förmåga att vräka ut sina hyresgäster vid värsta möjliga tillfälle.

Vad "AI-assisterad" faktiskt borde innebära

Problemet är inte att AI skriver kod. Problemet är att kvoten hyllas utan sammanhang. Ett mer ärligt ramverk erkänner att AI-assistans finns på ett spektrum, och lämplig nivå beror på vad som byggs.

Strukturerad balans (50–70% AI-assisterad): Utvecklaren definierar arkitekturen, sätter begränsningar och granskar varje betydande output. AI hanterar implementationsdetaljer inom ett ramverk som utvecklaren förstår och kontrollerar. Så här bör det mesta produktionsarbetet fungera — AI accelererar utförandet medan utvecklaren behåller ägarskapet.

Vibe coding (hög AI-generering): Giltigt för throwaway-prototyper, interna experiment och proof-of-concepts där kostnaden för misslyckande är låg och koden har en definierad kort livslängd. Inte giltigt för produktionssystem.

Genomtänkt planering (lägre AI-generering): Komplexa system, säkerhetskritiska komponenter och okänd terräng där varje rad kräver avsiktligt tänkande. AI assisterar med specifika implementationsuppgifter men det är människan som driver designen.

De team som arbetar effektivt med AI hyllar inte höga genereringskvoter. De hyllar förståelsekvoter — andelen av deras kodbas som teamet kan förklara, felsöka och underhålla utan den AI som genererade den.

Organisationens ansvar

När organisationer uppmuntrar eller stimulerar höga AI-genereringskvoter utan motsvarande investering i granskningsprocesser bygger de på en grund som urholkas över tid. De kortsiktiga vinsterna är verkliga. De långsiktiga kostnaderna är också verkliga — och de ackumuleras.

Production-first-tänkande kräver ett annat mätvärde än "hur mycket skrev AI." De relevanta frågorna är: hur stor del av kodbasen förstår teamet? Hur snabbt kan de reagera på fel? Hur säkert kan de göra ändringar utan att introducera regressioner?

"AI föreslår. Jag bestämmer. Jag pushar. Ordningen är oförhandlingsbar."

Ett praktiskt ramverk: kodägarskapsgranskningen

För organisationer som vill gå bortom fåfängemåttet AI-genereringskvot ger en kvartalsvis kodägarskapsgranskning en mer ärlig bild:

Välj ut kritiska moduler — identifiera de 20% av kodbasen som hanterar 80% av risken (autentisering, betalningshantering, datahantering, kärnaffärslogik)
Tilldela ägarskap — varje kritisk modul har en namngiven utvecklare som ansvarar för att förstå den fullständigt
Testa förståelsen — ägaren förklarar modulen för en kollega utan att referera till koden, inklusive felpunkter och beroenden
Dokumentera glapp — där förståelsen är otillräcklig, schemalägg dedikerad granskningstid — inte mer AI-generering, utan mänsklig förståelse
Följ upp över tid — övervaka om ägarskapet stärks eller försvagas allteftersom kodbasen utvecklas

Den här granskningen bromsar inte utvecklingen. Den säkerställer att den utveckling som bedrivs är hållbar.

Slutsatsen

"90% AI-kodat" är inte i sig bra eller dåligt. Det är en kvot som kräver sammanhang. För en helgprototyp kan det vara helt okej. För ett produktionssystem som hanterar kunddata är det en fråga som kräver uppföljning: vem äger den här koden?

De företag som kommer att blomstra med AI är inte de som maximerar sina genereringskvoter. Det är de som maximerar sina förståelsekvoter — som använder AI för att accelerera arbete de begriper och kontrollerar, inte för att producera output de inte kan underhålla.

Det verkliga måttet på AI-mognad är inte hur mycket kod AI skrev. Det är hur stor del av den koden teamet kan stå bakom.

Relaterad läsning: - Tre sätt att arbeta med AI-genererad kod — och varför din mix spelar roll - Bortom prototyper: varför alla demonstrerar men ingen levererar - Varför utvecklaransvar inte kan automatiseras

Utkast — mars 2026 Baserat på mönster observerade i workshops om AI-adoption i företag och produktionsdriftsättningar

Var detta till nytta?