En workshop om agentisk utvikling i Claude

1) Start store endringer med en plan

For alt som er større enn en liten endring: be om en plan før du ber om kode. La agenten lese relevant kode, forstå dagens løsning og foreslå steg før den endrer filer. Da fanger du gale antakelser tidlig, før mange filer er endret.

"Ikke skriv kode ennå. Les deg inn i hvordan X funker i dag og legg
fram en steg-for-steg plan for å gjøre Y: hvilke filer, hvilken
rekkefølge, og hva som må testes. Vent på at jeg godkjenner planen."

Mange agentverktøy har en egen planmodus. Bruk den på større oppgaver. Det gir mindre feil, bedre retning og færre bortkastede runder. I Claude Code veksler du modus med Shift+Tab.

2) Kontekst er alt

Kontekst er alt agenten ser akkurat nå:

• instruksjonene dine
• filene den har lest
• samtalen så langt
• eventuelle regler og prosjektfiler

Kvaliteten på svaret henger ofte direkte sammen med kvaliteten på konteksten.

Gi agenten nok kontekst:

• Pek på relevante filer.
• Lim inn hele feilmeldinger.
• Forklar hva du prøver å oppnå.
• Si hvorfor noe må endres.

Men ikke gi for mye:

• Ikke dump inn store filer uten grunn.
• Ikke bruk samme økt til mange urelaterte oppgaver.
• Start friskt når du bytter oppgave (/clear).

Legg fast prosjektkontekst i CLAUDE.md, for eksempel:

• stack
• viktige kommandoer
• testkommandoer
• kodekonvensjoner
• ting agenten alltid må huske

Da slipper du å gjenta det i hver økt.

3) Vit hva harnesset har tilgang til

Agenten er ikke bare en språkmodell. Den kjører i et harness som gir den verktøy. Den kan typisk få tilgang til:

• filer i arbeidsmappen
• terminalkommandoer
• tester og byggesteg
• git
• nett
• MCP-servere
• subagenter

Derfor må du vite hvor du starter den, og hva den har lov til å gjøre. To viktige regler:

• Start agenten i riktig prosjektmappe, ikke i hjemmemappen.
• Ha godkjenning på for handlinger som skriver, sletter, sender eller kjører kommandoer.

Agenten ser som regel bare mappen du har gitt den tilgang til. Utenfor den ser den ingenting før du utvider tilgangen.

4) Skriv presise prompter

Gode svar starter med gode prompter. Vær konkret. Ikke skriv:

Fiks auth-bugen.

Skriv heller:

Brukere får "Invalid token" etter 30 minutter.
JWT-tokens er satt til å utløpe etter 1 time i auth.config.ts.
Finn hvorfor dette skjer, og foreslå en løsning før du endrer kode.

Gi gjerne eksempler på ønsket output:

formatNOK(1234.5) skal gi "1 234,50 kr"

Tenk WRAP:

• Write: forklar oppgaven tydelig, som til en juniorutvikler.
• Refine: legg på relevant kontekst.
• Atomic: del store oppgaver i små deler.
• Pair: følg med og styr underveis. Ikke «fire and forget».

Unngå vage instrukser som:

• «Gjør det bedre»
• «Vær mer nøyaktig»
• «Fiks den funksjonen»
• «Se på denne lenken»

Vær konkret på filer, feil, mål og forventet resultat.

Vil du gjøre det proft? Spec-Driven Development

På ekte kundeprosjekter lønner det seg å jobbe mer strukturert enn én stor prompt. Med Spec-Driven Development lar du en spesifikasjon drive arbeidet, og agenten følger faste steg fra krav til ferdig kode.

Typisk flyt:

• Constitution: prinsipper og rammer for prosjektet
• Specify: funksjonelle krav og brukerhistorier
• Clarify: fjern uklarheter
• Plan: teknisk plan og valg
• Tasks: konkrete oppgaver i riktig rekkefølge
• Implement: gjennomfør oppgavene systematisk

Dette gir mer sporbare beslutninger, bedre dokumentasjon og en løsning andre enklere kan ta over. Verktøyet er GitHubs spec-kit:

