This blog post is also available in English
TL;DR
- Agentic Development macht Delivery so schnell und günstig, dass ein Trio aus Product Manager:in, UX Designer:in und Engineer beides übernehmen kann: Discovery und Delivery.
- Die freiwerdende Kapazität in mehr Output zu stecken ist eine Falle. Empirische Daten zeigen: Bugrate, Review-Zeiten und Incidents steigen, die Codequalität sinkt.
- Klüger ist, mehr in Discovery zu investieren und vorher zu klären, ob überhaupt die richtigen Probleme gelöst werden.
- Im Agentic Trio verschiebt sich die Rolle der Entwickler:in: Er oder sie wird zur Hüter:in nachhaltiger Lieferfähigkeit und baut das Agent Harness, das allen drei Rollen ermöglicht, sicher zu deployen.
Die besten Product Teams, ob in Start-ups oder großen Organisationen, arbeiten oft so, dass andere es kaum nachbauen können: Eine kleine Einheit, typischerweise aus Product Manager:in, UX-Designer:in und Engineer, erforscht systematisch relevante Nutzerprobleme, bevor Lösungen gebaut werden. Statt Stakeholder-Wünsche einfach umzusetzen, betreibt sie kontinuierliche Discovery, um herauszufinden, was überhaupt gebaut werden sollte. Die Delivery übernimmt das größere Product Team dahinter. Teresa Torres hat diese Arbeitsweise als Product Trio beschrieben.
Was bisher fehlte: Das Trio verantwortete die Discovery, die Delivery lag beim größeren Team dahinter. Agentic Development ändert das.
Wir nennen diese Weiterentwicklung das Agentic Trio.
Die verschobenen Economics der Delivery
Delivery wird schneller und günstiger. Der kontinuierliche Discovery-Delivery-Zyklus kann häufiger stattfinden, weil die Schwelle gesunken ist, ab der sich ein weiterer Zyklus lohnt. Dadurch entsteht Kapazität. Wie diese Kapazität genutzt wird, ist eine strategische Entscheidung.
Für Teams und Organisationen, die diese Entscheidung nicht bewusst treffen, bedeutet das Ergebnis oft: mehr Output – nicht besserer Output. Aber „mehr Discovery statt mehr Output“ ist kein Trade-off. Teams, die stärker in Discovery investieren, identifizieren relevantere Probleme, priorisieren besser und bauen Lösungen, die tatsächlich funktionieren. Im gleichen Zeitraum werden mehr Chancen erkannt, mehr davon vor dem Bauen validiert und mehr davon mit funktionierenden Lösungen adressiert. Es wird weniger Zeug gebaut – aber mehr von dem, was gebaut wird, ist wirklich wichtig.
Der naheliegende Einwand lautet: Wenn Bauen billig ist, warum nicht einfach alles ausprobieren und in Produktion lernen, was funktioniert? Das klingt pragmatisch, setzt aber voraus, dass relevante Unsicherheit ausschließlich auf der Lösungsebene liegt. In der Realität stecken viele der riskantesten Annahmen weiterhin im Opportunity Space: Ist das Problem real? Haben es genug Menschen? Ist es relevant genug, dass sie tatsächlich etwas dagegen tun würden? Keine gebaute Funktion kann diese Fragen beantworten. Du kannst Agenten nutzen, um in ein paar Stunden eine Lösung zu erzeugen – und weißt danach über die zugrunde liegende Opportunity genauso wenig wie vorher. Du hast getestet, ob die Lösung implementierbar ist, nicht ob das Problem existiert und ob die Lösung es wirklich adressiert.
Torres unterscheidet mehrere Kategorien von Annahmen: Desirability (wollen Nutzer:innen das überhaupt?), Feasibility (können wir es bauen?), Viability (ist es wirtschaftlich sinnvoll, es zu bauen?) und Usability (können Nutzer:innen es bedienen?). Nutzungsmetriken können diese Kategorien nur begrenzt auseinanderhalten. Wenn ein Feature nicht genutzt wird, kann das an fehlender Desirability, schlechter Usability oder an einem Workaround liegen, den Nutzer:innen verinnerlicht haben und nicht aufgeben wollen. Das Signal ist überlagert. Ein kurzes Gespräch vor dem Bauen hätte die Frage direkter und günstiger beantwortet. Desirability-Annahmen sind oft die riskantesten – und gleichzeitig am billigsten zu testen. Sie zu überspringen und direkt zu bauen heißt: die falschen Dinge validieren, nur schneller.
Das gilt nicht für jede Art von Annahme. Usability- und Feasibility-Annahmen lassen sich oft günstiger durch Prototyping oder direktes Bauen validieren als durch Interviews. Agentic Development senkt diese Schwelle weiter. Schnelle Prototypen werden günstiger, der Zyklus zwischen Bauen und Lernen wird kürzer. Das ist eine echte Verschiebung. Aber sie betrifft nur einen Teil des Annahmenraums.
Warum mehr Output das System destabilisiert
Die Entscheidung für mehr Output statt systematischer, kontinuierlicher Discovery hat einen zweiten, weniger offensichtlichen Preis: Sie destabilisiert das System. Daten von Faros AI und DORA belegen das empirisch.
Faros nennt dieses Muster „Acceleration Whiplash“: Wenn Teams Agentic Development vor allem für mehr Durchsatz nutzen, steigt der Output – Tasks werden 34% häufiger abgeschlossen, Epics 66% häufiger, code-spezifische Tasks sogar 210% häufiger. Gleichzeitig fallen alle Qualitätsindikatoren. Bugs pro Entwickler:in sind um 54% gestiegen, das Verhältnis Incidents zu PRs hat sich mehr als verdreifacht (+242,7%), die mediane Review-Zeit ist um 441% gestiegen, und 31,3% mehr Pull Requests werden ohne jegliches Review gemergt. Das betrifft sogar Teams, die DORA als „high-performing“ klassifiziert hat – Teams also, die sich schon vor der KI-Einführung durch schnelle Delivery und niedrige Change-Failure-Raten auszeichneten.
Reinertsen liefert die systemische Erklärung: Mehr Output erhöht die Auslastung an kritischen Engpässen. Der kritische Engpass heute ist das Review durch Senior Engineers. Was leidet, ist die Review-Qualität. Das Ergebnis: mehr Bugs gelangen in Produktion. Hohe Auslastung an Bottleneck-Ressourcen ist der teuerste Zustand in einem Product-Development-System.
Gründlichere Discovery reduziert den Input ins System an der richtigen Stelle: bevor unvalidierte Lösungen die Pipeline füllen und sich an kritischen Gates stauen. Weniger Zeug zu bauen heißt außerdem: weniger Review-Last für Senior Engineers, eine niedrigere Change-Failure-Rate und ein stabileres System.
Torres’ Product Trio
Teresa Torres’ Product Trio besteht aus Product Manager:in, UX-Designer:in und Engineer. Die Idee: Alle drei betreiben Discovery gemeinsam – jede Rolle bringt ihre Perspektive ein, niemand ist nur Empfänger:in der Entscheidungen anderer. Das Trio trifft Discovery-Entscheidungen als kleine, handlungsfähige Einheit. Der Rest des Teams ist ausschließlich für Delivery zuständig.
Das Trio exploriert nicht beliebig. Das gewünschte Business Outcome wird typischerweise von außen vorgegeben. Das kann eine Metrik sein, ein strategisches Ziel oder ein Kundenproblem, das die Organisation lösen will. Innerhalb dieses Rahmens sucht das Trio nach Opportunities und entscheidet, welche Lösungen verfolgt werden. Die Autonomie liegt im Wie und Was – nicht im Warum. Alle drei Trio-Mitglieder nehmen regelmäßig an User Interviews, Opportunity Mapping, Annahmentests und Solution Ideation teil.
In der Praxis scheiterte der Ansatz manchmal an einem einfachen Kapazitätsproblem: Der Engineer war oft stark in Delivery eingebunden und hatte weniger Zeit für Discovery als Product Manager:in und Designer:in. Die interne Trennung, die Torres überwinden wollte, reproduzierte sich unter dem Druck des Tagesgeschäfts. Delivery brauchte ein größeres Team – und wer liefert, hat keine Zeit für Discovery.
Agentic Development hebt diese Einschränkung auf – und macht damit möglich, was Torres ursprünglich vorschwebte.
Das Agentic Trio
Im Agentic Trio übernimmt ein kleines Trio nicht nur Discovery, sondern auch Delivery. Das Trio arbeitet damit als vollständig autonome Einheit. Die Rollen sind dieselben wie bei Torres: Product Manager:in, UX-Designer:in, Engineer. Was sich ändert, ist der Umfang ihrer gemeinsamen Verantwortung. Alle drei machen Discovery und Delivery – ohne Unterstützung durch Teammitglieder, die nicht an der Discovery-Arbeit beteiligt sind.
Das verändert nicht nur, wie Teams arbeiten, sondern auch, wie Organisationen geschnitten werden können. Kleinere, autonomere Einheiten mit echter End-to-End-Verantwortung werden möglich, ohne Discovery-Qualität zu opfern. Die durch schnellere Delivery frei werdende Kapazität fließt nicht in mehr Output, sondern in tieferes Problemverständnis.
Eine Unterscheidung ist hier wichtig: Das Agentic Trio und stream-aligned teams aus Team Topologies sind orthogonal. Team Topologies beantwortet, wie Teams strukturiert sind. Das Agentic Trio beantwortet, wie Discovery und Delivery innerhalb eines Teams organisiert sind. Im klassischen stream-aligned team – also dem, was Torres das Product Team nennt – könnte ein Teil des Teams das Trio bilden, während andere sich ausschließlich auf Delivery konzentrieren. Das Agentic Trio lässt genau diese interne Trennung zusammenfallen. Ein stream-aligned team ist keine notwendige Voraussetzung für Agentic Trios, aber in jedem Fall wünschenswert: Je mehr Entscheidungsautonomie das Trio hat, desto vollständiger kann es die verkürzten Zyklen von Agentic Development ausnutzen.
Konvergenz der Rollen
Das Agentic Trio verlangt von allen drei Rollen ein T-förmiges Profil: Jede Rolle behält ihr Tiefengebiet, aber die gemeinsame Basis wächst deutlich.
Auf der Delivery-Seite nutzen alle drei Rollen Coding Agents, um Lösungen umzusetzen. Product Manager:innen und Designer:innen werden zu aktiven Autor:innen und unabhängigen Produzent:innen. Prompting und die Arbeit mit Coding Agents werden zu Basiskompetenzen für alle Beteiligten – nicht nur für den Engineer, der weiterhin die Deep-Expert-Rolle bleibt.
Auf der Discovery-Seite nehmen alle drei gleichberechtigt an User Interviews, Opportunity Mapping, Solution Ideation und Annahmentests teil. Im idealen Product Trio war das immer das Ziel. Im Agentic Trio ist es erstmals ohne Kompromiss möglich, weil die Engineer-Rolle nicht mehr primär durch Delivery gebunden ist.
Die Konvergenz ist keine Einebnung. Product Manager:innen und Designer:innen müssen verstehen, was generierter Code leisten kann, wo Architekturentscheidungen Produktentscheidungen sind, wo Technical Debt die Strategie einschränkt. Der Engineer muss die Nutzerperspektive einnehmen, Probleme vor der Lösungsebene erfassen und Discovery-Methoden anwenden. Jede Rolle versteht mehr von den Spezialisierungen der anderen – aber die Tiefenbereiche bleiben unterschiedlich.
Entwickler:innen als Agent Harness Engineers
Auf der Delivery-Seite ist die Rolle des Engineers im Agentic Trio nicht primär die einer Produzent:in, sondern die einer Hüter:in der Fähigkeit, nachhaltig zu liefern – nicht nur heute, sondern auch in Zukunft – und damit sinnvolle Outcomes zu erzeugen. Seine oder ihre Kernaufgabe: das Bauen und Pflegen des Agent Harness, also der Infrastruktur, in der alle drei sicher und produktiv bauen können.
Der Harness umfasst maschinell durchgesetzte Quality Gates (Fitness Functions, Linter-Regeln, Architektur-Checks), spezialisierte Skills und Subagents für wiederkehrende Aufgaben, eine CI/CD-Pipeline, die keinen generierten Code ohne Gate in Produktion lässt, sowie Observability, Deployment und Monitoring. Der Engineer verantwortet nicht nur die Strukturen, sondern auch die Infrastruktur, die verhindert, dass agentisch generierter Code diese Strukturen untergräbt.
Daraus folgt eine wichtige Reihenfolge: Der Harness muss stehen, bevor Product Manager:innen und Designer:innen anfangen zu bauen. Sonst entsteht genau die Art von Debt, die Agentic Development in schlecht vorbereiteten Organisationen bereits produziert. Agent-Harness-Engineering ist daher eine der zentralen Schlüsselkompetenzen für Senior Engineers in der agentischen Ära. Entwickler:innen, die Guardrails definieren, Subagent-Repertoires kuratieren und Pipelines bauen, die agentischen Output zuverlässig absichern, sind nicht durch schnellere Code-Generierung ersetzbar. Sie sind diejenigen, die schnelle Code-Generierung überhaupt erst sicher machen.
Über den Harness hinaus trägt der Engineer eine Verantwortung, die sich nicht automatisieren lässt: Er oder sie hält das mentale Modell des Systems. Peter Naur beschreibt in „Programming as Theory Building“, dass der eigentliche Kern von Softwareentwicklung nicht der Code ist, sondern die Theorie dahinter: das Verständnis, warum das System so gebaut ist, wie es gebaut ist, welche Entscheidungen welche Strukturen rechtfertigen, was eine Änderung an einer Stelle für andere bedeutet. Diese Theorie lebt in den Köpfen der Entwickler:innen, nicht im Code selbst.
Im Agentic Trio ist der Engineer die einzige Person, die diese Theorie halten kann und muss. Drei Personen und mehrere Agenten schreiben gleichzeitig in dasselbe System. Code Review durch den Engineer ist deshalb keine Qualitätskontrolle im bürokratischen Sinn, sondern der Mechanismus, durch den die Theorie aktuell bleibt. Er oder sie sieht, was erzeugt wurde, bewertet, ob es zur bestehenden Theorie passt, und korrigiert, wo es abweicht. Ohne das bricht die Code-Qualität ein – und die Theorie des Systems geht verloren.
Discovery als Verpflichtung und Versprechen
Discovery-Beteiligung ist im Agentic Trio keine optionale Erweiterung der Developer:innen-Rolle. Sie ist konstitutiv. Das wirkt auf zwei sehr unterschiedliche Gruppen jeweils anders.
Für Engineers, die schon immer Discovery machen wollten, aber nie die Zeit hatten, erfüllt das Agentic Trio ein altes Versprechen. Das Interesse an Nutzerproblemen, am Warum hinter dem Was, war bei diesen Engineers immer da. Delivery hat nur den größten Teil der Zeit aufgefressen.
Für Engineers, die bisher nicht in einem Product Trio waren und keine Discovery-Arbeit machen wollten, ist das eine neue Herausforderung. Die Rolle verändert sich fundamental.
Ein letzter Punkt zu Juniors: Wenn wir eine neue Generation von Seniors aufbauen wollen, braucht es auch für sie einen expliziten Platz im Agentic Trio. Juniors arbeiten im Agentic Trio selten allein. Sie pairen – mit dem Senior Engineer beim Harness-Aufbau, mit der/dem Product Manager:in bei Discovery, mit der/dem Designer:in bei Solution Ideation und mit wechselnden Partner:innen in Delivery. Rotation durch alle Rollen ersetzt den klassischen Lernpfad des reinen Code-Schreibens. Juniors im Agentic Trio ähneln damit Trainees, die durch unterschiedliche Perspektiven und Rollen gehen. Das Ergebnis ist eine breitere Ausbildung als bisher. Und die Entscheidung über Spezialisierung fällt später und bewusster: Wer alle Bereiche erlebt hat, weiß besser, wo die eigene T-förmige Tiefe liegen sollte.
Das Agentic Trio ist keine Blaupause für jede Organisation und jeden Kontext. Es ist eine Antwort auf die Frage, wie man Produktentwicklung so organisiert, dass schnellere Delivery tatsächlich zu besseren Outcomes führt – nicht nur zu mehr Auslastung, mehr Review-Last und mehr Bugs in Produktion. Die Antwort, die das Agentic Trio gibt: indem man die frei werdende Kapazität bewusst in Discovery investiert – in einer kleinen Einheit, die beides besitzt. Nicht sequenziell, nicht in getrennten Strukturen, sondern kontinuierlich und gemeinsam.