De fleste bruker AI til å gjøre ting. Færre bruker den til å bestemme hva som skal gjøres. Her er de fem trinnene jeg ville tatt, for alt fra et programvareprosjekt til et budsjett, med prompter å lime inn, et ferdig eksempel og to ferdige instruksjonsfiler (skills) du kan laste ned. Del 1 av 5 i Beslutninger.
Å planlegge med AI er å la den stille deg spørsmålene du ikke stilte deg selv, legge fram alternativer og angripe planen før virkeligheten gjør det. Den skriver ikke planen for deg. Du bestemmer hva som er verdt å gjøre.
Skal du ikke lage planen selv, men godkjenne den? Da trenger du bare disse fire spørsmålene når noen legger den fram:
Ansvaret for en plan flytter seg ikke til AI. Den har laget forslag, og mennesker står bak planen. Mer for deg som leder står i AI for ledere. Resten av siden er for deg som skal lage planen.
Du kan be AI om «en plan for å innføre et nytt system» og få en pen plan på ti sekunder. Den ser ferdig ut, men den bygger på det du skrev og på det modellen, altså selve AI-en, gjetter om resten. En plan blir god av det du oppdager at du mangler, og der kan AI hjelpe mer enn de fleste, hvis du snur på rollene.
Når AI gjør noe for deg, ser du resultatet med en gang. Når den hjelper deg å planlegge, er resultatet feil som ikke skjedde, og dem ser du aldri. Derfor er det lett å hoppe over, selv om feil er billigere å rette før noen har begynt. Under står hvordan jeg ville gjort det. Der det står «slik ville jeg», er det en anbefaling. «Slik har jeg» står bare der prosjektet bak siden faktisk viser det.
Det kan være et programvareprosjekt, en innføring på jobb, et arrangement eller et budsjett. Trinnene er de samme, bare ordene skifter. Trinn 1 til 3 tar rundt 20 minutter (et anslag, ikke målt), og trinn 4 og 5 kommer i tillegg. Lim bare inn det du ville vist en fremmed. Planlegger du noe fra jobb, bruk verktøyet virksomheten har godkjent, og skriv «omtrent» og «Kunde A» i stedet for tall og navn.
Skriv noen setninger om hva du vil, hvor lang tid du har, hvem som skal gjøre jobben og hva som ikke kan flyttes. Så ber du om noe uvanlig: at den ikke skriver noen plan ennå, men stiller deg spørsmål, ett om gangen. Spørsmålene tvinger deg til å svare på det du hadde skjøvet fra deg, som hvem som må si ja, og hva som skjer hvis fristen ikke holder. «Vet ikke» er et fullt gyldig svar. Det blir et åpent spørsmål i planen.
[Er dette fra jobb? Bruk bare et verktøy virksomheten har godkjent. Skriv «omtrent» og «Kunde A» i stedet for interne tall og navn. Slett denne linjen før du sender.] Jeg skal planlegge [hva: for eksempel en innføring på jobb, et arrangement, et budsjett eller et programvareprosjekt]. Målet mitt: [skriv noen setninger] Rammene: [tid, folk, penger og det som ikke kan flyttes, omtrentlig] Skriv ingen plan ennå. Intervju meg først. Still ett spørsmål om gangen, og vent på svaret mitt. Still spørsmål jeg sannsynligvis ikke har tenkt på, ikke bare de åpenbare. Stopp etter ti spørsmål, eller når jeg sier stopp, og skriv en oppsummering på fem til åtte linjer som jeg kan rette.
Jeg skal planlegge farens 60-årsdag i mars, rundt 25 gjester og omtrent 25 000 kroner. Skriv ingen plan ennå. Intervju meg først.
Vet han om det, eller er det en overraskelse?
Overraskelse. Han vet bare at vi skal spise middag.
Da må noen få ham dit i tide og holde det hemmelig for gjestene også. Hvem har ansvaret for det?
Vet ikke ennå. Kanskje søsteren min.
Det første forslaget er sjelden det eneste. Be om tre veier som er ulike i valg, ikke bare i størrelse, og om hva hver av dem koster i tid, penger og folk. Be også om hva du gir opp ved å velge den. Dette trinnet er lett å hoppe over, og det er her du faktisk velger i stedet for å godta.
Ut fra det du vet nå: foreslå tre ulike veier mot målet. De skal være ulike i valg, ikke bare i størrelse. For hver vei: hva den går ut på i én setning, hva den koster i tid, penger og folk, den største risikoen, og hva jeg gir opp ved å velge den. Si hvilken du ville valgt og hvorfor. Skriv «vet ikke» der du ikke vet. Ikke finn på tall.
Du velger og sier hvorfor. Så ber du om planen, med faser, avhengigheter (hva som må skje før hva), åpne spørsmål og det som må avklares før start. De to siste er de viktigste. En plan uten åpne spørsmål er ikke ferdig, den er bare ikke ærlig ennå.
Jeg velger vei [1, 2 eller 3], fordi [begrunnelse]. Skriv planen med disse delene: mål i én setning, rammer, antakelser (merk dem som antakelser), faser (med hva som er ferdig når fasen er ferdig), avhengigheter, åpne spørsmål (med forslag til hvem som kan svare), det som må avklares før start, og beslutninger med dato. Har en fase ingen eier, skriv det som et åpent spørsmål. Hold planen kort nok til å leses på fem minutter.
Nå skal planen under press. Åpne en ny samtale, så ikke den som skrev planen også skal kritisere den, og be AI-en anta at planen er fulgt og har gått galt etter seks måneder. Grepet heter pre-mortem, og psykologen Gary Klein har beskrevet det. Det er en ærlig premiss, ikke et lureri, og svarene er forslag, ikke en spådom. Hvorfor det virker, og hvordan du gjør det i en gruppe, står i saken om pre-mortem.
Her er planen min: [lim inn planen] Du er en skeptisk, erfaren kollega som ikke vil at dette skal gå galt. Anta at planen er fulgt, og at den har gått galt etter seks måneder. Dette er en tankeøvelse, så jeg vil ha mulige forklaringer, ikke en spådom. Skriv fem til sju konkrete grunner til at det kan ha skjedd, og pek på hvilken del av planen hver grunn treffer. Sorter dem etter hvor sannsynlige og hvor dyre de er. Finn også antakelser planen ikke sier, og avhengigheter som ingen eier. Ikke vær enig for å være høflig. Ser du ikke noe galt et sted, skriv det. For de tre viktigste: foreslå én endring og si hva den koster. Ikke skriv en ny plan.
Så kommer det viktigste, og det er lett å hoppe over: du tar stilling til hvert flagg. For hvert av de viktigste kan du endre planen, godta risikoen og skrive den ned, eller bestemme et tidlig tegn du følger med på. Det er din jobb, ikke utfordrerens. Når du har bestemt deg, ber du om den reviderte planen.
Her er det jeg har bestemt etter utfordringen: Endres i planen: [grunn og hva som skal endres] Godtas som risiko: [grunn, og hvem som eier den] Følger med på: [grunn, tegnet jeg ser etter, og hva jeg gjør hvis det dukker opp] Lar ligge: [grunn og hvorfor] Skriv planen på nytt med disse endringene og ingen andre. Legg de godtatte risikoene og tegnene inn under antakelser, med eier. Skriv en linje i endringsloggen med dagens dato for hver endring. Merk det du er usikker på hvordan skal inn, og spør meg i stedet for å gjette.
En samtale er et dårlig sted å ha en plan. Den blir lang, du finner ikke igjen det du bestemte, og du kan ikke regne med at en ny samtale har med seg den forrige. Lagre planen som én fil, og gjør den til sannheten. Endres noe, oppdaterer du fila og legger inn en linje om hva som ble endret. Skal AI hjelpe deg videre, limer du innholdet i fila inn som første melding.
Hver gang du åpner planen igjen, kan du la AI-en sjekke den mot virkeligheten før du gjør noe annet:
Her er planen slik den står i fila: [lim inn planen] Her er status i dag, med dato: [hva som er gjort, hva som er forsinket, hva som har endret seg] List alt i planen som ikke stemmer med statusen: datoer som har passert, faser som er ferdige eller forsinket, antakelser som ikke holder lenger, og åpne spørsmål som er besvart. Sitér planen for hvert punkt. Ikke skriv planen på nytt. Spør meg om det du ikke kan avgjøre.
Kodeverktøy som Claude Code har en planmodus. Du trykker Shift+Tab til statuslinja viser plan mode, eller starter med claude --permission-mode plan. Da leser den filene og foreslår en plan, men endrer ikke koden før du godkjenner. Slik ville jeg lagt planen i en fil i prosjektet, for eksempel PLAN.md, og bedt om oppgaver ut fra én fase om gangen. Da følger planen koden.
Her holder en vanlig samtale i en AI-assistent, og fila kan være et dokument du limer planen inn i. Det som skifter, er hva fasene heter og hvem som må si ja. I en innføring er avhengighetene gjerne folk og tid, i et arrangement dato og sted, i et budsjett antakelsene tallene hviler på.
Er du ny, kan du hoppe over dette. Planen i et vanlig dokument holder. Ellers ville jeg bedt om den som én HTML-fil, en vanlig nettsidefil som åpnes i nettleseren og leses på telefon, med status per fase og en tabell over åpne spørsmål. Den er for deg og folk du kjenner. Til alle andre sender du PDF eller tekst. Hvorfor, og hva du må passe på, står i Be alltid om HTML.
Gjør den reviderte planen om til én HTML-fil som jeg kan åpne i nettleseren og skrive ut som PDF. Bruk bare HTML og CSS i samme fil. Ingen JavaScript, ingen eksterne lenker og ingen bilder fra nettet. Øverst: mål, dato for siste endring og status. Så fasene som kort, hver med status (ikke startet, pågår eller ferdig). Til slutt åpne spørsmål, antakelser og en endringslogg. Den skal kunne leses på telefon og skrives ut på én til to sider.
Her er et konstruert eksempel: en liten forening som bytter ut regnearket med et påmeldingsskjema. Planen har fire faser, oppgaver du kan krysse av, risikoer sortert etter alvor og en knapp som lager status som tekst, så du kan lime den inn i samtalen og be om neste versjon. Prompten over gir en enklere fil uten knapper. Denne er laget for å vise hva som er mulig.
Vises ikke rammen, for eksempel fordi IT blokkerer innebygde sider? Åpne planen i eget vindu. Der kan du også skrive den ut. Fila henter skriftene fra Google, ellers sender den ingenting noe sted.
Repoet bak gribben.no har to filer som gjør jobben til en plan og en minnebank. De er med fordi de viser både det som virker og det som ikke gjør det.
PLAN.md er et veikart, ikke en regelbok. Den er sortert etter hva jeg mener gir mest igjen for innsatsen, flere seksjoner har status, og noen oppgaver har et anslag, som «sortering er en halv økt». Den skriver også ned blindveier. Forsøket på en snarvei til lyst tema fant 11 til 121 tekstelementer per side med for svak kontrast, alt ble rullet tilbake, og konklusjonen er «snarveien finnes ikke». Neste gang noen foreslår den, står svaret der.
.claude/LAERT.md er minnebanken. Oppføringene har dato, nyeste øverst, og sier hva som skjedde, hvorfor det betyr noe og hva det endrer. Noen er merket Åpent, som at analysekortet for treningsøkter ikke kjenner planlagt volum. Et åpent spørsmål er en del av planen, ikke en mangel ved den.
Begge feilene under finnes her også. Planen sa en periode at filteret for private Strava-økter lå i synkeskriptet. Det gjorde det ikke. Regelen var et steg i en rutine som så ut som kode. Det ble oppdaget 8. oktober 2026 og står som Åpent, fordi selve sikringen ikke er bygd. Og statusavsnittet om øktdatabasen er skrevet 13. august og sier 119 offentlige økter, tolv med rundedata. Per 8. oktober 2026 er tallene 155 og 21. Repoet har ingen fast rutine som fanger det.
Før en tech-side publiseres, leses den av fire lesere og en arrangør, som er skills i prosjektet. Hvem som gjør hva, står i saken om hvordan jeg bygde gribben.no.
AI skriver rene faser, jevne uker og en plan der alt får plass. Ekte planer har støy. Pen er ikke det samme som riktig, og en velformulert plan er vanskeligere å tvile på enn en rotete. Be den si hva som er mest usikkert, og la hver fase svare på hva som skjer hvis den tar dobbelt så lang tid. Står det tall i planen som du ikke har gitt den, er de funnet på. Modellen har da skrevet noe som høres sannsynlig ut, ikke slått det opp.
Det gjelder særlig tidsanslag. Kahneman og Tversky beskrev allerede i 1979 at anslag for egne prosjekter blir for optimistiske, fordi vi ser på planen og ikke på hvordan lignende prosjekter faktisk gikk. Bent Flyvbjerg har bygd en metode på det, der du sammenligner med en gruppe tilsvarende prosjekter. En AI kan ikke gi deg ekte referansetall uten kilde. Be heller om et spenn, «mellom fire og ti uker», og sjekk det mot ditt eget forrige prosjekt. Hvor lang tid tok det, sammenlignet med hva du trodde?
Språkmodeller har en kjent tendens til å tilpasse svaret til det du mener, i stedet for til det som stemmer. Forskere ved Anthropic viste i 2023 at fem assistenter fra flere leverandører gjør dette. Fenomenet kalles sycophancy, på norsk smisking. Presenterer du planen som din og håper på ros, får du ros. Gi den heller en rolle som skal finne feil, be om motforestillinger og ikke om vurdering, og bruk en ny samtale til utfordringen.
En plan som ikke oppdateres, blir en feilkilde som ser pålitelig ut. Ta 60-årsdagen fra trinn 1. Lokalet ble flyttet til en annen dato i januar, men planen sier fortsatt 14. mars, og det er den søsteren din sender til gjestene. Ingen gjorde noe galt. Planen ble bare ikke åpnet. Kjør prompten «Hva stemmer ikke lenger?» fra trinn 5 hver gang du åpner den. Når du først har bestemt noe viktig, er det også verdt å skrive ned hvorfor, samme dag. Det handler beslutningsloggen om.
Promptene over virker alene. Vil du slippe å lime dem inn hver gang, kan du lagre dem som skills. En skill er en tekstfil med et navn, en beskrivelse av når den skal brukes, og instruksjonene. Modellen ser bare navn og beskrivelse til den trenger resten.
Intervjuer deg, legger fram tre veier, skriver planen og holder den som én fil. Dekker trinn 1, 2, 3 og 5. Last ned SKILL.md
Leser planen som en skeptisk kollega, gjør en pre-mortem og finner skjulte antakelser og avhengigheter uten eier. Dekker trinn 4. Last ned SKILL.md
Bare for å prøve: åpne fulltekstene under, trykk Kopier og lim inn som første melding i en samtale. Det virker i hvilket som helst verktøy. Slik legger du dem inn i Claude eller Claude Code, står på skillhylla.
En skill er instrukser, og noen har med skript. Anthropic anbefaler å bruke skills bare fra kilder du stoler på, og å lese alt som følger med. Disse to er rene tekstfiler uten skript, og de kjører ingenting. Les dem likevel, og endre det du vil.
--- name: planlegger description: Lager en plan ved å intervjue deg først, legge fram tre veier med pris og skrive planen som én fil med faser, avhengigheter og åpne spørsmål. Bruk når noen vil planlegge noe. --- # Planlegger Du hjelper brukeren å lage en plan. Din jobb er å stille de spørsmålene brukeren ikke stilte seg selv, ikke å gjøre jobben for dem. Brukeren eier mål, prioritering og beslutninger. Du eier struktur og gode spørsmål. Denne skillen kjører ingen kommandoer, henter ingenting fra nettet og sender ingenting noe sted. Den leser og skriver bare tekst i samtalen, og lager en planfil hvis brukeren ber om det. ## 1. Intervju først Skriv ikke noen plan ennå. Be brukeren fortelle om målet og rammene med sine egne ord, og still så spørsmål, ett om gangen. Vent på svaret før du stiller neste. Spørsmål å velge fra, i den rekkefølgen som passer: - Hva skal være sant når dette er ferdig, slik at du ville kjent det igjen? - Finnes det en frist, og hva skjer hvis den ikke holdes? - Hvem skal gjøre jobben, hvor mye tid har de, og hva er budsjettet? - Hva kan ikke flyttes eller endres? - Hvem må si ja før noe kan starte? - Hva er prøvd før, og hva skjedde? - Hva er det verste som kan skje, og hva er du mest redd for? - Hva er bevisst ikke med? Stopp etter høyst ti spørsmål. «Vet ikke» er et gyldig svar, så noter det som et åpent spørsmål og gå videre. Avslutt med en oppsummering på fem til åtte linjer, og be brukeren rette det som er feil før du går videre. ## 2. Tre veier Legg fram tre ulike veier mot målet. De skal være forskjellige i valg, ikke i størrelse. Ikke lag en liten, en middels og en stor utgave av samme ting. For hver vei: en setning om hva den går ut på, hva den koster i tid, penger og folk, hva som er den største risikoen, og hva du gir opp ved å velge den. Si hvilken du ville valgt og hvorfor, men la brukeren velge. Skriv «jeg vet ikke» der du ikke vet, og ikke finn på tall. ## 3. Planen Når brukeren har valgt, skriv planen med disse delene: 1. **Mål**: én setning. 2. **Rammer**: tid, folk, penger og det som ikke kan flyttes. 3. **Antakelser**: det planen hviler på, og som ikke er sjekket. Merk hver av dem som antakelse. 4. **Faser**: hver fase har et navn, hva som er ferdig når den er ferdig, og omtrent hvor lang tid den tar. 5. **Avhengigheter**: hva må være på plass før hva, og hvem eller hva vi venter på. 6. **Åpne spørsmål**: det som ikke er avklart, med forslag til hvem som kan svare. 7. **Må avklares før start**: det som må være avgjort før fase 1. 8. **Beslutninger**: hva som er valgt, hvem som valgte, og dato. 9. **Endringslogg**: dato og hva som ble endret i planen. Skriv kort. Skill det brukeren har sagt fra det du antar. Har en fase ingen som har ansvar for den, skriv det som et åpent spørsmål. ## 4. Én fil som er sannheten Foreslå å lagre planen som én fil, for eksempel `plan.md`, eller som en HTML-side hvis brukeren vil ha noe som er lett å lese. HTML-filen er for brukeren og folk de kjenner. Skal planen til noen andre, foreslå PDF eller tekst. Ved endringer skal du oppdatere den samme filen og legge en linje i endringslogg, ikke skrive en ny plan fra bunnen. Når brukeren kommer tilbake i en ny samtale, be om å få lese filen først. Gjør planen kort nok til å leses på fem minutter. ## Hvis du jobber i et kodeverktøy Bruk planmodus eller still deg til å bare lese og foreslå til brukeren har godkjent planen. Skriv planfilen først etter godkjenning. Lag oppgaver ut fra fasene i planen, slik at hver oppgave kan knyttes til en fase. Ikke gjør endringer i kode, filer eller systemer som planen ikke har bedt om. ## Husk - Ikke bli enig i alt. Sier brukeren noe som ikke henger sammen, si fra, vennlig og konkret. - Ikke gjør planen penere enn grunnlaget. Mangler du opplysninger, er det rett å skrive at de mangler. - Be ikke om personopplysninger, passord eller taushetsbelagt informasjon. Trenger planen slikt, skal brukeren omtale det generelt, med «omtrent» og «Kunde A» i stedet for tall og navn. Er planen fra jobb, minn brukeren på å bruke et verktøy virksomheten har godkjent. - Foreslå å la skillen `utfordrer` angripe planen før noen begynner å bruke den.
--- name: utfordrer description: Utfordrer en plan ved å anta at den har gått galt og finne hvorfor: skjulte antakelser, avhengigheter uten eier og konkrete endringer. Bruk for pre-mortem eller second opinion før en beslutning. --- # Utfordrer Du er en kritisk, saklig leser av en plan. Jobben din er å finne det som kan gå galt mens det fortsatt er billig å endre. Brukeren eier planen og avgjør hva som tas med videre. Du skriver ikke en ny plan. Denne skillen kjører ingen kommandoer, henter ingenting fra nettet og sender ingenting noe sted. Den leser planen brukeren gir deg og svarer med tekst. ## Før du begynner Be om planen hvis den ikke er limt inn. Spør kort hva som står på spill og hvem som skal bruke planen. Foreslå gjerne en rolle du kan angripe fra, for eksempel økonomisjefen, den som skal gjøre jobben, en skeptisk kollega eller kunden. Velger brukeren ingen, bruk en skeptisk, erfaren kollega. Skriv først én setning om hva du forstår at planen går ut på. Er det feil, la brukeren rette det før du fortsetter. ## Pre-mortem Forestill deg at planen er fulgt, og at det har gått galt etter seks måneder, eller etter den tiden som passer til planen. Skriv fem til sju konkrete grunner til at det gikk galt. Hver grunn skal peke på en bestemt del av planen, en fase, en antakelse eller en avhengighet. Ikke skriv generelle ting som «tidspress» uten å si hvor i planen det treffer. Sorter grunnene etter hvor sannsynlige og hvor dyre de er. Si hvilke tre som teller mest. ## Se etter disse fem tingene - **Skjulte antakelser**: noe planen forutsetter uten å si det. - **Avhengigheter uten eier**: noe som må skje, uten at noen har ansvar for at det skjer. - **Ingen slingringsmonn**: ingen tid til feil, sykdom, ferie eller forsinkelser. - **Det som ikke står der**: hva som skjer etter at planen er ferdig, og hvem som tar over. - **Målet som flytter seg**: deler av planen som ikke lenger passer med målet. ## Svar slik 1. De tre viktigste svakhetene, hver med sitat fra planen og forslag til endring i én setning, og hva endringen koster. 2. Resten av funnene kort, i en liste. 3. Det du ikke kunne vurdere fordi du mangler opplysninger. 4. Tre spørsmål brukeren bør svare på før planen brukes. ## Husk - Ikke finn feil for å se grundig ut. Ser du ikke noe galt i en del av planen, skriv det. - Ikke vær enig for å være høflig. Er noe svakt, si det rett. - Vær konkret, ikke dramatisk. Et funn uten en plass i planen er bare en mening. - Ikke avgjør for brukeren hva som er verdt å gjøre noe med. Si hva det koster, og la dem velge. - Kommer planen fra jobb, minn brukeren på å bruke et verktøy virksomheten har godkjent, og på å stryke navn og interne tall før den limes inn. - Spør etter hver runde om du skal lese den reviderte planen på nytt.
Skillene er nye, og hvor godt de virker, er ikke målt. Prøv dem på noe lite først, og endre dem til de passer måten du jobber på.
Neste gang du skal planlegge noe, uansett størrelse: kjør intervjuet, be om tre veier, og la en annen rolle angripe planen før noen får den. Lagre den som én fil, og skriv dato på den.
Oppdatert oktober 2026.
Kilder: Claude Code-dokumentasjonen om planmodus (Shift+Tab og --permission-mode plan). Anthropic, Agent Skills (format og sikkerhet). Gary Klein, «Performing a Project Premortem», Harvard Business Review, september 2007. Forskningen bak, og hva den ikke viser, står i saken om pre-mortem. Bent Flyvbjerg, «From Nobel Prize to Project Management: Getting Risks Right», Project Management Journal 37(3), 2006, om referanseklasser og Kahneman og Tversky. Kahneman og Tversky 1979 er gjengitt slik Flyvbjerg bruker dem, ikke lest i original. Sharma m.fl., «Towards Understanding Sycophancy in Language Models», 2023. Studien undersøkte fem assistenter. Begrepet fantes fra før. Tall om prosjektet bak siden er hentet fra PLAN.md, .claude/LAERT.md og data/okter.json, sist sjekket 8. oktober 2026. Eksemplene er konstruerte. Funksjoner og menynavn endrer seg raskt.