Guide Grunder

Kom igång med AI-assisterad programmering

De flesta som blir besvikna på AI-hjälp i kodning har inte fått ett dåligt verktyg — de har satt det på fel uppgift. Den här guiden går igenom vad en modell faktiskt är bra på när du programmerar, vad du fortfarande måste äga själv, och ett arbetsflöde i fyra steg som håller hela vägen till en granskad och driftsatt ändring.

Senast granskad: 26 jul 2026

Fyra mörka metall- och glasmoduler står i rad. Gröna ljuspunkter blir allt mer ordnade och slutar i en lysande kärna, medan en abstrakt primatprofil av neurala linjer svävar ovanför.
Kontext, plan, liten diff och verifiering: varje steg gör signalen tydligare innan nästa tar vid.

Kort sagt

AI föreslår och skriver utkast. Du äger beslutet och risken. Modellen är snabb på att producera kod som ser rimlig ut. Den kan inte veta vad som är rimligt i just ditt system. Ditt jobb flyttar från att skriva varje rad till att formulera problemet, avgränsa ändringen och verifiera resultatet.

Vad modellen faktiskt är bra på

Det lönar sig att vara konkret här, för det är gränsdragningen som avgör om du får nytta av verktyget eller bara nya buggar att felsöka.

Modellen är stark när uppgiften har ett tydligt mönster och när svaret går att kontrollera snabbt. Den är svag när uppgiften kräver kunskap om ditt system som inte står i prompten — konventioner, tidigare beslut, vad som gick fel förra gången.

Uppgifter där du oftast tjänar tid

Uppgifter där du oftast förlorar tid

Vad du fortfarande äger själv

Det här är den viktigaste punkten i hela guiden, och den som är lättast att glida ifrån när det går fort. Fyra saker flyttar inte över till modellen, oavsett hur bra den blir.

Problemformuleringen. Att avgöra vad som faktiskt ska lösas, och vad som ligger utanför. En modell som får en vag uppgift svarar med något plausibelt, inte med en fråga.
Avgränsningen. Hur stor ändringen får bli. Modellen har ingen naturlig broms — den skriver gärna om tre filer när du bad om en rad.
Verifieringen. Vad som räknas som bevis på att det fungerar. Ett test som körts, en logg du läst, ett anrop du gjort själv. Inte "det ser rätt ut".
Ansvaret. När koden går i produktion är det din kod. "AI skrev det" är inte en förklaring som håller i en incidentrapport.

Arbetsflödet: fyra steg

Det här är samma loop varje gång, oavsett om ändringen tar tio minuter eller en eftermiddag. Poängen är inte ceremonin — det är att varje steg har ett utfall du kan titta på innan du går vidare.

1
Kontext. Ge modellen det den omöjligt kan gissa: relevanta filer, konventionerna ni följer, vad som redan är bestämt. Ett par stycken räcker långt.
2
Plan före kod. Be om en plan i punktform först. Det tar trettio sekunder att läsa och avslöjar missförstånd innan de blivit två hundra rader.
3
En liten diff. Ett avgränsat steg i taget, inte hela funktionen. Läs den som om en kollega skickat en pull request.
4
Verifiering. Kör testet, gör anropet, läs loggen. Först då är steget klart — och först då startar du nästa.

Steg 2 är det som oftast hoppas över och det som oftast lönar sig mest. Om planen är fel är koden fel, och det är billigare att upptäcka i punktform.


Kontextfilen: skriv en gång, använd varje dag

Modellen har inget minne mellan sessioner. Utan en nedskriven kontext börjar varje ny konversation om från noll, och du märker det på att samma diskussion återkommer — ska det ligga i tjänstelagret eller i kontrollern, använder vi det biblioteket eller inte.

Lösningen är en kort fil i repot som du klistrar in eller pekar verktyget mot. Den behöver inte vara lång. Den behöver vara sann och uppdaterad.

Vad som hör hemma i kontextfilen

Uppdatera filen när ett beslut ändras. En kontextfil som ljuger är sämre än ingen alls, eftersom modellen följer den utan att invända.


Fem misstag som kostar mest

  1. Att be om för mycket på en gång. "Bygg inloggningen" ger en stor diff som är svår att granska och omöjlig att felsöka stegvis. Be om ett steg.
  2. Att acceptera kod du inte förstår. Om du inte kan förklara vad en rad gör kan du inte heller avgöra om den är fel. Fråga tills du kan.
  3. Att stapla fixar. Fel uppstår, du klistrar in det, får en fix, nytt fel uppstår. Efter fem varv är koden sämre än när du började. Backa i stället och förstå grundorsaken.
  4. Att blanda uppgifter i samma konversation. Felsökning, sedan en ny funktion, sedan felsökning igen — modellens bild av koden bryts ned. Starta om för nya uppgifter.
  5. Att lita på siffror och versioner. Priser, modellnamn och API-signaturer är precis den sorts fakta som låter säkrast och åldras snabbast. Kontrollera mot källan.

Nästa steg

Om du bara tar med dig en sak: gör ändringarna mindre. Det är den enskilda vanan som gör mest skillnad för hur användbar AI-hjälpen blir, och den är gratis att börja med i dag. Artikeln Små diffar vinner går igenom varför.

Den här guiden är del ett av åtta. Resten går igenom varje moment i arbetsflödet för sig — prompten, granskningen, felsökningen och testerna — och avslutas med säkerhet, verktyg och agenter.

Nästa guide
Prompta för kod: fyra delar som avgör vad du får tillbaka