Hva Claude Code trenger for å jobbe med deg

Kort fortalt

• Claude Code er ikke bare et verktøy for å skrive kode. Det er en AI-agent som må jobbe inne i et ekte arbeidsmiljø.
• Daisy Hollmans hovedpoeng er enkelt: agenten trenger tilgang, kunnskap og verktøy.
• Tilgang betyr at agenten må kunne se riktige filer, mapper, dokumenter, systemer og feilmeldinger.
• Kunnskap betyr at agenten må forstå regler, rutiner, stil, beslutninger og hva prosjektet faktisk brukes til.
• Verktøy betyr at agenten må kunne sjekke, teste, søke, eksportere og gjøre arbeid ferdig.
• Poenget er ikke å gi agenten alt hele tiden, men å gi riktig informasjon, riktig metode og riktige grenser til riktig tid.
• Derfor handler god agentbruk mindre om én perfekt prompt og mer om å bygge et godt system rundt modellen.

Hvorfor dette handler om mer enn kode

Det er lett å tenke på Claude Code som et verktøy for programmerere.

Men det Daisy Hollman forklarer i Beyond the Basics with Claude Code handler egentlig om noe mye større enn kode.

Det handler om hvordan en AI-agent kan jobbe sammen med deg inne i et ekte system.

Det systemet kan være:

• en kodebase
• en mappe med bilder
• et økonomisystem
• et regneark
• et bloggarkiv
• et prosjekt med PDF-er, notater, avtaler, designfiler og gamle beslutninger

Tenk deg at du gir noen tilgang til hele datamaskinen din.

• De kan åpne dokumentene dine.
• Se bildene dine.
• Lese notatene dine.
• Bla gjennom mapper.
• Finne regneark, PDF-er og gamle prosjekter.

Men det betyr ikke at de forstår livet ditt.

• De vet ikke hvilke dokumenter som er viktige.
• De vet ikke hvilke bilder som hører til hvilket prosjekt.
• De vet ikke hvilke regneark som er oppdatert.
• De vet ikke hvilke filer som er gamle.
• De vet ikke hvilke mapper du faktisk bruker.
• De vet ikke hvilke rutiner du følger.

De ser informasjonen, men mangler konteksten.

Akkurat det samme gjelder for Claude Code.

Claude Code kan lese filer, skrive kode, endre tekst, kjøre kommandoer og hjelpe deg med arbeid. Men kode er bare én type fil. I praksis handler dette om noe mer grunnleggende:

En AI-agent trenger et arbeidsmiljø.

Noen deler av dette arbeidsmiljøet er vanlige filer. En prosjektfil kan forklare hvordan mappen fungerer. En skill kan ligge i en SKILL.md. En spesialisert agent kan være definert i en egen agentfil. Andre deler er koblinger, innstillinger eller verktøy. Poenget er ikke filtypen, men at agenten får noe konkret å jobbe ut fra.

Daisy Hollman oppsummerer dette i tre enkle behov:

“Tilgang. Kunnskap. Verktøy.”

Hvis ett av disse mangler, blir agenten mindre nyttig.

Har den ikke tilgang, ser den ikke det den trenger.

Har den ikke kunnskap, forstår den ikke hvorfor ting er som de er.

Har den ikke verktøy, kan den ikke gjøre jobben ferdig.

Derfor er hovedpoenget i foredraget ikke bare at Claude Code er smartere enn før.

“En god kodeagent handler ikke bare om modellen. Den handler også om systemet modellen jobber i.”

Det er nøkkelen.

Claude Code er ikke bare en chatbot

Når folk hører om Claude Code, er det lett å se for seg en chatbot som kan skrive kode.

Du skriver:

“Lag denne funksjonen.”

Så svarer Claude med kode.

Det er den enkle versjonen.

Men Claude Code er nærmere en medarbeider som får tilgang til et prosjekt.

Et prosjekt ligger ofte i en mappe på datamaskinen. Der finnes det kode, dokumentasjon, konfigurasjonsfiler, tester, notater, bilder, designfiler, CSV-er, PDF-er, gamle utkast og små regler som bare prosjektet selv kjenner til.

