Git Bisect och AI: Hitta felet när modellen tappar tråden

Modellernas blinda fläckar

En av de vanligaste fallgroparna när du låter AI skriva kod är "glidande regressioner". Modellen fixar en bugg, men i processen ändrar den logiken i en angränsande funktion. Eftersom felet ligger utanför det direkta fokusområdet, upptäcker du det kanske inte förrän fem eller tio prompts senare.

När detta händer står du ofta inför en gigantisk diff. Att sitta och läsa igenom tusentals rader kod för att förstå vad AI:n ändrade är oerhört tidsödande. Det är här din git-historik blir ovärderlig – om du har använt den rätt.

Förutsättningar: Commits som andningspauser

För att git bisect ska fungera väl med AI-kodning, måste du ändra hur du använder versionshantering.

• Commit efter varje fungerande prompt: Gör inte en commit per "funktion", utan en commit för varje lyckad interaktion med AI:n. Om modellen skrev 100 rader och det kompilerar – commit.
• Låt AI skriva commit-meddelanden: Eftersom du committar frekvent, använd ett verktyg eller en prompt för att låta modellen sammanfatta vad den just gjorde.
• Rena byten: Se till att din byggprocess eller dina linting-regler inte är trasiga halvvägs. Varje commit bör idealt sett kunna bygga och köra tester.

Vanan hänger ihop med varför små diffar vinner: ju mindre varje steg är, desto mer exakt blir svaret du får ut av bisect. En commit som samlar fem promptar pekar bara ut klumpen — du vet fortfarande inte vilken av de fem som bröt något.

Att använda Git Bisect

Säg att appen kraschar när du klickar på "Spara". Du vet att det fungerade i morse. Du har gjort 15 AI-prompts och 15 commits sedan dess.

Du startar bisect-processen så här:

git bisect start
git bisect bad                 # Nuvarande läge är trasigt
git bisect good a1b2c3d        # Commiten i morse fungerade

Git checkar nu ut commiten exakt i mitten. Du kör koden och testar "Spara"-knappen. Fungerar den? Då skriver du git bisect good. Kraschar den? Då skriver du git bisect bad. Git halverar då sökutrymmet igen. Inom fyra eller fem steg (istället för att kolla 15) pekar Git ut exakt vilken commit – och därmed vilken AI-prompt – som orsakade felet.

Automatisera med bisect run

Om du har ett skript (eller ett test) som kan avgöra om koden är trasig eller inte, kan du låta Git sköta hela processen automatiskt. Säg att du har ett test npm run test:save.

git bisect start
git bisect bad HEAD
git bisect good a1b2c3d
git bisect run npm run test:save

Detta är särskilt kraftfullt när du hanterar stora, röriga diffar från AI, eftersom du på sekunder får reda på exakt vilken ändring som bröt bygget. Ofta inser du då att modellen i smyg tog bort en if-sats eller bytte namn på en variabel som användes på annat håll.

Den som spelar roll i praktiken är 125. Låt skriptet returnera 125 när bygget inte går igenom över huvud taget, så skiljer Git på "koden är trasig här" och "jag kunde inte avgöra det". Lägg också märke till 127: det är skalets kod för "kommandot finns inte". Stavar du fel på testkommandot markeras alltså varje commit som dålig, och bisect pekar självsäkert ut den allra första i intervallet.

När en commit inte går att bygga

Med täta commits och AI-genererad kod landar bisect förr eller senare på en commit som varken är bra eller dålig: den startar inte, saknar ett paket eller har ett halvfärdigt API mitt i en omskrivning. Markera den inte som bad bara för att den inte fungerar — då letar Git vidare i fel halva.

git bisect skip                # den här går inte att bedöma
git bisect skip v2.1..v2.3     # hoppa över ett helt intervall

Git väljer då en annan commit i samma spann. Behöver du hoppa över många i rad kan bisect sluta med att peka ut ett intervall i stället för en enda commit. Det är fortfarande långt bättre än att läsa en diff på tusen rader, men det är samtidigt en signal om att dina commits inte går att köra var för sig — vilket är just det som gör bisect trubbigt.

Testet måste misslyckas av rätt anledning

Ett bisect-svar är aldrig bättre än testet du matar in. Det vanligaste sättet att få ett självsäkert men felaktigt svar är ett test som misslyckas överallt: då blir varenda commit "dålig" och Git pekar ut den första i intervallet, som oftast är helt oskyldig.

Kontrollera testet i båda ändarna innan du startar. Det tar en halv minut:

Skriv testet så smalt du kan. Ett test som bara kontrollerar att appen inte kraschar fångar även en helt annan krasch som råkar finnas mitt i intervallet. Du får då en commit som mycket riktigt är dålig — men inte den du letade efter.

Om du tappar bort dig

Under en bisect står du i detached HEAD. Det är lätt att glömma om du blir avbruten och kommer tillbaka en timme senare och undrar varför dina ändringar inte hamnar på grenen.

git bisect log > bisect.txt    # spara det du svarat hittills
git bisect reset               # tillbaka till grenen du stod på
git bisect replay bisect.txt   # kör om från loggen

replay är räddningen när du råkat svara good på en commit som faktiskt var trasig. Du behöver inte börja om från noll: ta bort den felaktiga raden ur loggfilen och spela upp resten.