AI-agenter kommer til dit team. Måske om tre måneder. Måske om seks. Men de kommer.
Og når de gør, møder de din kodebase som den er, ikke som den er planlagt til at blive.
De teams der får mest ud af agenter, er ikke dem der finder den rigtige model eller prompter bedst. Det er dem hvis kodebase giver agenten noget at arbejde med: klar arkitektur, afgrænsede ansvarsområder, tests der fanger fejl, og en struktur der kan læses af et system, der ikke kan spørge om hjælp.
I min forrige artikel (https://www.linkedin.com/pulse/vibe-coding-kan-tage-dig-et-stykke-men-ikke-hele-vejen-bendtsen-zmtee/) skrev jeg om forskellen på vibe coding og Directed Agentic Engineering. Det her er et skridt tilbage: hvad skal der faktisk til, inden agenterne kommer? Det er harness engineering (tilpasning af kodebasen til at arbejde med agenter), før du har brug for det.
Spørgsmålet er ikke, hvilken agent I skal bruge, men om I er klar, og hvis ikke, hvad der skal til.
Det er det denne artikel handler om.
Ambient affordances: Kan du og din agent finde vej?
Birgitta Böckeler introducerer på martinfowler.com begrebet ambient affordances fra hendes kollega Ned Letcher: de strukturelle egenskaber i et miljø der gør det læsbart, navigerbart og let at arbejde i for en agent.
En agent kan ikke spørge. Den kan ikke sige "hvad mener du egentlig her?" eller "er det meningen at disse to services afhænger af hinanden?" Den arbejder med det den finder. Og hvis det den finder er mudret, er resultatet derefter.
Et konkret eksempel: Nitin Gavhane beskriver (https://nitingavhane.medium.com/ai-coding-agents-are-hitting-a-wall-and-the-wall-is-your-architecture-a57ec11d20ce) en agent der fik til opgave at tilføje en fakturafunktion til en stor monolit, og endte med at ændre 14 filer i stedet for 3. Den brækkede dele af systemet den aldrig eksplicit rørte. Ikke fordi agenten var dårlig, men fordi fakturering var spredt over seks forskellige steder i kodebasen: routes, services, repositories, models, workers og webhook-handlers. Agenten holdt konteksten flydende, mistede overblikket og tog beslutninger på ufuldstændigt grundlag.
Det er et arkitektur-problem, ikke et agent-problem.
Det er et arkitektur-problem, ikke et agent-problem.
Ambient affordances er svaret: den kodebase der er klar til agenter er ikke nødvendigvis den nyeste eller den mest avancerede. Det er den der er struktureret, så en agent kan finde ud af hvad den har med at gøre, og hvad den ikke har.
Tre stemmer, samme svar
Det interessante er, at dette ikke er nyt. Tre uafhængige kilder siger det samme.
DORA 2025 undersøgte hvad der adskiller de teams der får noget ud af AI fra dem der ikke gør. Svaret: løs kobling, automatiseret testning og observability. Teams med stramme afhængigheder og manuelle processer ser ingen gevinst, uanset hvilke AI-værktøjer de bruger.
Klassisk software engineering-litteratur har sagt det samme i årevis. Clean Architecture, Modern Software Engineering, Martin Fowlers arbejde. Afgrænsede ansvarsområder. Lav kobling. Høj kohæsion. Testbar kode. Principper for kode der kan forstås, ændres og vedligeholdes. Ikke skrevet med agenter i tankerne, men præcis hvad de har brug for.
Og i Directed Agentic Engineering, som jeg har beskrevet i denne artikelserie, afhænger principperne af det samme fundament. Du kan ikke gøre intentionen eksplicit i specifikationer og arkitekturbeskrivelser, hvis arkitekturen i sig selv er uklar. Du kan ikke eksekvere i små, reversible skridt, hvis kodebasen er så tæt koblet at alle ændringer har uforudsigelige konsekvenser. DAE forudsætter ambient affordances. Det er en metode der forstærker god software engineering, ikke en der kompenserer for fraværet af den.
Hvor starter man?
Man behøver ikke en 200-punkts checkliste for at komme i gang. Her er tre ting, der bringer jer langt:
1. Løs kobling og afgrænsede kontekster
Det er her agenter oftest løber ind i problemer. En feature der er spredt over seks lag og ti filer er svær at ændre uden at påvirke noget der ikke burde påvirkes. Organiser kodebasen efter features og domæner frem for tekniske lag, og giv hver del et klart afgrænset ansvarsområde. Jo smallere kontekst en agent skal holde, desto mere præcist arbejder den.
2. Test det der betyder noget
Agenter skriver kode hurtigt. Uden tests er der intet der fanger dem, når de rammer ved siden af. Faros AI er et developer analytics platform der samler data på tværs af engineering-værktøjer. De analyserede over 10.000 udviklere på tværs af 1.255 teams og fandt 9% stigning i bug-rate og 91% stigning i code review-tid hos teams med høj AI-adoption. Det taler ikke imod AI, det er et argument for tests som det feedback-loop, der fortæller agenten, om den rammer rigtigt, og som giver dig tillid til at lade den arbejde.
3. Observability og struktureret logging
En agent der ikke kan se hvad der sker i systemet, arbejder uden at kunne validere sit eget arbejde. Struktureret logging og observability er ikke kun for drift. DORA siger det direkte: AI øger leveringsinstabilitet, medmindre observability-fundamentet er på plads.
Rækkefølgen er bevidst: løs kobling giver agenten kontekst at arbejde i, tests fanger det den overser, og observability lukker løkken. Start fra toppen.
Forberedelsen betaler sig uanset hvad
Det paradoks Böckeler beskriver gælder særligt her: harness engineering er mest nødvendig der, hvor den er sværest at bygge. Det gælder legacy-systemer. Det gælder kodebaser med år af teknisk gæld. Og det er præcis der, de fleste teams befinder sig.
Løs kobling, god testdækning og observability gør din kodebase bedre at arbejde i, med eller uden agenter. Det er investering i kvalitet, der har sin egen værdi, uanset fremtidig teknologi.
Og det behøver ikke ske på én gang. Som jeg beskrev i min artikel om legacy modernisering (https://www.linkedin.com/pulse/legacy-modernisering-med-ai-anders-bendtsen-d6p1e/), kan agenter selv hjælpe med at bringe koden hen, hvor den skal være. De kan kortlægge afhængigheder, identificere mønstre der bør refaktoreres, og understøtte den gradvise modernisering. Forberedelse og brug af agenter er ikke to adskilte faser. De kan foregå parallelt.
Agentic Engineering er i den forstand en test af din kodebase, ikke af dine AI-værktøjer, og den test kommer, uanset om du er klar.
Hvad er det første du ville rette i din kodebase, hvis en agent skulle arbejde i den i morgen?