När AI-assistenter fastnar i koden: Bättre prompting och rätt arkitektur

Det finns ett ögonblick i AI-assisterad utveckling som känns igen. Det som började som smidigt och snabbt går plötsligt trögt. Svaren blir svävande, tokenförbrukningen skjuter i höjden och agenten verkar inte längre förstå vad som efterfrågas.

Felet ligger sällan hos AI:n. Det handlar oftare om hur frågan ställts.

Från smidiga ändringar till stora ombyggnader

AI-verktyg som Claude och GPT-4 är tränade för att göra små, precisa justeringer. De läser kodbasen, följer befintlig stil och respekterar testsviten. Så länge du ber om inkrementella förbättringar fungerar det utmärkt.

När du istället ber om en större omstrukturering av till exempel autentiseringslagret uppstår problem. Agenten ser befintliga tester som heliga. Den försöker bevara så mycket som möjligt av den gamla strukturen. Det som var en styrka vid underhåll blir nu ett hinder.

Det här kallas ibland test hell – där varje test låser fast koden och gör stora förändringar nästan omöjliga.

Tokenkonsumtionen som spårar ur

I praktiken går det ofta till så här:

1. Du ber om en refaktorering
2. Agenten försöker hålla alla tester gröna
3. Den nya arkitekturen stämmer inte med teststrukturen
4. Agenten gör minimala ändringar
5. Du upprepar frågan tydligare
6. Tokenanvändningen ökar snabbt
7. Svaren blir alltmer otydliga

Agenten är inte trasig. Den kämpar med motstridiga instruktioner: ändra allt, behåll allt, rör inte testerna.

Varför det uppstår

AI-assistenterna är tränade på hur riktiga pull requests ser ut. De är bra på att göra små, säkra förändringar i en stabil kodbas. Det är en värdefull egenskap.

Men när projektet behöver större ombyggnad är det inte längre fråga om att underhålla en stabil struktur. Det är evolution. De tester som skrevs för att validera en prototyp är inte längre aktuella. När agenten ändå håller fast vid dem är det inte av dumhet – det är lojalitet mot instruktionerna.

Hur du styr AI:n rätt

Seniorutvecklare ger inte bara order om att "refaktorera och behåll allt". De skapar en designspecifikation. De markerar vilka tester som ska tas bort. De sätter upp tydliga kriterier för slutresultatet.

Här är några arbetssätt som fungerar:

1. Var tydlig med vad som gäller

Säg inte bara: "Refaktorera modulen och håll testerna gröna."

Säg istället: "Vi gör en arkitekturförändring. Dessa tester fasas ut. Här är den nya specifikationen. Dessa acceptanstester gäller nu."

2. Håll isär utforskning och implementation

Låt agenten arbeta i små, tillfälliga grenar för att testa idéer. Bygg prototyper och få feedback. Definiera sedan den stabila arkitekturen – inte samtidigt som du håller fast vid gamla tester.

3. Uppdatera teststrategin

Tests är bra för att skydda funktioner och stabilitet. De är mindre bra som vägledning för ny arkitektur. Ge agenten uttryckligt tillstånd att refaktorera testerna samtidigt med koden.

4. Använd design dokument

Innan stora förändringar skrivs ned vad som ska ändras och varför. Det ger agenten mer kontext än bara kodstil och täckning.

Vad det betyder för AI-assisterad utveckling

Det här gäller särskilt när AI:n står för execution och du ger direction. AI är bra på att implementera när riktningen är klar. Det är när du låter agenten tolka både gamla och nya instruktioner samtidigt som det trasslar till sig.

Sammanfattning

AI-assistenterna är inte dumma. De gör precis vad de är tränade för – små, säkra, incremental changes. När du behöver något annat behöver du också formulera frågan annorlunda.

Fråga dig själv: Ber jag om små ändringar i en stabil struktur, eller ber jag om en ny arkitektur medan jag låtsas att strukturen fortfarande är stabil?