Når Claude Code får tilgang til en slik mappe, kan den lese filer, forstå strukturen, foreslå endringer og gjøre arbeid.

For utviklere skjer dette ofte i terminalen, i en kodeeditor eller i en app.

Men prinsippet er ikke bare teknisk.

Det samme gjelder hvis du har en mappe som heter:

• Økonomi 2026
• Bloggposter
• Kundeprosjekter
• Bilder
• Personlig operativsystem
• Regnskap
• Kurs og foredrag
• Styrearbeid i idrettslaget
• Dokumenter til boligsameiet
• Familiearkiv
• Kvitteringer og garantier

Hvis du ber en AI-agent hjelpe deg med en slik mappe, holder det ikke at den bare kan “se filene”.

Den må forstå hva filene betyr.

• Hva er gammelt?
• Hva er aktivt?
• Hva er ferdig?
• Hva er utkast?
• Hva kan slettes?
• Hva må aldri slettes?
• Hvilke filer hører sammen?
• Hva er kilden til sannheten?

Det er dette Hollman bruker foredraget på.

Hun snakker ikke først og fremst om bedre prompts.

Hun snakker om arbeidsmiljøet rundt agenten.

Problemet er ikke bare kode. Problemet er kontekst.

Hvis du ansetter en ny utvikler og gir personen tilgang til én mappe med kode, betyr ikke det at personen automatisk forstår prosjektet.

• Vedkommende vet ikke hvorfor systemet ble bygget.
• Vet ikke hvilke beslutninger som allerede er tatt.
• Vet ikke hvilke regler teamet følger.
• Vet ikke hvilke feil som har oppstått tidligere.
• Vet ikke hvordan endringer testes før de tas i bruk.

Selv om personen kan lese koden, mangler mye av konteksten.

Akkurat det samme gjelder for Claude Code.

Koden er bare én del av virkeligheten.

Rundt koden finnes det dokumentasjon, beslutninger, arbeidsflyter, rutiner, verktøy og erfaringer som har bygget seg opp over tid.

Og dette gjelder like mye utenfor programmering.

Hvis du har et regneark med privatøkonomi, er ikke tallene nok. Agenten må forstå hva kolonnene betyr, hvilke regler du bruker, hvilke kontoer som er private, hvilke som hører til firma, og hva som skal telles med eller ikke.

Hvis du har et bildearkiv, er ikke filnavnene nok. Agenten må forstå hvilke bilder som er originaler, hvilke som er eksportert, hvilke som er brukt i en kampanje, og hvilke som bare er gamle tester.

Hvis du har en mappe med bloggposter, er ikke teksten nok. Agenten må forstå stil, struktur, publiseringsrutine, kilder, målgruppe og hva som allerede er skrevet før.

Hvis du har et personlig operativsystem, ofte forkortet personlig OS, holder det ikke at agenten ser mappene. Et personlig OS kan være notater, prosjekter, filer, rutiner og mål samlet på ett sted. Noen kaller deler av dette et second brain eller et personlig kunnskapssystem. Før var dette mest noe du organiserte selv i mapper og apper. Systemet forsto ikke sammenhengene. Med AI-agenter kan det bli mer aktivt: agenten kan holde oversikt, finne riktig informasjon, koble ting sammen og gi raske svar. Men da må den forstå hvordan du jobber.

Dette er grunnen til at enkel kodehjelp ikke er nok når prosjektet vokser.

En agent kan hjelpe med små ting uten mye kontekst.

• Den kan skrive en funksjon.
• Rette en skrivefeil.
• Oppdatere en fil.
• Lage en enkel test.
• Oppsummere et dokument.

Men når prosjektet blir større, trenger den mer.

Den trenger tilgang. Den trenger kunnskap. Den trenger verktøy.

De tre tingene agenten trenger

Hollmans enkle modell er veldig nyttig fordi den kutter gjennom mye teknisk språk.

Her blir den en praktisk sjekkliste:

1. Tilgang

Agenten må kunne se det som er relevant.

