Vi ser ett mönster som upprepar sig. Du bygger din första AI-genererade app, det går fantastiskt, på några timmar finns det en fungerande prototyp och känslan är euforisk. Det kan vara en chef som vill testa om idén håller, en konsult som vill visa en kund vad som är möjligt, eller en analytiker som bygger ett internt verktyg. Gemensamt är att de aldrig riktigt kodat förut och ändå levererar de något konkret på rekordtid.
Sedan kommer komplexiteten. Filen AI:n genererade fungerar, men nästa sak du ber om förstör det du precis byggde. Agenten fastnar i loopar och gör saker du inte bad om. Du försöker återställa det som fungerade. Nu är två saker trasiga. En timme senare vet du inte var du befinner dig, och det roliga börjar kännas som arbete.
Det är inte ett tekniskt problem. Det är ett managementproblem. Och det är en distinktion som förändrar vad du faktiskt behöver lära dig.
Att prompta är en sak. Att managera är en annan.
Det är värt att skilja på två distinkta färdigheter som lätt förväxlas.
Promptning handlar om att kommunicera med ett AI-system i realtid. Du formulerar vad du vill ha, systemet svarar, du justerar, det itereras. Det är ett samtal, och samtal kan de flesta hantera ganska bra.
Agenthantering handlar om att ge ett autonomt system en uppgift och låta det arbeta självständigt mot ett mål. Det systemet fattar hundratals små beslut längs vägen. Och om du inte har skapat rätt förutsättningar från start spårar det ur. Ofta utan att du märker det förrän felet är stort och svårt att backa ur.
Skillnaden är densamma som mellan att ha ett samtal med en kollega och att delegera ett projekt till en ny medarbetare du inte kan följa tätt. I det andra fallet räcker det inte att be om rätt saker. Du behöver ha byggt strukturen som gör att de kan jobba rätt.
Fem saker avgör om det fungerar. Inte fem avancerade saker. Fem grundläggande saker som de flesta missar för att ingen förklarat dem.
Versionskontroll är inte valfritt. De flesta som börjar med AI-agenter jobbar utan versionskontroll. Förståeligt, det tillhör inte den naturliga verktygslådan utanför teknikbranschen. Men det är ett misstag som kostar mer ju längre man väntar.
Utan commits är varje session ett risktagande. Något fungerade i morse. Nu fungerar det inte. Vad förändrades? Du vet inte, och AI:n vet inte heller. Med regelbundna commits kan du alltid gå tillbaka till senaste fungerande läge. Du tappar en timmes arbete i värsta fall, inte en vecka. Tänk på det som att spara ett dokument innan du gör en stor omskrivning. Inte avancerat, men avgörande.
Kontextfönstret tar slut. Varje AI-modell arbetar inom ett kontextfönster, ett begränsat utrymme för aktiv information. I takt med att konversationen växer fylls det på. När det är fullt börjar modellen komprimera och ibland glömma. Svar försämras gradvis. Agenten börjar fatta beslut som verkar logiska för den men obegripliga för dig.
Det hanteras enklare än de flesta tror: starta om. Ta med dig det som är relevant, lämna resten. En ny session med rätt kontext är konsekvent bättre än att hårdnackat fortsätta i en uttömd en. De bästa som jobbar med AI-agenter behandlar kontextfönstret som en resurs att hushålla med, ungefär som batteritid. Du laddar om innan det tar slut.
Instruktioner ska inte behöva upprepas. Det finns ett mönster hos de som jobbat med AI-agenter mer än ett par veckor. De börjar säga samma saker om och om igen. Skriv på svenska. Rör inte den här filen. Commita alltid innan du ändrar något stort.
Det är ett tecken på att de saknar en rules-fil. En fil med stående instruktioner som agenten läser vid start. I Claude Code kallas det CLAUDE.md. Det är platsen för allt som definierar hur projektet ska skötas: arkitektur, namnkonventioner, vilka filer som är känsliga, vad som aldrig ska röras. Skriv den en gång. Uppdatera den när du lär dig något nytt. Det är onboarding för ett system som annars börjar varje session utan minne.
Stora uppgifter går sönder på stora sätt. Det finns en naturlig impuls att ge agenten en ambitiös, välformulerad uppgift och låta den köra. Det är också det snabbaste sättet att hamna i ett läge som är svårt att backa ur. Ju större uppgiften är, desto fler beslut fattar agenten utan ditt godkännande, och desto svårare är det att förstå var något gick fel.
Håll varje uppgift liten nog att du kan granska resultatet och commita innan du går vidare. Det är inte försiktighet, det är metod. De som faktiskt levererar med AI-agenter arbetar nästan utan undantag i täta, korta steg. Inte för att de är rädda, utan för att de vet att det är snabbare på sikt.
Agenten bygger det du ber om. Inget mer. Det är viktigt att förstå vad ett AI-system faktiskt optimerar för. Det löser uppgiften du gav det. Det frågar inte om du tänkt på vad som händer när det går sönder. Det frågar inte om det finns ett säkerhetshål i det du precis byggt. Det frågar inte om lösningen håller när tio gånger fler börjar använda den.
Det är inte en brist i systemet. Det är en design. Men det kräver att du aktivt tar ansvar för de frågor agenten inte ställer. Säkerhet: finns det exponerade nycklar, saknas validering, vad händer om någon testar gränser? Felhantering: vad händer när ett externt system inte svarar, när en användare gör något oväntat? Skalning: är lösningen byggd för den belastning du faktiskt planerar för? Ingen av dessa frågor ställer agenten på eget initiativ. Det är ditt jobb att ställa dem.
Det du redan kan
Det finns en ironi i att de som ibland har svårast att anpassa sig till agenthantering är de som kan mest om teknik. De vet hur systemen fungerar på låg nivå och förväntar sig att kunna kontrollera dem på samma sätt. Det fungerar sämre med autonoma system.
De som klarar sig bäst är ofta de som är vana vid att leda arbete de inte utför själva. De är bekväma med att sätta ramar, delegera, följa upp och rätta kursen längs vägen utan att ta över.
Det är precis vad agenthantering är. Och det är en kompetens de flesta som nått en viss erfarenhetsnivå i arbetslivet redan har. Det enda som krävs är att applicera den medvetet på ett nytt typ av system.
Tekniken förändras snabbt. Grunderna för hur man organiserar autonomt arbete gör det inte.