# Krever Python 3.11+ og Git
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Start med en instruksjonsfil

Før du lager skills, bør du gi agenten fast prosjektkontekst i en instruksjonsfil. Den kan beskrive teknologivalg, kommandoer, mappestruktur, terminologi og regler for oppgaven.

For Bekkværet kan instruksjonsfilen for eksempel si at appen bruker React, TypeScript og Vite, at værdata hentes fra met.no, og at all kildekode skal ligge under src/.

Instruksjonsfilen gjelder hele prosjektet og lastes alltid. Skills brukes til mer avgrenset kunnskap som agenten bare trenger noen ganger. Når agenten skjønner at den jobber med værdata, kan den laste en enhets-skill som beskriver nøyaktig hvordan vi viser temperatur, vind, nedbør og tid i Bekkværet. Den informasjonen er viktig for værrelaterte oppgaver, men unødvendig støy når agenten jobber med helt andre ting, for eksempel arkitekturvalg i kodebasen.

Hva en skill egentlig er

En skill er en gjenbrukbar instruksjonspakke som lærer agenten en bestemt arbeidsmåte. Den ligger i en SKILL.md-fil og kan inneholde regler, eksempler, sjekklister eller steg agenten skal følge.

Tenk på det som teamets erfaring skrevet ned én gang. I stedet for å gjenta «slik skriver vi tester», «slik formaterer vi datoer» eller «husk å kjøre denne kommandoen» i hver økt, legger du det i en skill. Da kan agenten hente det fram selv når oppgaven passer.

Instruksjonsfil, skill eller slash-kommando?

Det er tre ting som er lette å blande sammen:

Tommelfingerregel:

• Legg ting som alltid gjelder i instruksjonsfilen.
• Legg ting som bare gjelder noen typer oppgaver i en skill.
• Bruk slash-kommandoer for handlinger du vil starte manuelt.

Hvor skills bor

En skill er en mappe med en SKILL.md-fil.

.claude/skills/<navn>/SKILL.md
~/.claude/skills/<navn>/SKILL.md

Bruk .claude/skills når skillen skal deles med prosjektet.

Agenten leser først bare description. Resten av skillen lastes først når oppgaven matcher. Derfor er en presis description det viktigste du skriver.

Skills som er nyttige i utviklerhverdagen

1) Lås teknologivalgene i en instruksjonsfil

Husk hvor sprikende «Før vi begynner» ble: ingen hadde fortalt agenten hva slags app Bekkværet skulle være. Før vi bygger videre, fester vi valgene i en CLAUDE.md, den alltid-lastede konteksten fra tabellen over. Da slutter agenten å finne opp stacken på nytt for hver økt.

Bestem deg for en stack, det er din beslutning, og be agenten skrive den ned:

"Lag en CLAUDE.md i rota for Bekkværet. Skriv ned hvilken stack vi
bruker, hvordan prosjektet kjøres og testes, mappestrukturen, og
et par regler du skal følge. Hold det kort."

Et eksempel på hva fila kan inneholde:

# Bekkværet

## Stack
- React + TypeScript + Vite, ren CSS (bytt til det du valgte)
- Værdata: met.no Locationforecast

## Kommandoer
- npm install · npm run dev · npm test

## Mappestruktur
- All kildekode under src/.

## Terminologi
- Oslo skal alltid kalles Skuret.
- Trondheim skal alltid kalles Torget.

## Regler
- Ikke bytt rammeverk eller legg til store avhengigheter uten å spørre.

Legg merke til at stedsnavnene Skuret og Torget hører hjemme i instruksjonsfilen, fordi de gjelder hele prosjektet uansett oppgave. Enheter som °C, m/s og mm/t legger vi i en skill i neste steg, fordi de bare er relevante når agenten jobber med værdata.

Test at den virker: start en ny økt og spør «hvilken stack bruker dette prosjektet?» og «hva skal Oslo og Trondheim kalles?». Agenten skal svare fra CLAUDE.md uten at du forklarer noe.

2) Finn og installer skills

skills.sh er en markedsplass for skills. Installer med ett kall (åpen standard: samme SKILL.md funker for Claude, Codex, Copilot og Gemini):