For en utvikler kan det være GitHub, terminalen, testresultater, dokumentasjon, feilmeldinger, oppgaver eller CI-systemer, altså systemer som automatisk kjører tester og sjekker når kode endres.

For en ikke-teknisk bruker kan det være mapper, dokumenter, bilder, PDF-er, regneark, notater, kontrakter eller prosjektfiler.

Hvis du ber agenten rydde i økonomien, men den ikke kan se regnearket, kommer den til å gjette.

Hvis du ber den skrive en bloggpost, men den ikke kan se tidligere artikler, kommer den til å bomme på stil.

Hvis du ber den finne feil i et prosjekt, men den ikke kan lese feilmeldingen, jobber den i blinde.

Tilgang betyr ikke at agenten skal ha fri tilgang til alt.

Det betyr at den må få riktig informasjon når den jobber med en bestemt oppgave.

Hvis Claude ikke ser det du ser, og ikke kan bruke det du bruker, kan den heller ikke gjøre jobben fullt ut sammen med deg.

2. Kunnskap

Tilgang er ikke nok.

Agenten må også forstå hvordan ting fungerer.

Agenten trenger å forstå hvorfor, ikke bare hva.

Et regneark er ikke bare celler. Det har regler.

En mappe er ikke bare filer. Den har struktur.

Et bildearkiv er ikke bare JPG-er. Det har versjoner, valg, eksportfiler og originaler.

En kodebase er ikke bare kode. Den har arkitektur, avhengigheter, tester, historikk og beslutninger.

Kunnskap kan ligge i dokumentasjon, prosjektinstruksjoner, README-filer, egne regler, stilguider, sjekklister eller små forklaringer i prosjektet.

For Claude Code brukes ofte filer som CLAUDE.md til dette.

Men ideen er enkel også uten kode:

Lag en fil som forklarer hvordan prosjektet fungerer.

For eksempel:

• Hva denne mappen brukes til
• Hvilke filer som er viktige
• Hvilke regler som gjelder
• Hva som aldri skal slettes
• Hvordan ting navngis
• Hvordan arbeid skal sjekkes før det regnes som ferdig

Dette er ikke pynt.

Dette er arbeidskunnskap.

3. Verktøy

Til slutt trenger agenten verktøy.

Det holder ikke alltid å lese og skrive tekst.

Noen ganger må agenten kunne:

• kjøre en test
• åpne en fil
• sjekke en CSV
• analysere et regneark
• lage en rapport
• eksportere en fil
• sammenligne to versjoner
• lese metadata
• sjekke om en lenke virker
• finne bilder i en mappe
• kjøre en kommando

For utviklere kan dette være terminalverktøy, tester, linters, typecheckere, build-systemer og Git.

I vanlige prosjekter kan agenten trenge verktøy for å lese regneark, finne filer, forstå bilder, åpne PDF-er, søke, eksportere, følge sjekklister og lage rapporter.

Verktøy gjør at agenten ikke bare svarer.

Den kan faktisk utføre arbeidet.

Hvorfor agenten ikke skal få alt på én gang

Når et prosjekt blir stort, oppstår et nytt problem.

Agenten trenger mer informasjon, men den kan ikke få alt hele tiden.

Dette er viktig.

Mange tenker at løsningen er å skrive én enorm instruksjon til agenten.

Alt skal inn:

• Prosjekthistorikk.
• Mappestruktur.
• Regler.
• Kodefilosofi.
• API-er.
• Testregler.
• Designprinsipper.
• Tidligere feil.
• Arbeidsmåter.
• Personlige preferanser.
• Publiseringsrutiner.
• Filnavn.
• Kilder.
• Formater.

Men det fungerer dårlig når prosjektet vokser.

Det blir som å gi noen hele biblioteket før de skal svare på ett spørsmål.

En AI-modell har et begrenset kontekstvindu. Det betyr at den bare kan holde en viss mengde informasjon aktivt i hodet samtidig.

Derfor er ikke løsningen å gi agenten alt.

Løsningen er å organisere kunnskapen.

“Agenten skal ikke vite alt hele tiden. Den skal kunne hente riktig kunnskap, riktig verktøy eller riktig arbeidsflyt når den trenger det.”

