Så bemästrar du kodagenter: 7 tankesätt från ett år i terminalen
Adam Olofsson HammareSammanfattning: En kodagent är inte din underhuggare – den är en ny kollega som dyker upp blind varje morgon. Efter ett år av att arbeta nästan uteslutande via terminalen har jag landat i ett arbetssätt som känns mer som att leda ett litet utvecklingsteam än att skriva kod själv. Här är de sju tankesätt som har gjort skillnaden.
Vad är en kodagent?
En kodagent – tänk Claude Code, OpenAI Codex eller Cursor i agentläge – är en AI som bor i din terminal och arbetar autonomt. Den läser filer, kör kommandon, skriver kod och committar ändringar utan att du behöver klicka i en IDE.
Skillnaden mot vanlig IDE-hjälp:
- Copilot fyller i nästa rad baserat på vad du redan skrivit.
- En kodagent tar ett helt uppdrag, planerar stegen själv och verkställer dem – ibland i flera filer samtidigt.
Problemet är att agenten startar varje session från noll. Den har inget minne, ingen känsla för din arkitektur och ingen aning om var du döpte den där konfigurationsfilen för sex månader sedan. För att få ut det mesta av den måste du tänka som en teamledare, inte som en ensam hjälte.
1. Empati för agenten
Det låter konstigt, men det första du måste lära dig är att se din egen kodbas med nybörjarögon.
När en agent loggar in ser den inte din mentala karta. Den ser hundratusentals rader filer med konstiga namn och ingen vägbeskrivning. Om din kodbas är en röra med förkortningar och dolda beroenden kommer agenten drunkna – precis som en ny utvecklare skulle göra på sin första dag.
Ett verkligt exempel: När jag ber en agent ändra vår databasmodell pekar jag alltid ut tre saker direkt i prompten:
- Modellfilen där schemat definieras
- Migrationsverktyget vi använder
- Testfilen som verifierar ändringen
Utan de pekarna gissar agenten fel, skapar dubbla migrationer eller brutit API:et. Med pekarna löser den uppgiften på tre minuter.
Tips: Ha en tydlig README, konsekventa filnamn och en katalogstruktur som är förutsägbar. Agenten har ingen "doft" av din kodbas – du måste berätta var saker ligger.
2. Korta prompts är zen – men det tar tid att komma dit
Det finns en kurva i agentisk programmering. I början skriver folk långa, detaljerade prompts. Sedan överkompenserar man: orkestreringspipelines, multi-agent-mallar, arton olika slash-kommandon. Till slut landar man ändå i korta prompts igen – men nu av rätt anledning.
Jag kallar det agentfällan. Man tror att komplexiteten i orkestreringen är lösningen, när det i själva verket är att man inte har lärt sig prata med agenten än.
Ett verkligt exempel: Mitt första försök att be en agent bygga en pagineringsfeature tog nästan 40 minuter. Jag skrev en prompt som var längre än den kod som behövdes. Idag skriver jag bara "lägg till paginering i listvyerna" och agenten löser det på fem minuter. Skillnaden är inte promptlängden – det är att jag har lärt mig att lita på agenten.
Tips: Börja konkret och kort. Om något tar för lång tid, tryck escape och fråga dig själv: Förstod agenten problemet? Hade jag fel i min egen arkitektur?
3. Hantera det som en konversation, inte en beställning
Den största insikten för mig var att sluta bete mig som en kund på en restaurang. En kodagent är inte en servitör som tar din beställning och levererar maten tyst. Den är en kollega som du diskuterar problemet med.
När jag recenserar en ändring från en agent börjar jag alltid med samma fråga:
- "Förstår du vad jag försökte åstadkomma här?"
Om svaret är ja, går vi vidare:
- "Är detta det optimala sättet att göra det?"
- "Har du tittat på den delen av kodbassen?"
- "Vad händer om vi gör en större refaktorering istället?"
Det är samma dynamik som en bra pull-request-recension. Intenten kommer först, implementationen sedan.
Ett verkligt exempel: En agent föreslog nyligen att lösa ett buggfix med en ful workaround. Istället för att avvisa den direkt frågade jag: "Kan vi lösa detta mer fundamentalt om vi ändrar hur vi cache:ar data?" Agenten såg omedelbart en mycket renare lösning och refaktorerade hela flödet på tio minuter.
Tips: När något tar onödigt lång tid är det nästan alltid ett tecken på att du inte tillräckligt empathiskt guidade agenten till rätt perspektiv.
4. Acceptera att koden inte blir perfekt
Precis som när man leder ett team av mänskliga utvecklare måste du lära dig släppa kontroll. Agenten kommer inte skriva kod exakt som du skulle gjort. Kanske döper den en variabel till userData istället för userProfile. Kanske lägger den logiken i en annan fil än du föredrar.
Om du andas agenten i nacken på varje detalj kommer den arbeta långsamt och frustrerat – precis som en mänsklig utvecklare skulle göra.
Ett verkligt exempel: Jag brukade byta tillbaka variabelnamn som agenten valde. Resultatet? Nästa gång agenten sökte efter den filen hittade den inte, för den sökte på sitt ursprungliga namn. Nu accepterar jag agentens namnval så länge de är konsekventa. Kodbasen har blivit lättare för agenten att navigera – och därmed snabbare för mig att bygga med.
Tips: Bygg kodbasen för agenten, inte för din estetik. Förutsägbarhet slår perfectionism.
5. Commit till main och fixa framåt
En av de mest kontroversiella sakerna i mitt workflow är att jag sällan revertar. Om en agent introducerar en bugg är det nästan alltid snabbare att be en annan agent fixa den än att rulla tillbaka och börja om.
Jag kör tester lokalt. Om de går igenom – pushar jag direkt till main. Ingen feature branch. Ingen långvarig PR-cykel.
Ett verkligt exempel: Jag kör just nu 3–8 agenter parallellt, var och en i sin egen terminal. En bygger en större feature, en annan utforskar ett koncept jag är osäker på, och två-tre fixar små buggar eller skriver dokumentation till det som just landat. Om en agent bryter något, ber jag helt enkelt en ledig agent att åtgärda det. Refaktoreringar är billiga nu – agenterna löser ut konflikterna på ett par minuter.
Tips: Håll main shippable, men var inte rädd för att röra om. Framåtrörelse slår perfektion.
6. Behåll människan i loopen
Agenter är fantastiska på att skriva kod. Det de inte kan – och förmodligen aldrig kommer att kunna helt – är att känna vibe i en produkt. De små detaljerna som får användaren att le, den unika tonen i felmeddelanden, beslutet att säga nej till en feature för att den skulle späda ut kärnan.
Det är fortfarande mänskligt hantverk.
Ett verkligt exempel: När vår app uppdaterar sig spelar den ett litet ljud och visar ett meddelande. Meddelandet är humoristiskt, lite fjantigt, och det fick en användare att skicka ett kärleksfullt meddelande till supporten. En agent hade aldrig kommit på den formuleringen själv. Den kom från vår produktvision, inte från en prompt.
Tips: Skriv en soul.md eller ett konstitutionsdokument. Förklara din produkts värderingar, din vision, hur du vill att projektet ska kännas. Låt agenten ladda det vid varje session så den inte bara bygger kod – den bygger er kod.
7. Investera tid – det är en kompounderingseffekt
Det första halvåret kändes klumpigt. Jag skrev för långa prompts, rättade agenter i sidled, och undrade om detta verkligen var snabbare än att bara skriva koden själv. Sedan vände det.
Det är en skiljad som måste byggas, precis som att lära sig ett nytt språk eller ramverk. Agenterna blev bättre, mina prompts blev bättre, och min förståelse för hur de ser världen blev bättre. Effekten är exponentiell.
Ett verkligt exempel: Jag började med en minimal prototyp, lekte med den, och lät mitt koncept växa organiskt. Jag hade inte kunnat planera slutresultatet i förväg – varje iteration gav mig idéer som jag inte ens visste att jag skulle ha. Agenter excellerar i det utforskande stadiet.
Tips: Blocka tid för att bara "leka". Bygg något litet, be agenten variera det, kasta bort det, bygg igen. Det är repetitionen som skapar fingertoppskänslan.
Tankar om hur detta påverkar framtiden
Jag tror vi står inför en fundamental förskjutning i vad det innebär att vara utvecklare. Framtiden tillhör inte den som skriver mest kod – den tillhör den som ställer de bästa frågorna, som kan balansera autonomitet med vision, och som förstår att leda en agent är samma sak som att leda ett team.
Den som försöker automatiserar bort sig själv helt kommer missa det. Den som vägrar släppa kontrollen kommer aldrig få fart. Precis som alltid inom teknik är det balansen som är svaret.
