AI-agenter i praksis: Sådan leverer 2 personer det, der normalt kræver et bureau med 20 ansatte
Vi leverer enterprise-software på 18 dage med 2 personer. Ikke ved at arbejde i døgndrift, men ved at bygge et system af specialiserede AI-agenter, der researcher, implementerer, reviewer og bliver klogere efter hvert projekt. Her er, hvad vi har lært, hvad det betyder for branchen - og hvad vi stadig gør forkert.
Indholdsfortegnelse
Systemet, der gør det muligt
TwinCurrent er et 2-personers studie i København. Hans står for den tekniske arkitektur. Fredrik står for forretning og kunderelationer. Sammen har vi leveret IBPUnion.dk, DocubotAI.app, My Family Recipes og enterprise-platforme for virksomheder som JUC - alt sammen med en gennemsnitlig leveringstid på 18 dage.
Det kan lade sig gøre, fordi vi har bygget et system af specialiserede AI-agenter, der fungerer som et udvidet team. Hver agent har en defineret rolle, faste grænser for, hvad den må ændre, og adgang til en fælles vidensbase, der vokser med hvert projekt. Det her er ikke "AI-assisteret kodning", som de fleste forstår det - autocomplete-forslag og chatvinduer. Det er en produktionsklar multi-agent-arkitektur, der kører rigtige kundeprojekter, hvor agenterne håndterer alt fra research over implementering til kvalitetssikring.
Sådan ser systemet ud
Hver session starter klogere end den forrige. Hver fejl bliver til en permanent rettelse. Hvert vellykket mønster bliver kodet ind og genbrugt. Efter hundredvis af sessioner har systemet opbygget et dybt bibliotek af lærte mønstre - rettelser, præferencer og stilregler - der indlæses automatisk ved starten af hver session. Agenterne gentager ikke de samme fejl to gange, for fejlene er bogstaveligt talt skrevet ind i deres hukommelse.
Derfor har bureauer brug for 20 ansatte (og det har vi ikke)
Et traditionelt bureau bemander et projekt med 15-25 personer, fordi mennesker ikke kan parallelisere. En seniorudvikler kan ikke skrive en API-route, undersøge en konkurrents løsning, opdatere dokumentationen og reviewe sin egen kode på samme tid. Så bureauerne ansætter separate folk til hver rolle: frontend-udviklere, backend-udviklere, designere, QA-ingeniører, projektledere, tech leads, DevOps-ingeniører og tekniske skribenter.
Problemet er ikke, at rollerne er overflødige. Arbejdet bag dem er reelt nok. Problemet er, at når man bemander dem med mennesker, opstår der et kommunikationsoverhead, som vokser kvadratisk med teamets størrelse. Et team på 20 personer har 190 kommunikationskanaler. Størstedelen af budgettet går til koordinering - ikke til at skabe.
Den traditionelle bureaumodel
- 20 mennesker, der hver laver én ting ad gangen
- 190 kommunikationskanaler
- 25 % af tiden bruges på at skrive kode
- Viden forsvinder, når folk siger op
Vores agentmodel
- 2 mennesker, der styrer specialiserede agenter parallelt
- 1 kommunikationskanal (os to)
- Agenterne bruger 100 % af tiden på deres opgave
- Viden bevares i hundredvis af lærte mønstre
AI-agenter ændrer ligningen, fordi de kan parallelisere. Mens én agent researcher best practices, gennemgår en anden den eksisterende kodebase, en tredje bygger nye API-routes, og en fjerde ensretter navngivningen på tværs af snesevis af filer. De har ikke brug for standups. De misforstår ikke kravene, for de læser den samme fælles kontekst. De holder ikke ferie og skifter ikke kontekst.
Derfor slår specialisering generalisme
Vi har bygget et system af specialiserede AI-agenter - nogle tager sig af frontend-design, andre af backend-API-udvikling, og andre igen fokuserer på research, dokumentation, kvalitetssikring og code review. Hver agent har en defineret rolle og faste grænser for, hvilke filer den må læse og skrive. Det er ikke valgfrit - scope-begrænsninger forhindrer agenterne i at træde hinanden over tæerne og håndhæver de arkitektoniske grænser automatisk.
Den vigtigste erkendelse var, at specialisering betyder lige så meget for AI-agenter som for mennesker. Når en agent ved, at den er ansvarlig for ét domæne og intet andet, leverer den markant bedre resultater end en generalist-agent, der forsøger at gøre det hele. En frontend-agent, der aldrig rører backend-kode, laver bedre UI. En backend-agent, der aldrig skriver CSS, laver renere API'er.
De domæner, vores agenter dækker
UI-komponenter, styling, animationer, tilgængelighed
Serverlogik, databaseoperationer, autentificering
Konkurrentindsigt, dokumentationsanalyse, best practices
Præcis dokumentation, arkitektur-audits, gap-analyser
Code review, test, verifikation af acceptkriterier
Feature-brainstorming, kreativ problemløsning
Arkitektur håndhævet gennem scope
Arkitekturen håndhæves af agenternes grænser - ikke af udviklerdisciplin. Frontend-agenter tager sig af præsentationen. Backend-agenter tager sig af forretningslogikken. Databaseoperationer bliver i datalaget. Når en agent forsøger at krydse en grænse - for eksempel at lægge en databaseforespørgsel ind i en React-komponent - fanger systemet det. Det har været vores største enkeltstående kilde til kvalitetsforbedring.
Overtrædelser fanges automatisk
Vi lærte tidligt, at backend-logik i frontend-koden var vores største kilde til friktion. Den lektie er i dag kodet ind som et mønster med høj prioritet, der indlæses i hver session. Enhver agent, der forsøger at krydse grænsen, bliver rettet, før koden overhovedet er skrevet. Systemet lærer af tidligere fejl og anvender rettelserne permanent.
Efter implementeringen gennemgår review-agenter med skrivebeskyttet adgang arbejdet - de tjekker for edge cases, sikkerhedsproblemer og overholdelse af projektets standarder. Det svarer til en traditionel code review- og QA-cyklus, men det tager minutter i stedet for dage.
En hukommelse med renters rente
Det her er den del, der får systemet til at vokse over tid i stedet for at stå stille. Når en agent begår en fejl, og vi retter den, bliver rettelsen fanget som et permanent mønster. I næste session indlæses mønsteret automatisk. Agenten begår aldrig den fejl igen. Over tid vokser det til en dyb, fælles vidensbase, som alle agenterne trækker på.
Sådan ser lærte mønstre ud
Arkitekturgrænserne mellem frontend og backend må aldrig krydses
Teknologivalg er projektspecifikke - antag aldrig standard-stacken
Alt UI-arbejde skal gå gennem den dedikerede designagent, ikke en generalist
Lokalespecifik formatering og forretningsregler hentes altid fra konfiguration - aldrig hardcodet
Regnestykket er simpelt, men stærkt. I uge ét havde vi måske ti mønstre. I uge ti flere dusin. Nu, efter hundredvis af sessioner, har vi hundredvis af lærte mønstre fordelt på snesevis af kategorier - rettelser, præferencer, stilregler, arkitektoniske begrænsninger og forretningsregler. Hvert mønster forhindrer en hel klasse af fejl i nogensinde at opstå igen. Traditionelle teams mister viden, når folk stopper. Vores viden ligger i versionsstyrede filer, der automatisk indlæses i hver session.
Den selvforstærkende løkke
En agent begår en fejl, eller vi finder en bedre tilgang
Rettelsen fanges som et permanent mønster og committes til repositoriet
Automatiseret sessionsstyring indlæser alle mønstre i hver fremtidig session ved opstart
Fejlen sker aldrig igen. Viden akkumulerer. Projekt nummer 50 er markant hurtigere end nummer 1.
Derfor betyder det noget
De fleste AI-kodeværktøjer er tilstandsløse - hver session starter fra nul. Vores system er det modsatte. Det bærer alt med sig, som vi nogensinde har lært om vores projekter, vores kunder, vores arkitektur og vores fejl. Det er det tætteste, man kommer på institutionel hukommelse uden for menneskehjerner - og i modsætning til menneskehjerner glemmer det ikke, bliver ikke træt og siger ikke op for at skifte til en anden virksomhed.
Konkret eksempel: GEO-implementering på én eftermiddag
Teori er fint. Her er, hvad der faktisk skete i dag. Opgaven var at implementere Generative Engine Optimization (GEO) for twincurrent.dk - altså at gøre vores site synligt for AI-søgemaskiner som ChatGPT, Perplexity og Google AI Overviews. En udvikler, der gjorde det manuelt, ville bruge 2-3 uger. Vi gjorde det på én eftermiddag.
Fase 1 - Parallel research & audit
FLERE AGENTER KØRER PARALLELTFase 2 - Parallel implementering
FLERE AGENTER KØRER PARALLELTSessionens output
Den afgørende detalje: Agenterne skrev ikke bare kode hver for sig. Research-agenten syntetiserede 30+ kilder om GEO best practices, og den research formede, hvordan implementeringsagenterne strukturerede de AI-læsbare filer, sitemappet og indholdet. Resultatet hang sammen, fordi alle agenterne læste fra den samme projektkontekst og de samme lærte mønstre. Parallelisme uden fælles kontekst producerer bras. Parallelisme med fælles kontekst producerer fart.
Designsystemet som lås
En af de største risici ved AI-genereret kode er, at den ligner AI-genereret kode. Generiske layouts, standard-komponentbiblioteker, ingen visuel identitet. Det løste vi ved at bygge et navngivet designsystem - "Scandinavian Industrial" - med specifikke, holdningsprægede regler, som alle UI-agenter skal følge.
Designregler for Scandinavian Industrial
Varme metaltoner som primær palet. Ikke tech-blå.
Dæmpede baggrunde. Industrielt, ikke prangende.
Matterede glaskort med et subtilt teksturoverlæg.
WCAG-tilgængelighedskrav - ikke til forhandling.
Et lille sæt navngivne animationer, brugt konsekvent.
Rigelig luft. Lad indholdet ånde. Intet rod.
Grunden til, at det virker, er, at reglerne er specifikke nok til at kunne håndhæves maskinelt. "Få det til at se pænt ud" er ikke en brugbar instruks til en AI-agent. Et konkret sæt farve-tokens, spacing-regler, komponentmønstre og animationsbegrænsninger - det er en brugbar instruks. Agenten kan ikke afvige, for begrænsningerne efterlader ikke plads til generiske valg.
Resultatet: Folk fortæller os, at vores site ser håndlavet ud. Det ligner ikke noget AI-genereret, fordi designsystemet er holdningspræget nok til at tilsidesætte AI'ens tendens til generisk output. Det er samme princip, som får en brand-styleguide til at virke for menneskelige designere - bortset fra at vores "designere" følger guiden perfekt hver eneste gang.
Hvad vi gjorde forkert
Systemet opstod ikke færdigt fra start. Vi begik reelle fejl undervejs, og nogle af dem kan stadig delvist ses i kodebasen. Ærlighed om, hvad der gik galt, er mere brugbar end at lade som om, det gik glat.
Agent-vildvækst
Vi har bygget flere agenter, end vi formentlig har brug for. Nogle har overlappende ansvarsområder - især inden for dokumentation og kvalitetssikring. Enkelte agenter findes kun, fordi vi oprettede dem, før vi lagde os fast på den endelige arkitektur. Omkostningen ved at vedligeholde sjældent brugte agenter er lille, men den routing-tvetydighed, de skaber, er reel. Vi planlægger en konsolidering.
Status: Kendt problem, konsolidering planlagt
Overlappende designagenter
Vi endte med flere agenter, der kan lave UI-arbejde, fordi vi oprettede nogle af dem, før vi lagde os fast på vores Scandinavian Industrial-designsystem. Den primære designagent klarer det meste af arbejdet i dag, men de gamle agenter skaber stadig routing-tvetydighed. Det er en naturlig konsekvens af at bygge iterativt - man akkumulerer levn fra tidligere beslutninger.
Status: Konsolidering planlagt
Tidlige huller i tilgængeligheden
Vores første versioner havde dårlig tastaturnavigation og manglende ARIA-labels. Det krævede mange sessioner med rettelser, før mønstrene var robuste nok til automatisk at forhindre den slags problemer. I dag indeholder vores mønstre obligatoriske tilgængelighedskrav for alle interaktive elementer, men nogle ældre komponenter mangler stadig at blive opdateret.
Status: Rettes løbende, ~80 % løst
Konflikter mellem mønstre
Med hundredvis af mønstre er der nogle, der fra tid til anden modsiger hinanden. Ét mønster siger "foretræk server components", et andet siger "tilføj interaktivitet for bedre UX". Løsningen afhænger altid af konteksten, og det betyder, at systemet nogle gange har brug for menneskelig hjælp til at afgøre tvivlstilfælde. Vi gennemgår og beskærer mønstrene med jævne mellemrum, men konfliktdetektionen er stadig manuel.
Status: Manuel gennemgang med jævne mellemrum
Ingen af de her problemer er fatale. Systemet virker på trods af dem. Men de er reelle, og alle, der forsøger at bygge et lignende system, bør forvente at møde deres egne udgaver af dem. Multi-agent-systemer er kraftfulde, men rodede. Rodet kan håndteres, hvis man er ærlig omkring det.
Økonomien
Lad os være ærlige om, hvordan sammenligningen er skruet sammen. Bureau-kolonnen afspejler almindelige mønstre i branchen og de tilbud, potentielle kunder fortæller os, at de har fået - ikke reviderede tal. TwinCurrent-kolonnen afspejler, hvordan vi faktisk arbejder på leverede projekter.
Den selvforstærkende effekt
Et bureaus projekt nummer 20 er ikke nævneværdigt hurtigere end deres første - nye teammedlemmer, nye tech stacks og viden spredt ud over mange mennesker. Vores projekt nummer 20 er markant hurtigere end vores første, fordi hver session tilføjer mønstre, forfiner agenternes adfærd og forbedrer orkestreringen. Afstanden vokser med tiden - den skrumper ikke.
API-omkostningerne til at køre agenterne udgør en brøkdel af en enkelt udviklerløn - en forskel i størrelsesorden, ikke en afrundingsfejl. Vi har reelt output-kapacitet som et langt større team for mindre, end én junioransættelse koster. Økonomisk er det ikke engang et tæt løb.
Hvad det betyder for branchen
Vi er ikke det eneste team, der gør det her. Over hele branchen er små teams med velkonfigurerede agentsystemer begyndt at udkonkurrere langt større organisationer. Mønsteret er konsistent: 2-5 mennesker, der forstår arkitektur og forretningskrav, og som styrer en flåde af specialiserede agenter, der klarer implementeringsvolumen.
Det betyder ikke, at store bureauer forsvinder. Der vil altid være enterprise-kunder, der har brug for en leverandør med 200 ansatte af hensyn til compliance, ansvar og organisation. Men for langt størstedelen af alle softwareprojekter - webapplikationer, SaaS-produkter, mobilapps, interne værktøjer, AI-integrationer - flytter konkurrencefordelen sig entydigt mod små, agent-forstærkede teams.
Hvad der ændrer sig
- Hastighed bliver normen. 18 dages levering er ikke exceptionelt, når agenter håndterer implementeringsvolumen. Kunderne holder op med at acceptere tidsplaner på 6 måneder for standardprojekter.
- Kvalitet og hastighed afkobles. Agenter følger designsystemer og mønstre perfekt. Hurtigere levering betyder ikke lavere kvalitet, når begrænsningerne håndhæves maskinelt.
- Viden holder op med at være letfordærvelig. Institutionel viden ligger i versionsstyrede mønsterfiler - ikke i hovedet på medarbejdere, der kan sige op. Det ændrer fuldstændig økonomien i personaleudskiftning.
- Kompetencepræmien flytter sig. Den mest værdifulde kompetence er ikke længere at skrive kode. Det er at designe agentsystemer, skrive effektive begrænsninger og vide, hvilke mønstre der skal kodes ind. Arkitektur frem for implementering.
Vi byggede systemet, fordi vi var nødt til det. To personer kan ikke levere enterprise-software på 18-dages tidsplaner uden en kraftmultiplikator. AI-agenter er den multiplikator. Systemet er ikke perfekt - vi har beskrevet problemerne ovenfor - men det virker. Projekterne bliver leveret. Kunderne er glade. Økonomien hænger sammen.
Hvis I er et lille team, der overvejer denne tilgang, er vores råd: Start med få specialiserede agenter, ikke mange. Byg mønstersystemet fra dag ét. Håndhæv stramme scope-begrænsninger. Og vær klar til at iterere - det system, I ender med, kommer ikke til at ligne det system, I starter med.
Vil I se systemet i aktion?
Vi bruger agentsystemet på hvert eneste kundeprojekt. Tal med de stiftere, der har bygget det - og som vil bygge jeres.