Det er en mye bedre måte å tenke på AI-agenter.

Når du selv jobber, gjør du dette automatisk.

Hvis du skal finne en kvittering, åpner du ikke hele datamaskinen i hodet. Du går til riktig mappe.

Hvis du skal redigere et bilde, åpner du ikke alle bildene dine. Du åpner riktig fil i riktig program.

Hvis du skal skrive en bloggpost, åpner du ikke alt du noen gang har skrevet. Du finner relevante notater, kilder og tidligere artikler.

Hvis du skal fikse kode, leser du ikke nødvendigvis hele kodebasen. Du finner riktig fil, riktig test og riktig feilmelding.

Agenten må jobbe på samme måte.

Den må kunne hente riktig informasjon til riktig tid.

Fra chatbot til arbeidssystem

Dette er der begrepet agentic harness kommer inn.

Det høres teknisk ut, men ideen er enkel.

Et agentic harness er arbeidssystemet rundt agenten.

• Hvilke filer får den se?
• Hvilke systemer kan den bruke?
• Hvilke regler må den følge?
• Hvilke verktøy har den tilgang til?
• Hva skal den huske?
• Hva skal den sjekke?
• Hvor går grensene?

Tenk på en agent som en person som kommer inn på et kontor.

Hvis kontoret er tomt, må personen gjette.

Hvis kontoret har riktige mapper, riktige programmer, tydelige regler, gode sjekklister og tilgang til systemene arbeidet faktisk foregår i, kan personen gjøre en mye bedre jobb.

Det samme gjelder Claude Code.

Det er ikke nok at modellen er smart.

Den må sitte ved riktig skrivebord.

Et enkelt kart over systemet

Slik kan du lese systemet:

Poenget er ikke at alt skal være avansert.

Poenget er at agenten må få et arbeidsmiljø.

MCP: broen mellom agent og systemer

MCP står for Model Context Protocol.

Det kan høres teknisk ut, men ideen er ganske enkel.

MCP er en måte å koble AI-agenten til eksterne systemer på.

Det kan være databaser, dokumenter, interne verktøy, GitHub, Slack, filsystemer, oppgavesystemer eller andre tjenester.

En god analogi er USB-C.

USB-C er ikke selve harddisken, skjermen, laderen eller kameraet.

Det er kontakten som gjør at ting kan kobles sammen.

MCP fungerer litt på samme måte for AI-agenter.

MCP er ikke selve kunnskapen. Det er ikke selve databasen. Det er ikke selve verktøyet.

Det er koblingen.

Hvis Claude Code bare ser kodefilene i prosjektmappen, kan den hjelpe med det den finner der.

Men hvis den også kan hente informasjon fra andre systemer via MCP, kan den forstå mer av virkeligheten rundt prosjektet.

For en utvikler kan det bety at agenten kan se feil fra CI-systemet, hente informasjon fra GitHub, lese oppgaver fra et prosjektverktøy eller slå opp i intern dokumentasjon.

For en vanlig bruker kan det samme prinsippet bety at agenten kan jobbe med mapper, notater, dokumenter, regneark, bildefiler eller andre systemer som hører til prosjektet.

Poenget er ikke at agenten skal ha fri tilgang til alt.

Poenget er at den må kunne bruke de riktige kildene når oppgaven krever det.

Hver gang du må hente informasjon et annet sted, har du funnet noe Claude Code mangler.

“MCP kobler agenten til systemer og datakilder.”

Det er den korte forklaringen.

MCP er broen.

Skills: ferdigheter på forespørsel

Der MCP handler om koblinger, handler skills om ferdigheter.

En skill er en spesialisert evne agenten kan bruke når en bestemt type oppgave dukker opp.

Her passer Matrix-analogien ganske godt.

I The Matrix sitter Neo i stolen, får en plugg koblet til nakken, og plutselig kan han kung fu.

Han har ikke sittet i årevis og trent på vanlig måte. Han får en ferdighet lastet inn når han trenger den.

Slik kan man tenke på skills også, bare i en mer jordnær versjon.

En skill kan lære agenten hvordan den skal gjøre en bestemt type arbeid.

