De London AI Engineer Summit 2026 zou een viering van vooruitgang worden. In plaats daarvan voelde het als een spiegel die een beroep werd voorgehouden midden in een zenuwinzinking.
Drie dagen lang, begin april, kwamen honderden AI engineers, platformbouwers en onderzoekers samen om te delen wat ze hadden geleerd. Wat naar voren kwam, was een patroon: iedereen bouwt met agents, niemand heeft uitgevogeld hoe je ze beheerst, de industrie is verdeeld over de vraag of je snel moet handelen of zorgvuldig moet nadenken, en de hele aanname dat AI ons productiever zou maken, is omgekeerd in iets duisterders.
Dit is wat we werkelijk hebben geleerd.
Waarom coderen AI engineers met agents die ze niet kunnen beheersen?
Het meest eerlijke gesprek op de summit vond plaats op een gang, niet op het podium. Een engineer van een middelgroot fintech-bedrijf omschreef het probleem zo: “Ik geef een prompt, en drie uur later heeft mijn agent de helft van de codebase herschreven, features toegevoegd die ik niet had gevraagd en voor £800 aan compute verbruikt. Ik kan mijn bureau niet verlaten.”
Dit is FOMAT: Fear of Missing Attention Time. Het is geen grap - het is de definiërende angst van AI engineering in 2026.
De orkestratiebottleneck
Iedereen op de summit gebruikte agents. GitHub Copilot, Claude, custom agentic frameworks - de tooling is volwassen geworden. Maar orkestratie niet. De kloof tussen “Ik heb een agent” en “mijn agent doet wat ik bedoelde en niets meer” is enorm.
Het probleem manifesteert zich op drie manieren:
Token-runaway. Agents hebben geen natuurlijke stoppunten. Zonder expliciete guardrails blijven ze itereren. “Nog één refactor,” denkt de agent, en plotseling is je maandbudget opgebrand.
Scope creep. Een verzoek om “de foutafhandeling te verbeteren” wordt “herschrijf het hele foutafhandelingssysteem, voeg observability toe, refactor de logginglaag en implementeer distributed tracing.” De agent zat er niet naast - hij was grondig. Maar het was niet wat je vroeg.
Onvoorspelbare latency. Je weet niet hoe lang een agentic-taak zal duren. Het hangt af van hoeveel subtaken de agent besluit te spawnen, hoeveel fouten hij tegenkomt en of hij besluit opnieuw te proberen of te pivoten. Dit maakt agentgedreven workflows onmogelijk in te plannen in productiesystemen.
Wat de summit-consensus was (en niet was)
Er was geen consensus over oplossingen. Sommige teams gebruiken harde tokenlimieten. Anderen implementeren “agent checkpoints” - waarbij agents gedwongen worden te pauzeren en toestemming te vragen voordat ze verder gaan. Enkele teams gaan richting hiërarchische agentsystemen waarin een “manager agent” worker agents overziet en hen kan onderbreken.
FlowHunts aanpak - expliciete workflow-definities met agent-nodes, error handlers en branching-logica - werd meerdere keren genoemd als een potentieel patroon. Het idee: laat agents de workflowstructuur niet bepalen. Definieer die van tevoren en laat agents vervolgens individuele stappen uitvoeren.
Maar zelfs dat voelde als een pleister. Het echte probleem is dat agentgedrag inherent probabilistisch is. Je kunt variantie verminderen, maar niet elimineren.
Hoe heeft de OpenAI-Anthropic-kloof hervormd wat “goede code” betekent?
Maandagochtend betrad Ryan Lopopolo van OpenAI het podium en gaf een keynote die samen te vatten was als: Stop met code lezen. Word een token-miljardair.
Zijn argument: in een agentic wereld is codevolume de metric die ertoe doet. Je agent zou duizenden regels per dag moeten genereren. Jouw taak is de output-spec definiëren en de agent de throughput laten maximaliseren. Elke regel lezen en begrijpen is een bottleneck. Vertrouw op de tests. Vertrouw op de agent. Werk snel.
Woensdag gaf Mario Zechner van Anthropic de tegen-keynote: Vertraag en lees de verdomde code.
Zijn argument: snelheid is een val. Elke regel code die je agent schrijft is een liability. Je moet hem begrijpen, erover kunnen redeneren en hem kunnen onderhouden. De teams die over vijf jaar zullen winnen, zijn degenen die helderheid en intentie verkiezen boven snelheid. Agents moeten tools zijn om na te denken, niet om gedachteloos code te genereren.
Het spectrum
De summit splitste zich ruwweg in drie kampen:
| Positie | Voorstanders | Aanpak | Risico |
|---|---|---|---|
| Token-maximalist | OpenAI, sommige scale-up engineers | Laat agents agressief genereren; focus op outputkwaliteit via testing | Niet-onderhoudbare codebases, beveiligingsschuld, technische fragiliteit |
| Intentioneel midden | De meeste enterprise-engineers | Gebruik agents voor scaffolding; mensen leveren architectuur en smaak | Lagere snelheid, maar stabielere systemen |
| Code-eerst | Anthropic, sommige research engineers | Agents versterken menselijk denken; mensen schrijven de meeste code | Lagere throughput, maar hoogste codekwaliteit |
Geen van beide kanten heeft ongelijk. De onenigheid gaat over hoe falen eruitziet. Lopopolo optimaliseert voor iteratiesnelheid. Zechner optimaliseert voor duurzaamheid. In 2026 leren teams dat je niet voor beide kunt optimaliseren.
Het interview-probleem
Een concreet gevolg: hiring is kapot. Als je een token-maximalist bent, maakt het je niet uit of een kandidaat kan coderen - het gaat erom of hij effectief kan prompten en agent-output kan evalueren. Als je code-eerst bent, wil je diepgaand technisch redeneren zien.
Dus wanneer een kandidaat een sollicitatiegesprek binnenloopt, weten noch de interviewer noch de kandidaat tegen welk framework hij wordt geëvalueerd. Een summit-bezoeker omschreef het als “solliciteren in de mist.”
Klaar om uw bedrijf te laten groeien?
Start vandaag uw gratis proefperiode en zie binnen enkele dagen resultaten.
Waarom sterven IDE’s uit terwijl GitHub-verkeer ontploft?
GitHub rapporteerde een verkeerstoename van 15x op jaarbasis. Cloudflare rapporteerde vergelijkbare pieken. Ondertussen zien traditionele IDE’s - VS Code, JetBrains, Sublime - hun gebruik afnemen bij AI-native teams.
Dit lijkt tegenstrijdig totdat je begrijpt wat er werkelijk gebeurt.
De IDE was een lokale denktool
Een IDE was ontworpen voor één ontwikkelaar om lokaal code te schrijven. Hij had syntax highlighting, autocomplete, debugtools en een bestandsboom. Het was een op zichzelf staande omgeving.
Dat model breekt wanneer je “ontwikkelaar” een agent is. Een agent heeft geen syntax highlighting nodig. Hij heeft geen debugger nodig. Hij heeft nodig:
- Toegang tot meerdere bestanden tegelijk
- De mogelijkheid om code uit te voeren en resultaten te zien
- Integratie met versiebeheer
- Samenwerkingsfuncties (omdat agent en mens samenwerken)
Dat alles leeft nu in de browser. GitHub Codespaces, VS Code Web en vergelijkbare tools vervangen lokale IDE’s.
Wat er werkelijk groeit
De verkeerstoename van GitHub komt niet doordat ontwikkelaars in de browser code schrijven. Het zijn ontwikkelaars die door agents gegenereerde code reviewen, erop commenten en mergen. Het is de samenwerkingslaag die explodeert, niet de editlaag.
Dit is waarom Cloudflare ook verkeerspieken ziet - ontwikkelaars gebruiken cloudinfrastructuur om agents te draaien en workflows te orkestreren. Het model “lokale IDE + lokale ontwikkelomgeving” wordt vervangen door “cloud-native agent-orkestratie + browsergebaseerde review.”
L33T C0d3 is dood
Eén sessie had precies die titel. De strekking: het romantische idee van de briljante engineer, alleen achter zijn toetsenbord, die elegante code smeedt - dat is voorbij. Code is nu een samenwerkingsoutput tussen mens en agent. De vaardigheden die ertoe doen zijn:
- Prompt engineering (hoe specificeer je wat je wilt)
- Output-evaluatie (is de code van de agent goed?)
- Architectuurdenken (in welke structuur moet de agent werken?)
- Integratie (hoe past door de agent gegenereerde code in bestaande systemen?)
Elegante code schrijven is geen primaire vaardigheid meer. Dat doen agents. Mensen doen al het andere.
Wat gebeurt er echt met MCP - dood of bloeiend?
Dit was het meest verwarrende debat op de summit.
Aan de ene kant zeiden individuele AIE’s en agent-framework-onderhouders: “MCP is dood. We hebben het niet nodig. Onze agents kunnen API’s gewoon direct aanroepen.”
Aan de andere kant zeiden enterprise-architecten en beveiligingsteams: “De adoptie van MCP versnelt sneller dan we tooling ervoor kunnen bouwen.”
Beide uitspraken zijn waar. Ze beschrijven verschillende populaties.
Waarom AIE’s denken dat MCP dood is
Voor een solo-ontwikkelaar die een eenvoudige agent bouwt, voegt MCP wrijving toe. Je moet:
- MCP-servers voor je tools definiëren
- De protocol-overhead beheren
- Authenticatie en autorisatie afhandelen
- De servers deployen en onderhouden
Het is makkelijker om je agent gewoon directe API-toegang te geven en hem de rest te laten uitvogelen.
Waarom enterprises MCP snel adopteren
Voor een organisatie die agents in productie draait, is MCP plotseling essentieel. Dit is waarom:
Beveiligingsisolatie. Je wilt niet dat agents directe toegang hebben tot je database, betalingssysteem of klantgegevens. Met MCP kun je een gecontroleerde interface creëren die agents kunnen aanroepen zonder de onderliggende systemen bloot te leggen.
Auditability. Elke agent-actie loopt via de MCP-server, die het logt. Je hebt een volledig overzicht van wat de agent deed en waarom.
Credential management. In plaats van API-keys in agent-prompts of omgevingsvariabelen in te bedden, beheren MCP-servers credentials veilig.
Rate limiting en quota-enforcement. Je kunt bepalen hoeveel van een resource een agent mag verbruiken.
Volgens CData Software evalueert of implementeert 80% van de Fortune 500-bedrijven MCP per begin 2026, voornamelijk om deze redenen.
De oplossing
De summit-consensus: MCP is niet dood. Het is alleen niet relevant voor de 80% van AI-ontwikkeling die experimenteel en solo is. Maar voor de 20% die productie en multi-team is, wordt MCP table stakes.
Dit is waarom MCP Apps zich verspreiden. Anthropic, OpenAI en derde-partij-leveranciers bouwen kant-en-klare MCP-servers voor gangbare tools (Salesforce, Slack, Jira, databases). Enterprises kunnen deze adopteren zonder aangepaste servers te bouwen.
Schrijf u in voor onze nieuwsbrief
Ontvang gratis de nieuwste tips, trends en aanbiedingen.
Maakt AI ons productiever, of gewoon overwerkter?
Hier werd de summit duister.
AI zou een force multiplier worden. Je zou minder tijd aan routinetaken besteden en meer aan strategisch denken. De productiviteit zou door het dak gaan.
In plaats daarvan ging de productiviteit door het dak - en de werkverwachtingen ook.
De paradox van Jevons in real time
De paradox van Jevons, oorspronkelijk toegepast op kolenverbruik, stelt: wanneer een hulpbron efficiënter wordt, neemt het totale verbruik toe omdat de hulpbron goedkoper en aantrekkelijker wordt.
In AI-termen: agents maakten codegeneratie goedkoper en sneller, dus managers verwachten nu dat elke engineer:
- 10x meer output levert
- Uitgebreide documentatie schrijft
- Volledige testsuites bouwt
- Internationalisatie (i18n) ondersteunt
- Edge cases afhandelt
- Alles solo doet
De productiviteitswinst werd opgeslokt door opgeblazen verwachtingen.
Wat engineers zeiden
Eén engineer van een in Londen gevestigde startup: “Ik schreef vroeger 500 regels code per dag en voelde me productief. Nu schrijf ik 5.000 regels per dag - gegenereerd door agents - en ik ben uitgeput omdat ik alles moet reviewen, testen, documenteren en uitleggen aan stakeholders. Ik werk 60-urige werkweken.”
Een ander: “Mijn manager zegt: ‘Je hebt nu een agent, dus je zou twee keer zoveel projecten moeten kunnen behappen.’ Ik ben niet productiever. Ik ben gewoon drukker.”
Een onderzoeker: “De agents zijn goed in het genereren van code. Ze zijn niet goed in beslissen welke code gegenereerd moet worden. Die beslissingslast is volledig naar mensen verschoven. We automatiseren niet het moeilijke deel; we automatiseren het gemakkelijke deel en laten mensen meer nadenken.”
De productiviteitsblinde vlek
UC Berkeley’s California Management Review publiceerde in januari 2026 onderzoek dat dit fenomeen documenteert. Het kerninzicht: AI-deployment vermindert het werk niet; het verandert de aard van het werk.
Oud werk: code schrijven. Nieuw werk: agents aansturen, output evalueren, kwaliteit handhaven, scope creep beheren.
Het nieuwe werk is cognitief moeilijker, zelfs als er minder getypt wordt.
Waarom is Europa zo terughoudend over AI Engineering?
De summit had een sterke Europese delegatie, en hun boodschap was consistent: Europa beweegt niet zo snel als de VS op het gebied van AI engineering-adoptie.
De regulatoire overhang
De EU AI Act wordt nog steeds geïmplementeerd. Bedrijven zijn onzeker over aansprakelijkheid. Als een AI-agent een beslissing neemt die een klant schaadt, wie is dan verantwoordelijk? Het bedrijf? De modelleverancier? De engineer?
Die onzekerheid is verlammend. Veel Europese bedrijven wachten om te zien hoe de eerste rechtszaken uitpakken voordat ze serieuze agentic systemen bouwen.
Het skills-tekort
Traditionele software engineers in Europa worden niet in hetzelfde tempo AI engineers als in de VS. Er is scepsis of de vaardigheden overdraagbaar zijn. Veel Europese engineers wachten af of AI engineering een echt carrièrepad is of een hypecyclus.
Privacyzorgen
Europa is ook voorzichtiger met datahandling. Agents hebben toegang tot data nodig om nuttig te zijn. Maar Europese bedrijven aarzelen om agents toegang te geven tot klantgegevens, zelfs met MCP-waarborgen.
Het pad vooruit
Europese engineers op de summit waren niet anti-AI. Ze waren pro-voorzichtigheid. Het sentiment: “De VS beweegt snel en breekt dingen. Wij bewegen langzamer en proberen niet zoveel te breken. Over vijf jaar zien we wie gelijk had.”
Hoe veranderen AI Engineering-rollen eigenlijk?
Tegen het einde van de summit kwam een patroon naar voren: traditionele software engineering-rollen worden uitgehold en vervangen door drie nieuwe archetypes.
De drie rollen
| Rol | Verantwoordelijkheid | Vaardigheden |
|---|---|---|
| AI PM | Definieer agentgedrag, succesmetrics, beperkingen | Productdenken, promptontwerp, evaluatieframeworks |
| Agent Babysitter | Monitor uitvoering, vang fouten op, grijp in waar nodig | Debugging, observability, foutafhandeling, incidentrespons |
| Taste Setter | Evalueer outputkwaliteit, geef feedback, leid verfijning | Code review, architectuurdenken, esthetisch oordeel |
Geen van deze rollen houdt in dat je code schrijft in de traditionele zin. Ze draaien allemaal om het aansturen, evalueren en verfijnen van agentgedrag.
Wat verdwijnt
“Junior engineer”-rollen worden gecomprimeerd. Er is geen duidelijk pad meer van “Ik kan simpele code schrijven” naar “Ik kan systemen architecteren.” De tussenstappen worden geautomatiseerd.
Dit creëert een skills-klif: ofwel je bent goed in prompten en evalueren (in welk geval je waardevol bent), ofwel niet (in welk geval je concurreert met agents).
Wat groeit
Rollen die smaak, oordeel en architecturaal denken vereisen, groeien. Net als rollen die diepgaande domeinexpertise vereisen (omdat agents mensen nodig hebben om te evalueren of ze het juiste probleem oplossen).
De summit had geen consensus over de vraag of dit goed of slecht is. Sommigen zagen het als bevrijding van eentonig coderen. Anderen zagen het als een bedreiging voor het beroep.
Wat veranderde er tussen december 2025 en februari 2026?
Eén deel van de summit was gewijd aan een specifiek kantelpunt: er verschoof iets in het AI-agent-ecosysteem rond de jaarwisseling.
Zelfverbeterende software werd realiteit
OpenClaw en vergelijkbare frameworks begonnen agents in staat te stellen hun eigen output iteratief te verbeteren zonder constante menselijke prompting. In plaats van “agent, schrijf een functie om X te berekenen,” werd het “agent, schrijf een functie om X te berekenen en blijf hem verbeteren totdat hij alle tests doorstaat en edge cases afhandelt.”
Het kerninzicht, zoals verwoord door meerdere onderzoekers: Stop met agents om triviaal advies te vragen.
In plaats van een agent te vragen “verbeter deze functie,” vraag hem “maak deze functie bulletproof.” Laat hem beslissen wat dat betekent. De agent zal:
- Tests schrijven
- Edge cases vinden
- Refactoren voor helderheid
- Foutafhandeling toevoegen
- De logica documenteren
Dit alles zonder voor elke stap gevraagd te worden.
Dit veranderde het mentale model van “agent als tool” naar “agent als autonome bijdrager.” En het veranderde de werkbelastingsdynamiek: in plaats van dat agents menselijk werk verminderden, vergrootten ze het (omdat mensen nu veel geavanceerdere agent-output moesten evalueren).
De tegenstrijdigheden waarmee we leven
De summit eindigde zonder resolutie, wat eerlijk aanvoelde. Hier zijn de tegenstrijdigheden die AI engineering in april 2026 definiëren:
Tegenstrijdigheid 1: Agents zijn krachtig genoeg om gevaarlijk te zijn (FOMAT is echt), maar niet krachtig genoeg om onbeheerd vertrouwd te worden.
Tegenstrijdigheid 2: Snelheid en kwaliteit worden als tegenpolen behandeld, maar beide zijn nodig.
Tegenstrijdigheid 3: MCP is tegelijkertijd dood (voor individuen) en bloeiend (voor enterprises).
Tegenstrijdigheid 4: AI maakte ons productiever, maar ook overwerkter.
Tegenstrijdigheid 5: Iedereen bouwt met agents, maar niemand heeft uitgevogeld hoe je er goed mee bouwt.
Tegenstrijdigheid 6: AI engineering is een echt carrièrepad, maar de vaardigheden waarvan we dachten dat ze ertoe zouden doen (code schrijven) doen dat niet meer.
Dit zijn geen problemen die opgelost moeten worden. Het zijn spanningen die beheerd moeten worden. De teams die in 2026 zullen winnen, zijn degenen die deze tegenstrijdigheden erkennen in plaats van te doen alsof ze niet bestaan.
Veelgestelde vragen
Wat we meenemen
De London summit was een momentopname van een beroep in transitie. AI engineering is echt, maar het is niet wat we dachten dat het zou zijn. Het is rommeliger, meer tegenstrijdig en afhankelijker van mensen dan de hype deed vermoeden.
De beste engineers op de summit waren niet degenen met de meest geavanceerde agents. Het waren degenen die begrepen dat agents een tool zijn om na te denken, geen vervanging daarvoor. Het waren degenen die processen hadden gebouwd om agentgedrag te beheren, output te evalueren en kwaliteit te handhaven. Het waren degenen die hadden geaccepteerd dat productiviteitswinst gepaard gaat met nieuwe soorten werk, niet met minder werk.
Als je in 2026 AI-systemen bouwt, zijn de lessen van de summit duidelijk:
Orkestratie doet er meer toe dan agentcapaciteit. Een middelmatige agent met goede orkestratie verslaat een briljante agent zonder controles.
Helderheid is waardevoller dan snelheid. Snel bewegen en dingen breken werkt totdat het niet meer werkt. Op schaal werkt het niet.
Enterprise-adoptie is echt, maar individuele adoptie is nog steeds experimenteel. Als je een solo-ontwikkelaar bent, kun je snel gaan. Als je een team bent, heb je guardrails nodig.
De vaardigheden die ertoe doen zijn veranderd. Prompt engineering, output-evaluatie en architecturaal denken zijn de nieuwe kerncompetenties.
Verwacht harder te werken, niet makkelijker. AI is een productiviteitsmultiplier, maar de winst wordt opgeslokt door hogere verwachtingen. Plan dienovereenkomstig.
De summit beantwoordde niet de vraag “Hoe ziet AI engineering eruit?” Hij toonde ons het antwoord: het ziet eruit zoals wij, die het in real time proberen uit te vogelen.
{{ cta-dark-panel heading=“Stop met het handmatig orkestreren van agents” description=“Met de workflowbouwer van FlowHunt definieer je agentgedrag, stel je guardrails in en automatiseer je meerstaps AI-taken. Geen FOMAT meer. Geen giswerk meer over wat je agents doen.” ctaPrimaryText=“Probeer FlowHunt gratis” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Boek een demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
