KOD OCH FELSÖKNING

SKRIVA KOD // DEBUGGA // REFAKTORERA // GRANSKA

Senast uppdaterad:

PRINCIP

Ge AI kontext — inte bara uppgiften

Det vanligaste misstaget när ingenjörer använder AI för kod är att ge för lite kontext. "Skriv en funktion som sorterar en lista" ger ett generiskt svar. Ge istället AI det språk du använder, ramverket, versionen, befintliga konventioner i din kodbas, och vad som gör den här situationen specifik.

Mer kontext = bättre kod. Det är enkelt men underskattat.

KONTEXT MINSKAR ANTALET ITERATIONER
BESKRIV ALLTID: SPRÅK, RAMVERK, SYFTE, BEGRÄNSNINGAR

SKRIVA KOD

Effektiv kodgenerering med AI

Bra approach för att generera kod med AI:

  1. Specificera kontext. Språk, ramverksversion, relevanta beroenden, existerande mönster i kodbasen.
  2. Beskriv vad koden ska göra, inte hur. "Implementera en cache med TTL" är bättre än "Skriv en dictionary med en timer per nyckel."
  3. Be om förklaring av valen. "Förklara varför du valde den här approachen och vilka alternativ du övervägde."
  4. Be om undantagsfall. "Vilka felfall hanterar den här koden inte?"
  5. Granska koden kritiskt. Kör linters, kontrollera säkerhet, verifiera att den fungerar med din aktuella biblioteksversion.

BE ALLTID AI ATT IDENTIFIERA EGNA SVAGHETER
"VAD KAN GÅ FEL MED DETTA?" ÄR EN BRA PROMPT

KODGENERERING

FELSÖKNING

Debugga snabbare med AI som bollplank

AI är ett effektivt verktyg för felsökning — inte för att den alltid har rätt, utan för att den snabbt genererar hypoteser att testa.

Ge AI:

  • Felmeddelandet, exakt och komplett
  • Den relevanta kodsnutten
  • Vad du förväntade dig ska hända
  • Vad som faktiskt händer
  • Vad du redan provat

Be AI lista de tre till fem troligaste orsakerna i sannolikhetsordning och vad du bör kontrollera för att verifiera eller avfärda varje hypotes.

Det ersätter inte att läsa stacktracen — men det kan snabbt ge dig en riktning när du sitter fast.

Om felet kommer från en intern tjänst, kundmiljö eller säkerhetskritisk komponent behöver du först rensa bort hemligheter, interna URL:er, tokens och annan identifierande information. AI ska hjälpa dig resonera om problemet, inte få full insyn i miljön.

GE AI FELET + KODEN + KONTEXTEN
FÅ HYPOTESER ATT TESTA — INTE GARANTERADE SVAR

DEBUGGING

KODGRANSKNING

AI som extra ögonpar i code review

AI kan vara ett komplement till mänsklig code review — inte en ersättning. Bra saker att be AI granska:

  • Uppenbara buggar och logikfel. Saker som lätt missas under en snabb review.
  • Namngivning och läsbarhet. Variabelnamn som är otydliga, funktioner som gör för mycket, onödig komplexitet.
  • Saknade felhanteringar. Vad händer om det här API-anropet misslyckas? Om listan är tom? Om värdet är null?
  • Uppenbara säkerhetsproblem. Användarindata som inte valideras, hårdkodade nycklar, osäker hantering av känslig data.

Var medveten om att AI kan missa subtila problem och ibland flaggar saker som är korrekta. Behandla AI-feedback som förslag, inte som facit.

AI SER DET UPPENBARA — MÄNSKLIG REVIEW SER HELHETEN
ANVÄND BÅDA

CODE REVIEW

REFAKTORERING

Förbättra befintlig kod med AI

Refaktorering är ett område där AI fungerar särskilt bra. Koden finns redan — du vill bara förbättra den utan att ändra beteendet.

Specifika instruktioner ger bäst resultat:

  • "Gör den här funktionen mer läsbar utan att ändra beteendet"
  • "Extrahera denna logik till en återanvändbar hjälpfunktion"
  • "Skriv om detta till ett mer idiomatiskt mönster i [språk/ramverk]"
  • "Minska nästlingsdjupet i denna funktion"
  • "Lägg till typer/annotationer till den här koden"

Be alltid AI förklara varje refaktoreringsval, så att du kan bedöma om det är rätt för din kontext.

SPECIFICERA MÅLET MED REFAKTORERINGEN
"FÖRBÄTTRA" UTAN RIKTNING GER GENERISKA RESULTAT

REFAKTORERING

FÖRE MERGE

AI-kod ska igenom hela leveranskedjan

Att koden kompilerar eller klarar ett AI-genererat test är inte ett godkännande. Behandla ändringen som ett bidrag från en extern utvecklare som inte känner hela systemet.

  1. Läs diffen: förstå varje rad, ändrat beteende, behörighet och felväg. Dela stora förslag i mindre ändringar.
  2. Testa beteendet: lägg till tester för acceptanskriterier, gränsvärden, felvägar och missbruksfall. Följ kritiska flöden; total täckningsprocent ensam räcker inte.
  3. Skanna: kör projektets lint, typkontroll, SAST och secrets-kontroll. Säkerhetskänslig kod kräver sakkunnig review.
  4. Granska beroenden: verifiera paketnamn, utgivare, version, underhåll, kända sårbarheter, transitiva beroenden och licens innan installation.
  5. Kontrollera ursprung: om verktyget visar en kodreferens eller matchning mot publik kod, granska källan och licensvillkoren. Frånvaro av en träff är inte ett licensbesked.
  6. Dokumentera: uppdatera lockfil, beroendelista och SBOM när komponenterna ändras. Koppla ändringen till krav, PR och godkännare.

GENERERAT TEST + GENERERAD KOD ÄR INTE OBEROENDE VERIFIERING

AVSÄNDARE OCH GRANSKNING

Skribent, källor och ansvar

Sidan är skriven och innehållsgranskad av Christopher Leijon för AI på svenska. Ingen extern kodsäkerhetsrevisor har granskat exemplen; tillämpa alltid teamets ordinarie secure-development-process.

SKRIBENT OCH INNEHÅLLSGRANSKARE: CHRISTOPHER LEIJON // KÄLLKONTROLL: 2026-07-13

GUIDEVÄG // STEG 4 AV 13

Nästa: Problemlösning

Strukturera tekniska problem i hypoteser innan du testar en lösning.

Fortsätt till steg 5 →

Till guidens översikt