AI:n stannar vid PR:n — och det är regeln
Team som diskuterar hur mycket de ska lita på AI i sin utvecklingsprocess ställer vanligtvis fel fråga. Frågan är inte hur mycket — det är till när.
En gräns löser det mesta av debatten: Pull Requesten (PR) — den punkt då din kod lämnar din dator och går in i teamets gemensamma granskningsprocess.
Två felmönster jag ser återkommande
Det första felmönstret är överdriven försiktighet. Team som misstror AI vägrar använda det i närheten av kodbasen. De missar produktivitetsvinster som kommer av att fritt experimentera, skissa och iterera innan något committats. Verktyget används inte — eller används för lite — för att ingen kommit överens om när det är acceptabelt.
Det andra felmönstret är överdriven tillit. Team som förlitar sig för mycket på AI låter det köra genom hela pipeline — generera kod, hoppa över granskning, pusha till staging, driftsätta till produktion — med människor som i bästa fall agerar stämpelmaskiner. Det är inte AI-assisterad utveckling. Det är abdikation.
Båda felen kommer från samma källa: ingen tydlig gräns.
Vad PR:n faktiskt representerar
En Pull Request är det ögonblick då din kod lämnar din dator och träder in i teamets gemensamma process. Det är där individuellt arbete blir kollektivt ansvar. Kodgranskning, automatiserade tester, stagingmiljöer, regelefterlevnadskontroller — det är de grindar din organisation bestämde sig för att de spelar roll.
De byggdes inte för AI. De byggdes för att leverera trasig kod får konsekvenser.
Det förändras inte när AI skriver koden. Om något spelar det ännu större roll. AI producerar output med självförtroende oavsett om det stämmer. Dina kvalitetsgrindar är den sista verifieringspunkten för att det som mergas faktiskt är det som avsågs.
Innan PR:n: full frihet
Fram till att du öppnar PR:n — använd AI hur du vill.
Generera första utkast. Utforska tre olika implementationer av samma funktion och välj den bästa. Diktiera dina krav muntligt och låt AI skriva specifikationen. Iterera på arkitekturbeslut genom att be AI utmana dina antaganden. Låt det skriva boilerplate du annars skulle spendera en timme på.
Allt det sker innan grinden. Inget av det kringgår något.
Det enda villkoret är det som alltid gällt: du förstår vad du committar. Inte varje token AI producerat — men avsikten, strukturen, de potentiella felfallen. Det är inte AI:ns jobb. Det har aldrig varit det.
Efter PR:n: grindar oförändrade
Från det ögonblick du öppnar PR:n tar din befintliga process över. Oförändrad.
Kodgranskning sker för att en kollegas blick fångar saker som automatiserade verktyg missar och som du är för nära för att se. Automatiserade tester körs för att regressioner behöver fångas innan de når användare. Stagingmiljöer existerar för att produktionsbeteende aldrig simuleras perfekt lokalt. Regelefterlevnadskontroller existerar för att din organisation är ansvarig för vad den levererar.
AI får inte hoppa över något av det. Inte för att AI är opålitlig — utan för att de grindar inte är kontrollpunkter för misstro. De är kontrollpunkter för kvalitet.
Misstaget är att tro att snabbare AI-generering innebär att nedströmsprocessen också ska snabbas upp. Det gör den inte. Om AI hjälper dig nå PR:n med bättre kod, snabbare — är PR:n fortfarande PR:n.
Varför regeln fungerar i praktiken
Den är tillräckligt specifik för att följa. Team kan besvara vilken "ska vi använda AI här?"-fråga som helst genom att fråga: är vi före eller efter PR-gränsen? Om före — kör på. Om efter — gäller den befintliga processen.
Den kräver inget nytt policydokument, inget nytt verktyg, inget nytt styrningslager. Den använder den gräns ditt team redan har.
Den skalar. En ensam utvecklare som jobbar på ett personligt projekt har andra grindar än ett team som levererar reglerad mjukvara. Regeln är densamma i båda fallen — den mappar bara till den process du faktiskt har.
Och den skapar rätt ansvarsstruktur. Den som öppnar PR:n äger vad som finns i den. De använde AI, de granskade det, de bestämde sig för att det var redo för teamets process. Det skiljer sig inte från att ha skrivit koden själv. Ägarskapet är identiskt.
Fällan: att använda AI för att simulera grinden
Ett mönster att hålla utkik efter: att använda AI för att generera kodgranskningen, skriva testresultaten eller skissa godkännandekommentaren. Det är inte AI-assisterad utveckling före PR:n. Det är att använda AI för att simulera grinden i stället för att passera den.
Grindar existerar för att fånga saker människor missar — inklusive den som skrev koden. Att be AI utföra granskningen av kod som AI genererat stänger en loop som medvetet hölls öppen.
Regeln fungerar bara om grinden är verklig.
PR-gränsen är inte en begränsning av AI-användning. Det är en tydlig linje som möjliggör mer AI-användning — för att utvecklare vet exakt var deras autonomi slutar och deras ansvar börjar.
Det är inte en begränsning. Det är designen.