Git worktrees och AI som beslutsunderlag
Vi stod inför en strikt null checks-migrering på jobbet. TypeScript-kompilatorn pekade ut en drös med ställen i kodbasen där typer inte stämde. Det finns olika sätt att hantera det på, och inget av dem är självklart rätt.
Normalt hade vi diskuterat. Spekulerat vilken approach som var rimligast, försökt föreställa oss hur koden skulle se ut efteråt, och till slut valt en väg på magkänsla. Sen hade vi börjat implementera och hoppats att vi valde rätt.
Den här gången bad jag Claude skanna kodbasen, följa dataflödena, köra tsc och kartlägga var det var fel. Utifrån det skapade Claude tre migreringsplaner i markdown, tre olika strategier för samma problem, med olika trade-offs:
- Den enkla vägen. Strössla null checks överallt. Snabbt, minimalt invasivt, men resulterar i defensiv kod som skjuter problemen framför sig.
- Den grundliga vägen. Följ dataflödena ner till datastrukturerna och fixa dem så att null checks inte behövs. Mer arbete, fler rörda filer, men renare resultat.
- Mellanvägen. En pragmatisk mix. Fixa datastrukturerna där det är rimligt, acceptera null checks där kostnaden att gå djupare inte är värt det.
Varje plan fick en egen git worktree. Tre separata arbetskopior av samma kodbas, redo att implementeras parallellt.
Sedan lät jag Claude implementera alla tre. Fullt ut, tre kompletta migreringar.
Resultaten var inte perfekta. Det krävdes en del manuell granskning och jag hittade ställen där Claude tagit genvägar jag inte hade tagit. Men poängen var aldrig att få tre produktionsklara lösningar. Jag ville ha tillräckligt med substans för att kunna jämföra på riktigt.
Med tre färdiga implementationer kunde jag titta på hur koden faktiskt såg ut istället för att föreställa mig den.
Jag kombinerade AI-baserad review med stickprover. Tittade på antal rörda filer, hur invasiva ändringarna var, och till vilken grad jag var bekväm med resultatet.
Jag vet inte med säkerhet att vägen vi valde är den mest korrekta. Det var inte heller målet.
Vi hade mer att utgå ifrån. Quirks och edge cases som dyker upp längs vägen fångas i implementationen. En diskussion hittar dem inte.