Forward Deployed Engineer und Payload v4 Beta - Folge 13 zzs

Begrüßung: zum ersten Mal an einem Tisch

Folge 13 ist die erste, die Jens und Christoph am selben Tisch aufnehmen. Sie haben sich in den Niederlanden getroffen, erst zum zweiten Mal überhaupt persönlich, und die Gelegenheit für die Aufnahme genutzt. Das Setup ist minimalistisch: zwei MacBooks auf einem Tisch, um das Echo kümmert sich Riverside.

Die Hauptthemen: Christoph stellt die Rolle des Forward Deployed Engineers vor, Jens zeigt die erste öffentliche Beta von Payload v4. Vorher gibt es wie immer Snacks.

Christophs Snacks: Multica und KI-Wasserzeichen

Snack eins: Multica, ein Tipp von Simon. Auf den ersten Blick ein Kanban-Board wie Trello, nur dass man Tickets an Agents assignt, die sie dann abarbeiten. Skills, die man anlegt, kann das ganze Team nutzen. Christoph hatte genau diese Vision schon vor anderthalb Jahren und sich selbst so ein Board gebaut, allerdings ohne Skills. Er setzt Multica gerade auf und berichtet, sobald er echte Erfahrungen gesammelt hat.

Aufgefallen ist ihm dabei: Multica ist source-available, nicht Open Source. Für die eigene Nutzung ist es komplett frei, aber anders als bei vielen Open-Source-Projekten darf man daraus nicht einfach einen Hosted Service bauen und weiterverkaufen.

Snack zwei: Wie erkennt man KI-Texte? Wegen des EU AI Acts müssen OpenAI und Anthropic generierte Texte kennzeichnen und setzen dafür auf Wasserzeichen. Bei einem Bild kann man sich das vorstellen, bei Text weniger. Christophs Vergleich ist ein gezinkter Würfel: Bei zwölf Würfen mit einem normalen Würfel kommt die Sechs vielleicht zweimal, mit einem gezinkten fünfmal. Übertragen auf Text heißt das: An einer Stelle im Satz kämen sechs Wörter in Frage, und das Modell wählt auffällig oft dasselbe.

Daraus folgt einiges. Ein einzelner Wurf verrät nichts, erst die Menge. Kurze Texte lassen sich deshalb kaum zuordnen, lange gut. Wer einen Text durch andere Modelle schickt und Wörter austauschen lässt, würfelt neu, früher hieß das Text-Spinning. Prüfen können nur die Anbieter selbst, den Schlüssel bekommt man auf Antrag. Und ein Treffer heißt: KI war beteiligt, nicht, dass KI den Text komplett geschrieben hat. Absatz für Absatz lässt sich so abschätzen, wie viel davon von der KI stammt.

Jens' Snacks: Haiku 5.5, oxfmt kann Astro und Matt Pococks neue Skills

Snack eins: Nach Opus 5.5 in der letzten Folge hat Anthropic jetzt auch das kleine Modell aktualisiert, Claude Haiku 5.5. Es überzeugt vor allem über den Preis, besonders bei Prompts bis 100.000 Tokens. Für Coding-Aufgaben mit großem Kontext ist es nichts, aber für Klassifizierung oder ein KI-Feature im eigenen Produkt passt es gut. Anthropic zeigt außerdem Demos, in denen Opus mit Haiku als Subagents arbeitet, statt eine Aufgabe allein zu lösen.

Snack zwei: oxlint und oxfmt, die schnellen Alternativen zu ESLint und Prettier aus dem oxc-Projekt. Sentry hat seinen Formatierungsjob von 45 auf 6 Sekunden gedrückt, Mercedes-Benz die Lint-Zeit um 71 Prozent. Wenn mehr Pull Requests entstehen und mehr Code geschrieben wird, ist das bares Geld. Der eigentliche Anlass: Bisher fehlte Support für Astro, jetzt ist der Pull Request gemergt und kommt im nächsten Release.

Snack drei: Matt Pocock, dessen Agent Skills schon öfter Thema waren, hat drei neue Skills veröffentlicht. Seine Skills haben rund 287.000 Sterne auf GitHub, Jens nutzt vor allem den Grill-me-Skill. Für ihn besonders relevant ist der neue PR-Skill: Viele seiner Pull Requests erstellen Agents samt Beschreibung, und der Skill sorgt dafür, dass diese Beschreibung ein gutes Review möglich macht.

Christophs Tipp dazu: Claude Code im Projekt ein Skill-Repository anschauen lassen, fragen, welche Skills hier Sinn ergeben, und die dann übernehmen.

Forward Deployed Engineer: Prozesse neu bauen statt KI draufsetzen

