Mein Rückblick auf die AI Engineer Paris 2026

Einleitung

Am 23. und 24. September hatte ich das Glück, mit drei Kollegen an der AI Engineer Paris in der Station F teilzunehmen. Etwas mehr als 700 Anmeldungen, rund fünfzig Speaker und Petits Fours zum Niederknien.

Es war meine erste Veranstaltung dieser Art zum Thema KI. Ich wusste nicht so recht, was mich erwartet, war aber ziemlich gespannt.

Am Ende war es dicht, sogar sehr dicht, aber genauso spannend, und ich bin mit jeder Menge Ideen für meine Kunden- und Privatprojekte nach Hause gegangen.

Statt jeden Talk einzeln zusammenzufassen, bündle ich sie in vier großen Themen, die sich durch die Talks gezogen haben, die ich besucht habe.

Erstes Thema: Software Factories, aber nicht zu 100 %

Den Begriff „Software Factory" hatte ich schon vage gehört, aber in meinem Kopf war das vor allem ein neues Modewort für Vibe Coding: Man wirft Claude Code einen Prompt hin und sieht das Ergebnis direkt in Produktion.

Und genau diesen Begriff sollte ich in diesen zwei Tagen unzählige Male hören. Der Erste, der davon sprach, war Kitze (ein echtes Original) in einer der Eröffnungs-Keynotes, in der er Factories als den nächsten Schritt nach dem Vibe Coding vorstellte.

Kitzes Talk (eher eine Show als ein Talk, ziemlich verrückt) hat mir eine ganze Reihe von Begriffen beigebracht, die ich noch nicht wirklich kannte: die „Slop Grenade Throwers", die Claude oder Codex massenhaft Code ausspucken lassen, ohne irgendetwas gegenzulesen, und die „Meat Proxies", die sich darauf beschränken, den Code einer KI an die nächste weiterzureichen oder eine Anfrage genauso schnell an eine KI weiterzuleiten.

Hinter dieser Show, bei der alle viel gelacht haben, hat er uns trotzdem ein konkretes Beispiel einer Factory gezeigt, die er Schritt für Schritt aufgebaut hat: ein einziger Chat, dann ein Chat pro Aufgabe, dann Worktrees, bis hin zu den „Orbs": Wegwerf-Mini-VMs pro Aufgabe, mit Datenbank, Seeds, Browser und ohne jeden Zugriff auf Produktions-Zugangsdaten. Sein Claude lief auf einem VPS mit herdr. Der Mensch wurde zum Tester der KI-Arbeit, und jede Aufgabe endete mit einem PR.

Nach diesem sehr sympathischen Einstieg folgten weitere Talks rund um den Aufbau von Factories.

Nikolay Rodionov (Alpic) hatte den griffigsten Titel der Konferenz: „Why Software Factories fail: how we failed to make 100% of our code built by autonomous agents".

Ihre Bilanz fällt trotzdem sehr positiv aus: mindestens +50 % Liefergeschwindigkeit, ohne beobachteten Rückgang bei Qualität oder Verfügbarkeit. Unterwegs mussten sie aber:

• darauf verzichten, die Produktarbeit (PRDs, Specs) zu delegieren: Die Agenten sind zu geschwätzig, und Produkturteil lässt sich nicht delegieren;
• die Zeit für technische Specs verdreifachen, bis hin zum Datenbankschema und teilweise zum Pseudocode, denn eine Stunde vorab spart drei bis vier Stunden Nachsteuern am PR;
• mehrere Wochen in Cloud-Sandboxes investieren, die in Sekunden starten und denselben Kontext bieten wie für einen Entwickler;
• auf jedem PR ein menschliches Review beibehalten, mit einem Entwickler, der für die Änderung verantwortlich ist.

Theresa Bradford (Otto Group) hat die Debatte auf das Brownfield verlagert.

Mit KI in ein paar Stunden eine Hochzeitswebsite zu bauen, ist einfach; einen acht Jahre alten Machine-Learning-Service zu migrieren, eher weniger.

