Hvorfor mikrostyring faktisk gjør AI-agentene dine dummere

Åpne en tilfeldig system_prompt.txt fra et moderne GitHub-repo i dag, og hva ser du? Vanligvis er det en panisk vegg av tekst. "IKKE gjør X. Du MÅ returnere nøyaktig tre kulepunkter. ALDRI bruk dette biblioteket."

Utviklere behandler de mest avanserte resonneringsmotorene i menneskets historie som skjøre regex-skript.

Denne paranoiaen gir historisk sett mening. For bare et år eller to siden trengte tidlige LLM-er å bli holdt i hånden hele veien bare for å holde seg til temaet. Men tidene har endret seg. Moderne modeller er utrolig smarte, men vi skriver fortsatt prompter som om vi programmerer en mikrobølgeovn fra 1980-tallet. Vi prøver å hardkode intelligens.

Noe fascinerende skjedde nylig borte hos Vercel som beviser nettopp dette. Utviklingsteamet deres publiserte en gjennomgang av hvordan de forbedret v0-produktet sitt, og beskrev et kontraintuitivt trekk: de fjernet 80 % av agentens verktøy.

Resultatet? Systemet brøt ikke sammen. Det ble faktisk mye bedre. Ved å fjerne de overspesifiserte verktøyene og stive rammene, reduserte de forvirringen og lot modellen gjøre det den kan best – å resonnere seg gjennom problemet. Mindre friksjon førte til bedre kode.

Det ligger en dyp lærdom her for alle som bygger med AI akkurat nå: Gi prinsipper, ikke stive regler.

Når du forteller en LLM nøyaktig hva den skal gjøre steg for steg, tvinger du den til å bruke sin begrensede oppmerksomhet (compute) på å følge reglene fremfor å levere kvalitet. Du fratar den evnen til å bruke sine enorme mengder treningsdata til å finne en mer elegant løsning enn den du hardkodet.

For å se forskjellen, ta en titt på hvordan de fleste utviklere skriver agent-prompter kontra hvordan de burde skrive dem.

Den dårlige måten (stive regler):

"Skriv en Python-funksjon for å hente brukerdata. Du må bruke requests-biblioteket. Du må håndtere feil med en try/except-blokk. Du må returnere en dictionary med nøyaktig nøklene 'name', 'email' og 'status'. Ikke bruk async. Legg til kommentarer på hver linje."

Den gode måten (prinsipper og mål):

"Skriv en robust Python-funksjon for å hente brukerdata. Foretrekk moderne, standardiserte biblioteker. Koden skal være produksjonsklar, noe som betyr at den håndterer nettverksfeil og edge cases på en elegant måte. Prioriter lesbarhet og ren arkitektur fremfor smarte triks. Nedstrømssystemet forventer standard brukerprofiler (name, email, status)."

Legger du merke til skiftet? Det første eksempelet behandler AI-en som en juniorutvikler man ikke kan stole på. Det andre behandler den som en seniorutvikler som forstår målet og konteksten. Du forteller den hvordan et godt resultat ser ut og hvorfor, og så trer du tilbake og lar den finne ut hvordan.

Selvfølgelig finnes det ett stort unntak fra denne regelen.

Når agenter snakker med andre agenter – eller når en oppstrømsagent sender data til en rigid database-parser nedstrøms – trenger du absolutt strenghet. Maskin-til-maskin-overleveringer krever presise, ufravikelige JSON-skjemaer. Men for resonnering, generering og problemløsning? Slipp opp grepet.

Hvis du vil oppgradere kodeassistentene dine umiddelbart i dag, kopier og lim inn denne nøyaktige blokken i din claude.md, memory.md, eller agentens kjerne-systemprompt:

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

Slutt å prøve å detaljstyre maskinen. Stol på den moderne LLM-en. De er raskere, smartere og uendelig mye mer kapable når vi slutter å behandle dem som småbarn.