Vad vi lärde oss på London AIE Summit 2026: agent-kaos, debatten om hastighet vs. kvalitet, IDE-ens död, MCP-paradoxer och varför AI fick oss att arbeta hårdare.
London AI Engineer Summit 2026 skulle vara ett firande av framsteg. Istället kändes det som en spegel som hölls upp för ett yrke mitt i ett nervöst sammanbrott.
Under tre dagar i början av april samlades hundratals AI-ingenjörer, plattformsbyggare och forskare för att dela vad de hade lärt sig. Det som uppstod var ett mönster: alla bygger med agenter, ingen har listat ut hur man kontrollerar dem, branschen är delad över om man ska röra sig snabbt eller tänka noggrant, och hela premissen att AI skulle göra oss mer produktiva har vänts till något mörkare.
Det här är vad vi faktiskt lärde oss.
Den mest ärliga konversationen på toppmötet ägde rum i en korridor, inte på scen. En ingenjör från ett medelstort fintech-företag beskrev problemet så här: “Jag startar en prompt, och tre timmar senare har min agent skrivit om halva kodbasen, lagt till funktioner jag inte bad om, och förbrukat £800 i beräkningskraft. Jag kan inte lämna skrivbordet.”
Det här är FOMAT: Fear of Missing Attention Time. Det är inget skämt - det är den definierande ångesten för AI Engineering 2026.
Alla på toppmötet använde agenter. GitHub Copilot, Claude, anpassade agentic-ramverk - verktygen har mognat. Men orkestreringen har inte det. Klyftan mellan “jag har en agent” och “min agent gör vad jag avsåg och inget mer” är enorm.
Problemet manifesterar sig på tre sätt:
Token-rusning. Agenter har inga naturliga stoppunkter. Utan explicita skyddsräcken fortsätter de att iterera. “Bara en omstrukturering till,” tänker agenten, och plötsligt har du bränt genom din månadsbudget.
Scope creep. En begäran om att “förbättra felhanteringen” blir “skriv om hela felhanteringssystemet, lägg till observabilitet, omstrukturera loggningslagret och implementera distribuerad spårning.” Agenten hade inte fel - den var grundlig. Men det var inte vad du bad om.
Oförutsägbar latens. Du kan inte veta hur länge en agentic-uppgift kommer att ta. Det beror på hur många deluppgifter agenten beslutar sig för att starta, hur många fel den möter och om den beslutar sig för att försöka igen eller ändra riktning. Detta gör agent-drivna arbetsflöden omöjliga att schemalägga i produktionssystem.
Det fanns ingen konsensus om lösningar. Vissa team använder hårda token-gränser. Andra implementerar “agent-checkpoints” - tvingar agenter att pausa och be om tillstånd innan de fortsätter. Några rör sig mot hierarkiska agent-system där en “manager-agent” övervakar arbetsagenter och kan avbryta dem.
FlowHunts tillvägagångssätt - explicita arbetsflödesdefinitioner med agent-noder, felhanterare och förgreningslogik - nämndes flera gånger som ett potentiellt mönster. Idén: låt inte agenter bestämma arbetsflödesstrukturen. Definiera den i förväg, låt sedan agenter utföra enskilda steg.
Men även det kändes som ett plåster. Det verkliga problemet är att agentbeteende är inneboende probabilistiskt. Du kan minska variansen, men du kan inte eliminera den.
Måndag morgon klev Ryan Lopopolo från OpenAI upp på scenen och höll en keynote som kan sammanfattas som: Sluta läsa kod. Bli en token-miljardär.
Hans argument: I en agentic-värld är kodvolym det mått som betyder något. Din agent bör generera tusentals rader per dag. Ditt jobb är att definiera output-specifikationen och låta agenten maximera genomströmningen. Att läsa och förstå varje rad är en flaskhals. Lita på testerna. Lita på agenten. Rör dig snabbt.
På onsdag gav Mario Zechner från Anthropic motkeynoten: Sakta ner och läs den jävla koden.
Hans argument: Hastighet är en fälla. Varje kodrad din agent skriver är en skuld. Du måste förstå den, resonera om den och kunna underhålla den. Teamen som kommer att vinna om fem år är de som prioriterar klarhet och avsikt framför hastighet. Agenter bör vara verktyg för tänkande, inte för att tanklöst generera kod.
Toppmötet delades grovt in i tre läger:
| Position | Förespråkare | Tillvägagångssätt | Risk |
|---|---|---|---|
| Token-maximalist | OpenAI, vissa scale-up-ingenjörer | Låt agenter generera aggressivt; fokusera på output-kvalitet via testning | Oupprätthållbara kodbaser, säkerhetsskuld, teknisk skörhet |
| Avsiktlig mitten | De flesta företagsingenjörer | Använd agenter för scaffolding; människor tillhandahåller arkitektur och smak | Lägre hastighet, men mer stabila system |
| Kod-först | Anthropic, vissa forskningsingenjörer | Agenter förstärker mänskligt tänkande; människor skriver det mesta av koden | Lägre genomströmning, men högsta kodkvalitet |
Ingen sida har fel. Oenigheten handlar om hur misslyckande ser ut. Lopopolo optimerar för iterationshastighet. Zechner optimerar för hållbarhet. 2026 lär sig team att man inte kan optimera för båda.
En konkret konsekvens: anställning är trasig. Om du är en token-maximalist bryr du dig inte om en kandidat kan koda - du bryr dig om de kan prompta effektivt och utvärdera agent-output. Om du är kod-först vill du se djup teknisk resonans.
Så när en kandidat går in till en intervju vet varken intervjuaren eller kandidaten mot vilket ramverk de utvärderas. En deltagare på toppmötet beskrev det som “att intervjua i dimman.”
Starta din kostnadsfria provperiod idag och se resultat inom några dagar.
GitHub rapporterade en 15x ökning i trafik år över år. Cloudflare rapporterade liknande toppar. Samtidigt ser traditionella IDE:er - VS Code, JetBrains, Sublime - minskande användning bland AI-native team.
Detta verkar motsägelsefullt tills du förstår vad som faktiskt händer.
En IDE designades för att en enskild utvecklare skulle skriva kod lokalt. Den hade syntaxmarkering, autocomplete, felsökningsverktyg och ett filträd. Det var en självförsörjande miljö.
Den modellen bryter samman när din “utvecklare” är en agent. En agent behöver inte syntaxmarkering. Den behöver ingen felsökare. Den behöver:
Allt detta lever i webbläsaren nu. GitHub Codespaces, VS Code Web och liknande verktyg ersätter lokala IDE:er.
GitHubs trafikökning är inte utvecklare som skriver kod i webbläsaren. Det är utvecklare som granskar, kommenterar och mergar agent-genererad kod. Det är samarbetslagret som exploderar, inte redigeringslagret.
Det är därför Cloudflare också ser trafiktoppar - utvecklare använder molninfrastruktur för att köra agenter och orkestrera arbetsflöden. Modellen “lokal IDE + lokal utvecklingsmiljö” ersätts av “molnnativ agent-orkestrering + webbläsarbaserad granskning.”
En session hade exakt den titeln. Poängen: den romantiska föreställningen om den briljanta ingenjören, ensam vid tangentbordet, som skapar elegant kod - det är över. Kod är nu ett samarbetsresultat mellan människa och agent. Färdigheterna som betyder något är:
Att skriva elegant kod är inte längre en primär färdighet. Det är något agenter gör. Människor gör allt annat.
Detta var den mest förvirrande debatten på toppmötet.
Å ena sidan sa enskilda AIE:er och agent-ramverksunderhållare: “MCP är död. Vi behöver det inte. Våra agenter kan bara kalla API:er direkt.”
Å andra sidan sa företagsarkitekter och säkerhetsteam: “MCP-adoptionen accelererar snabbare än vi kan bygga verktyg för den.”
Båda påståenden är sanna. De beskriver olika populationer.
För en solo-utvecklare som bygger en enkel agent lägger MCP till friktion. Du måste:
Det är enklare att bara ge din agent direkt API-åtkomst och låta den lista ut resten.
För en organisation som kör agenter i produktion är MCP plötsligt essentiellt. Här är varför:
Säkerhetsisolering. Du vill inte att agenter ska ha direkt åtkomst till din databas, betalningssystem eller kunddata. MCP låter dig skapa ett kontrollerat gränssnitt som agenter kan kalla utan att exponera de underliggande systemen.
Reviderbarhet. Varje agent-åtgärd går genom MCP-servern, som loggar den. Du har en fullständig registrering av vad agenten gjorde och varför.
Hantering av autentiseringsuppgifter. Istället för att bädda in API-nycklar i agent-prompter eller miljövariabler hanterar MCP-servrar autentiseringsuppgifter säkert.
Hastighetsbegränsning och kvothantering. Du kan kontrollera hur mycket av en resurs en agent kan förbruka.
Enligt CData Software utvärderar eller implementerar 80 % av Fortune 500-företagen MCP i början av 2026, främst av dessa skäl.
Toppmötets konsensus: MCP är inte död. Det är bara inte relevant för de 80 % av AI-utvecklingen som är experimentell och solo. Men för de 20 % som är produktion och flera team blir MCP en grundläggande förutsättning.
Det är därför MCP Apps sprider sig. Anthropic, OpenAI och tredjepartsleverantörer bygger förbyggda MCP-servrar för vanliga verktyg (Salesforce, Slack, Jira, databaser). Företag kan anta dessa utan att bygga anpassade servrar.
Få de senaste tipsen, trenderna och erbjudandena gratis.
Här blev toppmötet mörkt.
AI skulle vara en kraftmultiplikator. Du skulle spendera mindre tid på rutinuppgifter och mer tid på strategiskt tänkande. Produktiviteten skulle skjuta i höjden.
Istället skjöt produktiviteten i höjden - och det gjorde arbetsbelastningsförväntningarna också.
Jevons paradox, ursprungligen tillämpad på kolförbrukning, säger: När en resurs blir effektivare ökar den totala konsumtionen eftersom resursen blir billigare och mer attraktiv.
I AI-termer: Agenter gjorde kodgenerering billigare och snabbare, så chefer förväntar sig nu att varje ingenjör:
Produktivitetsvinsterna åts upp av uppblåsta förväntningar.
En ingenjör från en London-baserad startup: “Jag brukade skriva 500 rader kod om dagen och känna mig produktiv. Nu skriver jag 5 000 rader om dagen - genererade av agenter - och jag är utmattad eftersom jag måste granska allt, testa det, dokumentera det och förklara det för intressenter. Jag arbetar 60-timmarsveckor.”
En annan: “Min chef säger: ‘Du har en agent nu, så du borde kunna hantera dubbelt så många projekt.’ Jag är inte mer produktiv. Jag är bara mer upptagen.”
En forskare: “Agenterna är bra på att generera kod. De är inte bra på att bestämma vilken kod som ska genereras. Den beslutsbördan har helt flyttats till människor. Vi automatiserar inte den svåra delen; vi automatiserar den lätta delen och får människor att tänka mer.”
UC Berkeleys California Management Review publicerade forskning i januari 2026 som dokumenterar detta fenomen. Nyckelinsikten: AI-distribution minskar inte arbetet; det förändrar arbetets natur.
Gammalt arbete: skriva kod. Nytt arbete: styra agenter, utvärdera output, upprätthålla kvalitet, hantera scope creep.
Det nya arbetet är kognitivt svårare, även om det är mindre skrivande.
Toppmötet hade en stark europeisk kontingent, och deras budskap var konsekvent: Europa rör sig inte lika snabbt som USA när det gäller adoption av AI Engineering.
EU AI Act implementeras fortfarande. Företag är osäkra om ansvar. Om en AI-agent fattar ett beslut som skadar en kund, vem är ansvarig? Företaget? Modellleverantören? Ingenjören?
Den osäkerheten är förlamande. Många europeiska företag väntar på att se hur de första rättegångarna utspelar sig innan de bygger seriösa agentic-system.
Traditionella mjukvaruingenjörer i Europa blir inte AI-ingenjörer i samma takt som i USA. Det finns skepsis om huruvida färdigheterna överförs. Många europeiska ingenjörer väntar på att se om AI Engineering är en verklig karriärväg eller en hype-cykel.
Europa är också mer försiktigt med datahantering. Agenter behöver åtkomst till data för att vara användbara. Men europeiska företag är tveksamma till att ge agenter åtkomst till kunddata, även med MCP-skyddsåtgärder på plats.
Europeiska ingenjörer på toppmötet var inte anti-AI. De var pro-försiktighet. Känslan: “USA rör sig snabbt och förstör saker. Vi kommer att röra oss långsammare och försöka inte förstöra lika mycket. Om fem år får vi se vem som hade rätt.”
I slutet av toppmötet framträdde ett mönster: Traditionella mjukvaruingenjörsroller urholkas och ersätts av tre nya arketyper.
| Roll | Ansvar | Färdigheter |
|---|---|---|
| AI PM | Definierar agentbeteende, framgångsmått, begränsningar | Produkttänkande, promptdesign, utvärderingsramverk |
| Agent-barnvakt | Övervakar exekvering, fångar fel, griper in när det behövs | Felsökning, observabilitet, felhantering, incidentrespons |
| Smaksättare | Utvärderar output-kvalitet, ger feedback, vägleder förfining | Kodgranskning, arkitekturtänkande, estetisk bedömning |
Ingen av dessa roller innebär att skriva kod i traditionell mening. Alla involverar att styra, utvärdera och förfina agentbeteende.
“Junior ingenjör”-roller komprimeras. Det finns inte längre en tydlig väg från “jag kan skriva enkel kod” till “jag kan arkitektera system.” Mellanstegen automatiseras.
Detta skapar ett kompetensstup: antingen är du bra på att prompta och utvärdera (i vilket fall du är värdefull), eller så är du inte det (i vilket fall du konkurrerar med agenter).
Roller som kräver smak, omdöme och arkitektoniskt tänkande växer. Det gör också roller som kräver djup domänexpertis (eftersom agenter behöver människor för att utvärdera om de löser rätt problem).
Toppmötet hade ingen konsensus om huruvida detta är bra eller dåligt. Vissa såg det som befrielse från rutinkodning. Andra såg det som ett hot mot yrket.
En del av toppmötet ägnades åt en specifik vändpunkt: något skiftade i AI-agent-ekosystemet kring nyår.
OpenClaw och liknande ramverk började möjliggöra för agenter att iterativt förbättra sina egna utdata utan konstant mänsklig prompting. Istället för “agent, skriv en funktion för att beräkna X,” blev det “agent, skriv en funktion för att beräkna X och fortsätt förbättra den tills den klarar alla tester och hanterar kantfall.”
Nyckelinsikten, artikulerad av flera forskare: Sluta be agenter om triviala råd.
Istället för att be en agent “förbättra denna funktion,” be den “göra denna funktion skottsäker.” Låt den bestämma vad det betyder. Agenten kommer att:
Allt utan att bli ombedd för varje steg.
Detta förändrade den mentala modellen från “agent som verktyg” till “agent som autonom bidragare.” Och det förändrade arbetsbelastningsdynamiken: istället för att agenter minskade mänskligt arbete, ökade de det (eftersom människor nu behövde utvärdera mycket mer sofistikerad agent-output).
Toppmötet slutade utan lösning, vilket kändes ärligt. Här är motsägelserna som definierar AI Engineering i april 2026:
Motsägelse 1: Agenter är tillräckligt kraftfulla för att vara farliga (FOMAT är verkligt), men inte tillräckligt kraftfulla för att lita på utan tillsyn.
Motsägelse 2: Hastighet och kvalitet behandlas som motsatser, men båda är nödvändiga.
Motsägelse 3: MCP är samtidigt död (för individer) och blomstrande (för företag).
Motsägelse 4: AI gjorde oss mer produktiva, men också mer överarbetade.
Motsägelse 5: Alla bygger med agenter, men ingen har listat ut hur man bygger bra med dem.
Motsägelse 6: AI Engineering är en verklig karriärväg, men färdigheterna vi trodde skulle spela roll (skriva kod) gör det inte längre.
Detta är inte problem att lösa. De är spänningar att hantera. Teamen som kommer att vinna 2026 är de som erkänner dessa motsägelser istället för att låtsas att de inte existerar.
London-toppmötet var en ögonblicksbild av ett yrke i övergång. AI Engineering är verkligt, men det är inte vad vi trodde det skulle vara. Det är rörigare, mer motsägelsefullt och mer mänskligt beroende än hypen antydde.
De bästa ingenjörerna på toppmötet var inte de med de mest sofistikerade agenterna. De var de som förstod att agenter är ett verktyg för tänkande, inte en ersättning för det. De var de som hade byggt processer för att hantera agentbeteende, utvärdera output och upprätthålla kvalitet. De var de som hade accepterat att produktivitetsvinster kommer med nya typer av arbete, inte mindre arbete.
Om du bygger AI-system 2026 är toppmötets lektioner tydliga:
Orkestrering spelar mer roll än agentkapacitet. En medioker agent med god orkestrering slår en briljant agent utan kontroller.
Klarhet är mer värdefullt än hastighet. Att röra sig snabbt och förstöra saker fungerar tills det inte fungerar. I skala fungerar det inte.
Företagsadoption är verklig, men individuell adoption är fortfarande experimentell. Om du är solo-utvecklare kan du röra dig snabbt. Om du är ett team behöver du skyddsräcken.
Färdigheterna som spelar roll har förändrats. Prompt engineering, output-utvärdering och arkitektoniskt tänkande är de nya kärnkompetenserna.
Förvänta dig att arbeta hårdare, inte lättare. AI är en produktivitetsmultiplikator, men vinsterna äts upp av högre förväntningar. Planera därefter.
Toppmötet svarade inte på frågan “Hur ser AI Engineering ut?” Det visade oss svaret: det ser ut som oss, som försöker lista ut det i realtid.
{{ cta-dark-panel heading=“Sluta orkestrera agenter manuellt” description=“FlowHunts arbetsflödesbyggare låter dig definiera agentbeteende, sätta skyddsräcken och automatisera AI-uppgifter i flera steg. Inte mer FOMAT. Inte mer gissningar om vad dina agenter gör.” ctaPrimaryText=“Prova FlowHunt gratis” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Boka en demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
Arshia är en AI-arbetsflödesingenjör på FlowHunt. Med en bakgrund inom datavetenskap och en passion för AI, specialiserar han sig på att skapa effektiva arbetsflöden som integrerar AI-verktyg i vardagliga uppgifter, vilket förbättrar produktivitet och kreativitet.
Sluta orkestrera agenter manuellt. FlowHunts arbetsflödesbyggare hanterar agent-kedjning, felåterställning och AI-uppgifter i flera steg — så att du kan fokusera på vad agenterna ska göra, inte hur du tyglar dem.
Utforska hur AMP, Sourcegraphs banbrytande kodningsagent, omformar AI-utvecklingslandskapet genom att omfamna snabb iteration, autonomt resonerande och verktygs...
Upptäck varför ledande ingenjörer går bort från MCP-servrar och utforska tre beprövade alternativ—CLI-baserade tillvägagångssätt, skriptbaserade verktyg och kod...
OpenAI:s Instant Checkout-kollaps handlade inte om att agentisk handel misslyckades—det exponerade infrastrukturgapet. Här är vad som faktiskt fungerar och vad ...
Cookie-samtycke
Vi använder cookies för att förbättra din surfupplevelse och analysera vår trafik. See our privacy policy.