For eksempel:

• Lage en rapport
• Analysere en kodebase
• Formatere en bloggpost
• Rydde i et regneark
• Jobbe med et bestemt filformat
• Følge en intern stilguide
• Lage bildeprompter
• Oppsummere research
• Sjekke en publiseringsklar artikkel

Agenten trenger ikke å ha alle skills aktive hele tiden.

Den trenger å kunne hente riktig skill når oppgaven passer.

Hvis MCP er USB-C-kabelen, er skills ferdighetspakker.

MCP sier:

“Slik kobler du deg til dette systemet.”

Skills sier:

“Slik gjør du denne typen arbeid.”

Det er en viktig forskjell.

Tenk deg at du har et personlig OS med mapper for økonomi, prosjekter, idéer, bilder og tekster.

MCP kan være måten agenten får tilgang til filene på.

En skill kan være måten agenten lærer hvordan den skal rydde i økonomimappen, lage en ukesrapport, oppsummere prosjektstatus eller skrive en bloggpost i riktig stil.

Det ene gir tilgang.

Det andre gir metode.

Hooks: automatiske kontrollpunkter

Hooks er små automatiske stoppunkter i arbeidsflyten.

De kan brukes til å sjekke, varsle, logge eller stoppe noe før det går videre.

For eksempel kan en hook gjøre dette i et kodeprosjekt:

• Kjør test etter at agenten har endret kode
• Sjekk formatering
• Stopp hvis agenten prøver å slette noe farlig
• Varsle hvis en fil mangler
• Minn agenten på en prosjektregel

Men hooks gir like mye mening utenfor kode.

I et privat system kan hooks være små kontrollpunkter:

• Før du sender en faktura, sjekk at beløp, dato og mottaker finnes
• Før du publiserer en bloggpost, sjekk at tittel, ingress og kilder er med
• Før du endrer en viktig fil, lag en kopi
• Før du sletter noe, stopp og spør
• Før du eksporterer bilder, sjekk riktig størrelse og filformat

Hooks gjør at agenten ikke bare jobber fritt i blinde.

De legger inn sikkerhet, rutine og kvalitet i systemet.

Det som hjelper, er som regel ikke en smartere modell, men en bedre feedback-loop.

Det er litt som rekkverket på en bro.

Rekkverket går ikke turen for deg.

Men det hindrer deg i å falle utenfor.

Subagents: spesialiserte hjelpere

Subagents er spesialiserte hjelpere.

I praksis kan en slik hjelper være definert i en liten agentfil med rolle, instruksjoner og bruksområde.

I stedet for at hovedagenten skal gjøre alt selv, kan den sende en deloppgave til en agent som er bedre på akkurat den typen arbeid.

I kode kan det være:

• En test-agent
• En sikkerhets-agent
• En dokumentasjons-agent
• En research-agent
• En review-agent

I et privat eller kreativt system kan det være:

• En økonomi-agent
• En bilde-agent
• En skrive-agent
• En struktur-agent
• En publiserings-agent
• En planleggings-agent

Dette ligner mer på hvordan mennesker jobber i større prosjekter.

Selv om du er én person, kan du fortsatt dele arbeidet inn i roller.

Du kan ha én rolle som skriver. Én som sjekker. Én som rydder. Én som publiserer. Én som tenker strategi.

Med subagents kan agent-systemet begynne å ligne mer på et lite arbeidslag, selv om det bare er du som styrer det.

Plugins: ferdigpakkede utvidelser

Plugins er mer som ferdigpakkede utvidelser.

De kan legge til funksjoner, integrasjoner eller arbeidsmåter uten at alt må bygges fra bunnen hver gang.

En plugin kan gi agenten en ny evne eller kobling.

Det viktige er å ikke blande alle ordene sammen.

Kort sagt:

Til sammen gir de Claude Code et bedre arbeidsmiljø.

Ikke bare mer informasjon.

Bedre organisert informasjon.

Ikke bare flere verktøy.

Riktige verktøy på riktig sted.

Ikke bare mer automasjon.

Tryggere og mer forståelig automasjon.

Hvor dette blir praktisk i hverdagen