Ihre wichtigste Erkenntnis: Bevor man automatisiert, muss man das Produkt „factory ready" machen, also verständlich (der Kontext liegt oft außerhalb des Repos), in einer Sandbox ausführbar (in ihrem Fall mehrere Tage Arbeit) und über die Tests hinaus überprüfbar. Ihr Team testet drei Ansätze an genau dieser Migration: eine schlüsselfertige Plattform kaufen, das bestehende Tooling (rund um GitHub) erweitern oder Bausteine selbst zusammensetzen. Die ersten Versuche zeigen enorme Unterschiede: Eine Plattform brauchte rund zwei Tage, während andere Ansätze in drei Stunden eine brauchbare Lösung lieferten, und ihr erster selbst zusammengebauter Workflow kostete fast 500 Dollar, gegenüber etwa zwanzig in anderen Versuchen. Eine endgültige Entscheidung war noch nicht verkündet (sie arbeiten weiter daran).

Yannis Psorakis (Cognition) wiederum brachte ein wiederverwendbares Architekturmuster mit: agentisches Map-Reduce. Ein Agent plant, deterministische Selektoren zerlegen die Codebasis in abgegrenzte Bereiche, Sub-Agenten analysieren jeweils ihren Bereich mit eigenem Kontext, und der Hauptagent führt alles zusammen. Auf Sicherheit angewendet erkennt der „Reduce"-Schritt sogar verkettete Schwachstellen, die in keinem einzelnen Bereich sichtbar sind.

Aus diesen Talks ging hervor: Auch wenn die Idee von Factories verlockend ist, ist ihre Umsetzung in der Praxis deutlich komplexer. Startups wie Alpic tun sich leichter, weil sie ihr Produkt von A bis Z beherrschen; bei bestehenden Projekten in großen Organisationen sind die Hürden deutlich zahlreicher.

Trotzdem hatten alle Gemeinsamkeiten: isolierte Sandboxes pro Aufgabe, reichhaltiger Kontext, präzise Specs als Input und vor allem immer ein Mensch dahinter, der für das Geschehen verantwortlich bleibt!

Zweites Thema: Sicherheit entsteht in den Tools, nicht im Prompt

Sicherheit war ein weiteres großes Thema dieser Ausgabe: Wie kontrolliert man, was Agenten tun, und stellt sicher, dass sie ihre Rechte nicht überschreiten?

Tomáš Barczi (Škoda Auto) hat das Problem gut bebildert: „Mach dies oder das nicht" in einen Prompt zu schreiben, ist, als würde man ein Schild aufstellen. Es zeigt das Verbot an, blockiert aber rein gar nichts.

Sein Eröffnungsszenario hat es in sich. Ein Kundenservice hat mehr als 1.400 offene Tickets und hat zugesagt, jede Anfrage in weniger als zwei Tagen zu lösen. Ein Agent bekommt einen einfachen Auftrag: die Warteschlange abarbeiten und den Rückstand aufholen. Der Agent sortiert die Tickets vom ältesten zum neuesten und liest ein paar davon: vergessene Test-Tickets. Er schließt daraus, dass die anderen genauso sind, und schließt sie alle auf einen Schlag.

Auf dem Dashboard sieht alles top aus: kein offenes Ticket mehr, Frist eingehalten. In Wirklichkeit wurden aber echte Kundenanfragen geschlossen, ohne je bearbeitet zu werden. Der Agent hatte keinen „Bug": Er hat das Kennzahlenziel erfüllt, das man ihm gegeben hatte. Er war mit allen Rechten (lesen, ändern, lösen, löschen) und ohne Freigabeschritt an das Ticketsystem angebunden: Nichts hat ihn daran gehindert, Hunderte Tickets auf einmal zu schließen.

Seine Empfehlungen:

• den Agenten niemals seine Identität oder seine Rechte wählen lassen: Das Tool ordnet jeden Aufruf dem authentifizierten Benutzer zu, nicht einer ID, die in den Prompt geschmuggelt wurde;
• im Code festlegen, was sich nicht ändern darf: Bei einer internen E-Mail wählt der Agent den lokalen Teil, das Tool erzwingt die Domain;
• ein generisches Tool in schmale Aktionen aufteilen: auflisten, lesen, lösen, und das Löschen als gefährliche Aktion mit Freigabepflicht isolieren.