Christophs Hauptthema ist eine Rolle, die es seiner Meinung nach bald auch in deutschen Unternehmen geben wird: der Forward Deployed Engineer, kurz FDE. Inspiration war ein langes Interview von Greg Isenberg im Startup Ideas Podcast mit Vas, dem Gründer von Varick Agents. Die Agency ist auf Enterprise-Kunden spezialisiert und tritt auf wie eine klassische Unternehmensberatung. Dort fällt auch das Schlagwort vom Eine-Million-Dollar-Job, US-Sprech, wie Christoph selbst sagt. Was in den USA schon Thema ist, kommt in Deutschland meist etwas später.

Die Rolle stammt von Palantir, Christoph betont, dass er kein Fan ist. Ein FDE ist ein Mix aus Prozessberater, Software Engineer, AI Engineer und Business Consultant, ausdrücklich kein Prompt Engineer. Die Kernthese: nicht schlechte Prozesse mit KI schneller machen, sondern den Prozess erst verstehen, zerlegen, Schritte streichen, neu bauen und dann automatisieren. Sonst streicht man ein vergammeltes Haus nur neu an.

Das eigentliche Problem zeigt sich, sobald man in die echten Daten schaut. Im Beispiel, einem börsennotierten Softwarekonzern mit rund fünf Milliarden Umsatz und über 150 Produkten, hat der Sales-Prozess auf der Folie fünf Schritte: Angebot, Freigabe, Deal Desk, Kunde, Unterschrift. In den Daten sind es rund zwanzig, mit Schleifen, in denen Vorgänge immer wieder zurückspringen, etwa zu Legal.

Die Discovery hat drei Quellen. Erstens die Menschen, die „Human API“, wie Greg Isenberg es nennt: Interviews auf allen Ebenen, denn wer nur mit Managern spricht, bekommt nicht die Wahrheit. Zweitens das System of Record, also Salesforce, Pipedrive oder das ERP, mit den letzten 20 oder 30 echten Fällen. Drittens die Kommunikation drumherum in Slack, Teams und E-Mail.

Dann landet jeder Schritt in einem von vier Töpfen. Delete, wenn ihn niemand mehr begründen kann, etwa die zweite Freigabe. Code, wenn es eine klare Regel gibt, deterministisch wie ein If-Else. Agent, wenn Kontext und Urteil nötig sind, zum Beispiel welche Kostenstelle eine Rechnungsposition meint. Human, wenn es für Automatisierung zu riskant ist: 187.000 Euro zu überweisen gibt ein Mensch frei. Die beste Automatisierung ist oft, den Schritt zu streichen.

Bei den Agents unterscheidet Christoph zwei Arten. Sidekicks wie ChatGPT oder Claude im Chat machen uns schneller. Background Agents nehmen Arbeit wirklich vom Tisch. Seine Hoffnung: dass nachhaltige Unternehmen die frei werdende Kapazität für mehr Qualität nutzen, statt Leute zu entlassen.

Das Beispiel aus dem Podcast ist der Rechnungseingang: von 17 auf 7 Prozessschritte, von 24 auf 6 Tage Durchlaufzeit, von sechs Exception-Loops auf einen, und statt 18 laufen 87 Prozent der Rechnungen glatt durch. Die Kosten pro Rechnung fallen von 31 auf 6 Dollar. Der Effekt kommt aus dem Redesign, gestrichenen Schritten, Regeln als Code und Agents an den richtigen Stellen. Nur ein Teil davon ist AI.

Bei 250.000 Rechnungen im Jahr sind das 2,75 Millionen gespart. Daher kommen die großen Zahlen bei der Bezahlung, oft mit kleiner Base Fee und einem erfolgsabhängigen Anteil, wie Christoph es aus der Conversion-Optimierung kennt. Auch beim Modell gilt: nicht überall dasselbe nehmen, sondern pro Prozess Genauigkeit, Latenz und Kosten abwägen. Christoph hat dafür gerade OpenRouter für sich entdeckt.

Das Playbook hat neun Schritte: Discover, Map, Measure, Redesign, Build, Deploy, Evaluate, Impact und Replicate. Measure heißt, eine Baseline zu schaffen, damit man die Verbesserung später messen kann. Deploy heißt, in die bestehenden Systeme einzubauen, statt der Firma neue aufzuzwingen. Agents zu bauen ist erst Schritt fünf. KI ist dabei gar nicht der große Teil: Sie macht ein paar risikoarme Schritte automatisierbar und den Code schneller gebaut.

