Deine Agenten liefern in Stunden. Deine Organisation entscheidet einmal im Quartal.

Agentische Systeme verkürzen den Weg von der Produktidee zur lauffähigen Variante auf Stunden. Der Zeitgewinn erreicht Deine Nutzer trotzdem nicht, solange Review, Freigabe und Portfolioplanung im alten Takt laufen. Plandek misst über mehr als 2.000 Engineering-Teams hinweg, dass Code Review zum sichtbarsten Engpass geworden ist. Die Entscheidung, die vor Dir liegt, ist deshalb keine Werkzeugentscheidung, sondern eine über Entscheidungswege: Wo im Unternehmen fällt künftig die Wahl zwischen fünf Feature-Varianten, und wie lange darf sie dauern?

Ein Senior-Entwickler beschäftigt acht Agenten, die parallel Varianten eines Features bauen und an Nutzerkohorten verproben. Das ist keine Zukunftsskizze, sondern die Arbeitsweise, die wir im Produktwerker-Podcast beschreiben. Rechne in diesem Bild einmal Deinen eigenen Freigabeweg mit: Das Ergebnis dieser acht Agenten geht in ein Refinement, von dort in ein Gremium, das Epics gegen Objectives spiegelt, und danach in die nächste Portfolioplanung. Die Maschine hat in einem Nachmittag geliefert. Die Entscheidung darüber braucht ein Quartal. Diese Differenz kostet Dich den Ertrag Deiner Investition in agentische Entwicklung, während die Token-Rechnung weiterläuft.

Vibe Coding war die Demo, Context Engineering ist die Arbeit

Die erste Welle prompt-gesteuerter Entwicklung hat vor allem eines geliefert: schnelle Klickdummies für Vorstandspräsentationen. Für ernsthafte Systeme mit Testabdeckung, verteilten Architekturen und Datenflüssen trägt das Prinzip nicht. Wir halten Vibe Coding deshalb für durch.

Was an seine Stelle getreten ist, hat einen unspektakulären Namen und eine klare Definition. Birgitta Böckeler beschreibt Context Engineering für Coding-Agenten bei Thoughtworks als das Kuratieren dessen, was das Modell sieht, damit ein besseres Ergebnis herauskommt. In der Praxis heißt das: versionierte Projektkonventionen, pfadbasierte Regeln, dedizierte Kontexte für größere Aufgaben und strukturierter Zugriff auf externe Werkzeuge. Nicht der bessere Prompt entscheidet über die Qualität des erzeugten Codes, sondern die Frage, welche Informationen das System zum richtigen Zeitpunkt vorliegen hat.

Für Dich als Entscheider hat das zwei Seiten: Kontext ist ein Wert, den Du bereits besitzt und den kein Wettbewerber kopieren kann, aber er muss erst maschinenlesbar werden, bevor ein Agent damit arbeiten kann.

Der Agent braucht Zugang zu Deinen Daten, nicht bessere Prompts

Der technische Hebel dafür ist das Model Context Protocol, kurz MCP: eine Schnittstelle, über die ein KI-System Zugriff auf andere Systeme und auf Werkzeuge bekommt. Wenn Du diese und benachbarte Begriffe für ein Gespräch mit Deinen Fachbereichen sortieren willst, hilft unsere Landkarte durchs KI-Vokabular. Das Werkzeug kann ein Deployment auslösen, Kundendaten heraussuchen oder einen Bericht abrufen, und das System entscheidet selbst, welches es dafür einsetzt.

Praktisch bedeutet das: Dein Coding-Agent liest nicht nur das Repository, sondern auch die Auswertung darüber, was das letzte Release bei den Abonnements bewirkt hat. Er kennt die Zahlen aus dem Berichtswesen und die Ergebnisse aus der Nutzerbefragung. Aus einem Werkzeug, das Code schreibt, wird damit ein System, das begründete Vorschläge macht.

Das ist auch eine Datenfrage: Wo Deine Kennzahlen in Tabellen auf Laufwerken liegen und Dein Produktwissen in Köpfen, hat der Agent nichts zu lesen. Der Aufwand verschiebt sich dann von der Entwicklung in die Datenarchitektur. In einem Team von drei Leuten mit einem Produkt rechnet sich dieser Umbau nicht. Ab dem Punkt, an dem mehrere Teams an einem Bestand arbeiten, wird er zur Voraussetzung für alles Weitere.

Discovery und Delivery fallen zu einem Kreislauf zusammen

Das Tempo ist dabei nur ein Faktor. Schwerer wiegt, dass eine Trennung verschwindet, an der wir unsere Prozesse seit Jahren ausrichten. Wenn ein Research-Agent über Nacht Daten zusammenträgt, daraus fünf Varianten eines Features ableitet, diese implementiert und an Nutzerkohorten ausspielt, und wenn die Messsysteme das Ergebnis direkt zurückspeisen, dann sind Discovery und Delivery kein Wechselspiel zweier Phasen mehr. Sie werden ein System, das sich selbst verstärkt.

Für die Steuerung Deines Unternehmens heißt das: Die Entscheidung muss dorthin, wo die Arbeit geschieht. Wenn ein Entwicklerteam an einem Vormittag fünf Varianten baut und verprobt, kann die Auswahl nicht in einem Gremium liegen, das alle zehn Wochen zusammenkommt. Stakeholder geben dann Zielaufträge und Leitplanken, nicht mehr Feature-Listen.

Gemerged wird trotzdem erst nach 35 Stunden

