Der London AI Engineer Summit 2026 sollte eine Feier des Fortschritts sein. Stattdessen fühlte er sich an wie ein Spiegel, der einem Beruf mitten in einem Nervenzusammenbruch vorgehalten wird.
Drei Tage lang versammelten sich Anfang April Hunderte von KI-Ingenieuren, Plattformbauern und Forschern, um zu teilen, was sie gelernt hatten. Was sich abzeichnete, war ein Muster: Alle bauen mit Agenten, niemand hat herausgefunden, wie man sie kontrolliert, die Branche ist gespalten, ob man schnell vorangehen oder sorgfältig nachdenken soll, und die gesamte Prämisse, dass KI uns produktiver machen würde, hat sich in etwas Dunkleres verkehrt.
Das ist, was wir tatsächlich gelernt haben.
Warum programmieren KI-Ingenieure mit Agenten, die sie nicht kontrollieren können?
Das ehrlichste Gespräch auf dem Summit fand in einem Flur statt, nicht auf der Bühne. Ein Ingenieur eines mittelgroßen Fintech-Unternehmens beschrieb das Problem so: „Ich starte einen Prompt, und drei Stunden später hat mein Agent die halbe Codebasis umgeschrieben, Features hinzugefügt, die ich nicht wollte, und 800 £ an Rechenleistung verbraucht. Ich kann meinen Schreibtisch nicht verlassen."
Das ist FOMAT: Fear of Missing Attention Time. Es ist kein Witz – es ist die prägende Angst des KI-Engineerings 2026.
Der Orchestrierungs-Engpass
Alle auf dem Summit nutzten Agenten. GitHub Copilot, Claude, eigene agentische Frameworks – die Tools sind gereift. Aber die Orchestrierung nicht. Die Kluft zwischen „Ich habe einen Agenten" und „Mein Agent tut, was ich wollte, und nichts weiter" ist enorm.
Das Problem manifestiert sich auf drei Arten:
Token-Runaway. Agenten haben keine natürlichen Stopppunkte. Ohne explizite Leitplanken iterieren sie weiter. „Nur noch ein Refactoring", denkt der Agent, und plötzlich hast du dein Monatsbudget verbraucht.
Scope Creep. Eine Anfrage, „die Fehlerbehandlung zu verbessern", wird zu „das gesamte Fehlerbehandlungssystem umschreiben, Observability hinzufügen, die Logging-Schicht refaktorieren und verteiltes Tracing implementieren". Der Agent hatte nicht unrecht – er war gründlich. Aber er tat nicht, was du verlangt hast.
Unvorhersehbare Latenz. Du kannst nicht wissen, wie lange eine agentische Aufgabe dauert. Es hängt davon ab, wie viele Unteraufgaben der Agent startet, wie viele Fehler er trifft und ob er es erneut versucht oder umschwenkt. Das macht agentengesteuerte Workflows in Produktionssystemen unmöglich zu planen.
Was der Summit-Konsens war (und nicht war)
Es gab keinen Konsens über Lösungen. Einige Teams verwenden harte Token-Limits. Andere implementieren „Agenten-Checkpoints" – zwingen Agenten zu pausieren und um Erlaubnis zu bitten, bevor sie fortfahren. Einige bewegen sich in Richtung hierarchischer Agentensysteme, bei denen ein „Manager-Agent" Worker-Agenten überwacht und unterbrechen kann.
Der Ansatz von FlowHunt – explizite Workflow-Definitionen mit Agentenknoten, Fehlerbehandlungen und Verzweigungslogik – wurde mehrfach als potenzielles Muster erwähnt. Die Idee: Lass Agenten nicht die Workflow-Struktur entscheiden. Definiere sie im Voraus und lass dann Agenten einzelne Schritte ausführen.
Aber selbst das fühlte sich wie ein Pflaster an. Das eigentliche Problem ist, dass Agentenverhalten inhärent probabilistisch ist. Du kannst die Varianz reduzieren, aber nicht eliminieren.
Wie hat der OpenAI-Anthropic-Graben neu geformt, was „guter Code" bedeutet?
Am Montagmorgen betrat Ryan Lopopolo von OpenAI die Bühne und hielt eine Keynote, die sich zusammenfassen lässt als: Höre auf, Code zu lesen. Werde Token-Milliardär.
Sein Argument: In einer agentischen Welt ist Code-Volumen die entscheidende Metrik. Dein Agent sollte täglich tausende Zeilen generieren. Deine Aufgabe ist es, die Output-Spezifikation zu definieren und den Agenten den Durchsatz maximieren zu lassen. Jede Zeile zu lesen und zu verstehen, ist ein Engpass. Vertraue den Tests. Vertraue dem Agenten. Bewege dich schnell.
Am Mittwoch gab Mario Zechner von Anthropic die Gegen-Keynote: Werde langsamer und lies den verdammten Code.
Sein Argument: Geschwindigkeit ist eine Falle. Jede Codezeile, die dein Agent schreibt, ist eine Verbindlichkeit. Du musst sie verstehen, darüber nachdenken und in der Lage sein, sie zu warten. Die Teams, die in fünf Jahren gewinnen, sind diejenigen, die Klarheit und Absicht über Geschwindigkeit stellen. Agenten sollten Werkzeuge zum Denken sein, nicht zum gedankenlosen Generieren von Code.
Das Spektrum
Der Summit teilte sich grob in drei Lager:
| Position | Vertreter | Ansatz | Risiko |
|---|---|---|---|
| Token-Maximalist | OpenAI, einige Scale-up-Ingenieure | Agenten aggressiv generieren lassen; Fokus auf Output-Qualität durch Tests | Unwartbare Codebasen, Sicherheits-Schulden, technische Zerbrechlichkeit |
| Absichtliche Mitte | Die meisten Enterprise-Ingenieure | Agenten für Gerüste nutzen; Menschen liefern Architektur und Geschmack | Langsamere Geschwindigkeit, aber stabilere Systeme |
| Code-First | Anthropic, einige Forschungsingenieure | Agenten erweitern menschliches Denken; Menschen schreiben den meisten Code | Geringerer Durchsatz, aber höchste Codequalität |
Keine Seite liegt falsch. Die Uneinigkeit dreht sich darum, wie Scheitern aussieht. Lopopolo optimiert für Iterationsgeschwindigkeit. Zechner für Nachhaltigkeit. 2026 lernen Teams, dass man nicht für beides optimieren kann.
Das Interview-Problem
Eine konkrete Folge: Einstellungen sind kaputt. Wenn du Token-Maximalist bist, interessiert es dich nicht, ob ein Kandidat programmieren kann – dich interessiert, ob er effektiv prompten und Agenten-Output bewerten kann. Wenn du Code-First bist, willst du tiefes technisches Denken sehen.
Also weiß, wenn ein Kandidat zu einem Interview kommt, weder Interviewer noch Kandidat, gegen welches Framework sie bewertet werden. Ein Summit-Teilnehmer beschrieb es als „Interviews im Nebel".
Bereit, Ihr Geschäft zu erweitern?
Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.
Warum sterben IDEs, während GitHub-Traffic explodiert?
GitHub meldete einen 15-fachen Anstieg des Traffics im Jahresvergleich. Cloudflare meldete ähnliche Spitzen. Gleichzeitig sehen traditionelle IDEs – VS Code, JetBrains, Sublime – rückläufige Nutzung bei KI-nativen Teams.
Das scheint widersprüchlich, bis du verstehst, was tatsächlich passiert.
Die IDE war ein lokales Denkwerkzeug
Eine IDE wurde für einen einzelnen Entwickler entworfen, um lokal Code zu schreiben. Sie hatte Syntaxhervorhebung, Autovervollständigung, Debugging-Tools und einen Dateibaum. Es war eine eigenständige Umgebung.
Dieses Modell bricht zusammen, wenn dein „Entwickler" ein Agent ist. Ein Agent braucht keine Syntaxhervorhebung. Er braucht keinen Debugger. Er braucht:
- Zugriff auf mehrere Dateien gleichzeitig
- Die Fähigkeit, Code auszuführen und Ergebnisse zu sehen
- Integration mit Versionskontrolle
- Kollaborationsfunktionen (weil Agent und Mensch zusammenarbeiten)
All das lebt jetzt im Browser. GitHub Codespaces, VS Code Web und ähnliche Tools ersetzen lokale IDEs.
Was tatsächlich wächst
GitHubs Traffic-Anstieg sind nicht Entwickler, die Code im Browser schreiben. Es sind Entwickler, die agentengenerierten Code reviewen, kommentieren und mergen. Es ist die Kollaborationsschicht, die explodiert, nicht die Editierschicht.
Deshalb sieht auch Cloudflare Traffic-Spitzen – Entwickler nutzen Cloud-Infrastruktur, um Agenten auszuführen und Workflows zu orchestrieren. Das Modell „lokale IDE + lokale Entwicklungsumgebung" wird durch „Cloud-native Agenten-Orchestrierung + browserbasiertes Review" ersetzt.
L33T C0d3 ist tot
Eine Session hatte genau diesen Titel. Der Punkt: Die romantische Vorstellung des brillanten Ingenieurs, allein an seiner Tastatur, der eleganten Code schreibt – das ist vorbei. Code ist jetzt ein kollaborativer Output zwischen Mensch und Agent. Die Fähigkeiten, die zählen, sind:
- Prompt Engineering (wie man spezifiziert, was man will)
- Output-Bewertung (ist der Code des Agenten gut?)
- Architekturdenken (in welcher Struktur soll der Agent arbeiten?)
- Integration (wie passt agentengenerierter Code in bestehende Systeme?)
Eleganten Code zu schreiben ist keine primäre Fähigkeit mehr. Das ist etwas, was Agenten tun. Menschen tun alles andere.
Was passiert wirklich mit MCP – tot oder blühend?
Das war die verwirrendste Debatte auf dem Summit.
Auf der einen Seite sagten einzelne KI-Ingenieure und Agenten-Framework-Maintainer: „MCP ist tot. Wir brauchen es nicht. Unsere Agenten können APIs einfach direkt aufrufen."
Auf der anderen Seite sagten Enterprise-Architekten und Sicherheitsteams: „Die MCP-Adoption beschleunigt sich schneller, als wir Werkzeuge dafür bauen können."
Beide Aussagen sind wahr. Sie beschreiben unterschiedliche Populationen.
Warum KI-Ingenieure MCP für tot halten
Für einen Solo-Entwickler, der einen einfachen Agenten baut, fügt MCP Reibung hinzu. Du musst:
- MCP-Server für deine Tools definieren
- Protokoll-Overhead verwalten
- Authentifizierung und Autorisierung handhaben
- Server bereitstellen und warten
Es ist einfacher, dem Agenten einfach direkten API-Zugriff zu geben und ihn den Rest herausfinden zu lassen.
Warum Unternehmen MCP rasch übernehmen
Für eine Organisation, die Agenten in der Produktion betreibt, ist MCP plötzlich unverzichtbar. Hier ist warum:
Sicherheitsisolation. Du willst nicht, dass Agenten direkten Zugriff auf deine Datenbank, dein Zahlungssystem oder Kundendaten haben. MCP lässt dich eine kontrollierte Schnittstelle schaffen, die Agenten aufrufen können, ohne die zugrunde liegenden Systeme offenzulegen.
Auditierbarkeit. Jede Agentenaktion geht durch den MCP-Server, der sie protokolliert. Du hast eine vollständige Aufzeichnung dessen, was der Agent getan hat und warum.
Credential-Management. Statt API-Schlüssel in Agenten-Prompts oder Umgebungsvariablen einzubetten, verwalten MCP-Server Anmeldedaten sicher.
Rate-Limiting und Kontingentdurchsetzung. Du kannst steuern, wie viel einer Ressource ein Agent verbrauchen kann.
Laut CData Software evaluieren oder implementieren 80 % der Fortune-500-Unternehmen MCP zu Beginn von 2026, hauptsächlich aus diesen Gründen.
Die Auflösung
Der Summit-Konsens: MCP ist nicht tot. Es ist nur für die 80 % der KI-Entwicklung, die experimentell und solo ist, nicht relevant. Aber für die 20 %, die Produktion und Multi-Team ist, wird MCP zum Standard.
Deshalb verbreiten sich MCP-Apps. Anthropic, OpenAI und Drittanbieter bauen vorgefertigte MCP-Server für gängige Tools (Salesforce, Slack, Jira, Datenbanken). Unternehmen können diese übernehmen, ohne eigene Server zu bauen.
Abonnieren Sie unseren Newsletter
Erhalten Sie die neuesten Tipps, Trends und Angebote kostenlos.
Macht uns KI produktiver oder nur überarbeiteter?
Hier wurde der Summit düster.
KI sollte ein Kraftmultiplikator sein. Du würdest weniger Zeit mit Routineaufgaben und mehr Zeit mit strategischem Denken verbringen. Die Produktivität würde in die Höhe schießen.
Stattdessen schoss die Produktivität in die Höhe – und die Arbeitsbelastungserwartungen ebenso.
Jevons‘ Paradoxon in Echtzeit
Jevons‘ Paradoxon, ursprünglich auf Kohleverbrauch angewendet, besagt: Wenn eine Ressource effizienter wird, steigt der Gesamtverbrauch, weil die Ressource billiger und attraktiver wird.
In KI-Begriffen: Agenten haben Codegenerierung billiger und schneller gemacht, also erwarten Manager jetzt von jedem Ingenieur:
- 10x mehr Output liefern
- Umfassende Dokumentation schreiben
- Vollständige Testsuiten bauen
- Internationalisierung (i18n) unterstützen
- Edge Cases behandeln
- All das allein machen
Die Produktivitätsgewinne wurden von überzogenen Erwartungen aufgezehrt.
Was Ingenieure sagten
Ein Ingenieur eines Londoner Startups: „Ich schrieb früher 500 Codezeilen pro Tag und fühlte mich produktiv. Jetzt schreibe ich 5.000 Zeilen pro Tag – generiert von Agenten – und bin erschöpft, weil ich alles reviewen, testen, dokumentieren und Stakeholdern erklären muss. Ich arbeite 60-Stunden-Wochen."
Ein anderer: „Mein Manager sagt: ‚Du hast jetzt einen Agenten, also solltest du doppelt so viele Projekte bewältigen können.‘ Ich bin nicht produktiver. Ich bin nur beschäftigter."
Ein Forscher: „Die Agenten sind gut darin, Code zu generieren. Sie sind nicht gut darin zu entscheiden, welcher Code generiert werden soll. Diese Entscheidungslast hat sich vollständig auf den Menschen verlagert. Wir automatisieren nicht den schwierigen Teil; wir automatisieren den einfachen Teil und lassen Menschen mehr nachdenken."
Der blinde Fleck der Produktivität
Die California Management Review der UC Berkeley veröffentlichte im Januar 2026 Forschung, die dieses Phänomen dokumentiert. Die zentrale Erkenntnis: KI-Einführung reduziert keine Arbeit; sie verändert die Natur der Arbeit.
Alte Arbeit: Code schreiben. Neue Arbeit: Agenten anleiten, Output bewerten, Qualität sichern, Scope Creep managen.
Die neue Arbeit ist kognitiv schwerer, auch wenn weniger getippt wird.
Warum ist Europa so zögerlich beim KI-Engineering?
Der Summit hatte ein starkes europäisches Kontingent, und ihre Botschaft war konsistent: Europa bewegt sich bei der Einführung von KI-Engineering nicht so schnell wie die USA.
Der regulatorische Überhang
Der EU AI Act wird noch umgesetzt. Unternehmen sind unsicher über die Haftung. Wenn ein KI-Agent eine Entscheidung trifft, die einem Kunden schadet, wer ist verantwortlich? Das Unternehmen? Der Modell-Anbieter? Der Ingenieur?
Diese Unsicherheit lähmt. Viele europäische Unternehmen warten, wie die ersten Klagen ausgehen, bevor sie ernsthafte agentische Systeme bauen.
Die Fähigkeitslücke
Traditionelle Softwareingenieure in Europa werden nicht im gleichen Tempo zu KI-Ingenieuren wie in den USA. Es gibt Skepsis, ob die Fähigkeiten übertragbar sind. Viele europäische Ingenieure warten, ob KI-Engineering ein echter Karrierepfad oder ein Hype-Zyklus ist.
Datenschutzbedenken
Europa ist auch vorsichtiger beim Umgang mit Daten. Agenten brauchen Zugriff auf Daten, um nützlich zu sein. Aber europäische Unternehmen sind zögerlich, Agenten Zugriff auf Kundendaten zu geben, selbst mit MCP-Schutzmaßnahmen.
Der Weg nach vorn
Die europäischen Ingenieure auf dem Summit waren nicht anti-KI. Sie waren pro-Vorsicht. Die Stimmung: „Die USA bewegen sich schnell und zerbrechen Dinge. Wir werden uns langsamer bewegen und versuchen, nicht so viel zu zerbrechen. In fünf Jahren werden wir sehen, wer recht hatte."
Wie verändern sich KI-Engineering-Rollen tatsächlich?
Am Ende des Summits zeichnete sich ein Muster ab: Traditionelle Software-Engineering-Rollen werden ausgehöhlt und durch drei neue Archetypen ersetzt.
Die drei Rollen
| Rolle | Verantwortung | Fähigkeiten |
|---|---|---|
| KI-PM | Agentenverhalten, Erfolgsmetriken, Einschränkungen definieren | Produktdenken, Prompt-Design, Evaluations-Frameworks |
| Agenten-Babysitter | Ausführung überwachen, Fehler abfangen, bei Bedarf eingreifen | Debugging, Observability, Fehlerbehandlung, Incident Response |
| Geschmacksgeber | Output-Qualität bewerten, Feedback geben, Verfeinerung leiten | Code-Review, Architekturdenken, ästhetisches Urteil |
Keine dieser Rollen beinhaltet das Schreiben von Code im traditionellen Sinne. Alle beinhalten das Leiten, Bewerten und Verfeinern von Agentenverhalten.
Was verschwindet
„Junior-Ingenieur"-Rollen werden komprimiert. Es gibt keinen klaren Weg mehr von „Ich kann einfachen Code schreiben" zu „Ich kann Systeme architekturieren". Die Zwischenschritte werden automatisiert.
Das schafft eine Fähigkeitsklippe: Entweder du bist gut im Prompten und Bewerten (dann bist du wertvoll), oder nicht (dann konkurrierst du mit Agenten).
Was wächst
Rollen, die Geschmack, Urteilsvermögen und architektonisches Denken erfordern, wachsen. Ebenso Rollen, die tiefe Domänenexpertise erfordern (weil Agenten Menschen brauchen, um zu bewerten, ob sie das richtige Problem lösen).
Der Summit hatte keinen Konsens, ob dies gut oder schlecht ist. Manche sahen es als Befreiung vom Routine-Coding. Andere sahen es als Bedrohung für den Beruf.
Was hat sich zwischen Dezember 2025 und Februar 2026 geändert?
Ein Abschnitt des Summits war einem bestimmten Wendepunkt gewidmet: Etwas verschob sich im KI-Agenten-Ökosystem um den Jahreswechsel.
Selbstverbessernde Software wurde real
OpenClaw und ähnliche Frameworks ermöglichten es Agenten, ihre eigenen Outputs iterativ ohne ständiges menschliches Prompten zu verbessern. Statt „Agent, schreibe eine Funktion, die X berechnet", wurde es zu „Agent, schreibe eine Funktion, die X berechnet, und verbessere sie weiter, bis sie alle Tests besteht und Edge Cases behandelt."
Die Kernerkenntnis, formuliert von mehreren Forschern: Höre auf, Agenten um triviale Ratschläge zu bitten.
Statt einen Agenten zu bitten, „diese Funktion zu verbessern", bitte ihn, „diese Funktion kugelsicher zu machen". Lass ihn entscheiden, was das bedeutet. Der Agent wird:
- Tests schreiben
- Edge Cases finden
- Für Klarheit refaktorieren
- Fehlerbehandlung hinzufügen
- Die Logik dokumentieren
All das, ohne für jeden Schritt gefragt zu werden.
Das veränderte das mentale Modell vom „Agenten als Werkzeug" zum „Agenten als autonomen Mitwirkenden". Und es veränderte die Arbeitsbelastungsdynamik: Statt dass Agenten menschliche Arbeit reduzieren, erhöhten sie sie (weil Menschen nun viel anspruchsvolleren Agenten-Output bewerten mussten).
Die Widersprüche, mit denen wir leben
Der Summit endete ohne Auflösung, was sich ehrlich anfühlte. Hier sind die Widersprüche, die KI-Engineering im April 2026 definieren:
Widerspruch 1: Agenten sind mächtig genug, um gefährlich zu sein (FOMAT ist real), aber nicht mächtig genug, um unbeaufsichtigt vertraut zu werden.
Widerspruch 2: Geschwindigkeit und Qualität werden als Gegensätze behandelt, aber beide sind notwendig.
Widerspruch 3: MCP ist gleichzeitig tot (für Einzelpersonen) und blühend (für Unternehmen).
Widerspruch 4: KI machte uns produktiver, aber auch überarbeiteter.
Widerspruch 5: Alle bauen mit Agenten, aber niemand hat herausgefunden, wie man gut mit ihnen baut.
Widerspruch 6: KI-Engineering ist ein echter Karrierepfad, aber die Fähigkeiten, von denen wir dachten, sie würden zählen (Code schreiben), tun es nicht mehr.
Das sind keine Probleme, die gelöst werden müssen. Es sind Spannungen, die gemanagt werden müssen. Die Teams, die 2026 gewinnen, sind diejenigen, die diese Widersprüche anerkennen, statt so zu tun, als gäbe es sie nicht.
Häufig gestellte Fragen
Was wir mitnehmen
Der Londoner Summit war eine Momentaufnahme eines Berufs im Übergang. KI-Engineering ist real, aber nicht das, was wir dachten, dass es sein würde. Es ist chaotischer, widersprüchlicher und menschenabhängiger, als der Hype vermuten ließ.
Die besten Ingenieure auf dem Summit waren nicht die mit den ausgefeiltesten Agenten. Es waren die, die verstanden, dass Agenten ein Werkzeug zum Denken sind, kein Ersatz dafür. Es waren die, die Prozesse gebaut hatten, um Agentenverhalten zu managen, Output zu bewerten und Qualität zu erhalten. Es waren die, die akzeptiert hatten, dass Produktivitätsgewinne mit neuen Arten von Arbeit einhergehen, nicht mit weniger Arbeit.
Wenn du 2026 KI-Systeme baust, sind die Lektionen des Summits klar:
Orchestrierung zählt mehr als Agentenfähigkeit. Ein mittelmäßiger Agent mit guter Orchestrierung schlägt einen brillanten Agenten ohne Kontrollen.
Klarheit ist wertvoller als Geschwindigkeit. Schnell zu sein und Dinge zu zerbrechen funktioniert, bis es das nicht mehr tut. In der Skalierung funktioniert es nicht.
Unternehmensadoption ist real, aber individuelle Adoption ist noch experimentell. Wenn du Solo-Entwickler bist, kannst du schnell sein. Wenn du ein Team bist, brauchst du Leitplanken.
Die Fähigkeiten, die zählen, haben sich geändert. Prompt Engineering, Output-Bewertung und architektonisches Denken sind die neuen Kernkompetenzen.
Erwarte härter zu arbeiten, nicht leichter. KI ist ein Produktivitätsmultiplikator, aber die Gewinne werden von höheren Erwartungen aufgezehrt. Plane entsprechend.
Der Summit beantwortete nicht die Frage „Wie sieht KI-Engineering aus?" Er zeigte uns die Antwort: Es sieht aus wie wir, die versuchen, es in Echtzeit herauszufinden.
{{ cta-dark-panel heading=“Höre auf, Agenten manuell zu orchestrieren” description=“Mit dem Workflow-Builder von FlowHunt kannst du Agentenverhalten definieren, Leitplanken setzen und mehrstufige KI-Aufgaben automatisieren. Kein FOMAT mehr. Kein Raten mehr, was deine Agenten tun.” ctaPrimaryText=“FlowHunt kostenlos testen” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Demo buchen” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
