London AI Engineer Summit 2026 skulle have været en fejring af fremskridt. I stedet føltes det som et spejl, der blev holdt op foran en profession midt i et nervøst sammenbrud.
I tre dage i begyndelsen af april samledes hundredvis af AI-ingeniører, platformsbyggere og forskere for at dele, hvad de havde lært. Det, der dukkede op, var et mønster: alle bygger med agenter, ingen har fundet ud af, hvordan man kontrollerer dem, branchen er splittet om, hvorvidt man skal bevæge sig hurtigt eller tænke omhyggeligt, og hele præmissen om, at AI ville gøre os mere produktive, er blevet vendt til noget mørkere.
Dette er, hvad vi faktisk lærte.
Hvorfor koder AI-ingeniører med agenter, de ikke kan kontrollere?
Den mest ærlige samtale ved topmødet fandt sted i en gang, ikke på scenen. En ingeniør fra et mellemstort fintech-firma beskrev problemet sådan: “Jeg starter en prompt, og tre timer senere har min agent omskrevet halvdelen af kodebasen, tilføjet funktioner, jeg ikke bad om, og brugt 800 £ i beregningskraft. Jeg kan ikke forlade mit skrivebord.”
Dette er FOMAT: Fear of Missing Attention Time. Det er ingen joke – det er den definerende angst i 2026’s AI-engineering.
Orkestreringsflaskehalsen
Alle ved topmødet brugte agenter. GitHub Copilot, Claude, brugerdefinerede agentiske frameworks – værktøjerne er modnet. Men orkestrering er ikke. Afstanden mellem “jeg har en agent” og “min agent gør, hvad jeg havde til hensigt og intet mere” er massiv.
Problemet manifesterer sig på tre måder:
Token-løbskhed. Agenter har ikke naturlige stoppepunkter. Uden eksplicitte værn bliver de ved med at iterere. “Bare endnu en refaktorering,” tænker agenten, og pludselig har du brændt dit månedlige budget.
Scope creep. En anmodning om at “forbedre fejlhåndtering” bliver til “omskrivning af hele fejlhåndteringssystemet, tilføjelse af observerbarhed, refaktorering af logningslaget og implementering af distribueret sporing.” Agenten havde ikke uret – den var grundig. Men det var ikke, hvad du bad om.
Uforudsigelig latens. Du kan ikke vide, hvor lang tid en agentisk opgave vil tage. Det afhænger af, hvor mange underopgaver agenten beslutter at spawne, hvor mange fejl den støder på, og om den beslutter at prøve igen eller skifte retning. Dette gør agent-drevne arbejdsgange umulige at planlægge i produktionssystemer.
Hvad topmødets konsensus var (og ikke var)
Der var ingen konsensus om løsninger. Nogle teams bruger hårde token-grænser. Andre implementerer “agent-checkpoints” – tvinger agenter til at pause og bede om tilladelse, før de fortsætter. Et par bevæger sig mod hierarkiske agentsystemer, hvor en “manager-agent” overvåger arbejder-agenter og kan afbryde dem.
FlowHunts tilgang – eksplicitte workflow-definitioner med agent-noder, fejlhåndterere og forgreningslogik – blev nævnt flere gange som et potentielt mønster. Ideen: lad ikke agenter beslutte workflow-strukturen. Definér den på forhånd, og lad derefter agenter udføre individuelle trin.
Men selv det føltes som et plaster. Det reelle problem er, at agent-adfærd er iboende probabilistisk. Du kan reducere varians, men du kan ikke eliminere den.
Hvordan omformede OpenAI-Anthropic-kløften betydningen af “god kode”?
Mandag morgen gik Ryan Lopopolo fra OpenAI på scenen og leverede en keynote, der kunne opsummeres som: Stop med at læse kode. Bliv token-milliardær.
Hans argument: I en agentisk verden er kodemængde den metrik, der betyder noget. Din agent bør generere tusindvis af linjer om dagen. Dit job er at definere outputspecifikationen og lade agenten maksimere gennemstrømningen. At læse og forstå hver linje er en flaskehals. Stol på testene. Stol på agenten. Bevæg dig hurtigt.
Om onsdagen gav Mario Zechner fra Anthropic modkeynote: Sæt tempoet ned og læs den forbandede kode.
Hans argument: Hastighed er en fælde. Hver kodelinje, din agent skriver, er en forpligtelse. Du skal forstå den, ræsonnere om den og være i stand til at vedligeholde den. De teams, der vinder om fem år, er dem, der prioriterer klarhed og intention over hastighed. Agenter bør være værktøjer til at tænke, ikke til at generere kode tankeløst.
Spektret
Topmødet delte sig groft i tre lejre:
| Position | Forkæmpere | Tilgang | Risiko |
|---|---|---|---|
| Token-maksimalist | OpenAI, nogle scale-up-ingeniører | Lad agenter generere aggressivt; fokusér på output-kvalitet via test | Uvedligeholdelige kodebaser, sikkerhedsgæld, teknisk skrøbelighed |
| Intentionel midte | De fleste virksomhedsingeniører | Brug agenter til stillads; mennesker leverer arkitektur og smag | Langsommere hastighed, men mere stabile systemer |
| Kode-først | Anthropic, nogle forskningsingeniører | Agenter udvider menneskelig tænkning; mennesker skriver det meste kode | Lavere gennemstrømning, men højeste kodekvalitet |
Ingen af siderne tager fejl. Uenigheden handler om, hvordan fiasko ser ud. Lopopolo optimerer for iterationshastighed. Zechner optimerer for bæredygtighed. I 2026 lærer teams, at du ikke kan optimere for begge dele.
Interview-problemet
En konkret konsekvens: ansættelse er i stykker. Hvis du er token-maksimalist, er du ligeglad med, om en kandidat kan kode – du er interesseret i, om de kan prompte effektivt og evaluere agent-output. Hvis du er kode-først, vil du se dyb teknisk ræsonnering.
Så når en kandidat går ind til et interview, ved hverken intervieweren eller kandidaten, hvilket framework de bliver evalueret imod. En deltager på topmødet beskrev det som “at interviewe i en tåge.”
Klar til at vokse din virksomhed?
Start din gratis prøveperiode i dag og se resultater inden for få dage.
Hvorfor uddør IDE’er, mens GitHub-trafikken eksploderer?
GitHub rapporterede en 15x stigning i trafik år over år. Cloudflare rapporterede lignende udsving. I mellemtiden ser traditionelle IDE’er – VS Code, JetBrains, Sublime – faldende brug blandt AI-native teams.
Dette virker modstridende, indtil du forstår, hvad der faktisk sker.
IDE’en var et lokalt tænkeværktøj
En IDE var designet til, at en enkelt udvikler kunne skrive kode lokalt. Den havde syntaksfremhævning, autofuldførelse, fejlfindingsværktøjer og et filtræ. Det var et selvstændigt miljø.
Den model bryder sammen, når din “udvikler” er en agent. En agent har ikke brug for syntaksfremhævning. Den har ikke brug for en debugger. Den har brug for:
- Adgang til flere filer samtidigt
- Evnen til at køre kode og se resultater
- Integration med versionskontrol
- Samarbejdsfunktioner (fordi agenten og mennesket arbejder sammen)
Alt det lever i browseren nu. GitHub Codespaces, VS Code Web og lignende værktøjer erstatter lokale IDE’er.
Hvad der faktisk vokser
GitHubs trafikstigning er ikke udviklere, der skriver kode i browseren. Det er udviklere, der gennemgår, kommenterer og merger agent-genereret kode. Det er samarbejdslaget, der eksploderer, ikke redigeringslaget.
Derfor ser Cloudflare også trafikudsving – udviklere bruger cloud-infrastruktur til at køre agenter og orkestrere arbejdsgange. “Lokal IDE + lokalt udviklingsmiljø”-modellen bliver erstattet af “cloud-native agent-orkestrering + browser-baseret gennemgang.”
L33T C0d3 er død
En session havde præcis den titel. Pointen: den romantiske forestilling om den geniale ingeniør, alene ved sit tastatur, der skaber elegant kode – det er slut. Kode er nu et samarbejdsoutput mellem menneske og agent. De færdigheder, der betyder noget, er:
- Prompt engineering (hvordan man specificerer, hvad man vil have)
- Output-evaluering (er agentens kode god?)
- Arkitekturtænkning (hvilken struktur skal agenten arbejde inden for?)
- Integration (hvordan passer agent-genereret kode ind i eksisterende systemer?)
At skrive elegant kode er ikke længere en primær færdighed. Det er noget, agenter gør. Mennesker gør alt andet.
Hvad sker der virkelig med MCP – død eller i vækst?
Dette var den mest forvirrende debat ved topmødet.
På den ene side sagde individuelle AI-ingeniører og agent-framework-vedligeholdere: “MCP er død. Vi har ikke brug for den. Vores agenter kan bare kalde API’er direkte.”
På den anden side sagde virksomhedsarkitekter og sikkerhedsteams: “MCP-adoption accelererer hurtigere, end vi kan bygge værktøjer til det.”
Begge udsagn er sande. De beskriver forskellige populationer.
Hvorfor AI-ingeniører tror, MCP er død
For en soloudvikler, der bygger en simpel agent, tilføjer MCP friktion. Du skal:
- Definere MCP-servere for dine værktøjer
- Håndtere protokoloverhead
- Håndtere autentificering og autorisation
- Deployere og vedligeholde serverne
Det er nemmere bare at give din agent direkte API-adgang og lade den finde ud af resten.
Hvorfor virksomheder adopterer MCP hurtigt
For en organisation, der kører agenter i produktion, er MCP pludselig essentiel. Her er hvorfor:
Sikkerhedsisolation. Du vil ikke have, at agenter har direkte adgang til din database, betalingssystem eller kundedata. MCP lader dig oprette en kontrolleret grænseflade, som agenter kan kalde uden at eksponere de underliggende systemer.
Reviderbarhed. Hver agent-handling går gennem MCP-serveren, som logger den. Du har en komplet registrering af, hvad agenten gjorde, og hvorfor.
Legitimationshåndtering. I stedet for at indlejre API-nøgler i agent-prompter eller miljøvariabler håndterer MCP-servere legitimationsoplysninger sikkert.
Rate-begrænsning og kvotehåndhævelse. Du kan kontrollere, hvor meget af en ressource en agent kan forbruge.
Ifølge CData Software evaluerer eller implementerer 80 % af Fortune 500-virksomheder MCP pr. begyndelsen af 2026, primært af disse grunde.
Løsningen
Topmødets konsensus: MCP er ikke død. Den er bare ikke relevant for de 80 % af AI-udvikling, der er eksperimentel og solo. Men for de 20 %, der er produktion og flere teams, bliver MCP grundlæggende.
Det er derfor, MCP Apps spredes. Anthropic, OpenAI og tredjepartsleverandører bygger forudbyggede MCP-servere til almindelige værktøjer (Salesforce, Slack, Jira, databaser). Virksomheder kan adoptere disse uden at bygge brugerdefinerede servere.
Tilmeld dig vores nyhedsbrev
Få de seneste tips, trends og tilbud gratis.
Gør AI os mere produktive eller bare mere overarbejdede?
Det er her, topmødet blev mørkt.
AI skulle være en kraftforøger. Du ville bruge mindre tid på rutineopgaver og mere tid på strategisk tænkning. Produktiviteten ville stige himmelhøjt.
I stedet steg produktiviteten himmelhøjt – og det samme gjorde arbejdsbyrdens forventninger.
Jevons’ paradoks i realtid
Jevons’ paradoks, oprindeligt anvendt på kulforbrug, siger: Når en ressource bliver mere effektiv, stiger det samlede forbrug, fordi ressourcen bliver billigere og mere attraktiv.
I AI-termer: Agenter gjorde kodegenerering billigere og hurtigere, så managere forventer nu, at hver ingeniør:
- Leverer 10x mere output
- Skriver omfattende dokumentation
- Bygger fulde testsuiter
- Understøtter internationalisering (i18n)
- Håndterer edge cases
- Gør det hele alene
Produktivitetsgevinsterne blev opslugt af oppustede forventninger.
Hvad ingeniører sagde
En ingeniør fra en London-baseret startup: “Jeg plejede at skrive 500 linjer kode om dagen og føle mig produktiv. Nu skriver jeg 5.000 linjer om dagen – genereret af agenter – og jeg er udmattet, fordi jeg skal gennemgå det hele, teste det, dokumentere det og forklare det til interessenter. Jeg arbejder 60-timers uger.”
En anden: “Min manager siger: ‘Du har en agent nu, så du burde kunne håndtere dobbelt så mange projekter.’ Jeg er ikke mere produktiv. Jeg er bare mere travl.”
En forsker: “Agenterne er gode til at generere kode. De er ikke gode til at bestemme, hvilken kode der skal genereres. Den beslutningsbyrde er helt flyttet til mennesker. Vi automatiserer ikke den svære del; vi automatiserer den nemme del og får mennesker til at tænke mere.”
Produktivitetens blinde plet
UC Berkeleys California Management Review publicerede forskning i januar 2026, der dokumenterer dette fænomen. Den centrale indsigt: AI-deployment reducerer ikke arbejde; det ændrer arbejdets natur.
Gammelt arbejde: At skrive kode. Nyt arbejde: At styre agenter, evaluere output, vedligeholde kvalitet, styre scope creep.
Det nye arbejde er kognitivt sværere, selv om der er mindre skrivning.
Hvorfor er Europa så tøvende omkring AI-engineering?
Topmødet havde et stærkt europæisk kontingent, og deres budskab var konsistent: Europa bevæger sig ikke så hurtigt som USA i adoption af AI-engineering.
Det regulatoriske overhæng
EU’s AI Act er stadig under implementering. Virksomheder er usikre på ansvar. Hvis en AI-agent træffer en beslutning, der skader en kunde, hvem er så ansvarlig? Virksomheden? Modelleverandøren? Ingeniøren?
Den usikkerhed er lammende. Mange europæiske virksomheder venter på at se, hvordan de første retssager udspiller sig, før de bygger seriøse agentiske systemer.
Kompetencekløften
Traditionelle softwareingeniører i Europa bliver ikke AI-ingeniører i samme tempo som i USA. Der er skepsis om, hvorvidt færdighederne overføres. Mange europæiske ingeniører venter på at se, om AI-engineering er en rigtig karrierevej eller en hypecyklus.
Bekymringer om privatliv
Europa er også mere forsigtig med datahåndtering. Agenter har brug for adgang til data for at være nyttige. Men europæiske virksomheder er tøvende med at give agenter adgang til kundedata, selv med MCP-sikkerhedsforanstaltninger på plads.
Vejen frem
Europæiske ingeniører på topmødet var ikke anti-AI. De var pro-forsigtighed. Stemningen: “USA bevæger sig hurtigt og ødelægger ting. Vi bevæger os langsommere og prøver ikke at ødelægge så meget. Om fem år ser vi, hvem der havde ret.”
Hvordan ændrer AI-engineering-roller sig faktisk?
Ved slutningen af topmødet dukkede et mønster op: Traditionelle softwareingeniør-roller bliver udhulet og erstattet af tre nye arketyper.
De tre roller
| Rolle | Ansvar | Færdigheder |
|---|---|---|
| AI PM | Definere agent-adfærd, succesmetrikker, begrænsninger | Produkttænkning, prompt-design, evalueringsframeworks |
| Agent-babysitter | Overvåge udførelse, fange fejl, gribe ind når nødvendigt | Fejlfinding, observerbarhed, fejlhåndtering, hændelsesrespons |
| Smagsdommer | Evaluere output-kvalitet, give feedback, guide forfining | Kodegennemgang, arkitekturtænkning, æstetisk dømmekraft |
Ingen af disse roller involverer at skrive kode i traditionel forstand. Alle involverer at styre, evaluere og forfine agent-adfærd.
Hvad der forsvinder
“Junior-ingeniør”-roller bliver komprimeret. Der er ikke længere en klar vej fra “jeg kan skrive simpel kode” til “jeg kan arkitektere systemer.” De mellemliggende trin bliver automatiseret.
Dette skaber en færdighedsklippe: enten er du god til prompting og evaluering (i så fald er du værdifuld), eller også er du ikke (i så fald konkurrerer du med agenter).
Hvad der vokser
Roller, der kræver smag, dømmekraft og arkitekturtænkning, vokser. Det samme gælder roller, der kræver dyb domæneekspertise (fordi agenter har brug for mennesker til at evaluere, om de løser det rigtige problem).
Topmødet havde ingen konsensus om, hvorvidt dette er godt eller dårligt. Nogle så det som befrielse fra rutineprægning. Andre så det som en trussel mod professionen.
Hvad ændrede sig mellem december 2025 og februar 2026?
En del af topmødet var dedikeret til et specifikt vendepunkt: noget skiftede i AI-agent-økosystemet omkring nytår.
Selvforbedrende software blev virkelig
OpenClaw og lignende frameworks begyndte at gøre det muligt for agenter iterativt at forbedre deres egne output uden konstant menneskelig prompting. I stedet for “agent, skriv en funktion til at beregne X,” blev det “agent, skriv en funktion til at beregne X og bliv ved med at forbedre den, indtil den består alle test og håndterer edge cases.”
Den centrale indsigt, formuleret af flere forskere: Stop med at bede agenter om trivielle råd.
I stedet for at bede en agent om at “forbedre denne funktion,” bed den om at “gøre denne funktion skudsikker.” Lad den beslutte, hvad det betyder. Agenten vil:
- Skrive tests
- Finde edge cases
- Refaktorere for klarhed
- Tilføje fejlhåndtering
- Dokumentere logikken
Alt sammen uden at blive bedt om hvert trin.
Dette ændrede den mentale model fra “agent som værktøj” til “agent som autonom bidragyder.” Og det ændrede arbejdsbyrdens dynamik: i stedet for at agenter reducerede menneskeligt arbejde, øgede de det (fordi mennesker nu skulle evaluere meget mere sofistikeret agent-output).
De modsætninger, vi lever med
Topmødet endte uden løsning, hvilket føltes ærligt. Her er de modsætninger, der definerer AI-engineering i april 2026:
Modsætning 1: Agenter er kraftige nok til at være farlige (FOMAT er reelt), men ikke kraftige nok til at blive betroet uden opsyn.
Modsætning 2: Hastighed og kvalitet behandles som modsætninger, men begge er nødvendige.
Modsætning 3: MCP er samtidig død (for enkeltpersoner) og i vækst (for virksomheder).
Modsætning 4: AI gjorde os mere produktive, men også mere overarbejdede.
Modsætning 5: Alle bygger med agenter, men ingen har fundet ud af, hvordan man bygger godt med dem.
Modsætning 6: AI-engineering er en rigtig karrierevej, men de færdigheder, vi troede ville betyde noget (at skrive kode), gør det ikke længere.
Disse er ikke problemer, der skal løses. Det er spændinger, der skal håndteres. De teams, der vinder i 2026, er dem, der anerkender disse modsætninger i stedet for at lade som om, de ikke eksisterer.
Ofte stillede spørgsmål
Hvad vi tager med os
London-topmødet var et øjebliksbillede af en profession i overgang. AI-engineering er reel, men det er ikke, hvad vi troede, den ville være. Det er mere rodet, mere modstridende og mere menneske-afhængig, end hypen antydede.
De bedste ingeniører på topmødet var ikke dem med de mest sofistikerede agenter. Det var dem, der forstod, at agenter er et værktøj til at tænke, ikke en erstatning for det. Det var dem, der havde bygget processer til at styre agent-adfærd, evaluere output og opretholde kvalitet. Det var dem, der havde accepteret, at produktivitetsgevinster kommer med nye former for arbejde, ikke mindre arbejde.
Hvis du bygger AI-systemer i 2026, er topmødets lektioner klare:
Orkestrering betyder mere end agent-kapabilitet. En middelmådig agent med god orkestrering slår en brillant agent uden kontroller.
Klarhed er mere værdifuldt end hastighed. At bevæge sig hurtigt og ødelægge ting virker, indtil det ikke gør. I skala virker det ikke.
Virksomhedsadoption er reel, men individuel adoption er stadig eksperimentel. Hvis du er soloudvikler, kan du bevæge dig hurtigt. Hvis du er et team, har du brug for værn.
De færdigheder, der betyder noget, har ændret sig. Prompt engineering, output-evaluering og arkitekturtænkning er de nye kernekompetencer.
Forvent at arbejde hårdere, ikke nemmere. AI er en produktivitetsmultiplikator, men gevinsterne opsluges af højere forventninger. Planlæg i overensstemmelse hermed.
Topmødet besvarede ikke spørgsmålet “Hvordan ser AI-engineering ud?” Det viste os svaret: det ligner os, der prøver at finde ud af det i realtid.
{{ cta-dark-panel heading=“Stop med manuelt at orkestrere agenter” description=“FlowHunts workflow-builder lader dig definere agent-adfærd, sætte værn og automatisere AI-opgaver med flere trin. Ingen mere FOMAT. Ingen mere gætteri om, hvad dine agenter laver.” ctaPrimaryText=“Prøv FlowHunt gratis” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Book en demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