npx skills add <repo-url> --skill <skill-navn>

Bla i katalogen og se hva som finnes. Til oppgaven under henter vi grill-me, som vi bruker til å stress-teste skillen vår:

npx skills add https://github.com/mattpocock/skills --skill grill-me

npx skills add <repo-url> --skill <skill-navn> -g

3) Bygg konvensjons-skill(s) for Bekkværet

En værtjeneste lever av konsistente enheter og formater. I stedet for å gjenta «vind i m/s, temp i Celsius, norsk dato» i hver eneste prompt, pakker du reglene i en skill agenten laster automatisk hver gang den jobber med vær i Bekkværet.

1. Bestem konvensjonene. For Bekkværet bruker vi blant annet:
   • Temperatur i Celsius (f.eks. -3 °C, 14 °C)
   • Vind i meter per sekund (5 m/s), vindretning som kompass (N, NØ, Ø, SØ, …)
   • Nedbør i millimeter per time (1,2 mm/t) for timesvarsel, og akkumulert per døgn (8 mm/døgn) for dagsoversikt
   • Tidspunkter på norsk format, 24-timers (tirsdag 30. juni, kl. 14:00), med komma som desimalskilletegn
2. Lag skillen. Be agenten skrive den til .claude/skills/bekkvaer-enheter/SKILL.md med en presis description så den lastes automatisk når noen jobber med værdata:

   ---
   name: bekkvaer-enheter
   description: Bruk alltid når du viser eller behandler værdata i
     Bekkværet, så enheter og formater blir konsistente.
   ---
   Enheter og format for all værdata i Bekkværet:
   - Temperatur: Celsius, f.eks. "-3 °C", "14 °C".
   - Vind: meter per sekund, f.eks. "5 m/s". Retning som kompass:
     N, NØ, Ø, SØ, S, SV, V, NV.
   - Nedbør: "1,2 mm/t" for timesvarsel, "8 mm/døgn" akkumulert.
   - Lufttrykk: hektopascal, f.eks. "1013 hPa".
   - Tid: norsk, 24-timers, "tirsdag 30. juni, kl. 14:00".
     Komma som desimalskilletegn.

3. Vurder å dele i to. Enheter (m/s, °C, mm) og norsk formatering (dato, klokke, desimaltegn) er to ulike ansvar. Det er ofte renere som to skills, bekkvaer-enheter og norsk-formatering, enn én stor. Husk: én skill = én ferdighet.
4. Grill skillen. Kjør en /grilling (fra grill-me) mot utkastet: «Er hver regel entydig? Mangler det enheter eller grensetilfeller, som vindstille, frost eller manglende data?»

   Se etter uklare regler:

   • Hva viser vi ved manglende data?
   • Hvordan viser vi 0 m/s — tall eller «vindstille»?
   • Skal temperatur avrundes? Til heltall?
   • Hvordan viser vi minusgrader — -3 °C eller −3 °C?
   • Skal nedbør vises som 0 mm/t eller «ingen nedbør»?
   • Skal tidspunkt alltid vises i norsk tid (CET/CEST)?
5. Test at den lastes. Start en ny oppgave: «Legg til en 7-dagers oversikt i Bekkværet.» Sjekk at agenten bruker m/s, °C, mm og norsk tid uten at du gjentar det, og at den nevner at den brukte skillen.

   Test også at den ikke lastes unødvendig. Start en helt annen oppgave:

   "Foreslå en bedre mappestruktur for kodebasen."

   Da trenger agenten fortsatt instruksjonsfilen (stack, regler, Skuret/Torget), men enhets-skillen skal ikke aktiveres — den er irrelevant for arkitekturvalg.

Oppsummert

Instruksjonsfiler og skills løser to ulike problemer:

• Instruksjonsfilen (CLAUDE.md) sier: «dette gjelder alltid i prosjektet.»
• Skills sier: «dette gjelder når du jobber med denne typen oppgave.»

For Bekkværet betyr det:

