Det vi lærte på London AIE Summit 2026: agent-kaos, debatten om fart vs. kvalitet, IDE-ens død, MCP-paradokser, og hvorfor AI fikk oss til å jobbe hardere.
London AI Engineer Summit 2026 skulle være en feiring av fremgang. I stedet føltes det som et speil holdt opp for en profesjon midt i et nervøst sammenbrudd.
I tre dager i begynnelsen av april samlet hundrevis av AI-ingeniører, plattformbyggere og forskere seg for å dele hva de hadde lært. Det som kom frem var et mønster: alle bygger med agenter, ingen har funnet ut hvordan de skal kontrollere dem, bransjen er delt om hvorvidt man skal bevege seg raskt eller tenke nøye, og hele premisset om at AI ville gjøre oss mer produktive har blitt snudd til noe mørkere.
Dette er det vi faktisk lærte.
Den mest ærlige samtalen på toppmøtet skjedde i en korridor, ikke på scenen. En ingeniør fra et mellomstort fintech-selskap beskrev problemet slik: “Jeg starter en prompt, og tre timer senere har agenten min skrevet om halve kodebasen, lagt til funksjoner jeg ikke ba om, og brukt £800 i compute. Jeg kan ikke forlate skrivebordet.”
Dette er FOMAT: Fear of Missing Attention Time. Det er ingen vits - det er den definerende angsten for AI Engineering i 2026.
Alle på toppmøtet brukte agenter. GitHub Copilot, Claude, tilpassede agentic rammeverk - verktøyene har modnet. Men orkestreringen har ikke det. Gapet mellom “Jeg har en agent” og “agenten min gjør det jeg mente og ingenting mer” er enormt.
Problemet manifesterer seg på tre måter:
Token-runaway. Agenter har ikke naturlige stoppunkter. Uten eksplisitte rekkverk fortsetter de å iterere. “Bare én refaktorering til,” tenker agenten, og plutselig har du brent gjennom månedsbudsjettet.
Scope creep. En forespørsel om å “forbedre feilhåndteringen” blir til “skriv om hele feilhåndteringssystemet, legg til observability, refaktorer loggingslaget og implementer distribuert sporing.” Agenten tok ikke feil - den var grundig. Men det var ikke det du ba om.
Uforutsigbar ventetid. Du kan ikke vite hvor lang tid en agentic oppgave vil ta. Det avhenger av hvor mange underoppgaver agenten bestemmer seg for å starte, hvor mange feil den møter, og om den bestemmer seg for å prøve på nytt eller pivotere. Dette gjør agent-drevne arbeidsflyter umulige å planlegge i produksjonssystemer.
Det var ingen konsensus om løsninger. Noen team bruker harde tokengrenser. Andre implementerer “agent-sjekkpunkter” - som tvinger agenter til å pause og be om tillatelse før de fortsetter. Noen få beveger seg mot hierarkiske agentsystemer der en “manager-agent” overvåker arbeidsagenter og kan avbryte dem.
FlowHunts tilnærming - eksplisitte arbeidsflytdefinisjoner med agentnoder, feilhåndterere og forgreningslogikk - ble nevnt flere ganger som et potensielt mønster. Ideen: la ikke agenter bestemme arbeidsflytstrukturen. Definer den på forhånd, og la deretter agenter utføre enkelttrinn.
Men selv det føltes som et plaster. Det virkelige problemet er at agentatferd er iboende probabilistisk. Du kan redusere variansen, men du kan ikke eliminere den.
Mandag morgen gikk Ryan Lopopolo fra OpenAI på scenen og holdt en keynote som kan oppsummeres som: Slutt å lese kode. Bli en token-milliardær.
Hans argument: I en agentic verden er kodevolum måleparameteren som betyr noe. Agenten din skal generere tusenvis av linjer per dag. Din jobb er å definere output-spesifikasjonen og la agenten maksimere gjennomstrømningen. Å lese og forstå hver linje er en flaskehals. Stol på testene. Stol på agenten. Beveg deg raskt.
På onsdag holdt Mario Zechner fra Anthropic motsvar-keynoten: Senk farten og les den jævla koden.
Hans argument: Fart er en felle. Hver kodelinje agenten din skriver er en forpliktelse. Du må forstå den, resonnere om den, og kunne vedlikeholde den. Teamene som vil vinne om fem år er de som prioriterer klarhet og intensjon fremfor hastighet. Agenter bør være verktøy for tenking, ikke for å tankeløst generere kode.
Toppmøtet delte seg grovt i tre leirer:
| Posisjon | Forkjempere | Tilnærming | Risiko |
|---|---|---|---|
| Token-maksimalist | OpenAI, noen scale-up-ingeniører | La agenter generere aggressivt; fokuser på output-kvalitet via testing | Uvedlikeholdbare kodebaser, sikkerhetsgjeld, teknisk skjørhet |
| Intensjonell midte | De fleste enterprise-ingeniører | Bruk agenter til stillas; mennesker leverer arkitektur og smak | Lavere fart, men mer stabile systemer |
| Kode-først | Anthropic, noen forskningsingeniører | Agenter forsterker menneskelig tenking; mennesker skriver mesteparten av koden | Lavere gjennomstrømning, men høyeste kodekvalitet |
Ingen av sidene tar feil. Uenigheten handler om hvordan feil ser ut. Lopopolo optimaliserer for iterasjonshastighet. Zechner optimaliserer for bærekraft. I 2026 lærer team at du ikke kan optimalisere for begge deler.
En konkret konsekvens: rekruttering er ødelagt. Hvis du er token-maksimalist, bryr du deg ikke om hvorvidt en kandidat kan kode - du bryr deg om de kan prompte effektivt og evaluere agent-output. Hvis du er kode-først, vil du se dyp teknisk resonnering.
Så når en kandidat går inn til et intervju, vet verken intervjueren eller kandidaten hvilket rammeverk de blir evaluert mot. En deltaker på toppmøtet beskrev det som “å intervjue i tåken.”
Start din gratis prøveperiode i dag og se resultater i løpet av få dager.
GitHub rapporterte en 15x økning i trafikk år-over-år. Cloudflare rapporterte lignende topper. I mellomtiden ser tradisjonelle IDE-er - VS Code, JetBrains, Sublime - synkende bruk blant AI-native team.
Dette virker motsigende inntil du forstår hva som faktisk skjer.
En IDE ble designet for én utvikler for å skrive kode lokalt. Den hadde syntaksuthevingsverktøy, autofullføring, debuggingverktøy og et filtre. Det var et selvstendig miljø.
Den modellen faller sammen når “utvikleren” din er en agent. En agent trenger ikke syntaksutheving. Den trenger ikke en debugger. Den trenger:
Alt dette lever i nettleseren nå. GitHub Codespaces, VS Code Web og lignende verktøy erstatter lokale IDE-er.
GitHubs trafikkboom er ikke utviklere som skriver kode i nettleseren. Det er utviklere som gjennomgår, kommenterer og slår sammen agent-generert kode. Det er samarbeidslaget som eksploderer, ikke redigeringslaget.
Dette er grunnen til at Cloudflare også ser trafikktopper - utviklere bruker skyinfrastruktur til å kjøre agenter og orkestrere arbeidsflyter. Modellen “lokal IDE + lokalt utviklingsmiljø” blir erstattet av “skynativ agent-orkestrering + nettleserbasert gjennomgang.”
En sesjon hadde nøyaktig den tittelen. Poenget: den romantiske forestillingen om den briljante ingeniøren, alene ved tastaturet, som utformer elegant kode - det er over. Kode er nå et samarbeidsresultat mellom menneske og agent. Ferdighetene som betyr noe er:
Å skrive elegant kode er ikke lenger en primær ferdighet. Det er noe agenter gjør. Mennesker gjør alt annet.
Dette var den mest forvirrende debatten på toppmøtet.
På den ene siden sa individuelle AIE-er og vedlikeholdere av agentrammeverk: “MCP er død. Vi trenger det ikke. Agentene våre kan bare kalle API-er direkte.”
På den andre siden sa enterprise-arkitekter og sikkerhetsteam: “MCP-adopsjonen akselererer raskere enn vi kan bygge verktøy for det.”
Begge utsagn er sanne. De beskriver forskjellige populasjoner.
For en solo-utvikler som bygger en enkel agent, legger MCP til friksjon. Du må:
Det er lettere å bare gi agenten direkte API-tilgang og la den finne ut av resten.
For en organisasjon som kjører agenter i produksjon, er MCP plutselig essensielt. Her er hvorfor:
Sikkerhetsisolasjon. Du vil ikke at agenter skal ha direkte tilgang til databasen, betalingssystemet eller kundedataene dine. MCP lar deg lage et kontrollert grensesnitt som agenter kan kalle uten å eksponere de underliggende systemene.
Reviderbarhet. Hver agenthandling går gjennom MCP-serveren, som logger den. Du har en fullstendig oversikt over hva agenten gjorde og hvorfor.
Legitimasjonshåndtering. I stedet for å bygge inn API-nøkler i agent-prompts eller miljøvariabler, håndterer MCP-servere legitimasjon sikkert.
Hastighetsbegrensning og kvotehåndheving. Du kan kontrollere hvor mye av en ressurs en agent kan forbruke.
Ifølge CData Software evaluerer eller implementerer 80 % av Fortune 500-selskapene MCP per tidlig 2026, primært av disse grunnene.
Konsensusen på toppmøtet: MCP er ikke død. Det er bare ikke relevant for de 80 % av AI-utviklingen som er eksperimentell og solo. Men for de 20 % som er produksjon og på tvers av team, blir MCP en grunnleggende forutsetning.
Dette er grunnen til at MCP Apps sprer seg. Anthropic, OpenAI og tredjepartsleverandører bygger ferdige MCP-servere for vanlige verktøy (Salesforce, Slack, Jira, databaser). Enterpriser kan ta i bruk disse uten å bygge tilpassede servere.
Få de siste tipsene, trendene og tilbudene gratis.
Her ble toppmøtet mørkt.
AI skulle være en kraftmultiplikator. Du ville bruke mindre tid på rutineoppgaver og mer tid på strategisk tenkning. Produktiviteten ville gå gjennom taket.
I stedet gikk produktiviteten gjennom taket - og det gjorde arbeidsmengdeforventningene også.
Jevons’ paradoks, opprinnelig anvendt på kullforbruk, sier: Når en ressurs blir mer effektiv, øker totalforbruket fordi ressursen blir billigere og mer attraktiv.
I AI-termer: Agenter gjorde kodegenerering billigere og raskere, så ledere forventer nå at hver ingeniør:
Produktivitetsgevinstene ble spist opp av oppblåste forventninger.
En ingeniør fra en London-basert oppstart: “Jeg pleide å skrive 500 linjer kode om dagen og føle meg produktiv. Nå skriver jeg 5 000 linjer om dagen - generert av agenter - og jeg er utmattet fordi jeg må gjennomgå alt, teste det, dokumentere det og forklare det til interessenter. Jeg jobber 60-timers uker.”
En annen: “Sjefen min sier, ‘Du har en agent nå, så du burde kunne håndtere dobbelt så mange prosjekter.’ Jeg er ikke mer produktiv. Jeg er bare travlere.”
En forsker: “Agentene er gode til å generere kode. De er ikke gode til å bestemme hvilken kode som skal genereres. Beslutningsbyrden har flyttet seg helt over på mennesker. Vi automatiserer ikke den vanskelige delen; vi automatiserer den enkle delen og får mennesker til å gjøre mer tenking.”
UC Berkeleys California Management Review publiserte forskning i januar 2026 som dokumenterer dette fenomenet. Nøkkelinnsikten: AI-utrulling reduserer ikke arbeidet; det endrer arbeidets natur.
Gammelt arbeid: å skrive kode. Nytt arbeid: å styre agenter, evaluere output, opprettholde kvalitet, håndtere scope creep.
Det nye arbeidet er kognitivt vanskeligere, selv om det er mindre tasting.
Toppmøtet hadde en sterk europeisk kontingent, og deres budskap var konsistent: Europa beveger seg ikke like raskt som USA når det gjelder adopsjon av AI Engineering.
EUs AI Act er fortsatt under implementering. Selskaper er usikre på ansvar. Hvis en AI-agent tar en beslutning som skader en kunde, hvem er ansvarlig? Selskapet? Modellleverandøren? Ingeniøren?
Den usikkerheten er lammende. Mange europeiske selskaper venter på å se hvordan de første søksmålene utspiller seg før de bygger seriøse agentic systemer.
Tradisjonelle programvareingeniører i Europa blir ikke AI-ingeniører i samme tempo som i USA. Det er skepsis om hvorvidt ferdighetene er overførbare. Mange europeiske ingeniører venter på å se om AI Engineering er en reell karrierevei eller en hype-syklus.
Europa er også mer forsiktig med databehandling. Agenter trenger tilgang til data for å være nyttige. Men europeiske selskaper er nølende med å gi agenter tilgang til kundedata, selv med MCP-sikkerhetstiltak på plass.
Europeiske ingeniører på toppmøtet var ikke anti-AI. De var pro-forsiktighet. Stemningen: “USA beveger seg raskt og knuser ting. Vi beveger oss saktere og prøver å ikke knuse like mye. Om fem år får vi se hvem som hadde rett.”
Mot slutten av toppmøtet dukket et mønster opp: Tradisjonelle programvareingeniørroller blir uthulet og erstattet av tre nye arketyper.
| Rolle | Ansvar | Ferdigheter |
|---|---|---|
| AI PM | Definer agentatferd, suksessmål, begrensninger | Produkttenkning, promptdesign, evalueringsrammeverk |
| Agent-barnevakt | Overvåk utførelse, fang feil, grip inn når det trengs | Debugging, observability, feilhåndtering, hendelsesrespons |
| Smaksetter | Evaluer output-kvalitet, gi tilbakemelding, veiled finpussing | Kodegjennomgang, arkitekturtenkning, estetisk vurdering |
Ingen av disse rollene innebærer å skrive kode i tradisjonell forstand. Alle innebærer å styre, evaluere og finpusse agentatferd.
“Junior-ingeniør”-roller blir komprimert. Det er ikke lenger en klar vei fra “Jeg kan skrive enkel kode” til “Jeg kan arkitektere systemer.” Mellomtrinnene blir automatisert.
Dette skaper en ferdighetsstup: enten er du god til å prompte og evaluere (i så fall er du verdifull), eller så er du det ikke (i så fall konkurrerer du med agenter).
Roller som krever smak, dømmekraft og arkitektonisk tenkning vokser. Det samme gjør roller som krever dyp domeneekspertise (fordi agenter trenger mennesker for å evaluere om de løser riktig problem).
Toppmøtet hadde ingen konsensus om hvorvidt dette er bra eller dårlig. Noen så det som befrielse fra rutinekoding. Andre så det som en trussel mot profesjonen.
En seksjon av toppmøtet var viet et spesifikt vendepunkt: noe skiftet i AI-agent-økosystemet rundt nyttår.
OpenClaw og lignende rammeverk begynte å gjøre det mulig for agenter å iterativt forbedre sine egne utdata uten konstant menneskelig prompting. I stedet for “agent, skriv en funksjon for å beregne X,” ble det “agent, skriv en funksjon for å beregne X og fortsett å forbedre den til den består alle tester og håndterer kantsaker.”
Nøkkelinnsikten, artikulert av flere forskere: Slutt å be agenter om trivielle råd.
I stedet for å be en agent “forbedre denne funksjonen,” be den “gjør denne funksjonen skuddsikker.” La den bestemme hva det betyr. Agenten vil:
Alt uten å bli bedt om det for hvert trinn.
Dette endret den mentale modellen fra “agent som verktøy” til “agent som autonom bidragsyter.” Og det endret arbeidsbelastningsdynamikken: i stedet for at agenter reduserte menneskelig arbeid, økte de det (fordi mennesker nå måtte evaluere mye mer sofistikert agent-output).
Toppmøtet sluttet uten løsning, noe som føltes ærlig. Her er motsetningene som definerer AI Engineering i april 2026:
Motsetning 1: Agenter er kraftige nok til å være farlige (FOMAT er reelt), men ikke kraftige nok til å stoles på uten tilsyn.
Motsetning 2: Fart og kvalitet blir behandlet som motsetninger, men begge er nødvendige.
Motsetning 3: MCP er samtidig død (for individer) og blomstrer (for enterpriser).
Motsetning 4: AI gjorde oss mer produktive, men også mer overarbeidet.
Motsetning 5: Alle bygger med agenter, men ingen har funnet ut hvordan man bygger med dem godt.
Motsetning 6: AI Engineering er en reell karrierevei, men ferdighetene vi trodde ville bety noe (å skrive kode) gjør det ikke lenger.
Dette er ikke problemer som skal løses. Det er spenninger som skal håndteres. Teamene som vil vinne i 2026 er de som erkjenner disse motsetningene i stedet for å late som de ikke eksisterer.
London-toppmøtet var et øyeblikksbilde av en profesjon i overgang. AI Engineering er reelt, men det er ikke det vi trodde det ville bli. Det er rotete, mer motstridende og mer menneskelig-avhengig enn hypen antydet.
De beste ingeniørene på toppmøtet var ikke de med de mest sofistikerte agentene. De var de som forsto at agenter er et verktøy for tenking, ikke en erstatning for det. De var de som hadde bygget prosesser for å håndtere agentatferd, evaluere output og opprettholde kvalitet. De var de som hadde akseptert at produktivitetsgevinster kommer med nye typer arbeid, ikke mindre arbeid.
Hvis du bygger AI-systemer i 2026, er toppmøtets lærdommer klare:
Orkestrering betyr mer enn agentkapasitet. En middelmådig agent med god orkestrering slår en briljant agent uten kontroller.
Klarhet er mer verdifullt enn fart. Å bevege seg raskt og knuse ting fungerer inntil det ikke fungerer. I skala fungerer det ikke.
Enterprise-adopsjon er reell, men individuell adopsjon er fortsatt eksperimentell. Hvis du er solo-utvikler, kan du bevege deg raskt. Hvis du er et team, trenger du rekkverk.
Ferdighetene som betyr noe har endret seg. Prompt engineering, output-evaluering og arkitektonisk tenkning er de nye kjernekompetansene.
Forvent å jobbe hardere, ikke lettere. AI er en produktivitetsmultiplikator, men gevinstene blir spist opp av høyere forventninger. Planlegg deretter.
Toppmøtet svarte ikke på spørsmålet “Hvordan ser AI Engineering ut?” Det viste oss svaret: det ser ut som oss, som prøver å finne ut av det i sanntid.
{{ cta-dark-panel heading=“Slutt å orkestrere agenter manuelt” description=“FlowHunts arbeidsflytbygger lar deg definere agentatferd, sette rekkverk og automatisere flertrinns AI-oppgaver. Ikke mer FOMAT. Ikke mer gjetting på hva agentene dine gjør.” ctaPrimaryText=“Prøv FlowHunt gratis” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Bestill en demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
Arshia er en AI Workflow Engineer hos FlowHunt. Med bakgrunn i informatikk og en lidenskap for kunstig intelligens, spesialiserer han seg på å lage effektive arbeidsflyter som integrerer AI-verktøy i daglige oppgaver, og dermed øker produktivitet og kreativitet.
Slutt å orkestrere agenter manuelt. FlowHunts arbeidsflytbygger håndterer agentkjeding, feilgjenoppretting og flertrinns AI-oppgaver, slik at du kan fokusere på hva agentene skal gjøre, ikke hvordan du skal temme dem.
Utforsk hvordan AMP, Sourcegraphs banebrytende kodingsagent, omformer AI-utviklingslandskapet ved å omfavne rask iterasjon, autonom resonnering og verktøykallen...
OpenAIs Instant Checkout-kollaps handlet ikke om at agentic commerce feilet—det avslørte infrastruktur-gapet. Her er det som faktisk fungerer og hva handelsmenn...
Utforsk hvorfor AI-ledelse er avgjørende for organisasjoners suksess, hvordan sterke ledere driver AI-transformasjon, og hvordan FlowHunt sitt AI Leadership Wor...
Informasjonskapselsamtykke
Vi bruker informasjonskapsler for å forbedre din surfeopplevelse og analysere vår trafikk. See our privacy policy.