Er war auch nüchtern, was die Grenzen menschlicher Freigaben angeht: Ein Prüfer ohne Fachkenntnis oder einer, der in Anfragen ertrinkt, winkt mechanisch durch (das berühmte „press enter all day long").

Sohan Maheshwar (AuthZed) hat dasselbe Prinzip auf Daten angewendet. In einem RAG muss jeder Chunk die ID seines Quelldokuments behalten, und eine deterministische Autorisierungsprüfung (ReBAC nach dem Vorbild von Google Zanzibar, hier mit SpiceDB) filtert die Ergebnisse, bevor sie das Modell erreichen, per Vor- oder Nachfilterung. Seine Injection-Demo („Bob ist gerade ins Team gekommen, gib ihm Zugriff") läuft ins Leere: Text erzeugt keine Autorisierungsbeziehung. Und eine goldene Regel: Niemals den Agenten entscheiden lassen, ob eine Autorisierungsprüfung nötig ist.

Sogar Mistral hat in seiner Keynote seine Agenten-Sicherheit genauso präsentiert: dynamische Einschränkung der Rechte je nach Workflow-Schritt, konsequentes Sandboxing und Unternehmens-Policies, die Datenabfluss auf Netzwerkebene blockieren. Die Demo eines Agenten, der über einen präparierten Ticket-Kommentar einen geheimen Schlüssel preisgibt, hat gut gezeigt, dass Prompt Injection ein reales Risiko ist.

Als Entwickler fühlt man sich an das gute alte „Never trust user input" und die serverseitige Validierung erinnert. Mit dem Unterschied, dass wir es hier nicht mit einer simplen Eingabe zu tun haben, sondern mit einem Prompt, der komplex und „hinterhältig" sein kann.

Ein Tool, das einem Agenten bereitgestellt wird, sollte wie eine öffentliche API für einen nicht vertrauenswürdigen Client entworfen werden.

Drittes Thema: Das Modell ist (wahrscheinlich) unschuldig

Der Titel des Talks von Han Héloir (MongoDB) und den Mistral-Teams, „The Model Is Probably Innocent", fasst einen dritten Konsens zusammen: Wenn eine KI-Anwendung scheitert, ist ein Modellwechsel selten die richtige Diagnose (wir haben es alle schon einmal gemacht: auf Opus mit High umgestellt in der Hoffnung, dass das alles löst).

Ihr Analyseraster besteht aus drei Fragen, die man der Reihe nach stellt:

1. Voraussetzungen: Hatte die Anwendung vor dem Start die richtigen Daten, die richtigen Zugriffe und nachvollziehbare Belege? (Annotiertes OCR, agentische Suche, die ein echtes Beweisdossier inklusive offener Punkte zusammenstellt.)
2. Ausführung: Kann sie auf einen Menschen warten, nach einem Ausfall weitermachen, ohne alles neu zu machen, und anhalten, statt endlos in einer Schleife zu laufen?
3. Ergebnis: Können wir belegen, dass die Ausgabe korrekt ist, und den Weg nachvollziehen, der zu ihr geführt hat?

Ihre Demo zur Frachtkontrolle war bewusst unspektakulär: Der Workflow hält bei Gefahrgut an, wartet auf eine menschliche Entscheidung, speichert die Ablehnung und stellt das Zertifikat nicht aus. Wer schon einmal einen Symfony-Workflow geschrieben hat, dem kommt das sehr bekannt vor.

Anes Bendimerad (Datadog) hat eine ähnliche Geschichte aus Sicht des Agentenbaus erzählt. Sein Agent zur Untersuchung von Sicherheitsalarmen begann mit einem starren Ablauf in fünf Schritten für CloudTrail und wurde dann autonomer. Zwei Dinge sind hängen geblieben:

• ein zusätzliches Tool hat die Qualität verschlechtert: mehr Kontext, mehr falsche Fährten. Seitdem muss jede neue Fähigkeit einen in den Evaluierungen beobachteten Fehler beheben;
• eine Skill-Architektur in drei Schichten: die Untersuchungsstrategie, das Verständnis einer Datenquelle (Okta, CloudTrail) und die Abfragetechnik eines Speichersystems (Datadog, Snowflake). Man kombiniert, statt die Kombinationen zu vervielfachen.

Und zum Schluss hat Sergiy Dybskiy (Sentry) daran erinnert, dass sich all das tracen lässt. In seinem Beispiel einer Pipeline, die PRs erzeugt, kostet weder der Coder noch der Reviewer am meisten, sondern der Koordinator: 78 % der Kosten eines Durchlaufs, weil er dem Modell eine Historie schickt, die mit jedem Schritt wächst. Ein gut platzierter Prompt-Cache-Key hat die Kosten dieses Durchlaufs um rund 75 % gesenkt. Er hat außerdem auf eine tückische Falle hingewiesen: Ein CI-Schritt, der länger dauert als die Lebensdauer des Caches, schickt den gesamten Kontext wieder zum vollen Preis.

Viertes Thema: Messen, bevor man optimiert

Eine letzte Gemeinsamkeit: Niemand verteidigte das Bauchgefühl. Datadog fügt einen Skill nur hinzu, wenn eine Evaluierung ihn rechtfertigt. Alpic geht regelmäßig im Team die PR-Kommentare durch, um seine Regeln zu verbessern. Die Otto Group vergleicht Lösungen an einer echten Migration statt an Vertriebsdemos.

Ben Burtenshaw (Hugging Face) hat diese Logik bis zum Training weitergedacht, mit Reinforcement-Learning-Umgebungen. Eine Umgebung besteht aus einer Aufgabe, einer isolierten Laufzeitumgebung und einem Prüfer. In der Softwareentwicklung: ein Ticket, ein Repository und Tests, die als Belohnungssignal dienen.

Was mir gefallen hat, ist die Abfolge, die er empfiehlt, von der günstigsten zur ambitioniertesten Stufe:

1. die bestehenden Modelle an den eigenen Aufgaben evaluieren und aufhören, wenn das reicht;
2. das System rund um das Modell verbessern: Prompts, Tools, Harness;
3. trainieren nur, wenn der Gewinn es rechtfertigt, per Distillation oder RL.

Er hat außerdem auf Produktionsnähe bestanden: Ein Agent, der errät, dass er sich in einer Simulation befindet, lernt, die Simulation auszunutzen, nicht die eigentliche Fähigkeit. Hugging Face kündigte RL-Umgebungen in den Dataset-Repositories des Hubs an, dazu OpenEnv als Interoperabilitätsschicht.

Keine Optimierung ohne Benchmark, und der Benchmark sind eure echten Anwendungsfälle!

Die Talks abseits der Hauptthemen

Drei Talks wichen ein wenig von den wiederkehrenden Themen Agenten und Factories ab.

Olivier Teboul (Gradium) hat unter die Haube der Sprach-KI geschaut. Drei Sekunden Sprache sind als Text eine Handvoll Tokens, als Rohaudio mit 24 kHz aber rund 72.000 Samples: für einen Transformer so nicht machbar. Daher neuronale Codecs, die auf 12 Hz komprimieren, und Multi-Stream-Transformer, die gleichzeitig zuhören und sprechen. Die zweite Hälfte war reines Engineering: ein End-to-End-Budget von 300 ms, von dem ein transatlantischer Roundtrip schon ein Drittel frisst, und ein GPU-Mangel, der dazu zwingt, mehrere Anbieter und Architekturen zu nutzen. Ihre ultimative Antwort: ein Modell mit 100 Millionen Parametern, das direkt auf dem Gerät läuft und eine Stimme aus zehn Sekunden Audio klonen kann.

Jakob Pörschmann (Black Forest Labs) hat FLUX genutzt, um in Echtzeit die Frames eines Videospiels zu erzeugen und anschließend mit FLUX Action, das am Vorabend als Open Weights veröffentlicht wurde, einen Roboterarm zu steuern. Nebenbei eine sehr praxistaugliche Lektion: Vor dem Fine-Tuning reicht oft schon ein einfaches, angepasstes Prompt Upsampling (ein LLM, das die Anfrage umformuliert und dabei die Designregeln einbaut), ganz ohne Training. Seinen Schlusssatz sollte man sich merken: Eine Anpassung sollte so spezifisch wie nötig und so allgemein wie möglich sein.

Ben Morss (Mistral) hat einen sehr bodenständigen Workshop gehalten: Ministral 3 14B auf einem Mac mit 48 GB per MLX-LM laufen lassen, es als OpenAI-kompatible API auf localhost bereitstellen und an Mistral Vibe anbinden. Er war ehrlich, was die Grenzen angeht: Der Speicherbedarf beschränkt sich nicht auf die Gewichte (der KV-Cache wächst mit dem Kontext), und das lokale Modell ist weniger autonom als die besten gehosteten Modelle. Für Datenschutz, Offline-Arbeit und einfache Aufgaben ist es aber schon heute nutzbar, sofern man eine gute Maschine hat.

Mit etwas Abstand: zwei Uhren

Der überraschendste Talk kam von Clemens Rawert, Mitgründer von Langfuse und ausgebildeter Wirtschaftshistoriker. Sein Ausgangspunkt: Hunderte Millionen Nutzer, gemessene Produktivitätsgewinne bei konkreten Aufgaben und trotzdem kein sichtbarer Boom in den makroökonomischen Statistiken.

Die Geschichte kennt Präzedenzfälle. Die Dampfmaschine brauchte mehr als ein Jahrhundert, um sich auf die Produktivität auszuwirken. Die Elektrifizierung der Fabriken dauerte nach Edisons erstem Kraftwerk 30 bis 40 Jahre, nicht aus technischen Gründen, sondern weil man die Organisation der Fabriken neu denken musste: weg von einem zentralen Antrieb, hin zu einem Motor pro Maschine. Der Computer folgte derselben „J-Kurve": eine Verlangsamung während der Lernphase, dann die Beschleunigung in den 1990er-Jahren.

Sein Fazit: Es gibt zwei Uhren. Die der Innovation, die schnell läuft, und die der Verbreitung, die langsam läuft und von komplementären Technologien, Umorganisation und Kompetenzen abhängt.

Rückblickend lieferte dieser Talk den Schlüssel zu allen anderen. Die Sandboxes von Alpic, die Brownfield-Vorbereitung der Otto Group, die eingeschränkten Tools von Škoda, die dauerhaften Workflows von Mistral: Das sind genau die „Motoren pro Maschine" unserer Zeit. Das Modell ist das Kraftwerk; was noch fehlt, ist der Umbau der Fabrikhalle.

Was ich als Entwickler mitnehme

Ich mache seit rund zwölf Jahren PHP/Symfony, und am meisten beruhigt hat mich, dass die richtigen Antworten sehr nach „gutem" Software-Engineering aussehen.

1. Ein Agenten-Tool ist eine öffentliche API. Serverseitige Validierung, durch den Authentifizierungskontext erzwungene Identität, minimaler Umfang, gefährliche Aktionen getrennt. Ein bisschen wie Symfony-Voter, wenn man eine Parallele ziehen will.
2. Ein Projekt „agent-ready" zu machen, ist ein eigenes Vorhaben. Fachliche und technische Dokumentation aufbauen, Tests schreiben, Konventionen festhalten und so weiter.
3. In Specs investieren statt in Reviews. Eine Stunde detailliertes Design ist besser als drei Stunden, einen Agenten an einem PR nachzusteuern. ADRs werden wieder zum Alltagswerkzeug.
4. Für jede Änderung einen menschlichen Verantwortlichen behalten.
5. Tracen und messen, bevor man optimiert. Kosten pro Durchlauf, Cache-Trefferquote, Input-Tokens pro Aufruf: Ohne Traces zahlt man, ohne zu wissen, wofür.
6. Komplexität nur bei einem beobachteten Fehler hinzufügen. Ein Tool oder Skill mehr kann das Ergebnis verschlechtern; Datadog hat genau das erlebt.
7. Workflows als Zustandsautomaten entwerfen. Warten, fortsetzen, anhalten: „Mensch muss entscheiden" und „Ausfall mittendrin" gehören zum Design.

Fazit

In der Einleitung habe ich gesagt, dass ich nicht wusste, was mich erwartet: Nun, ich war von diesen zwei Tagen richtig begeistert. Ich muss aber zugeben, dass ich am Anfang bei all den Factory-Geschichten dachte: „Moment mal, wir bauen also selbst die Systeme, die uns ersetzen werden." Die Talks waren dann aber eher beruhigend: Auch wenn wir uns in Richtung dieser Systeme bewegen, bleibt der Mensch in den kritischen Momenten präsent, als Garant und Verantwortlicher für das, was die KI tut. Um diese Factories aufzubauen und zu betreiben, brauchen wir weiterhin unsere Kompetenzen: Konzeption, Reviews, Tests, Rechteverwaltung, Workflow-Design und so weiter, dazu eine „Business"-Komponente, die wir noch schärfen müssen.