Dieser Blogpost ist auch auf Deutsch verfügbar
TL;DR
- Agentic development makes delivery so fast and cheap that small teams can now handle both discovery and delivery – the core idea behind the Agentic Trio (product manager, UX designer, engineer).
- Using that freed-up capacity for more output is a trap: empirical data shows it raises bug rates, review times, and incident counts while tanking code quality.
- The smarter investment is more discovery – validating that the right problems are being solved before building, not after.
- The engineer’s key role shifts from producer to guardian: building the agent harness (quality gates, CI/CD, subagents) that makes it safe for all three roles to ship code.
The best product teams, whether in startups or large organizations, often work in ways others struggle to replicate: a small unit, typically a product manager, UX designer, and engineer, systematically researches relevant user problems before solutions are built. Rather than implementing stakeholder wishes, it practices continuous discovery to find out what should actually be built. Delivery is handled by the larger product team behind it. Teresa Torres described this way of working as the Product Trio.
What was missing until now: the trio owned discovery, while delivery belonged to the larger team behind it. Agentic development changes that.
We call this evolution the Agentic Trio.
The shifted economics of delivery
Delivery is getting faster and cheaper. The continuous discovery-delivery cycle can happen more frequently because the threshold at which another cycle pays off has dropped. This creates capacity. How that capacity is used is a strategic choice.
For teams and organizations that don’t make this choice explicitly, the result is often more output, not better output. But “more discovery instead of more output” is not a trade-off. Teams that invest more in discovery identify more relevant problems, prioritize better, and build solutions that actually work. Over the same period, more opportunities are identified, more are validated before building begins, and more are addressed with solutions that function. Less stuff gets built, but more of what gets built matters.
The obvious objection is: if building is cheap, why not just try everything and learn in production what works? The objection sounds pragmatic, but it assumes that relevant uncertainty sits exclusively at the solution level. In reality, many of the riskiest assumptions still live in the opportunity space: Is the problem real? Do enough people have it? Is it relevant enough that they would do something about it? No built feature can answer these questions. You can use agents to generate a solution in a few hours and know just as little about the underlying opportunity afterward as you did before. You’ve tested whether the solution is implementable, not whether the problem exists and whether the solution actually addresses it.
Torres distinguishes several categories of assumptions: desirability (do users even want this?), feasibility (can we build it?), viability (is it economically sensible to build it?), and usability (can users use it?). Usage metrics are limited in their ability to distinguish between these. If a feature goes unused, it could be due to missing desirability, poor usability, or a workaround users have internalized and won’t give up. The signal is confounded. A short conversation before building would have answered the question more directly and cheaply. Desirability assumptions are often the riskiest and simultaneously the cheapest to test. Skipping them and building directly means validating the wrong things, just faster.
This doesn’t apply to every type of assumption. Usability and feasibility assumptions can often be validated more cheaply through prototyping or direct building than through interviews. Agentic development lowers this threshold further. Quick prototypes get cheaper, the cycle between building and learning gets shorter. That is a real shift. But it only affects part of the assumption space.
Why more output destabilizes the system
The choice for more output over systematic and continuous discovery has a second, less obvious cost: it destabilizes the system. Data from Faros AI and DORA demonstrate this empirically.
Faros calls the pattern “Acceleration Whiplash”: when teams use agentic development primarily for more throughput, output rises — tasks are completed 34% more often, epics 66% more often, code-specific tasks even 210% more often. At the same time, all quality indicators fall. Bugs per developer have risen by 54%, the incidents-to-PR ratio has more than tripled (+242.7%), median review time has risen by 441%, and 31.3% more pull requests are merged without any review. This affects even teams that DORA classified as “high-performing” — teams that distinguished themselves before AI adoption by fast delivery and low change failure rates.
Reinertsen provides the systemic explanation: more output increases utilization at critical bottlenecks. The critical bottleneck today is review by senior engineers. What suffers is review quality. The result: more bugs reach production. High utilization at bottleneck resources is the most expensive state in a product development system.
More thorough discovery reduces input into the system at the right point, before unvalidated solutions fill the pipeline and back up at critical gates. Building less stuff also means less review load for senior engineers, a lower change failure rate, and a more stable system.
Torres' Product Trio
Teresa Torres' Product Trio consists of product manager, UX designer, and engineer. The idea was that all three would conduct discovery together: each role contributes its perspective, none is merely a recipient of others' decisions. The trio makes discovery decisions as a small, capable unit. The rest of the team is solely responsible for delivery.
The trio doesn’t explore arbitrarily. The desired business outcome is typically set externally. This can be a metric, a strategic goal, or a customer problem the organization wants to solve. The trio searches within this frame for opportunities and decides which solutions to pursue. The autonomy lies in the how and what, not the why. All three trio members participate in regular user interviews, opportunity mapping, assumption testing, and solution ideation.
In practice, the approach sometimes failed on a straightforward capacity problem: the engineer was often also heavily involved in delivery and had less time for discovery than the product manager and designer. The internal separation Torres wanted to overcome reproduced itself under the pressure of day-to-day work. Delivery required a larger team, and those who deliver have no time to discover.
Agentic development removes this constraint and thereby makes possible what Torres originally had in mind.
The Agentic Trio
In the Agentic Trio, a small trio takes on not only discovery but also delivery. The trio thus operates as a fully autonomous unit. The roles are the same as in Torres: product manager, UX designer, engineer. What changes is the scope of their shared responsibility. All three do discovery and delivery, without support from team members not involved in the discovery work.
This changes not only how teams work, but how organizations can be structured. Smaller, more autonomous units with genuine end-to-end responsibility become possible without sacrificing discovery quality. The capacity freed up by faster delivery flows not into more output, but into deeper problem recognition.
One distinction is important here: the Agentic Trio and stream-aligned teams from Team Topologies are orthogonal. Team Topologies answers how teams are structured. The Agentic Trio answers how discovery and delivery are organized within a team. In the classic stream-aligned team — what Torres calls the product team — part of the team could form the trio while others focus exclusively on delivery. The Agentic Trio collapses exactly this internal separation. A stream-aligned team is not a necessary condition for agentic trios, but is in any case desirable: the more decision-making autonomy the trio has, the more fully it can leverage the shortened cycles of agentic development.
Convergence of roles
The Agentic Trio requires a T-shaped profile from all three roles: each role retains its area of depth, but the shared base grows substantially.
On the delivery side, all three roles use coding agents to implement solutions. Product managers and designers become active authors and independent producers. Prompting and working with coding agents become baseline competencies for everyone involved, not just the engineer, who remains the deep expert she is.
On the discovery side, all three participate equally in user interviews, opportunity mapping, solution ideation, and assumption testing. In the ideal Product Trio, this was always the goal. In the Agentic Trio, it is possible for the first time without compromise, because the engineer is no longer primarily bound by delivery.
The convergence is not a leveling. Product managers and designers need to understand what generated code can do, where architecture decisions are product decisions, where technical debt constrains strategy. The engineer needs to take the user perspective, grasp problems before the solution level, and apply discovery methods. Each role understands more about the others' specializations, but the areas of depth remain different.
The developer as an Agent Harness Engineer
On the delivery side, the engineer’s role in the Agentic Trio is not primarily that of a producer, but of a guardian of the ability to deliver sustainably, not just now, but in the future, and thus to generate meaningful outcomes. Her core task: building and maintaining the agent harness, meaning the infrastructure in which all three can build safely and productively.
The harness encompasses machine-enforced quality gates (fitness functions, linter rules, architecture checks), specialized skills and subagents for recurring tasks, a CI/CD pipeline that lets no generated code reach production without a gate, as well as observability, deployment, and monitoring. The engineer is responsible not only for the structures, but also for the infrastructure that prevents agentically generated code from undermining those structures.
This has an important sequential implication: the harness must be in place before product managers and designers start building. Otherwise, exactly the kind of debt accumulates that agentic development is already producing in poorly prepared organizations. Agent harness engineering is therefore one of the central key competencies for senior engineers in the agentic era. Developers who define guardrails, curate subagent repertoires, and build pipelines that reliably secure agentic output are not replaceable by faster code generation. They are the ones who make fast code generation safe in the first place.
Beyond the harness, the engineer carries a responsibility that cannot be automated: she maintains the mental model of the system. Peter Naur describes in “Programming as Theory Building” that the actual core of software development is not the code, but the theory behind it: the understanding of why the system is built the way it is, which decisions justify which structures, what a change in one place means for others. This theory lives in the minds of developers, not in the code itself.
In the Agentic Trio, the engineer is the only one who can and must hold this theory. Three people and several agents are writing into the same system simultaneously. Code review by the engineer is therefore not quality control in a bureaucratic sense, but the mechanism through which the theory stays current. She sees what was generated, evaluates whether it fits the existing theory, and corrects where it deviates. Without this, code quality collapses and the theory of the system is lost.
Discovery as obligation and promise
Discovery participation is not an optional extension of the development role in the Agentic Trio. It is constitutive. This lands differently for two very different groups.
For engineers who always wanted to do discovery but never had the time, the Agentic Trio delivers on an old promise. The interest in user problems, in the why behind the what, was always there for these engineers. Delivery simply consumed most of the time.
For engineers who have not previously been in a Product Trio and did not want to do discovery work, this is a new challenge. The role changes fundamentally.
A final note on juniors: if we want to build a new generation of seniors, there must be an explicit place for them in the Agentic Trio as well. Juniors in the Agentic Trio rarely work alone. They pair — with the senior engineer on harness construction, with the product manager on discovery, with the designer on solution ideation, and with rotating partners on delivery. Rotation through all roles replaces the classical learning path of writing code. Juniors in the Agentic Trio thus resemble trainees moving through different perspectives and roles. The result is a broader education than before. And the decision about specialization comes later and more deliberately: those who have experienced all areas know where their T-shaped depth should lie.
The Agentic Trio is not a blueprint for every organization and every context. It is an answer to the question of how to organize product development so that faster delivery actually leads to better outcomes, not just more utilization, more review load, and more bugs in production. The answer the Agentic Trio offers: by deliberately investing the freed-up capacity in discovery, in a small unit that owns both. Not sequentially, not in separate structures, but continuously and together.