Jeg har de seneste 6 måneder skrevet og snakket meget om Directed Agentic Delivery. Ti artikler. Lige fra de mere teoretiske artikler til: hvordan bruger du Lovable sammen med Claude Code. Men en ting er at skrive om det, noget andet er at prøve det af i virkeligheden.
De seneste 2-3 måneder har jeg arbejdet intensivt på to projekter, hvor jeg har afprøvet mine tanker og idéer i praksis. Det ene er primært en arkitekturmæssig opgave. Det andet er en ren udviklingsopgave, og her valgte jeg at gå 100% agentic. Jeg valgte også at påtage mig opgaven, selvom det er mange år siden jeg sidst har haft et direkte ansvar for kode.
Projektet handler om at erstatte et forældet system og en håndfuld Excel-ark med en moderne app. En frivilligdrevet organisation, registrering af data i felten, rollebaseret adgang, realtidsflow. Elleve leverancebølger. Jeg kodede ikke en eneste linje.
Meget holdt. Men ikke altid der, hvor jeg troede det ville.
Architecture-first og spec-driven
En af de grundlæggende antagelser i Directed Agentic Delivery er, at man bruger lang tid på at planlægge og kort tid på at eksekvere. Architecture-first og spec-driven: du definerer hvad der skal bygges og inden for hvilken arkitektur det skal bygges. Præcist nok til at en agent kan arbejde inden for de rammer. Agenten implementerer. Du beslutter.
Det lød rigtigt da jeg skrev det. Og det viste sig også at holde stik i praksis.
Det er enkelt, men stadig ikke let.
Beslutningsarbejdet
Måske er det fordi jeg er arkitekt, men for mig er en arkitekturbeskrivelse vigtig. Ikke forstået sådan at alle detaljer skal være på plads, men man skal have en idé om retningen. Det er det man kalder en target architecture, og det var der jeg begyndte: med at beskrive den retning systemet skulle tage. Hvad skal det kunne, hvilke principper skal det bygges efter, og hvilke beslutninger er fastlåste fra start. Som en del af det arbejde beskrev jeg også systemets features, de konkrete evner systemet skal have for at opfylde sit formål.
Da der var tale om et nyt system, var baseline tom fra begyndelsen. Der var ingen eksisterende kode at tage udgangspunkt i.
Derefter udførte jeg en gap analyse. En gap analyse kortlægger afstanden mellem baseline og target architecture: hvad mangler for at nå dertil? Hvert gap er en konkret observation, og de opstod fra reviews, klientmøder og afklaringer undervejs. I projektet endte jeg med 57 gaps over projektets levetid. Kunden ser dem ikke. De er mit arbejdsredskab.
Fra gaps lavede jeg workpackages. Et workpackage defineres tæt på implementeringen, ikke måneder i forvejen. Det er en afgrænset leveranceenhed med et klart scope, konkrete done-criteria (kriterier for hvornår leverancen er færdig) og de brugerhistorier der hører til. Det indeholder også hvilke dele af arkitekturen der er relevante, og hvilke arkitektoniske beslutninger der gælder. Det er kontrakten mellem mig og kunden om hvad der leveres i næste omgang.
Kunden var tæt inde over hele vejen. Jeg arbejdede ikke med workpackages i isolation. Kombineret med prototyper undervejs sikrede vi at retningen var den rigtige, inden implementeringen begyndte.
Til implementeringen brugte jeg to værktøjer. Lovable brugte jeg særligt i begyndelsen til at definere applikationens look and feel. Efterfølgende brugte jeg det til UX-review af det Claude Code havde implementeret, og til at lave større ændringer i brugergrænsefladen. Claude Code tog sig af resten: databasemigrationer, edge functions, tests og dokumentation.
Tre til fem timer på at forberede og diskutere med kunden. Cirka én time på implementering.
Den time var faktisk ret nem. Jeg åbnede workpackagen, agenten byggede det der var scopet. Det er den del der ligner "udvikling" i traditionel forstand, og det er den del der tager kortest tid.
De tre til fem timer var noget andet. Det var tid brugt på at vedligeholde tråden fra vision til arkitektur til gaps til workpackages. På at afklare med kunden hvad der var i scope, hvad der var godt nok, og hvornår noget skulle tilbage.
Når Claude Code havde implementeret et workpackage, brugte jeg tid på at skrive frem og tilbage for at tilpasse det implementerede og komme med forslag til rettelser. Det hører til processen — sådan fungerer den. Agenten leverer et første bud, jeg vurderer det mod specifikationen og arkitekturen, og vi justerer.
Undervejs tilpassede jeg mine gaps og workpackages ud fra den erfaring jeg gjorde mig. Nye observationer blev til nye gaps. Nogle gaps viste sig at være løst af noget andet. Prioriteterne rykkede sig i takt med at systemet tog form.
Når et workpackage var implementeret og tilpasset, foretog jeg et review af det leverede og holdt demo for kunden. Godkendte kunden leverancen, opdaterede jeg baseline-arkitekturen, så den afspejlede den nye tilstand. Og så begyndte cyklussen forfra.
Hvad holdt, hvad overraskede
Nogle antagelser holdt ikke, og det overraskede mig.
Spec-first virkede. Workpackages som kontraktform med kunden virkede. Human gates, de punkter i processen hvor jeg tog stilling inden agenten fortsatte, var ikke ceremonielle. De betød noget. De gange jeg sprang dem over, kunne jeg mærke det bagefter.
Det der overraskede mig positivt var, hvor nemt det var at ændre retning. Tidligt i projektet besluttede jeg at nonfood-varer skulle håndteres som en separat registreringstype. Halvvejs inde opdagede vi at varegrupper var en bedre løsning. Beslutningen blev omgjort, en ny arkitektonisk beslutning blev skrevet, og processen absorberede det uden drama. Det er en af gevinsterne ved lang planlægning og kort implementering: når du ikke har brugt uger på at kode noget, koster det ikke uger at gøre det om. Du prøver. Og du justerer.
Den menneskelige kontakt blev mere central end jeg havde forventet. Jeg brugte mere tid med kunden, ikke mindre. De tre til fem timer per workpackage var samarbejde, ikke administration. Vi afklarede retning, prototypede og vurderede hvad der var godt nok. Agenten løste implementeringen. Den menneskelige del, forståelsen af hvad der skulle bygges og hvad kunden virkelig havde brug for, den forblev hos os.
Størrelse viste sig at betyde mere end jeg havde forudset. Jeg fik mere end én gang en advarsel fra Claude Code om, at et workpackage måske var i overkanten. Jeg pressede på alligevel et par gange. Det var ikke en god idé. Resultatet var halvfærdigt, sammenhængen gik tabt undervejs, og jeg brugte mere tid på at rette end jeg havde sparet. Små, afgrænsede opgaver virker bedre. Det stod i teorien. Nu ved jeg det af erfaring.
Små, afgrænsede opgaver virker bedre. Det stod i teorien. Nu ved jeg det af erfaring.
Hvad det vil sige
Jeg kodede ikke en eneste linje. Og det føles ikke længere mærkeligt.
Det der fylder dagene er noget andet. Det er at holde tråden fra vision til leverance, mens kunden ændrer mening og prioriteterne rykker sig. Det arbejde ser ikke ud af meget. Men det er det der afgør om projektet lander rigtigt.
Teorien holdt. Ikke fordi den var fejlfri, men fordi den var bygget til at håndtere det den ikke forudså. Det er måske den vigtigste observation jeg sidder tilbage med.
Jeg har nu prøvet det på konkrete projekter. Rytmen var den samme begge steder: lang planlægning, kort implementering, tæt kontakt med kunden, og vilje til at ændre retning når noget viste sig ikke at holde.
Hvad bruger du mest tid på i dag, planlægning eller implementering? Og hvad ville der ske, hvis forholdet var omvendt?