Die Messwerte aus der Branche zeigen, wo dieser Umbau zuerst klemmt. Plandek hat für die Engineering Productivity Benchmarks 2026 mehr als 2.000 Engineering-Teams weltweit ausgewertet und benennt das Code Review als den sichtbarsten Engpass: Teams im unteren Viertel brauchen im Schnitt über 35 Stunden, um einen Pull Request zu mergen, die Spitzengruppe bleibt unter 21 Stunden. Die Erzeugung von Code ist billig geworden, seine Prüfung nicht.

Ein Agent liefert in Minuten, was vorher Tage gedauert hat. Verfünffacht sich dadurch der Durchsatz, verfünffacht sich auch die Menge, die durch Review, Sicherheitsprüfung und Freigabe muss. Wer diese Strecke nicht mitskaliert, tauscht damit einen Engpass gegen einen noch teureren: Die Kosten laufen weiter, das Ergebnis erreicht die Nutzer trotzdem nicht.

Skalieren heißt hier nicht, mehr Menschen ins Review zu setzen. Es heißt, Prüfung so weit zu automatisieren, wie sie automatisierbar ist, und dort ein Gate zu setzen, wo der Schaden im Fehlerfall groß wird. Welche Übergabe wie viel Prüfung verträgt, haben wir in der Risiko-Staffel für den Kontrollverlust bei KI-Agenten ausbuchstabiert.

Hohe Testabdeckung ist kein Kostenfaktor mehr, seit die Maschine die Tests schreibt. Wie präzise die Spezifikation dafür sein muss, haben wir am Beispiel von Spec-Driven Development und KI-Code-Qualität beschrieben. In unseren Projekten erreichen wir damit 98 Prozent Abdeckung, mit einer Einschränkung: Ein Agent, dem Du nur „mach mal Tests“ sagst, schreibt Tests, die grün aussehen und nichts prüfen. Auch Testqualität braucht Kontext. Messgrößen wie zyklomatische Komplexität und Abdeckungsgrad lassen sich dann wiederum an das bauende System zurückspielen, das damit früh erkennt, wenn es in die falsche Richtung läuft.

Im Altbestand zahlt sich Context Engineering zuerst aus

Der greifbarste Anwendungsfall ist nicht das neue Produkt, sondern das alte System. Modernisierungen waren bisher Mehrjahresprojekte, in denen ein Team zwischen Tagesgeschäft und Umbau zerrieben wurde. Mit agentischen Systemen, die Altcode analysieren, vollständig dokumentieren, mit Tests unterfüttern und Domänen herausarbeiten, arbeiten wir in unseren Projekten um den Faktor drei bis vier schneller als vor agentischer KI.

Und noch ein Problem lässt sich lösen: Agenten steuern eine virtuelle Maschine und bedienen die Altsoftware über deren Oberfläche. Das geht weiter als klassische Robotic Process Automation, also die regelbasierte Automatisierung von Klickstrecken, weil kein Weg vorab konfiguriert werden muss. Damit lässt sich eine Prozessstrecke durchgängig automatisieren, in der bisher ein Mensch an einem alten Terminal saß. Altbestand blockiert dann nicht länger die Automatisierung der Prozesse, die um ihn herum laufen.

Und die Kosten? In einem unserer Voice-Projekte liegt der Betrieb bei 2,60 bis 3,80 Euro pro Gesprächsstunde, inklusive Absichtserkennung und automatischem Protokoll. Der Vergleich mit einer menschlichen Arbeitsstunde fällt deutlich aus. Das Argument, KI-Einsatz sei zu teuer, zielt fast immer auf die falsche Größe: Gemessen wird der Token-Preis, entscheidend ist der Hebel.

Was Du mitnimmst

Frage Deinen Plattform-Lead, welche Deiner Produktkennzahlen ein Agent heute ohne menschliches Zutun lesen könnte. Lautet die Antwort „gar keine“ oder „die liegen im Reporting-Tool“, hast Du Dein erstes Arbeitspaket gefunden; dann ist es ein Datenprojekt, kein KI-Projekt.

Drei Schritte, die sich im nächsten Quartal anstoßen lassen:

• Kontext zugänglich machen. Mit dem Datenteam einen Kennzahlensatz und ein Berichtssystem auswählen und maschinenlesbar anbinden. Erfolgskriterium ist, dass ein Agent die Wirkung des letzten Releases selbst nachschlagen kann.
• Die Prüfstrecke messen. Mit der Engineering-Leitung die Zeit vom fertigen Pull Request bis zum Merge erheben und gegen den Plandek-Korridor halten. Diese Zahl ist Dein realer Durchsatz, nicht die Zahl der erzeugten Zeilen.
• Den Entscheidungsweg verkürzen. Mit den Produktverantwortlichen festlegen, welche Variantenentscheidung ohne Gremium im Team fallen darf, und wo die Leitplanke stattdessen im Zielauftrag steht.

Wenn Du in der Produktarbeit selbst anfangen möchtest: Setze Dich für eine Sitzung mit einem Entwickler an einen Rechner und bauet gemeinsam ein kleines System. Nicht um Backlog-Einträge generieren zu lassen, sondern um zu erleben, wie sich die eigene Kommunikation verändert, wenn eine Maschine am anderen Ende die Anforderung ausführt.

Das ganze Gespräch mit Björn Schotte über den Einfluss von KI auf die Produktentwicklung kannst Du bei den Produktwerkern nachhören. Dort stehen die Praxisbeispiele ausführlich, die dieser Artikel nur streift, samt der Migrationsfälle aus Beständen, die seit Jahrzehnten laufen. Wenn Du danach Deinen eigenen Fall durchsprechen möchtest, erreichst Du Björn direkt auf LinkedIn.