La oss ta dette ut av kodeverdenen.

Se for deg at du har et prosjekt som heter “Kurs 2026”.

I mappen ligger:

• gamle kursnotater
• bilder
• PDF-er
• kundelister
• idéer
• regneark med priser
• presentasjoner
• bloggposter
• videomanus
• fakturaer
• gamle versjoner
• eksportfiler

Hvis du ber en vanlig chatbot hjelpe deg, må du forklare mye manuelt.

Men hvis du bygger et bedre agent-system rundt arbeidet, kan agenten gjøre mer.

Den kan vite hvor kursmateriell ligger. Den kan vite hvilken stil du bruker. Den kan vite hvilke filer som er aktive. Den kan vite hvilke bilder som er godkjent. Den kan vite hvilket regneark som styrer priser. Den kan vite hvilken sjekkliste som gjelder før publisering. Den kan bruke en skill for å lage kursmoduler. Den kan bruke en hook for å sjekke at kilder og lenker finnes. Den kan bruke en subagent til å kontrollere tekst. Den kan bruke et verktøy til å eksportere riktig format.

Da svarer ikke agenten bare på spørsmål.

Den blir en del av arbeidsflyten.

Et konkret eksempel: regneark

La oss si at du har et regneark med økonomi.

En dårlig agentbruk ser slik ut:

“Se på dette regnearket og si hva du tenker.”

Det kan gi et greit svar, men agenten må gjette mye.

En bedre agentbruk er å gi den kontekst:

Dette regnearket brukes til privatøkonomi. Kolonne A er dato. Kolonne B er beskrivelse. Kolonne C er beløp. Kolonne D er kategori. Alt med kategori “firma” skal skilles ut. Alt uten kategori skal foreslås kategorisert. Ikke endre originalfilen. Lag heller en ny rapport.

Da får agenten både tilgang, kunnskap og regler.

Enda bedre blir det hvis dette ikke må forklares hver gang.

Da kan kunnskapen ligge i en prosjektfil eller skill.

Agenten trenger ikke å vite alt hele tiden.

Den trenger å vite hvor den skal hente riktig instruksjon.

Et konkret eksempel: bilder

La oss si at du har en mappe med 800 bilder til et kreativt prosjekt.

En agent som bare ser filene, vet lite.

Den vet ikke hvilke bilder som er referanser. Den vet ikke hvilke som er eksportert. Den vet ikke hvilke som er ferdige. Den vet ikke hvilke som tilhører samme karakter. Den vet ikke hvilke som kan brukes offentlig. Den vet ikke hvilke som bare er gamle tester.

Et bedre system kan ha en enkel forklaringsfil:

Denne mappen inneholder referansebilder til karakteren. originals inneholder urørte filer. exports inneholder ferdige versjoner. archive inneholder gamle tester. Ikke slett noe uten bekreftelse. Bruk bare bilder fra approved når du lager nye prompts.

Dette er ikke avansert.

Men det gjør agenten mye mer nyttig.

Kontekst er forskjellen mellom å se filer og forstå prosjektet.

Et konkret eksempel: bloggpost

La oss si at du vil at Claude Code skal hjelpe deg å skrive bloggposter.

Da trenger agenten mer enn temaet.

Den bør vite:

• hvilken struktur du bruker
• hvordan introen skal være
• hvor enkel teksten skal være
• hvilke ord du foretrekker
• hvilke ord du vil unngå
• hvordan kilder skal brukes
• hvordan tekniske begreper skal forklares
• hvilken målgruppe teksten er for
• hvordan ferdig artikkel skal sjekkes

Da kan du ha en skill som heter “skriv bloggpost”.

Den skillen kan si:

Start med tittel. Skriv “Kort fortalt”. Bruk korte avsnitt. Forklar tekniske begreper med hverdagslige eksempler. Bruk kodeeksempler bare når det faktisk hjelper. Bruk også eksempler fra mapper, filer, bilder og regneark. Avslutt med ordliste og kilder.

Da slipper du å forklare alt på nytt hver gang.

Agenten får en fast måte å jobbe på.

Hva dette betyr for fremtidens arbeid

