Most discussions about AI in engineering focus on tools: which coding assistant to adopt, how to automate test generation, or what documentation support looks like in practice. Product decisions tend to get the attention, while structural ones do not.
That creates a business problem. Many organizations are investing in AI but leaving the operating model unchanged: developers may move faster individually, but the business still pays for the same handoffs, the same coordination loops, the same approval delays, and the same unclear ownership. McKinsey found that regular AI use is now widespread, with 88% of organizations using AI in at least one business function, but only 39% reporting enterprise-level EBIT impact. This is useful because it shows the adoption/value gap.
So, what’s causing this rift? It’s because the actual shift is not about tools – it is about how work is organized. As AI moves from assistance to execution, team size, ownership boundaries, cost structures, and delivery rhythm all evolve together.
Adding AI to an unchanged team structure produces incremental improvement. Changing the structure is what creates a different business case.
For engineering teams, the question is often whether AI can increase developer productivity. For business leaders, the better question is whether AI can reduce the cost and time required to turn product decisions into working software.
That distinction matters. A 20% improvement in individual developer productivity does not automatically become a 20% improvement in product delivery. If work still waits on functional handoffs, sprint dependencies, review queues, or unclear ownership, the gain is absorbed by the system.
The cost of that system is already significant. Atlassian's developer experience research found that 69% of developers lose eight hours or more each week to inefficiencies. That is roughly one working day, or a fifth of their time, spent on friction rather than product progress.
This is where the business case begins. The value of agentic engineering is not simply that engineers write code faster. It is that organizations can reduce the delay between identifying a product opportunity and validating it in production.
That affects several business measures:
The point is not to replace engineering judgments. The point is to stop using expensive human capacity for work that can be executed, checked, and repeated by an agent layer under human supervision.
Jeff Bezos introduced the two-pizza rule at Amazon as the company was working out how to preserve speed and accountability while growing. The principle was simple: teams should remain small enough to avoid the communication and decision-making costs that increase with headcount. In practice, this usually meant autonomous groups of around five to ten people – or the number of people you can feed with two pizzas.
The size of the team was only part of the idea. Two-pizza teams were given responsibility for a defined product or service, with the skills needed to build, operate and improve it embedded within the group. Rather than passing work between separate development, testing and operations departments, the team could own a workload from end to end. This closely matched the wider direction of agile and DevOps transformation: smaller teams, shorter feedback loops and accountability placed closer to the customer.
This represented a significant improvement on traditional project structures. Bringing frontend and backend engineering, QA, operations and product direction into one team reduced dependencies on central functions. Decisions could be made closer to the work, and teams could release and learn without coordinating every change across a large organization.
However, the model still depended on several specialists collaborating to move one product area forward. Work passed between roles inside the team even when it no longer passed between departments. Frontend development, backend development, testing, infrastructure, and product management remained distinct areas of responsibility.
That internal division of labor placed a limit on how small and fast the team could become. Each additional specialism introduced another dependency, while accountability for the final outcome remained distributed across the group. When delivery slowed, the cause could sit anywhere across a chain of decisions, reviews, and handovers.
For roughly two decades of agile transformation, the two-pizza team offered a practical answer to the coordination problems created by larger, functionally separated organizations. Agentic engineering now changes the underlying economics of that answer. When AI can perform more of the execution work across coding, testing, documentation, and infrastructure, a product no longer requires the same number of specialists to move forward.
The next step is therefore not simply a more productive two-pizza team, but a smaller team built around broader product ownership.
The two-pizza model rested on one assumption: execution required multiple specialized roles. A single engineer could not own the full stack, write the tests, handle the infrastructure, and keep documentation current at the same time, so specialization existed because breadth was expensive.
AI changes that assumption. Code, tests, documentation, refactoring, and workflow scaffolding can be generated in parallel. Repetitive engineering work that previously required dedicated headcount can be automated. The cost of context-switching across domains drops for an engineer who is directing rather than writing every line manually.
This changes the constraint in a specific way. The bottleneck is no longer execution capacity but direction quality: the ability to define what to build with enough precision that agents can execute it, validate that the output is correct, and decide what ships.
That is why the business case depends on operating model change. If AI is used only inside the existing structure, the organization gets faster task completion. If AI changes ownership and delivery flow, the organization gets faster product movement.
When execution is no longer the constraint, the logic behind team size changes. What emerges is not a smaller version of the two-pizza team but a different model with a different name: the one-pizza team.
Two to three product builders replace a six-to-eight-person function-based team. Each builder owns a full value stream rather than a functional slice, and an agent layer handles execution: code generation, test creation, refactoring, documentation, and workflow scaffolding. AI-native product builders do not just use agents. They orchestrate them.
The structural difference is visible in how value gets delivered. In the two-pizza model, value delivery is collective and diffuse, with accountability spread across functions. In the single-pizza model, value delivery is individual and traceable, with each builder accountable for delivery rather than for completing a task in a chain.
For the business, this creates a different unit of measurement. Instead of asking how many developers are assigned to a product area, leaders can ask how much validated product movement each builder can generate with the support of an agent layer. That is a more useful measure of return because it links engineering capacity to business throughput.
The return on agentic engineering comes from several gains that compound when the operating model changes:
This is the business case that matters. Agentic engineering should be measured by whether the same investment produces more validated product movement, not by tool usage alone.
This shift does not happen by adopting the right tools. It requires deliberate organizational decisions that sit above the technology stack.
Leaders need to redefine what a team is. The two-pizza model was a useful heuristic for two decades of agile transformation, when delivering software still depended on several specialists working together within one autonomous team. Agentic engineering changes that equation by allowing product builders to direct execution across coding, testing, documentation, and infrastructure with the support of an agent layer.
The hiring profile of a product builder who orchestrates agent workflows and owns a full value stream is therefore different from that of a specialist who owns a functional domain. Both remain valuable, but they serve different delivery models and are not interchangeable.
Leaders also need to treat orchestration capability as infrastructure, not professional development. This means investing in an agentic engineering platform that provides a consistent way to define agent scope, control access to systems and data, enforce security policies, monitor activity, and review outputs before they reach production.
Without that shared foundation, orchestration remains dependent on individual working practices and becomes difficult to govern at scale. With it, organizations can apply the same standards for security, quality, and accountability across teams while giving product builders the freedom to direct agent workflows effectively.
The goal is not to use more AI. It is to build a delivery system in which agents can execute effectively, and product builders can direct that execution with precision. Organizations that make that shift can reduce coordination costs, shorten product cycles, and make better use of scarce engineering capacity.
Those that treat agentic engineering as a tooling decision will get faster execution. Those that redesign the delivery model around it will change the economics of software development.