• Skuret og Torget → instruksjonsfil (gjelder alltid)
• React, TypeScript, Vite → instruksjonsfil (gjelder alltid)
• src/ som kildekodemappe → instruksjonsfil (gjelder alltid)
• Celsius, m/s, mm/t, norsk tid → skill (gjelder kun værdata-oppgaver)

Samme mønster fungerer for valuta, datoformat, API-felter, feilmeldinger, domenebegreper, teststruktur og PR-format.

Hva MCP er

MCP står for Model Context Protocol.

Det er en åpen standard som lar agenten koble seg til eksterne verktøy gjennom små servere. En MCP-server kan gi agenten tilgang til for eksempel:

• nettleser
• designverktøy
• dokumentasjon
• issues
• pull requests
• databaser
• interne systemer

Agenten får ikke magisk tilgang til alt. Den får tilgang til verktøyene MCP-serveren tilbyr, og handlingene går gjennom agentens vanlige godkjenninger.

Hvordan koble på en MCP-server

Du legger til MCP-servere med disse kommandoene i Claude Code:

claude mcp add <navn> -- <kommando som starter serveren>

For en remote MCP-server:

claude mcp add --transport http <navn> <url>

Se hva som er koblet på:

claude mcp list

Inne i Claude Code kan du også bruke:

/mcp

Da ser du status og hvilke verktøy MCP-serveren tilbyr.

Et hav av servere

Det finnes mange MCP-servere. Mange verktøy du bruker i utviklerhverdagen har allerede en MCP-integrasjon.

I denne oppgaven bruker vi Figma.

Oppgave: koble på Figma og bygg fra skissen

Du skal koble agenten til Figmas remote MCP-server og be den bygge Bekkværet basert på en ferdig Figma-skisse.

Remote-serveren krever ikke Figma Desktop. Første gang logger du inn i nettleseren.

🎨 Åpne Bekkværet-skissen i Figma

1. Koble på Figma

Kjør:

claude mcp add --transport http figma https://mcp.figma.com/mcp

Start Claude Code og kjør:

/mcp

Fullfør innloggingen i nettleseren hvis du blir bedt om det.

2. Gi agenten skissen

Be agenten bygge Figma-designet inn i Bekkværet:

"Bygg dette Figma-designet inn i Bekkværet:
https://www.figma.com/design/4BlBYolhiHE9Zjv5pAT4QB/Bekkvaeret--Copy-?node-id=0-1

Match layout, farger og typografi så nært du kan.
Følg bekkvaer-enheter-skillen fra nivå 2 for enheter og format."

Agenten skal nå kunne hente informasjon fra Figma og bruke den når den endrer appen.

3. Sammenlign med skissen

Når agenten er ferdig, åpner du Bekkværet i nettleseren og sammenligner med Figma-skissen.

Se spesielt på:

• layout
• avstand mellom elementer
• farger
• typografi
• kort og seksjoner
• visning av nåværende vær
• nedbør neste time
• 7-dagers varsel
• Skuret og Torget som stedsnavn
• riktige enheter og norsk format

Spør deg selv:

• Hva traff agenten godt?
• Hva bommet den på?
• Hvilke detaljer måtte du presisere?
• Brukte den skillen fra nivå 2 riktig?
• Var Figma-konteksten nok, eller måtte du forklare mer?

Hvis du vil kjøre Figma lokalt

Figma Desktop har også en lokal Dev Mode MCP-server. Den kjører på:

http://127.0.0.1:3845/sse

Dette krever riktig Figma-tilgang. For denne oppgaven er remote-serveren enklest.

Hvorfor dette er nyttig

MCP gjør agenten bedre fordi den kan hente kontekst direkte fra verktøyene du allerede bruker.

Uten MCP må du ofte forklare eller lime inn informasjon manuelt. Med MCP kan agenten selv hente relevant kontekst fra for eksempel Figma, GitHub eller dokumentasjon.

For Bekkværet betyr det:

• Instruksjonsfilen forteller hva som alltid gjelder i prosjektet.
• Skills forteller hvordan agenten skal løse bestemte typer oppgaver.
• MCP gir agenten tilgang til eksterne verktøy, som Figma-skissen.

Sammen gir dette agenten bedre retning og mindre behov for gjetting.

Tokenoptimalisering: hold konteksten ren

