Emil og Alfred, del 2: Når kravene bliver vigtigere end koden

Kan du udvikle software, hvor kravene definerer systemet, og koden blot er noget, der kan genskabes? Og hvordan bygger du AI-systemer, der kan følge med, når modellerne ændrer sig?

På Faglig Fredag den 30. oktober 2026 vendte Jesper Agerled Wermuth, CEO og partner i Lund&Bendsen, tilbage med et spadestik dybere i arbejdet med Emil og Alfred, hans to autonome AI-butlere.

I det første oplæg fra august introducerede Jesper de to assistenter og arkitekturen bag dem. Arkitekturen er et bud på, hvordan man kan udvikle et fuldt privat system med LLM- og AI-komponenter, der kan afvikles med åbne modeller lokalt eller i EU-compliant cloudmiljøer. Samtidig er den designet til at håndtere den hastige udvikling i AI-modeller, så nye modeller løbende og gradvist kan tages i brug uden at skulle ændre hele systemet.

Alfred hjælper med private opgaver, mens Emil arbejder med blandt andet økonomi og administrative opgaver i Lund&Bendsen. De bygger på fælles softwarekomponenter, men er arkitektonisk adskilt, så deres data og arbejdsområder holdes hver for sig.

Anden del handler i højere grad om erfaringerne fra selve udviklingsarbejdet. Jesper viser den metode og de værktøjer, han har udviklet undervejs, og undersøger en mere grundlæggende idé: Hvad nu, hvis kravene er systemet, og koden blot er et resultat af dem?

Fra AI-genereret kode til struktureret kravhåndtering

Da Jesper begyndte at udvikle Emil og Alfred med hjælp fra LLM’er, var det forholdsvis enkelt at få modellerne til at skrive kode. Udfordringen opstod, efterhånden som systemet voksede.

Flere udviklingsspor kørte parallelt, krav ændrede sig, og det blev vanskeligt at bevare overblikket over, hvilke beslutninger der var truffet, og hvordan de enkelte dele af systemet hang sammen. Det var ikke kun et problem for udvikleren. Når intentionen bag koden ikke var dokumenteret, havde den kodende LLM heller ikke et tilstrækkeligt grundlag for at forstå den.

Jesper begyndte derfor at arbejde med en mere formaliseret kravmodel med udgangspunkt i de klassiske begreber epics, features, user stories, bugs og acceptkriterier.

Kravene ligger i en struktureret database, hvor systemet både registrerer hierarkiske og funktionelle afhængigheder. Samtidig anvendes embeddings og semantisk søgning til at finde beslægtede krav og tidligere fejl, også når de ligger andre steder i systemet.

For at håndtere usikkerheden i LLM-modellernes adfærd, herunder risikoen for hallucinationer, har Jesper desuden indført faste regler, der håndhæves direkte i kode. På den måde bliver overholdelsen af centrale krav og begrænsninger ikke afhængig af, hvordan modellen fortolker en instruktion.

Når en AI-agent skal løse en opgave, får den dermed ikke kun beskrivelsen af den konkrete opgave. Den får også relevant kontekst fra de omkringliggende krav, afhængigheder og tidligere erfaringer.

Det er en væsentlig forskel fra at give en kodende LLM en isoleret prompt og bede den implementere en funktion.

Kan man genskabe koden alene ud fra kravene?

Et af de mest interessante spørgsmål i Jespers andet oplæg er, om et system kan beskrives så præcist gennem sine krav, at den eksisterende kode kan fjernes og genskabes.

Jesper har afprøvet idéen på et afgrænset modul af sit system. Han har givet en AI-agent kravene uden adgang til den oprindelige kode og derefter undersøgt, om den nye implementering opførte sig som den eksisterende.

Ved første forsøg opnåede han omkring 90 procent kodeparitet. Forsøget afslørede blandt andet, at fejlrettelser ikke altid var blevet omsat til forbedrede krav. En fejl kunne være rettet i koden, uden at det underliggende krav var blevet præciseret.

Efter yderligere justeringer, blandt andet med konkrete input/output-eksempler og mekanismer til at identificere manglende krav, opnåede han i tredje forsøg 100 procent kodeparitet for det testede modul.

