5 principper for directed agentic engineering
I min forrige artikel beskrev jeg det valg: over eller under algoritmen. Tool User eller Solution Provider. Jeg tror stadigvæk på, at fremtiden er Agentic, men for at vi vedbliver med at være over algoritmen skal vi sikre os, den bliver directed. Agentic engineering uden retning risikerer bare at resultere i hurtigere kaos. Directed Agentic Engineering handler om at sikre, at mennesker sætter rammerne, før AI eksekverer inden for dem.
Men hvad er de rammer egentlig, og hvordan ser de ud i praksis? Jeg har destilleret det ned til fem principper.
1. Tænk før du handler
Det lyder banalt, men det er det princip jeg selv oftest har set blive sprunget over. Også af mig. Når AI kan producere kode på sekunder, er fristelsen at starte med det samme. Men hastighed uden retning er bare mere output, ikke produktivitet.
Før en AI-agent rører en linje kode, skal vi vide hvad vi bygger og hvorfor. Ikke i detaljer, men klart nok til at vi kan vurdere, om resultatet er rigtigt. Det kræver, at nogen sætter sig ned og tænker, frem for at prompte.
2. Gør intentionen eksplicit
Tænkning der ikke er skrevet ned er usynlig for en agent. Og ærligt talt også for resten af teamet. Directed Agentic Engineering kræver at intentionen er eksplicit: hvad er scope, hvad er den forventede adfærd, hvad er begrænsningerne, hvad er acceptkriterierne.
Det er ikke 200-siders kravdokumenter. Det er specifikationer der er præcise nok til at en AI-agent kan implementere mod dem. Det er arkitekturbeskrivelser der fanger den tilsigtede struktur og vedligeholdes løbende. Arkitekturen er partituret, som orkestret spiller efter, ikke et billede, der hænger på væggen.
Jeg tror arkitekturen, de tekniske beslutninger og standarderne skal være på plads, før agenter begynder at bygge. Ikke fordi alt skal være perfekt, men fordi agenter uden et fundament træffer deres egne beslutninger. Og de beslutninger er ikke nødvendigvis konsistente med hinanden eller med det der allerede eksisterer.
Et konkret eksempel: dit team skal bygge en ny API-integration. Uden et fundament prompter du din AI-agent med "byg en integration til X" og håber på det bedste. Med specifikationer og en arkitekturbeskrivelse har agenten rammer: følg teamets konventioner for error handling og autentificering, skriv integrationstests der dækker edge cases, og dokumentér beslutninger i en ADR (Architecture Decision Record), hvis der er afvigelser fra standarden. Samme opgave, men agenten opererer inden for rammer i stedet for at gætte.
Tilsammen sikrer specs og arkitektur at tre spørgsmål er besvaret før enhver leverancecyklus:
- Hvad bygger vi? Scope, capabilities og begrænsninger.
- Hvordan skal det bygges? Arkitektur, mønstre og tekniske beslutninger.
- Hvordan ved vi det er rigtigt? Acceptkriterier, sporbarhed og review gates.
Når de tre spørgsmål er besvaret i dokumentation som AI kan operere inden for, bliver eksekvering hurtig, aligned og reversibel. Når de ikke er det, hjælper AI bare med at afvige hurtigere end antaget.
For arkitekter betyder det et skift. Vi bruger mindre tid på at tegne og præsentere. Mere tid på at skrive specifikationer og arkitekturbeskrivelser som agenter faktisk kan arbejde inden for. Det er et andet håndværk, men det er stadig arkitektur. Og det er vigtigere end nogensinde.
3. Gør viden operationel
Første gang jeg skrev en skill ned, føltes det som at dokumentere noget selvfølgeligt. Men da en kollega kunne følge proceduren uden at spørge mig, gik det op for mig hvad der var sket: erfaringen var ikke længere låst fast i mit hoved.
Tænk på en skill som en kodificeret procedure. En opskrift der beskriver præcist, hvordan en bestemt opgave skal løses: hvad er input, hvilke trin skal følges, hvad er output, og hvilke kvalitetskriterier gælder. Det er ikke prosa eller guidelines. Det er en procedure der er præcis nok til at både et menneske og en AI-agent kan følge den.
Skills er også akkumuleret praksis: hver skill repræsenterer et stykke erfaring, der ikke længere behøver at blive genopdaget.
Playbooks er det næste niveau. Hvor en skill håndterer en specifik opgave, orkestrerer en playbook en hel arbejdsgang. En playbook definerer hvornår et workflow begynder, hvad det kræver som input, hvilke skills der bruges undervejs, og hvad det producerer som output.
Rent praktisk er skills og playbooks markdown-filer. Struktureret tekst som ligger i dit repository sammen med koden. Når du starter en AI-agent, fx Claude Code eller Cursor, kan den læse disse filer og følge procedurerne. Det er ikke et nyt værktøj du skal købe eller en platform du skal implementere. Det er tekst, versioneret i git, som udvikler sig sammen med projektet. Tærsklen for at komme i gang er lav. Værdien vokser med hver procedure der bliver skrevet ned.
Uden playbooks genopfinder hvert projekt de samme processer. Med dem er den akkumulerede erfaring tilgængelig fra dag ét. Forskellen på vibe coding og directed agentic engineering ligger her. Vibe coding er "gør noget for mig." Directed agentic engineering er at sige "her er partituret, følg det."
Vibe coding er "gør noget for mig." Directed agentic engineering er at sige "her er partituret, følg det."
4. Mennesket tager de kritiske beslutninger
Jo hurtigere AI eksekverer, desto vigtigere bliver de øjeblikke, hvor den ikke eksekverer. Human gates: punkter i en playbook hvor et menneske skal godkende, justere eller beslutte, før processen fortsætter.
Det er her dirigenten i orkestret kommer ind. Dirigenten spiller ikke hvert instrument, men bestemmer tempo, dynamik og fortolkning. Uden en dirigent kan musikerne spille teknisk perfekt og stadig producere noget, der ikke hænger sammen.
Det samme gælder for AI-agenter. De kan implementere teknisk korrekt kode der løser det forkerte problem, følger det forkerte mønster, eller bryder en beslutning der blev taget tre sprints tidligere. Human gates er der, hvor mennesket sikrer sammenhæng. Ikke ved at kontrollere hver linje, men ved at validere retning, arkitektur og intention ved de afgørende punkter.
5. Eksekvér i små, reversible skridt
Store ændringer er svære at validere og svære at rulle tilbage. AI-agenter der kan producere tusindvis af linjer kode på minutter gør det problem værre, ikke bedre. Disciplinen, som vi forsøger at følge, er at holde hvert skridt lille nok til at et menneske kan vurdere det, og reversibelt nok til at det kan fortrydes uden konsekvenser. Det er sværere end det lyder.
En playbook for at levere en ny feature illustrerer det: agenten læser specifikationen og arkitekturbeskrivelsen, genererer en implementeringsplan, implementerer i små skridt, kører tests efter hvert skridt, og producerer et review-summary med sporbarhed tilbage til specifikationen.
Mellem hvert skridt er der et kontrolpunkt. Før implementering begynder: er planen rigtig? Efter hvert skridt: matcher resultatet intentionen? Ved afvigelser: er det en bevidst beslutning eller en fejl?
Hvad nu?
Fem principper. Ingen af dem er revolutionerende i sig selv. Det der er nyt, er at de nu kan kodificeres og operationaliseres på en måde der ikke var mulig for et år siden. Skills og playbooks gør det muligt at omsætte principper til praksis, som både mennesker og AI-agenter kan følge.
I min næste artikel vil jeg vise, hvordan det ser ud i en konkret leverancecyklus. Hvordan fungerer samspillet mellem arkitekt, specs, skills og playbooks i et rigtigt projekt?
Indtil da: overvej hvor meget af din nuværende praksis der er kodificeret nok til at en agent kan følge den. Hvis svaret er "ikke meget", så er det et godt sted at starte.
Hvad er jeres erfaring? Er I begyndt at tænke i skills og playbooks, eller er det stadig vibe coding der driver?