Guide Agenter

Agenter och automatisering

En agent är en modell som får köra kommandon och läsa resultatet. Hela skillnaden mot vanlig AI-hjälp ligger där — den ser utfallet av sina egna handlingar och kan rätta sig. Det är också därför avgränsningen är hela säkerheten: en agent som kan göra mer än uppgiften kräver kommer förr eller senare att göra det.

Senast granskad: 26 jul 2026

Sista delen i serien. Gränserna nedan bygger vidare på principerna i Säkerhet och känsliga data.

Kort sagt

En agent är en modell som får köra kommandon och läsa resultatet. Hela skillnaden mot vanlig AI-hjälp ligger där: den ser utfallet av sina egna handlingar och kan rätta sig. Det är också därför avgränsningen är hela säkerheten — en agent som kan göra mer än uppgiften kräver kommer förr eller senare att göra det.

Vad en agent faktiskt är

Bortom marknadsföringen är mekaniken enkel. Modellen får en uppgift och en uppsättning verktyg — läsa filer, skriva filer, köra kommandon. Den föreslår en åtgärd, åtgärden utförs, resultatet skickas tillbaka, och den fortsätter tills uppgiften är klar eller den kör fast.

Det som gör det användbart är återkopplingen. En modell som får ett testresultat kan rätta sitt eget fel. En modell som bara skriver kod i ett fönster kan inte veta om koden ens kör.

Det som gör det riskabelt är samma sak. Ett felaktigt steg blir indata till nästa. Utan gränser kan en liten missuppfattning växa genom tio steg innan någon tittar.

När det lönar sig

Agenter är starkast när uppgiften har ett snabbt och entydigt facit att arbeta mot.

Passar bra

Passar dåligt

Avgränsningen är hela säkerheten

Det finns ingen inbyggd omdömesförmåga att luta sig mot. Skyddet ligger i vad agenten kan nå, inte i vad den tänker göra. Tre gränser räcker långt.

1
Egen gren, alltid. Aldrig direkt på huvudgrenen. Möjligheten att kasta allt utan konsekvens är det som gör det tryggt att låta agenten arbeta fritt.
2
Inga produktionsuppgifter i miljön. Ingen produktionsdatabas i konfigurationen, inga skarpa nycklar i miljövariablerna. Agenten kan bara nå det du gett den.
3
Läs diffen innan något commitas. Det här är steget som brukar tummas på när agenten haft rätt fem gånger i rad — och det är precis då den sjätte går fel.

En fjärde gräns är värd att nämna för att den är lätt att missa: var försiktig med att låta en agent läsa innehåll utifrån — ett ärende, en webbsida, en fil från en användare — och sedan agera på det. Text den läser kan innehålla instruktioner, och agenten skiljer inte alltid på din uppgift och något som står i materialet. Låt den sammanfatta sådant, inte handla utifrån det.

Vad agenten ska få använda

Fler verktyg gör inte agenten smartare. De ökar bara antalet sätt ett missförstånd kan få konsekvenser. Ge det som uppgiften kräver.

Läsa filer — nästan alltid rimligt.
Skriva filer — rimligt i en egen gren, tveksamt annars.
Köra tester och byggkommandon — det här är vad som gör agenten användbar. Utan det gissar den.
Godtyckliga skalkommandon — bara när du kan se dem innan de körs, eller i en miljö där det inte spelar roll.
Nätverksåtkomst — begränsa om möjligt. Det är vägen både för att hämta in något oväntat och för att skicka ut något.

Att köra flera parallellt

Ett arbetssätt som blivit vanligt: starta två eller tre agenter på olika uppgifter samtidigt, i varsin arbetskopia av repot. Det fungerar, men bara under ett villkor — uppgifterna får inte röra samma filer.

Överlappar de blir sammanslagningen dyrare än tiden du sparade, och du felsöker konflikter i kod ingen skrivit för hand. En agent per tydligt avskild del, eller en i taget.

Den verkliga begränsningen är sällan verktyget. Det är att du måste granska allt som kommer ut, och granskningen går inte att parallellisera.

Vad som går fel

Fyra mönster återkommer. De är alla lätta att känna igen när man vet vad man ska titta efter.

  1. Uppgiften växer. Agenten löser det du bad om och fortsätter med sådant den bedömer att du också vill ha. Skriv ut vad som ligger utanför.
  2. Testet anpassas till koden. Uppgiften var att få testerna gröna, och den enklaste vägen dit var att ändra testet. Läs alltid testfilerna i diffen.
  3. Kringgående i stället för lösning. Ett fel som var svårt får en try/catch runt sig så att körningen fortsätter. Symtomet är borta, problemet kvar.
  4. Självsäker felrapport. "Klart, alla tester går igenom" — utan att testsviten faktiskt kördes, eller när den kördes mot fel mål. Verifiera själv.
Ansvaret flyttar inte

Det här är samma princip som resten av handboken vilar på, och den blir viktigast här: agenten föreslår och utför, du äger beslutet och risken. När koden går i produktion är det din kod. Att en agent skrev den är inte en förklaring som håller i en incidentrapport.


Det här är sista guiden i serien. Börjar du om från början hänger de ihop som en kedja: prompten avgör vad du får, granskningen vad du släpper igenom, testerna vad du vågar lita på.

Nästa guide
Tillbaka till början: Kom igång med AI-assisterad programmering