Det er ikke et bevis for, at enhver kodebase kan genskabes ud fra krav alene. Men forsøget illustrerer en interessant mulighed: At bevare systemets tilsigtede adfærd i et vedligeholdt kravgrundlag, frem for at lade den eksisterende kode være den eneste beskrivelse af, hvad systemet skal kunne.

Det rejser samtidig spørgsmål om, hvordan vi fremover dokumenterer designbeslutninger, håndterer ændringer og vedligeholder software, når stadig mere kode bliver skrevet af AI.

Udviklingsmetoden skal også håndtere AI’ens svagheder

Jesper demonstrerer i oplægget sit eget udviklingsmiljø med dashboards, kravhierarkier, afhængighedsgrafer og en flåde af AI-agenter, der kan arbejde med forskellige opgaver.

Men værktøjerne løser ikke alle problemer.

En af hans erfaringer er, at AI-assisteret udvikling også kan føre til duplikeret kode, teknisk gæld og gradvis forringelse af arkitekturen. Det er ikke mindre udbredt, når det er let at sætte mange opgaver i gang samtidig.

Derfor arbejder han med løbende reviews, test og eksplicitte regler for udviklingsprocessen. Regler, der skal overholdes uden undtagelse, bliver håndhævet i almindelig software frem for overladt til en LLM’s fortolkning.

Et centralt princip er, at modellen gerne må foreslå løsninger, men at de afgørende kontroller skal ligge uden for modellen.

Det er også en erfaring fra arbejdet med selve AI-butlerne: Når en assistent kan læse beskeder, anvende værktøjer og handle på brugerens vegne, er det afgørende, hvilke handlinger arkitekturen faktisk tillader, og hvor der kræves menneskelig godkendelse.

Private LLM-systemer, der kan skifte model

Et andet gennemgående tema i begge oplæg er digital suverænitet.

Fra begyndelsen har Jespers mål været at udvikle et system, der kan fungere med lokale LLM’er, beskytte private data og løbende tage nye modeller i brug uden omfattende ændringer i den øvrige software.

Det har han arbejdet med gennem en arkitektur, hvor forskellige modeller anvendes til forskellige opgavetyper. Fallback-kæder gør det muligt at vælge en alternativ model, hvis den foretrukne ikke er tilgængelig.

I oktoberoplægget viser Jesper, hvordan afhængigheden af kommercielle cloud-modeller har ændret sig under udviklingen. Bedre open-weight-modeller, hurtigere inferenssoftware og mere effektiv udnyttelse af lokal hardware betyder, at flere opgaver nu kan løses lokalt eller med europæiske alternativer.

Han skelner samtidig mellem at udvikle et system med AI og at drive et system med AI. De stærkeste kommercielle modeller er efter hans erfaring fortsat væsentligt bedre til komplekse kode- og analyseopgaver, mens mindre modeller er tilstrækkelige til mange af de opgaver, et færdigt system skal udføre.

Her fremhæver Jesper også betydningen af datakvalitet. Et velstruktureret datagrundlag kan reducere behovet for både store modeller og mange tokens. Valget af LLM er derfor kun én del af arbejdet med at skabe en velfungerende løsning.

Se begge oplæg fra Faglig Fredag

De to oplæg kan ses hver for sig, men supplerer hinanden. Første del introducerer Emil og Alfred, deres funktioner, sikkerhedsarkitektur og de første erfaringer med udviklingen. Anden del går dybere ned i kravmodellen, udviklingsværktøjerne, forsøgene med at genskabe kode og arbejdet med udskiftelige LLM’er.

28. august 2026: Emil og Alfred, mine autonome AI-butlere – og hvorfor Emil blev sendt i brændeskuret Se første oplæg her.

Hvordan kan Lund&Bendsen hjælpe?

Jesper deler gerne sine praktiske erfaringer med kravhåndtering i AI-assisteret udvikling, private LLM-systemer med udskiftelige modeller og udviklingsmetoder, hvor AI-agenter indgår i arbejdet.

Det kan være gennem et fagligt oplæg eller som sparring om jeres egne idéer, tekniske overvejelser og muligheder for at anvende AI i softwareudvikling og eksisterende systemer.

Uanset om I er ved at undersøge mulighederne eller allerede arbejder med konkrete løsninger, kommer Jesper gerne ud og tager en faglig dialog med afsæt i jeres behov og udfordringer.

Kontakt Lund&Bendsen, hvis I har lyst til at høre mere eller aftale en samtale.