Fra principper til praksis
AI-agenter kan bygge kode hurtigt. Men hastighed er ikke det samme som retning. Og de fleste processer vi bruger i dag er ikke designet til en verden hvor agenter er en del af teamet. Uden en model for hvordan afgrænsning, arkitektur og leverance hænger sammen i en agentic verden, accelererer man bare i tilfældige retninger.
Jeg har bygget en konkret model. Jeg kalder den Conductor Model. Den bygger på de principper jeg beskrev i mine forrige artikler (del 1, del 2).
De fleste kender efterhånden til skills, kodificerede procedurer som en AI-agent kan følge. Playbooks er en udvidelse af skills: hvor en skill håndterer en specifik opgave, orkestrerer en playbook en hel arbejdsgang fra start til slut. Og roller sørger for at arkitekten, tech lead'en og produktejeren har klare ansvarsområder. Alt sammen markdown-filer i repositoryet, som både mennesker og AI-agenter kan følge.
I denne artikel vil jeg vise, hvordan modellen fungerer. Først det typiske udviklingsflow. Derefter det lange lys og den udforskning der kommer før.
Filosofien
Conductor Model bygger på en simpel overbevisning: tænk før du koder. Definér arkitekturen før agenter implementerer den. Skriv specifikationerne præcist nok til at en agent kan arbejde inden for dem. Byg i små iterationer, hvor mennesket validerer ved hvert afgørende punkt. Og kodificér den viden du opbygger, så den er tilgængelig næste gang. Det hviler på to bærende principper. Architecture-driven betyder at arkitekturen fungerer som en levende kontrakt, ikke et statisk diagram. Den beskriver den tilsigtede struktur, de beslutninger der er taget, og de grænser agenter opererer inden for. Spec-driven betyder at specifikationer definerer hvad der skal bygges, præcist nok til at en agent kan implementere mod dem. Scope, forventet adfærd, begrænsninger og acceptkriterier. Ikke 200-siders kravdokumenter, men klare nok rammer til at intentionen er eksplicit.
Det er de fem principper fra del 2 omsat til en leverancemodel:
- Tænk før du handler — forstå hvad og hvorfor, før agenten begynder
- Gør intentionen eksplicit — specifikationer og arkitektur som levende dokumenter
- Gør viden operationel — kodificér processer i skills og playbooks
- Mennesket tager de kritiske beslutninger — human gates ved hvert afgørende punkt
- Eksekvér i små, reversible skridt — byg i små iterationer, validér undervejs
Delivery
I praksis starter en leverance med fundamentet. Afgrænsningen og arkitekturen skal på plads, før agenter begynder at bygge. Hvad skal bygges, hvad skal ikke bygges, og hvordan hænger det sammen. AI kan hjælpe med at udforske muligheder og generere udkast, men det er mennesket der ejer afgrænsningen og de arkitektoniske beslutninger.
Capabilities, de forretningsevner systemet skal understøtte, defineres med et ID, så de kan spores hele vejen fra intention til leveret kode. Det er sporbarhedens udgangspunkt. Arkitekturen dokumenteres med beslutninger og begrundelser, ikke som ceremoni, men fordi agenter har brug for kontekst. En ADR (Architecture Decision Record) der forklarer hvorfor en event-driven tilgang blev valgt, forhindrer at en agent tre uger senere bygger noget synkront, fordi det var det hurtigste.
Med fundamentet på plads kommer gap analysen: hvad mangler, og i hvilken rækkefølge skal det bygges? Tanken er at bryde det ned i opgaver der er små nok til at hver kan leveres i én PR, og starte med dem der giver hurtigst feedback og lavest risiko. Det er her intentionen bliver til noget en agent kan eksekvere.
Så implementering. Hver opgave har en specifikation agenten kan arbejde inden for. Og efter hver opgave et review: ikke bare koden, men sammenhængen. Kan man følge tråden fra capability til arkitektur til kode til test? Det er sporbarhed i praksis.
Til sidst status. Hvad blev færdigt, hvad blev udskudt, hvad ændrede sig. Fundamentet opdateres, så næste iteration starter fra et korrekt udgangspunkt. Det er den del jeg tror de fleste springer over, og det er den del der gør forskellen mellem et projekt der akkumulerer viden og et der starter forfra hver gang.
Start, slut, lær, gentag. Man behøver ikke bruge det hele. Til prototyper og spikes er der en hurtigere vej: kickstart. Tre spørgsmål, ti minutter, og du har et udkast til charter og arkitekturbeskrivelse. Nok til at komme i gang.
Start, slut, lær, gentag.
Bag det hele ligger playbooks. Konkrete, kodificerede arbejdsgange:
/elaborate— afgrænser scope og capabilities/architect— designer løsningen og dokumenterer beslutninger/version-planning— gap analyse og opgavenedbrydning/review— validerer leverancen mod spec og arkitektur/version-close— gør status og opdaterer fundamentet/kickstart— den hurtige vej til prototyper
Hver playbook definerer trin, inputs, outputs og de punkter hvor mennesket skal ind. Det er kodificerede processer, ikke dokumentation. Og modellen er bevidst opinionated: arkitekturen følger arc42, en velafprøvet skabelon der sikrer de samme elementer er dækket uanset projektet. Det gør det nemmere for agenter at navigere og nemmere for nye folk at finde rundt.
Det lange lys — Direction
I nogle tilfælde er det nødvendigt at løfte blikket fra den enkelte iteration og se længere frem. Til det har jeg udarbejdet en række playbooks der hjælper med at sætte retningen og definere, hvor det er vi er på vej hen.
/vision definerer hvad god oplevelse ser ud for de mennesker systemet skal betjene. Hvad er friktionen i dag, og hvad er det system der fjerner den. /target-architecture definerer den langsigtede arkitektur, de principper og beslutninger der skal holde på tværs af mange iterationer.
Det er to forskellige tidshorisonter. En iteration er uger. Direction er måneder eller år. Men de hænger sammen. Hver iteration opererer inden for den retning der er sat, og hver afsluttet iteration kan give anledning til at justere retningen.
For mig er det her arkitektens vigtigste arbejde: at definere det partitur som al leverance bygger på.
Udforsk muligheder — Discovery
Nogle gange er svaret ikke at bygge, men at undersøge først. Forestil dig at teamet overvejer at migrere fra en monolitisk API til en event-driven arkitektur. Det er en stor beslutning med mange ukendte. At gå direkte til implementering ville være at satse uden at vide hvad man satser på.
Til det har jeg /discovery. En playbook der udforsker muligheder og risici inden commitment. Den stiller spørgsmålene: hvad er mulighederne, hvad er trade-offs, og hvad anbefaler vi? Resultatet er ikke kode. Det er en beslutning og et scope der kan gå direkte ind som fundament for den næste iteration.
Derfra gentages det normale flow. Elaborate og architect tager discovery-resultatet og ser på, hvordan det vil ændre på fundamentet. Hvordan ændrer det fundamentet, og hvad skal arkitekturen tage højde for. Så det normale flow. Samme rytme, nyt udgangspunkt.
Reglen er enkel: hvis scope allerede er klart, spring discovery over og gå direkte til elaborate. Hvis der er for mange ukendte til at afgrænse fornuftigt, så undersøg først.
Hvad jeg tror det ændrer
Jeg er stadig tidligt i rejsen med Conductor Model. Men jeg kan allerede se konturerne af, hvad der ændrer sig.
Arkitektens håndværk er det mest tydelige. Mindre tid på at præsentere, mere tid på at skrive. Arkitekturbeskrivelser der ikke kun er billeder på væggen, men dokumenter som agenter faktisk læser og opererer inden for.
Onboarding er en anden. Nye folk der har et fundament fra dag ét. Playbooks der forklarer hvordan vi arbejder. Skills der kodificerer de processer der ellers ville tage uger at lære. Arkitekturbeslutninger der er dokumenteret med begrundelser, ikke bare resultater.
Og så er der det der sker mellem iterationerne. Hver afsluttet iteration efterlader et opdateret fundament. Den næste starter ikke forfra, den starter fra et bedre udgangspunkt. Det er i hvert fald ambitionen.
Hvad nu?
Jeg har kaldt mit framework the Conductor Model, men det vigtigste er principperne bag, ikke den konkrete implementation. Det er en praksis du opbygger. Start med én playbook. Kodificér én arbejdsgang dit team gentager. Se hvad der sker, når en agent kan følge den.
I min næste artikel vil jeg vise, hvordan de samme principper ser ud i en helt anden kontekst: enterprise architecture governance. Samme model, anden skala, andre beslutninger.
Hvad ville den første playbook i jeres team være? Hvilken arbejdsgang gentager I oftest, men aldrig har skrevet ned?