Für Deutschland kommt zu den vier Töpfen noch Governance dazu: EU AI Act, DSGVO und bei großen Unternehmen der Betriebsrat. Die Zahlen zeigen, wo der Mittelstand steht: ChatGPT ist angekommen, Prozessautomatisierung nicht. 20 Prozent der Mittelständler nutzen KI, bei mehr als 50 Beschäftigten 36 Prozent, aber nur 14 Prozent für Texterzeugung und 3 Prozent für Datenanalyse. Anfangen sollte man dort, wo es langweilig, teuer und häufig ist: Rechnungseingang, Monatsabschluss, Abstimmungen, Angebotserstellung, CRM-Pflege, Ticket-Klassifizierung, E-Mail ins ERP.

Zum Nachmachen: eine Woche, ein Workflow. Montag die eigenen Systeme auflisten, Dienstag 20 Dinge aufschreiben, die man letzte Woche getan hat, Mittwoch einen Prozess komplett dokumentieren, Donnerstag die Schritte sortieren, Freitag ein erster Kunde mit einem einzigen Workflow. Eine Firma direkt „AI-native“ zu machen, hält Christoph nicht für realistisch.

Jens erkennt viel aus seiner eigenen Arbeit wieder. Er überarbeitet gerade Prozesse bei einem Kunden und hat gesehen, wie ein wöchentlicher Ablauf komplett einem Sprachmodell überlassen werden sollte, obwohl er jede Woche nach festen Regeln gleich läuft. Sein Vorschlag: in Code gießen. Deterministisch heißt gleiche Eingabe, gleiche Ausgabe, und das ist reproduzierbarer, verlässlicher, günstiger und schneller. Christoph ergänzt, dass es oft jemanden von außen braucht, der nicht zu tief im Prozess steckt, und ein Unternehmen, das die Veränderung wirklich will.

Payload v4 Beta: weniger Lock-in, mehr Agents

Jens zeigt die erste öffentliche Beta von Payload v4. Vorher ein Schritt zurück: Payload ist ein Backend, das aus einer Config entsteht. Man beschreibt Collections und ihre Felder, ob Pages, Posts und Media für eine Website oder Leads für ein CRM, und Payload erzeugt daraus Admin Panel, Datenbank mit Migrations, APIs und einen MCP-Server, dazu Auth, Access Control und Uploads. Dieser Code-First-Ansatz passt gut zur Arbeit mit Agents. Payload ist Open Source, lässt sich selbst hosten, wo man will, und lief bisher immer in der eigenen Next.js-App. Jens nutzt es seit Jahren.

Neu im Admin Panel: ein Redesign, nachdem Payload von Figma übernommen wurde, dazu eine Grid View, Hierarchien und Tags, eine verbesserte Upload-Oberfläche und mehr Accessibility. Die Hierarchien betreffen Jens direkt, denn eines seiner Open-Source-Plugins für Payload sorgt bisher für Parent- und Child-Pages mit Breadcrumbs. Das ist jetzt im Core, für manche Use Cases wird er sein Plugin aber weiter brauchen.

In der Live-Demo zeigt Jens Christophs Artikel zu Local SEO und GEO 2026 im CMS dieser Website, einmal im neuen v4- und einmal im alten v3-Design. Minimalistischer, weniger Schatten, cleaner, aber für Jens gewöhnungsbedürftig und nicht unbedingt übersichtlicher. Daran wird noch gefeilt.

Das Überzeugende an v4 steckt im Core: weniger Lock-in, mehr Agents. Payload läuft jetzt auch mit TanStack Start statt nur mit Next.js. Der MCP-Server ist neu geschrieben und setzt auf generische Tools statt eines CRUD-Tools pro Collection, das skaliert bei vielen Collections deutlich besser. Genau dieses Muster hatte Jens in Folge 4 unter dem Stichwort Progressive Disclosure beschrieben und für seinen eigenen Payload-MCP umgesetzt. Außerdem ist die Bildbibliothek Sharp raus aus dem Core, und für den Umstieg gibt es Codemods.

Dazu wird Payload sicherer per Default: Versions und Authorship sind immer an. Gerade wenn Agents am Projekt mitarbeiten, sieht man so, wer wann was geändert hat, und kann zurückrollen, falls ein Agent etwas tut, was er nicht soll. Alle Änderungen stehen im Migration Guide.

Wofür Jens Payload empfiehlt: als Website-CMS, weil es Mehrsprachigkeit, Versioning, Drafts und Live Preview mitbringt, und als App-Backend für Web-Apps, theoretisch auch für Mobile-Apps. Datenmodell, Auth, Rechte und API bekommt man als Gerüst dazu und kann sich auf die Business-Logik konzentrieren. Christoph kannte Payload bisher nur als CMS und findet den Blick als Backend-Boilerplate spannend.

Outro

Nach gut 42 Minuten ist Schluss, die erste Folge am selben Tisch ist im Kasten. Beide freuen sich über Follows, Likes und Kommentare und über Themenwünsche, die bisher meist per DM kamen. Auf Social Media gibt es außerdem Beiträge zu den Snacks.