En fungerande CI separerar hårda stopplinjer från mjuka signaler. Hårda regler blockerar merge direkt, till exempel trasiga tester, brutna säkerhetskontroller eller en maskinellt definierad ändringsyta som överskrids. Mjuka regler markerar risk som kräver manuell bedömning, till exempel ovanligt stor diff eller oväntad prestandaförändring. Reglerna bör gälla all kod; AI-användning är skäl att vara noggrann, inte något som en pipeline ska försöka gissa från källtexten.
Varför just AI-diffar behöver en tydlig grind
Klassisk CI fångar främst sådant som går att uttrycka som byggfel, testfel och analysresultat. En AI-assistent kan samtidigt lösa huvuduppgiften och föreslå sidoändringar som ser rimliga ut: byta bibliotek, justera felhantering eller flytta logik mellan lager. Om de accepteras utan avgränsning blir både diffen och granskningsytan större.
Det gör granskningen dyrare och mer ojämn. En erfaren reviewer ser många avvikelser, en stressad reviewer ser färre. CI behöver därför bära mer av miniminivån, så att granskningen kan fokusera på beslut i stället för att jaga grundfel.
Team gör ofta alla regler till varningar "så att flödet inte stannar". Resultatet blir att pipeline-signalen tappar betydelse och att varje merge bygger på individuell disciplin. Börja hellre med få hårda regler som verkligen blockerar.
Bygg grinden på risk, inte på vem som skrev raden
CI kan normalt inte avgöra på ett tillförlitligt sätt om en viss rad skrevs av en människa eller föreslogs av ett verktyg. Försök därför inte skapa en svagare eller starkare parallell pipeline utifrån kodens antagna ursprung. Låt samma skydd gälla varje pull request och skärp kontrollerna när ändringen berör riskområden som autentisering, betalning, personuppgifter, databas eller infrastruktur.
Om teamet vill följa upp AI-användning kan det deklareras i pull requesten, men deklarationen ska styra granskning och lärande — inte ersätta tekniska bevis. Testresultat, ändringsyta och obligatoriska godkännanden är kontrollerbara; kodens upphov är det sällan.
Fem hårda regler som bör stoppa merge direkt
Det minsta pipeline-upplägget som fungerar i praktiken
Upplägget ligger i linje med principen i Små diffar vinner: ju mindre ändring, desto lättare blir både automatiserad kontroll och mänsklig granskning.
Gör varningar användbara, inte dekorativa
Varningar behövs för signaler som inte alltid är fel, men ofta betyder risk. Exempel är plötsligt stor kodyta, ny extern dependency eller mätbar prestandaförändring under tröskel för blockering.
Tre regler för fungerande varningar
- Varningen måste vara konkret. Säg exakt vad som avviker, inte bara "kvalitet försämrad".
- Varningen måste vara spårbar. Kräv kort motivering eller länk till beslut i pull requesten.
- Varningen måste kunna städas. Sätt deadline för uppföljning så att varningar inte blir permanent brus.
Varje blockerande regel behöver också en namngiven ägare och en kontrollerad undantagsväg. Ett undantag ska vara synligt, tidsbegränsat och godkänt av någon annan än den som skrev ändringen. Annars blir första falsklarmet lätt början på en permanent avstängd kontroll.
En enkel policytext att klistra in i repot
Alla pull requests ska passera blockerande steg för bygg, analys, test och säkerhet.
Ändringar utanför maskinellt definierad filyta kräver explicit godkännande och tydlig motivering i pull requesten.
Varningar får inte ignoreras tyst: varje varning ska antingen åtgärdas eller dokumenteras med tidsatt uppföljning.
Vid upprepad varning på samma område ska regeln omprövas: antingen skärps till blockerande nivå eller tas bort för att minska brus.
Undantag från en blockerande regel ska vara tidsbegränsade, spårbara och godkännas av en utsedd regelägare.
Införande på två veckor utan att bromsa teamet
Du behöver inte bygga en perfekt pipeline på en gång. Börja med tre hårda regler och en diffvakt. Mät sedan hur ofta reglerna träffar och om de fångar riktiga fel.
Om du redan har en etablerad granskning kan du koppla denna modell till sju frågor per diff och testguidens verifieringssteg. CI blir då förfiltret som säkerställer miniminivån innan den mänskliga granskningen börjar.