Du skriver «lag en adminside der administrator kan opprette, redigere og slette bøker», sender den inn og går. Tjue minutter senere har Claude Code laget en side som heter Katalog, endret README, lagt inn en test du ikke ba om, og gjort en rekke andre valg du aldri fikk ta stilling til. Resultatet er ikke dårlig. Men det er Claudes løsning, ikke din.
Claude Code kommer overraskende langt med noen få ord. Problemet er at jo mindre du forteller, desto mer må den avgjøre selv, og ikke alle avgjørelsene blir gode. Denne artikkelen viser rammeverket kursholderen bruker for å skrive oppgaver Claude ikke må gjette på, med den samme CRUD-oppgaven kjørt to ganger.
Hvorfor den vage oppgaven likevel gikk bra
Den vage versjonen ga faktisk et brukbart resultat: en katalogside med opprett, les, rediger og slett, og en bekreftelsesdialog før sletting. Grunnen var ikke flaks. Prosjektet hadde allerede sider for aktive lån, brukere og innstillinger, så Claude hadde etablerte mønstre å følge. Lager du en helt ny type side uten mønstre, må Claude gjette langt mer, og da sprer resultatene seg.
Det er også der kostnaden ligger. Hver ting Claude måtte gjette på, fra sidenavn til testoppsett, er noe du enten må leve med eller rette etterpå. På en liten oppgave er det billig. På en stor oppgave kan det bety en halvtime i feil retning.
Fire grep som gjør oppgaven konkret
Rammeverket har fire deler, og de bør stå i denne rekkefølgen:
- Beskriv utfallet. Hva skal bygges eller endres? Vær konkret på det som betyr noe for deg: sidens navn, hvor den ligger, hva som skal være synlig og i hvilken rekkefølge.
- Gi relevant kontekst. Er det noe Claude må vite før den setter i gang? Pek på mønstre, komponenter eller filer i prosjektet den skal bruke. Claude finner ofte mønstrene selv, men du fjerner tvilen ved å si det.
- Sett rammer. Hva skal Claude passe på, eller ikke gjøre? Ikke endre datamodellen, ikke installere nye pakker, alltid be om bekreftelse før sletting.
- Definer hva ferdig betyr. Hva må faktisk fungere for at oppgaven skal kunne merkes som løst?
Det siste punktet er viktigere enn det ser ut. Når du gir Claude Code en oppgave, starter en sløyfe der den undersøker, gjør noe og sjekker resultatet, om og om igjen. Forteller du hva ferdig betyr, vet sløyfen når den skal stoppe. Forteller du det ikke, stopper Claude når den selv synes det ser bra ut.
Samme oppgave, konkret versjon
Slik så den konkrete oppgaven ut i kurset, med de fire delene på plass:
- Utfall: Lag en side for bokadministrasjon i admin-området, kalt Bøker, der administrator kan administrere bibliotekets bøker. På redigeringssiden skal det være brødsmuler, deretter informasjon om boken, så et kort med feltene og handlingene Lagre og Avbryt, og nederst mulighet til å slette boken.
- Kontekst: Bruk feltene, komponentene og mønstrene som allerede finnes i prosjektet.
- Rammer: Ikke endre datamodellen eller installer nye npm-pakker. Sletting skal bekreftes av brukeren først.
- Ferdig: Administrator kan se alle bøker, opprette en ny bok, redigere en eksisterende og slette en bok.
Resultatet tok like lang tid, femten til tjue minutter, men landet der kursholderen ville: en side som heter Bøker, brødsmuler på redigeringssiden, riktig rekkefølge på elementene og en bekreftelse før sletting. Testen dukket opp denne gangen også, og det er et godt eksempel på at rammer virker begge veier: vil du ikke ha tester, må du si det.
La Claude hjelpe deg å konkretisere
Er du usikker på hva som mangler i en oppgave, kan du be Claude finne det ut. Legg til en setning som «før du begynner, still meg spørsmål om viktige valg eller detaljer som er uklare». Da får du spørsmål om ting du ikke hadde tenkt på, og du og Claude er enige om retningen før en eneste fil er endret. Det er ofte den raskeste veien fra vag til konkret.
Når du kan være kort likevel
Kursholderen skriver ikke detaljerte oppgaver hver gang. Til små endringer er han ofte kortfattet, og i et prosjekt med tydelige mønstre er Claude flink til å finne dem selv. Da er det raskere å gi en kort oppgave, se på resultatet og iterere derfra enn å beskrive hvert steg på forhånd.
Tenk på det som en skala. Små oppgaver kan være korte og utforskende. Jo større oppgaven blir, desto mer koster det om Claude går i feil retning, og desto mer tid bruker du på utfall, kontekst, rammer og ferdig. En god oppgave trenger ikke være lang. Den trenger å være konkret på det som betyr noe.
Neste steg
Oppgaven er det første av flere valg som styrer resultatet. De neste er hvilken modus Claude jobber i, og om du leser planen før du godkjenner den. Skal Claude kjenne prosjektet før du skriver en eneste oppgave, legger du den faste kunnskapen i CLAUDE.md. Prinsippene i rammeverket gjelder også utenfor kodebasen, og Slik skriver du en god prompt til Claude viser hvordan de ser ut i en vanlig samtale. Vil du gå dypere i selve håndverket, dekker Hva er prompt engineering teorien bak.
Denne videoen er hentet fra kurset Claude Code – komplett guide på Utdannet.no. I det fulle kurset ser du begge versjonene av CRUD-oppgaven bli løst i sanntid, får en egen øvelse der du gjør en vag oppgave konkret, og lærer hvordan modus, modell og planmodus spiller sammen med oppgaven du skriver.