Tokens er både en kostnad og et budsjett for agentens «hukommelse». Når kontekstvinduet fylles opp, blir svarene dårligere.

Gode vaner

• Start med blanke ark. Bruk /clear mellom oppgaver. Kunnskap fra forrige feilsøking hjelper sjelden på neste oppgave, den bare fyller opp konteksten med unødvendig støy.
• Ikke dump inn hele filer. Be agenten lese filen selv, eller pek på spesifikke funksjoner eller linjer.
• Bruk sub-agenter. En sub-agent kan lese 40 filer og returnere kun konklusjonen, slik at hovedkonteksten din holdes ren.
• Vær presis. En presis prompt sparer en runde med oppklaringer, og dermed en runde med tokens.

Verktøy for komprimering

Mye av token-bruken i utvikling kommer fra output fra kommandoer som git status, git diff, npm test og ls.

Verktøy som rtk (Rust Token Killer) og context-mode kan komprimere denne outputen før den når konteksten, uten å miste informasjonen agenten trenger.

Forskjellen er merkbar, spesielt over tid:

# Før og etter med rtk
git status      # → ca. 300 tokens
rtk git status  # → ca. 30 tokens (90 % mindre)

Poenget er ikke én enkelt kommando, men summen over en hel arbeidsdag. Mindre kontekst gir bedre svar og lavere kostnad.

Autonomi: la agenten jobbe alene

Sandboxing: kjør agenten isolert

Godkjenning for hvert steg er trygt, men det er også tregt.

Alternativet er å gi agenten et avgrenset miljø der den ikke kan gjøre skade. Da kan du slippe den mer løs.

Tre nivåer av isolasjon:

1. Git worktree (lett). En egen utsjekk av repoet i en separat mappe. La agenten jobbe der, så forblir hovedmappen din urørt.

   git worktree add ../bekkvaeret-ai -b ai-eksperiment

2. Container (anbefalt). Kjør agenten i en Docker-container. Monter kun repo-mappen og sett opp brannmur mot nettverket. Da når agenten verken hjemmemappen din, nøkler eller resten av maskinen.
3. Isolert VM (tungt). Full separasjon på en egen virtuell maskin. Alt agenten gjør, forblir i VM-en. Du kan ta et snapshot før du starter, og rulle tilbake hvis noe går galt.

Oppgave: prøv en egen idé i sandbox

Tenk ut en funksjon du selv kunne tenke deg å legge til i Bekkværet, for eksempel varsel ved ekstremvær, historikk over tidligere dager, eller en tredje by å velge mellom. Velg ett av de tre alternativene over (worktree, container eller isolert VM) og la agenten jobbe med ideen der, uten at du godkjenner hvert steg underveis.

Spør deg selv etterpå: turte du gi agenten friere tøyler enn du ellers ville gjort? Hvorfor, eller hvorfor ikke?

Helautomatisk med openclaw

openclaw er en alltid-på agent-gateway du kan kjøre som en tjeneste, gjerne i den isolerte VM-en fra steget over.

Når instruksjonsfilen (nivå 2), skills (nivå 2) og MCP (nivå 3) er på plass, kan openclaw bygge Bekkværet videre helt automatisk mens du gjør noe annet.

Slik fungerer det:

1. Installer openclaw i et isolert miljø (VM).
2. Konfigurer den til å bruke det samme oppsettet du allerede har laget: instruksjonsfil, skills og Figma-MCP.
3. Koble den til en chat-kanal (f.eks. Telegram), slik at den kan varsle deg.
4. Gi den hele oppgaven i én melding og la den jobbe.

"Bygg Bekkværet ferdig fra Figma-skissen. Hent designet via
Figma-MCP, følg bekkvaer-enheter-skillen for enheter og format,
koble på ekte værdata fra met.no, og kjør testene til alt er
grønt. Meld meg på Telegram når den er klar, eller hvis du må
ta en avgjørelse."

Fordi openclaw kjører i et sandboxed miljø, kan du gi den friere tøyler enn i en vanlig økt. Den melder fra i chatten når den er ferdig, og du kan lese gjennom diffen før du merger til main.