Agentic Engineering ohne Plattformteam
Was von Zalandos zweieinhalb Jahren bei fünfzehn Entwicklern übrig bleibt
Zalandos Maßnahmen lösen fast alle ein Koordinationsproblem. Ein Team von fünfzehn Leuten hat kein Koordinationsproblem. Es hat ein Prüfproblem.
Ein Konzern hat gemessen
Bartosz Ocytko, Executive Principal Engineer bei Zalando, hat am 14. August 2026 veröffentlicht, was zweieinhalb Jahre agentic engineering über 250 Engineering-Teams ergeben haben. Der Text steht im Zalando Engineering Blog.
Ungewöhnlich daran ist nicht, dass ein Konzern über KI schreibt. Ungewöhnlich ist, was darin vorkommt: ein zentraler LLM-Proxy, ein Tech Radar für Werkzeuge, ein Marktplatz für geteilte Anleitungen, eine interne Guild, Trainingsformate, dazu rechtliche Einstiegspunkte und ein Scanner, der ausgelieferte Container-Images auf Modellnutzung durchsucht.
Und dann kommt der Teil, den sonst niemand veröffentlicht: Sie zeigen auch, was schiefläuft. Pull Requests werden größer. Die Komplexität pro Commit steigt. Ocytkos Formulierung dafür lautet, dass KI die guten und die schlechten Praktiken gleichermaßen verstärkt.
Das ist eine ehrliche Bilanz, und sie ist die Arbeit, die man sonst selbst machen müsste.
Nur: Fast nichts davon lässt sich übernehmen.
Warum davon fast nichts übertragbar ist
Der naheliegende Grund wäre Geld. Der ist falsch.
Sehen Sie sich an, was diese Maßnahmen tatsächlich tun. Ein Proxy sorgt dafür, dass zweihundertfünfzig Teams nicht zweihundertfünfzig Zugänge verwalten. Ein Tech Radar sorgt dafür, dass Team A weiß, was Team B schon ausprobiert hat. Ein Marktplatz für Anleitungen sorgt dafür, dass eine Lösung aus dem Checkout-Team im Logistik-Team ankommt. Eine Guild sorgt dafür, dass Wissen die Abteilungsgrenze überspringt.
Jede dieser Maßnahmen ordnet die Arbeit zwischen Teams.
Bei fünfzehn Entwicklern gibt es kein Zwischen. Es gibt einen Raum, einen Kanal und eine Codebasis. Wer dort einen Marktplatz für Anleitungen aufbaut, löst ein Problem, das er nicht hat, und bindet dafür Zeit, die an anderer Stelle fehlt.
Das ist kein Argument gegen Zalando. Es ist eine Feststellung über die Bauform. Plattformen entstehen, wenn Koordination teurer wird als Technik. In einem kleinen Team ist Koordination fast umsonst.
Das andere Problem
Was in einem kleinen Team dafür teurer wird, ist die Prüfung.
Im Konzern verteilt sich ein Fehler über mehrere Stufen. Es gibt ein Review, einen Architekturkreis, ein Staging, eine Freigabe. Keine dieser Stufen ist perfekt, aber sie sind unabhängig voneinander, und Unabhängigkeit ist der ganze Trick. Ein Fehler muss durch alle durch.
In einem Team von fünfzehn Leuten prüfen sich oft dieselben zwei Personen gegenseitig, die den Code auch geschrieben haben. Wenn eine Maschine jetzt dreimal so viel Code erzeugt, fällt nicht mehr Arbeit an. Es fällt mehr ungeprüfte Arbeit an.
Genau darin liegt die Verschiebung, die der Zalando-Text indirekt belegt: Größere Pull Requests sind kein Tempoproblem. Sie sind ein Prüfproblem, das wie ein Tempoerfolg aussieht.
Dazu kommt eine Eigenart von maschinell erzeugtem Code, die ein Review nur schwer abfängt. Er ist selten offensichtlich falsch. Er ist plausibel. Variablen heißen richtig, die Struktur sieht aus wie das, was im Repository schon steht, und die Tests sind grün. Ein Mensch, der ein eigenes Missverständnis in Code gießt, hinterlässt meistens Spuren davon im Code. Eine Maschine, die eine Vorgabe falsch interpretiert, hinterlässt sauberen Code mit einer falschen Annahme darin.
Darauf ist ein Code-Review nicht ausgelegt. Es prüft, ob der Code taugt, nicht ob er das Richtige tut.
Was übrig bleibt
Fünf Dinge, die ohne Plattform funktionieren. Jedes mit ehrlicher Aufwandsangabe.
Kein vorgeschriebenes Werkzeug
Zalando hat bei zweihundertfünfzig Teams nie ein Werkzeug zentral vorgeschrieben. Sie führen ein Radar, das zeigt, was wo im Einsatz ist, und überlassen die Wahl den Teams.
Ein Team von fünfzehn Leuten, das sich auf ein Werkzeug festlegt, hat sich damit mehr Vorschrift auferlegt als ein Konzern mit zweihundertfünfzig. Das ist meistens nicht Absicht, sondern entsteht nebenbei, weil jemand etwas eingerichtet hat und es seitdem so läuft.
Aufwand: keiner. Es geht darum, etwas nicht zu tun.
Messen statt vermuten
Der stärkste Zug in Zalandos Bilanz ist keine Plattform. Es ist eine Auswertung. Sie haben nachgesehen, wie sich Komplexität pro Commit und Größe der Pull Requests über die Zeit verändert haben, und sie veröffentlichen das Ergebnis, auch wo es unangenehm ist.
Dafür braucht es kein Team. Es braucht ein Skript über die eigene Repository-Historie und eine halbe Stunde, um das Ergebnis anzusehen.
Wer nicht misst, merkt den Knick erst, wenn die Reviews stehen. Dann ist er ein halbes Jahr alt.
Aufwand: ein Nachmittag, einmalig.
Wogegen wird gebaut
Das ist der Kern, und es ist die einzige Maßnahme in dieser Liste, die im kleinen Team billiger ist als im Konzern.
Ein unbeschränkter Auftrag an ein System, das nicht weiß, was fachlich richtig ist, erzeugt schnell sehr viel. Eine Spezifikation macht daraus einen beschränkten Auftrag. Sie ist nicht Dokumentation für Menschen, sondern Vorgabe für die Maschine, und zugleich das Einzige, wogegen sich das Ergebnis prüfen lässt.
Im Konzern muss so etwas abgestimmt, eingeführt und durchgesetzt werden. In einem Team von fünfzehn Leuten reicht eine Entscheidung und die Disziplin, sie zu halten.
Die unbequeme Seite davon: Wenn fachliche Änderungen ausschließlich in der Spezifikation entstehen dürfen, gibt es kein schnelles Nachbessern im Code mit späterer Dokumentation. Es gibt kein Später.
Wie wichtig dieser Punkt ist, zeigt sich erst beim Prüfen. In einem Modernisierungsvorhaben, das ich derzeit begleite, haben die fachlichen Tests Fehler gefunden, die kein Code-Review gefunden hätte. In einem Fall war der erzeugte Code technisch einwandfrei und der Geschäftsprozess wäre trotzdem falsch gelaufen. Ein Schritt wäre ausgelöst worden, der zugehörige zweite nie. Aufgefallen wäre das erst Wochen später bei einem Abgleich.
Gefunden wurde das nicht, weil jemand besonders gründlich auf den Code geschaut hat. Gefunden wurde es, weil es eine Vorgabe gab, gegen die man das Verhalten stellen konnte.
Aufwand: eine Projektentscheidung, danach laufende Disziplin.
Wer prüft
Zalando prüft nicht alles gleich streng. Was wenig Risiko trägt, läuft automatisch durch, ohne dass jemand hinsieht.
In einem kleinen Team sind Prüfschichten keine Rollen und keine Systeme. Es sind Personen. Aber es müssen verschiedene Blickwinkel sein, und zwar mindestens drei: Stimmt der Code technisch, stimmt das fachliche Verhalten, und stimmt, was ein Anwender am Ende sieht.
Wenn dieselbe Person alle drei Blickwinkel einnimmt, existiert nur einer.
Aufwand: Tage je Prüfrunde. Das ist der teuerste Punkt dieser Liste, und der, an dem zuerst gespart wird.
Geteilte Anleitungen statt geteilter Plattform
Zalandos Marktplatz für Anleitungen hat im Kleinen eine triviale Entsprechung: ein Verzeichnis im Repository mit den fünf Abläufen, die im Haus immer wieder gebraucht werden.
Der Nutzen entsteht dabei nicht durch die Verteilung. Er entsteht durch das Aufschreiben. Wer einen wiederkehrenden Ablauf einmal so formuliert, dass eine Maschine ihn ausführen kann, hat ihn zum ersten Mal vollständig verstanden.
Aufwand: Stunden, verteilt über Wochen.
Was ohne Plattform gefährlicher ist
Bis hierhin könnte man den Eindruck gewinnen, im kleinen Team sei alles einfacher. An einer Stelle ist das Gegenteil der Fall, und sie betrifft genau die Umgebungen, in denen ich arbeite.
Zalando hat für frühe Vorhaben Einstiegspunkte in eine rechtliche Bewertung je Anwendungsfall. Sie erkennen Modellnutzung automatisch, indem sie ausgelieferte Container-Images scannen, tragen das System im Entwicklerportal ein und fordern die Verantwortlichen zur Dokumentation auf.
Ein Mittelständler hat weder Portal noch Scanner noch Rechtsabteilung. Was dort an Modellen zum Einsatz kommt, entscheidet in der Praxis die Person, die ein Werkzeug gerade ausprobiert hat. Niemand weiß zentral, welches Modell welche Daten gesehen hat.
In einem Produkt mit Zulassung, CE-Kennzeichnung oder Rechtsfolge ist das das eigentliche Risiko, nicht die Codequalität. Codequalität fällt im Test auf. Eine undokumentierte Modellnutzung fällt im Audit auf, und dann ist das Produkt schon im Markt.
Was ich nicht behaupte
Der Text setzt auf fremder Arbeit auf. Deshalb gehört dazu, was er nicht hergibt.
Ich habe keine zweihundertfünfzig Teams begleitet. Was hier steht, stammt aus einem laufenden Mandat und aus dem Lesen einer fremden Auswertung.
Die Zahlen in diesem Text sind Zalandos Zahlen, nicht meine. Wo ich von Komplexität, Pull-Request-Größen oder Freigabequoten schreibe, gebe ich ihre Messung wieder.
Die fünf Punkte sind nicht gegeneinander getestet. Es gibt keine Kontrollgruppe und keinen Vergleich. Es ist das, was in einer kleinen Organisation getragen hat.
Zu Kosten und Geschwindigkeit sage ich hier nichts, weil ich dazu keine belastbaren Zahlen habe. Wer sie Ihnen nennt, hat sie meistens auch nicht.
Wogegen wird gebaut
Was im Konzern Plattform heißt, heißt im kleinen Team Disziplin.
Am Ende bleiben zwei Fragen, und beide lassen sich ohne Budget beantworten: Wogegen wird gebaut, und wer prüft das Ergebnis.
Wenn Ihr Team darauf keine Antwort hat, ist das kein Werkzeugproblem. Dann liefert eine KI schneller etwas ab, von dem niemand sagen kann, ob es stimmt.
Falls bei Ihnen eine KI Code schreibt und niemand sagen kann, wo die fachlichen Entscheidungen festgehalten sind: Lassen Sie uns sprechen.
Transparenz: Dieser Text ist mit KI-Unterstützung auf Grammatik und Dramaturgie überarbeitet. Inhalt, Zahlen und Entscheidungen sind meine.