Storleken på ändringen avgör hur mycket nytta du får av AI-hjälpen. En diff du kan läsa i sin helhet och verifiera på en minut ger dig kontroll. En diff du bara kan skumma ger dig en känsla av produktivitet och en okänd mängd risk. Be om ett steg i taget, med ett tydligt utfall per steg.
Varför stora diffar blir dyra
En stor ändring är inte dyr för att den innehåller mer kod. Den är dyr för att den bryter kopplingen mellan orsak och verkan. När hundra rader ändras samtidigt och något går sönder vet du inte vilken av dem som gjorde det. Du får leta i hela ytan i stället för i det senaste steget.
Det här är inte nytt med AI. Skillnaden är att tröskeln för att producera en stor ändring har försvunnit. Förr kostade fyra hundra rader en eftermiddag, och den eftermiddagen fungerade som en broms: du tänkte igenom strukturen medan du skrev. Nu kostar de tjugo sekunder, och bromsen är borta. Granskningen kostar däremot lika mycket som förut.
Resultatet är en obalans som känns bra i stunden. Genereringen är snabb, granskningen är långsam, och det är frestande att låta granskningen bli ytligare i stället för ändringen mindre.
Vad en lagom ändring är
Ett användbart mått: en ändring är lagom stor när du kan svara på tre frågor utan att scrolla tillbaka.
Om något av svaren kräver ett resonemang är ändringen för stor. Det är ett tecken på att den innehåller minst två beslut som borde ha fattats var för sig.
Så delar du upp arbetet
Ta ett vanligt exempel: du ska lägga till uppladdning av profilbild. Bett om det i ett svep blir det lagring, validering, gränssnitt, felhantering och behörighet i samma diff. Uppdelat blir det fem steg som var och ett har ett tydligt utfall.
Steg 3 är det som oftast försvinner i en stor diff, eftersom det inte syns förrän någon letar efter det. I ett eget steg med ett eget utfall är det svårt att missa.
Prompten som håller ihop stegen
Uppdelningen fungerar bara om modellen också håller sig till steget. Det gör den inte av sig själv — den vill gärna leverera en komplett funktion. Skillnaden ligger i att skriva ut avgränsningen och utfallet i prompten.
Fyra rader som håller ändringen liten
- Uppgiften: exakt ett steg, formulerat i en mening.
- Avgränsningen: vilka filer som får ändras, och vad som uttryckligen ska lämnas.
- Utfallet: hur jag tänker verifiera att steget är klart.
- Stoppet: "gör inget mer än detta — jag kommer be om nästa steg separat".
Den sista raden gör mer nytta än man tror. Utan den fyller modellen gärna på med sådant den bedömer att du "kommer vilja ha ändå", och då är du tillbaka i en stor diff.
Invändningen: blir det inte långsammare?
Fler steg betyder fler rundor, och varje runda har en fast kostnad. Om man bara mäter tiden till första körbara version är stora diffar snabbare. Det är en riktig invändning, och den gäller i två fall: när du prototypar något som ska kastas, och när koden inte ska underhållas av någon.
I allt annat arbete ligger kostnaden inte i att skriva koden utan i att förstå den senare — vid granskningen, vid buggen tre veckor senare, vid ändringen någon annan ska göra. Där betalar små steg tillbaka, för då finns historiken kvar: varje commit är ett beslut med ett synligt utfall.
Rena mekaniska ändringar — byta namn på en variabel överallt, formatera om en fil, uppdatera en importsökväg i trettio filer — är stora diffar som ändå är lätta att granska, eftersom de är enformiga. Blanda dem bara aldrig med en ändring som faktiskt gör något. En omdöpning plus en logikändring i samma commit är den kombination som göms bäst för en granskare.
Att börja i morgon
Du behöver inte lägga om hela ditt arbetssätt. Ta nästa uppgift du tänkt be en modell om, och skriv ned vad första steget är och hur du tänker verifiera det innan du skriver prompten. Det är hela ändringen. Resten följer av att steget faktiskt är litet nog att kontrollera.