AI kan skrive en imponerende strategi på få sekunder. Den kan fylle siden med «AI-native», «autonome agenter», «personalisering», «plattform» og «datadrevet». Problemet kommer når teksten kunne passet like godt for en frisør i Ålesund, et industrielt vedlikeholdsteam og et globalt programvareselskap. Den høres riktig ut, men den hjelper ingen med neste beslutning.
Dette kalles ofte Trendslop: generiske, tidsriktige AI-råd som følger mønstre i treningsdata og offentlig samtale, men som ikke er bundet til virksomhetens faktiske kunder, økonomi, systemer, kompetanse eller risiko. Harvard Business Review beskriver hvordan nyere forskning fant systematiske skjevheter i LLM-råd om strategi, og advarer mot å behandle modellen som et nøytralt eksternt blikk. [1]
AI skal gjerne hjelpe dere å tenke bredere. Men den må ikke få late som om en glatt formulering er det samme som en beslutning som passer hos dere.
Denne artikkelen ligger under Teknisk fordypning, men poenget er praktisk: Når dere bruker AI til strategi, arkitektur eller større endringer, er ikke målet å få flest mulig ideer. Målet er å få et dokumentert forslag som kan testes, utfordres og brukes.
Slik kjenner du igjen Trendslop
Trendslop er ikke alltid direkte feil. Det er ofte mer krevende enn som så: Rådet er rimelig i teorien, men for vagt til å styre et valg. Det mangler prioriteringer, konkrete forutsetninger og ærlige grenser.
| Tegn i AI-svaret | Hvorfor det er et problem | Spørsmålet som gjør svaret bedre |
|---|---|---|
| «Bygg en AI-plattform» eller «bli AI-native» | Ingen vet hvilken oppgave som skal forbedres først. | Hvilken arbeidsflyt, for hvem, med hvilken målbar effekt? |
| «Automatiser kundereisen» | Rådet sier ingenting om systemer, rettigheter eller hva som kan gå galt. | Hvilke data får AI-en lese, og hvilke handlinger må godkjennes? |
| Én konklusjon uten alternativer | Dere ser ikke kostnad, risiko eller hva som må være sant for at rådet skal fungere. | Hvilke to realistiske alternativer finnes, og hva taler mot hver av dem? |
| Ingen kilder eller datoer | Strategien kan bygge på gamle antakelser eller oppdiktede detaljer. | Hvilket dokument, tall eller intervju støtter hvert viktig poeng? |
| «Dette vil spare tid» uten måling | Det blir umulig å prioritere eller vite om forsøket virket. | Hvilken baseline, hvilken eier og hvilken dato avgjør om vi fortsetter? |
For en liten bedrift på Sunnmøre betyr dette ofte å bytte spørsmålet «Hva bør AI-strategien vår være?» med noe mer krevende og nyttig: «Vi bruker for lang tid på å svare på henvendelser etter kl. 16. Hvilke tre løsninger kan redusere ventetiden uten at feil priser eller avtaler blir sendt?»
Først: bruk 4D til å definere oppdraget
Før dere bygger en skill, setter opp RAG eller ber en agent gjøre arkitekturanalyse, må dere bestemme hva AI-en skal bidra med. 4D-rammeverket gir en god start.
| 4D-steg | Spørsmål som stanser Trendslop tidlig |
|---|---|
| Delegering | Skal AI-en samle innsikt, foreslå alternativer, kvalitetssikre et utkast eller få gjøre en handling? Ikke bland alt i samme oppgave. |
| Beskrivelse | Hvilke kilder er godkjent, hvilken periode gjelder, hva betyr et godt svar, og hvilket format skal leveres? |
| Dømmekraft | Hvordan tester vi om rådet passer vår drift: mot tall, kundesamtaler, eksisterende arkitektur eller et avgrenset pilotprosjekt? |
| Aktsomhet | Hvem godkjenner, hvilke opplysninger må holdes utenfor, hva kan modellen ikke gjøre, og når skal den stoppe? |
Dette er mer enn en god prompt. Det er arbeidsbeskrivelsen som gjør at en modell kan være kreativ innenfor oppgaven uten å være fri til å dikte opp retning eller konsekvenser.
Bygg en skill som leverer et beslutningsgrunnlag — ikke en trendrapport
En skill er en gjenbrukbar arbeidsoppskrift for en bestemt type oppgave. Den kan ligge i en SKILL.md-fil, i en intern veiledning eller i et agentverktøy. Det viktige er ikke filnavnet. Det viktige er at samme arbeidsmåte, kilder og kvalitetskrav brukes hver gang.
En enkel skill for strategi eller arkitektur bør si:
- Oppdraget. Hva skal avklares, for hvilken virksomhet og innen hvilken tidsramme?
- Kildene. Hvilke dokumenter, tall, intervjuer og systemoversikter er autoritative — og hvilken dato har de?
- Arbeidsmåten. Modellen skal skille observerte fakta, antakelser, alternativer og anbefalinger.
- Motspørsmålene. Den skal alltid identifisere hva som kan gjøre anbefalingen feil, hva som mangler og hvem som må svare.
- Leveransen. Et kort beslutningsnotat med alternativer, konsekvenser, usikkerhet, eier og neste test — ikke en lang inspirasjonstekst.
En praktisk struktur kan for eksempel være en liten mappe med STRATEGI.md, ARKITEKTUR.md, BEGREPER.md og BESLUTNINGER.md. Hver fil bør ha eier, sist oppdatert dato og lenker til originale kilder. Da kan AI-en lese avgrenset, oppdatert kontekst i stedet for å gjette ut fra generelle mønstre.
Temperatur, vekter og modellvalg: nyttig finjustering, ikke en kur
Det er fristende å tro at en enkelt teknisk innstilling løser slop. Det gjør den ikke. Temperatur styrer hvor mye variasjon modellen tillater når den formulerer et svar; høyere temperatur gir normalt flere og mer varierte formuleringer, mens lavere temperatur gir mindre variasjon. [2] For strategi og arkitektur er det ofte klokt å teste med en stabil innstilling først, slik at dere kan se om forskjellen skyldes kilder og arbeidsflyt — ikke tilfeldig ordvalg.
| Begrep | Hva det faktisk styrer | God praksis mot Trendslop |
|---|---|---|
| Temperatur | Variasjon i hvordan modellen velger neste ord eller forslag. | Hold den stabil når dere sammenligner forslag. Bruk mer variasjon når dere bevisst vil utforske alternativer, og mindre når dere skal oppsummere dokumenterte fakta. |
| Modellvekter | De lærte parametrene i selve modellen. De er normalt ikke en knapp en vanlig bruker justerer i en strategiprosess. | Velg eller evaluer modell, eventuelt finjustering, bare mot reelle testoppgaver. Ikke prøv å «skru ned slop» ved å endre noe dere ikke kan måle. |
| Prioriteringsvekter | Regler for hva harnesset eller søket skal vektlegge, som kildens autoritet, dato, lokal relevans eller risiko. | Gi egne, oppdaterte og kildebelagte beslutninger høyere prioritet enn generelle blogginnlegg og trender. Gjør regelen synlig og testbar. |
| Top-p, format og systeminstruks | Hvor bredt modellen utforsker og hvordan den skal strukturere svaret. | Velg ett strukturert format med krav om kilder, antakelser, alternativer og åpne spørsmål. Evaluer svaret, ikke bare innstillingen. |
Noen moderne modeller og arbeidsmodi låser eller ignorerer bestemte samplinginnstillinger. Derfor må teamet alltid følge dokumentasjonen for verktøyet de faktisk bruker. Prinsippet består likevel: Kvaliteten kommer først fra oppgaven og konteksten, deretter fra innstillingene.
Bruk RAG og .md-filer når de løser et faktisk problem
RAG betyr at systemet henter relevante biter fra en kunnskapsbase før modellen svarer. Det er nyttig når dere har mange dokumenter og trenger å finne fram til riktig del i rett øyeblikk. Men RAG er ikke en garanti mot feil. Hvis kildene er gamle, fragmenterte eller feil merket, kan modellen bare hente frem gammelt eller irrelevant materiale på en mer overbevisende måte.
Anthropic anbefaler å behandle kontekst som en begrenset ressurs: bruk minst mulig, men høy-signals informasjon, og hent inn data målrettet når det trengs. [3] For en mindre og stabil kunnskapsbase kan hele, godt vedlikeholdte dokumenter ofte være enklere og mer pålitelig enn et avansert RAG-oppsett. [4]
| Situasjon | Start med | Hva dere må teste |
|---|---|---|
| Én strategi, ett prosjekt eller 5–20 sentrale dokumenter | Gode .md-filer og en fast kildeoversikt. | Om modellen siterer riktig dokument og merker det den ikke vet. |
| Mange historiske dokumenter, rutiner og versjoner | RAG med metadata for eier, dato, system, tilgangsnivå og dokumentstatus. | Om søket henter riktige kilder for spørsmålene dere faktisk stiller. |
| Tall eller status som endrer seg ofte | Direkte, godkjent datakilde eller et kontrollert verktøyoppslag. | Om tidspunkt, datagrunnlag og eventuelle feil i integrasjonen vises i svaret. |
| Kritiske beslutninger med flere kilder | En kombinasjon: faste styringsfiler, målrettet søk og menneskelig kontroll. | Om konklusjonen skiller tydelig mellom fakta, tolkning og beslutning. |
Gi hvert RAG-dokument en enkel kontekstlinje, som «Rutine for tilbud — eies av salg — oppdatert 2026-08-15 — gjelder kun Norge». Slike små detaljer gjør det mye vanskeligere for modellen å blande sammen gammel politikk, utkast og gjeldende beslutning.
Harnesset er slop-filteret mellom spørsmål og beslutning
Et harness er rammen rundt modellen: hvilke filer den kan lese, hvilke verktøy den kan bruke, hvilken rekkefølge den arbeider i, og hvordan resultatet testes. I artikkelen om AI-orkestrering beskriver vi hvorfor modellen bare er én del av løsningen. Her er en enkel variant for strategiarbeid:
- Hent kontekst. Les kun godkjente kilder og skriv opp hvilke som ble brukt.
- Formuler problemet. Gjenta oppgaven med avgrensninger, dato og mål før analysen starter.
- Lag alternativer. Foreslå minst to realistiske veier, ikke bare den mest moderne.
- Utfordre forslaget. Let etter manglende fakta, lokale forhold, kostnader, personvernspørsmål og arkitekturkonsekvenser.
- Lever beslutningsnotat. Skill fakta, antakelser, anbefaling, risiko og spørsmål som må besvares av en ansvarlig person.
- Evaluer. Sammenlign notatet mot en enkel fasit eller menneskelig vurdering før arbeidsmåten brukes igjen.
Dette ligner en god rådgiverprosess. AI-en får lov til å foreslå, men den må vise arbeidsgrunnlaget sitt og tåle motspørsmål. Hvis den ikke har nok kontekst, er et godt svar «jeg vet ikke ennå» — ikke en oppdiktet strategipassasje.
Test for bedre beslutninger, ikke bare penere tekst
Lag et lite sett med reelle spørsmål fra virksomheten. Det kan være «skal vi bygge et eget kundeområde eller rydde i dagens bookingflyt først?» eller «hvilke tre datakilder trenger vi før vi automatiserer oppfølging av henvendelser?». Kjør samme spørsmål med en tom chat, med .md-filer, og med harnesset deres.
Vurder deretter svaret på fire ting: Brukte det riktige kilder? Passet anbefalingen virksomhetens begrensninger? Viste det hva som er usikkert? Gav det et neste steg som noen faktisk kan eie? Når dere ser forskjellen, blir det tydelig at målet ikke er å fjerne all kreativitet. Målet er å rette kreativiteten mot et konkret problem.
Proseskartlegging før AI hjelper dere å finne oppgaven. Loop Engineering viser hvordan måling og tilbakemelding kan gjøre resultatene bedre for hver runde.
Det korte rådet
Når AI-strategien føles smart, men ikke hjelper dere velge: Ikke be om en lengre rapport. Gi modellen færre, bedre og ferskere fakta. Definer hva svaret skal brukes til. Krev alternativer og motargumenter. Legg inn en enkel evaluering. Og behold beslutningsansvaret hos menneskene som må leve med konsekvensene.
Det er slik dere går fra Trendslop til AI-arbeid som faktisk passer virksomheten deres.
Bruk den ferdige anti-Trendslop-skillen
Kakushin har publisert en åpen Anti-Trendslop Skill på norsk. Den kan brukes som et startpunkt når et team skal lage strategi, arkitektur, kode- eller agentarbeidsflyter som må være konkrete og testbare. Skillen inneholder mal for beslutningsnotat, eksempler på progressiv kontekst, RAG, temperatur og prioriteringsvekter, eval-drevne loops, bakgrunnsagenter, self-healing tester, agent CI/CD, flere agenter og multi-repo-orkestrering.
Den korte videoen Loop Engineering 101 Explained illustrerer oppdagelse, planlegging, utførelse, verifisering og iterasjon. Se den som en praktisk visualisering av en lukket loop, ikke som en oppskrift på ubegrenset autonomi eller en ytelsesgaranti.
For en praktisk grunnmur under skills, prosjektfiler og kontrollmekanismer, se Harness Engineering fra grunnen av. Den viser hvordan kontekst, minne, testing og avgrenset scope kan organiseres uten å starte med en stor plattform.
Kilder
[2] Claude Platform Docs — Glossary: Temperature
[3] Anthropic Engineering — Effective context engineering for AI agents
[4] Anthropic Engineering — Introducing Contextual Retrieval
[5] Mo Bitar på YouTube — Harvard just discovered what AI actually is