Hvorfor micromanagement af dine AI-agenter faktisk gør dem dummere

Åbn en tilfældig system_prompt.txt fra et moderne GitHub-repo i dag, og hvad ser du? Som regel er det en panisk mur af tekst. "Gør IKKE X. Du SKAL outputte præcis tre punkter. Brug ALDRIG dette bibliotek."

Udviklere behandler de mest avancerede ræsonnementsmotorer i menneskets historie som skrøbelige regex-scripts.

Denne paranoia giver historisk set god mening. For bare et år eller to siden krævede tidlige LLM'er, at man holdt dem i hånden hele vejen, bare for at de ikke mistede tråden. Men tiderne har skiftet. Moderne modeller er utroligt kloge, og alligevel skriver vi stadig prompts, som om vi programmerer en mikroovn fra 80'erne. Vi forsøger at hardcode intelligens.

Der skete noget fascinerende for nylig ovre hos Vercel, som beviser netop dette. Deres udviklerteam udgav en gennemgang af, hvordan de forbedrede deres v0-produkt, og beskrev et kontraintuitivt træk: de fjernede 80 % af deres agents tools.

Resultatet? Systemet brød ikke sammen. Det blev faktisk meget bedre. Ved at fjerne de overstyrede tools og stive rammer, reducerede de forvirringen og gav modellen lov til at gøre det, den er bedst til – at ræsonnere sig frem til en løsning. Mindre friktion førte til bedre kode.

Der er en dyb lektion her for alle, der bygger med AI lige nu: Giv principper, ikke stive regler.

Når du fortæller en LLM præcis, hvad den skal gøre trin-for-trin, tvinger du den til at bruge sin begrænsede opmærksomhed (compute) på at overholde regler frem for at levere kvalitet. Du fratager den evnen til at bruge sin enorme mængde træningsdata til at finde en mere elegant løsning end den, du har hardcodet.

For at se forskellen, så kig på, hvordan de fleste udviklere skriver agent-prompts i forhold til, hvordan de burde skrive dem.

Den dårlige måde (Stive regler):

"Skriv en Python-funktion til at hente brugerdata. Du skal bruge requests-biblioteket. Du skal håndtere fejl med en try/except-blok. Du skal returnere et dictionary med præcis 'name', 'email' og 'status' som keys. Brug ikke async. Tilføj kommentarer til hver linje."

Den gode måde (Principper & Mål):

"Skriv en robust Python-funktion til at hente brugerdata. Foretræk moderne standardbiblioteker. Koden skal være production-ready, hvilket betyder, at den håndterer netværksfejl og edge cases elegant. Prioritér læsbarhed og ren arkitektur over smarte tricks. Downstream-systemet forventer standard brugerprofiler (name, email, status)."

Lægger du mærke til skiftet? Det første eksempel behandler AI'en som en juniorudvikler, man ikke kan stole på. Det andet behandler den som en seniorudvikler, der forstår målet og konteksten. Du fortæller den, hvordan et godt output ser ud og hvorfor, og så træder du et skridt tilbage og lader den finde ud af hvordan.

Der er selvfølgelig én stor undtagelse til denne regel.

Når agenter taler med andre agenter – eller når en upstream-agent sender data til en rigid downstream database-parser – har du brug for absolut stringens. Maskine-til-maskine-overleveringer kræver præcise, ufravigelige JSON-skemaer. Men til ræsonnement, generering og problemløsning? Løsn grebet.

Hvis du vil opgradere dine kodningsassistenter med det samme i dag, så kopier og indsæt præcis denne blok i din claude.md, memory.md eller din agents core system prompt:

## 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

Stop med at forsøge at mikrostyre maskinen. Stol på den moderne LLM. De er hurtigere, klogere og uendeligt meget mere kapable, når vi holder op med at behandle dem som småbørn.