Verktygsvalet spelar mindre roll än uppsättningen. Skillnaden mellan de ledande alternativen är liten jämfört med skillnaden mellan att ha en nedskriven projektkontext och att inte ha det. Välj något, sätt upp det ordentligt, byt när du har ett konkret skäl.
Tre kategorier, inte femton produkter
Marknaden ser rörig ut men verktygen faller i tre lägen som löser olika problem. De flesta använder två av dem samtidigt utan att tänka på det.
Komplettering i editorn
Föreslår nästa rader medan du skriver. Lägst tröskel, minst risk, hjälper mest med det repetitiva. Du ser varje förslag innan det blir kod.
Passar: löpande arbete i kod du kan.
Chatt med tillgång till projektet
Du beskriver vad som ska göras, verktyget läser relevanta filer och föreslår ändringar över flera filer. Kräver att du granskar en diff i stället för en rad.
Passar: avgränsade uppgifter som rör mer än en fil.
Agent i terminalen
Kör kommandon, läser utdata, ändrar filer och itererar själv. Störst hävstång och störst risk, eftersom stegen sker utan att du ser varje ett.
Passar: tydligt avgränsade uppgifter med snabb verifiering.
En vanlig uppsättning är komplettering påslagen hela tiden, chatt för det som kräver eftertanke, och agent för avgränsade uppgifter i en gren du kan kasta. De tre konkurrerar inte med varandra.
Vad som faktiskt avgör valet
Modelljämförelser går snabbt ur tiden. Det här gör det inte:
Kontextfilen som verktygen läser
De flesta moderna verktyg letar efter en instruktionsfil i repot och tar med den i varje förfrågan. Filnamnet skiljer sig mellan verktygen, men innehållet är detsamma — och det här är den enskilda åtgärd som ger mest effekt per nedlagd minut.
Utan den filen börjar varje session från noll, och samma diskussion återkommer: ska logiken ligga i tjänstelagret eller i kontrollern, använder vi det biblioteket eller inte.
Vad filen ska innehålla
- Vad projektet gör, i två meningar.
- Språk, ramverk och versioner som faktiskt används — inte de som står i README från 2023.
- Konventioner som inte syns i koden: var affärslogik hör hemma, hur fel hanteras, namngivning.
- Kommandon för att bygga, köra och testa.
- Beslut ni redan tagit och inte vill diskutera om, med en rad om varför.
- Det som uttryckligen är förbjudet: bibliotek ni lämnat, mönster ni slutat med.
En kontextfil som beskriver hur projektet såg ut förra halvåret är sämre än ingen alls. Modellen följer den utan att invända, och du får konsekvent fel svar med hög självsäkerhet. Uppdatera den när ett beslut ändras — det är en rad, och den betalar sig direkt.
Uppsättning som lönar sig
Fyra saker tar en förmiddag tillsammans och påverkar varje arbetsdag efteråt.
Vad du inte ska automatisera
Frestelsen med agentverktyg är att låta dem gå hela vägen. Två gränser är värda att hålla.
Låt inte något commita och pusha utan att du läst diffen. Hela poängen med versionshanteringen är att den är en logg över beslut. En logg full av ändringar ingen granskat är inte en logg, bara historik.
Låt inte något köra mot produktion. Inte databasen, inte driftsättningen, inte migreringarna. Kostnaden för ett plausibelt men felaktigt steg är av en helt annan storlek där.
Om fakta i den här kategorin
Den här guiden nämner medvetet inga modellnamn, priser eller versionsnummer. Sådana uppgifter ändras med några månaders mellanrum, och en guide som listar dem är fel kort efter att den publicerats — utan att det syns på sidan.
När du behöver den sortens fakta: läs leverantörens egen dokumentation samma dag du ska använda den. Fråga inte en modell, och lita inte på en jämförelseartikel utan datum. Det gäller särskilt priser, gratisnivåer och vilka modeller som finns i vilken plan.
Den tredje kategorin — agenter som arbetar självständigt — är den som förändras snabbast och kräver mest av avgränsningen. Den har en egen guide.