Det Daisy Hollman peker på, er et skifte.

Vi går fra å bruke AI som en chatbot til å bruke AI som en arbeidsagent: en slags digital medarbeider.

En chatbot trenger bare et spørsmål.

En arbeidsagent trenger et system.

Det er stor forskjell.

Hvis du spør:

“Hva er MCP?”

Da kan en chatbot svare.

Men hvis du sier:

“Gå gjennom prosjektet mitt, finn hva som mangler, oppdater dokumentasjonen, sjekk at regnearket stemmer, foreslå neste steg og lag en publiseringsklar rapport.”

Da trenger agenten mye mer.

• Den trenger å se filer.
• Den trenger å forstå regler.
• Den trenger å bruke verktøy.
• Den trenger å vite hva som er trygt.
• Den trenger å vite hva som er ferdig.
• Den trenger å vite hvor den skal stoppe.

Det er derfor moderne agentarbeid ikke bare handler om bedre modeller.

Det handler om bedre arbeidsmiljøer for modellene.

Den viktigste misforståelsen

Den vanligste misforståelsen er at mer informasjon alltid er bedre.

Det stemmer ikke.

Mer informasjon kan gjøre agenten bedre.

Men bare hvis informasjonen er organisert.

Hvis du kaster alt inn i én stor prompt, får du ofte rot.

Hvis du derimot legger riktig kunnskap på riktig sted, får du et system.

• Noe skal ligge i prosjektinstruksjoner.
• Noe skal ligge i dokumentasjon.
• Noe skal ligge i egne filer.
• Noe skal hentes via verktøy.
• Noe skal aktiveres som skills.
• Noe skal sjekkes med hooks.
• Noe skal sendes til subagents.

Dette er hele poenget:

“Agenten skal ikke få alt. Den skal få riktig ting til riktig tid.”

Det er slik mennesker jobber.

Og det er slik gode AI-agenter må jobbe også.

Gi agenten tilgang. Respekter kontekstvinduet. Velg løsninger som fortsatt fungerer når bruken vokser.

Hva du kan gjøre allerede nå

Du trenger ikke bygge et avansert agentsystem med én gang.

Du kan starte enkelt.

Lag én prosjektmappe.

Legg inn en enkel forklaringsfil.

Skriv:

• Hva er dette prosjektet?
• Hva er målet?
• Hvilke mapper finnes?
• Hvilke filer er viktige?
• Hva er gammelt?
• Hva er aktivt?
• Hvilke regler gjelder?
• Hva skal agenten aldri gjøre uten å spørre?
• Hvordan vet vi at en oppgave er ferdig?

Bare det kan gjøre en enorm forskjell.

For eksempel:

• For en kodebase kan dette være en CLAUDE.md.
• For et privat prosjekt kan det være README.md.
• For et bildeprosjekt kan det være project-notes.md.
• For økonomi kan det være rules.md.
• For en blogg kan det være styleguide.md.

Navnet er ikke det viktigste.

Poenget er at agenten får en bruksanvisning til prosjektet.

En enkel startstruktur

Du kan tenke slik:

• Prosjektmappe
• README eller prosjektforklaring
• Arbeidsfiler
• Kilder
• Utkast
• Ferdige filer
• Arkiv

I README-filen kan du samle:

• mål
• regler
• stil
• sjekkliste

Dette er nok til å begynne.

Ikke fordi strukturen er perfekt.

Men fordi agenten får noe å orientere seg etter.

Konklusjon

Det viktigste i Hollmans poeng er ikke at Claude Code kan skrive mer kode.

Det er at AI-agenter blir bedre når de får et godt arbeidsmiljø rundt seg.

En chatbot kan svare på et spørsmål. En arbeidsagent må forstå oppgaven, finne riktig kontekst og bruke riktige verktøy.

Derfor handler dette mindre om én smart modell, og mer om hvordan vi organiserer arbeidet rundt modellen.

Når tilgang, kunnskap og verktøy henger sammen, blir agenten mer enn et sted du skriver inn spørsmål.

Den blir en del av arbeidsflyten.

Ordliste

Kilder og ressurser