Agentic software development needs more than faster code generation

AI is producing more code, and more review work

Developers using AI are completing 21% more tasks, but their review time has increased by 91%. They are also managing 47% more concurrent workstreams. AI coding tools are increasing development output, while the people responsible for checking and coordinating that work face a heavier workload.

These findings come from Bain’s April 2026 Tech and Engineering Survey of 293 senior technology leaders. The figures expose a problem that faster coding alone cannot solve. Every additional change needs appropriate testing, review, integration, and release. When code production outpaces those activities, work begins to pile up inside the development process.

The distinction matters because completing tasks and delivering reliable software are different measures of productivity. A coding tool can shorten implementation time without accelerating the release of a change. For engineering leaders, the value of faster coding depends on what happens to the work afterward.

Yet leaders expect much larger productivity improvements over the next one to two years. Bain’s survey found that organizations currently report gains across key engineering metrics, while their expectations for future improvements are substantially higher.

The gap between current results and future expectations raises a practical investment question. Organizations already have coding tools that accelerate individual tasks, but their ambitions require improvements across the software delivery process. Further gains depend on how efficiently teams can turn additional code into changes that are verified, integrated, and released.

Bain has a commercial interest in this transition because its technology consulting business can benefit from investments in engineering transformation. Its findings provide a starting point for identifying where development capacity is becoming constrained. For engineering leaders, the next challenge is to increase the capacity of the systems surrounding code generation.

The bottleneck has moved beyond code generation

The pressure on code review follows a basic relationship between production and capacity. When AI reduces the time needed to generate code, more work enters testing, review, integration, and deployment. Unless those downstream activities also become faster, the additional output increases waiting times and coordination demands.

Bain described this mechanism in its 2024 brief, “Beyond Code Generation: More Efficient Software Development.” The firm identified a shifting bottleneck effect: speeding up one activity exposes constraints elsewhere in the development process. Once another activity becomes the limiting factor, further improvements to code generation deliver progressively smaller gains in overall performance.

Consider an engineering team whose AI agents can implement several changes while developers handle other assignments. Each change may arrive quickly, but it must still meet engineering standards, pass tests, and receive appropriate approval. When changes affect related components, developers must also coordinate dependencies and resolve integration problems. Faster implementation therefore creates more work for the people and systems responsible for bringing those changes together.

For much of the preceding three years, model capability was the main constraint on AI-assisted development. Models needed to get better at understanding requirements, reasoning about code, and executing complex engineering tasks. Those capabilities have advanced substantially, and effective coding models are now widely available.

Wider access changes the investment calculation. Nearly three-quarters of technology leaders identify AI as their most important opportunity for improving engineering productivity, according to Bain. Yet organizations that focus their investment on generating more code may see diminishing returns when existing processes cannot absorb the additional work.

The relevant unit of improvement is therefore the software development life cycle (SDLC), which covers everything from planning and implementation to testing, deployment, and maintenance. Its performance depends on the capacity of each activity and the handoffs between them.

Improving that system requires three capabilities. AI agents need reliable engineering knowledge to carry out assignments correctly. Verification systems must evaluate more changes without a matching increase in human effort. Engineering leaders must also manage the development process continuously as the balance between human and automated work changes.

Structured knowledge makes AI agents more effective

The first constraint appears before an AI agent writes any code: whether it has enough information to complete the assignment correctly.

A capable coding model can inspect a repository and produce an implementation. But an acceptable engineering change also depends on organizational conventions, previous architectural decisions, compatibility requirements, and quality standards. Much of that knowledge sits outside the code an agent is asked to modify.

Experienced engineers often carry this context in their heads. A senior developer may know why a service has an unusual structure, which interfaces must remain compatible, or when a small change needs additional approval. That knowledge passes between people through conversations, code reviews, and experience.

Without the same context, an agent must ask for clarification or make assumptions. Either outcome can create more work for engineers, especially when incorrect assumptions reach the review stage. Giving agents relevant knowledge before they begin can reduce that avoidable effort.

Turn engineering decisions into reusable instructions

The practical response is to make engineering knowledge available through structured specifications, maintained documentation, and shared instructions.

Agents need access to several categories of information:

• Codebase structure and the reasoning behind important architectural decisions.
• Engineering conventions for implementation, testing, security, and maintainability.
• Historical decisions that explain existing constraints and dependencies.
• Rules defining when agents may proceed independently and when they must escalate.
• Interfaces connecting planning, implementation, and testing.
• Task inputs, expected outputs, and acceptance conditions.

These resources help agents make appropriate implementation decisions while establishing a basis for evaluating their work. Reviewers can then compare the result against requirements defined before execution. That makes expectations clearer for both the agent and the people checking its output.

Consider an agent assigned to modify an API, an interface through which software components exchange requests and responses. The agent needs to know which consumers depend on the existing interface, what compatibility requirements apply, and which tests confirm that the migration is complete. Without this information, it may produce working code that breaks an existing integration.

Providing that context requires engineering leaders to identify the decisions agents repeatedly need. They must then establish where those decisions are recorded and how to keep the information current. Documentation becomes part of the infrastructure used to execute development work, and its accuracy directly affects the reliability of agent output.

Stripe uses specifications to delegate bounded tasks

Stripe offers a concrete example through its task-specific coding agents, called “minions.”

These agents handle bounded assignments such as writing unit tests, correcting linter warnings, and migrating existing code to a newer API version. Each assignment uses a specification containing five elements: objective, scope, relevant context, verification method, and constraints.

The objective defines the required outcome, while scope establishes which parts of the system the agent may change. Context provides information for implementation decisions. The verification method explains how success will be checked, and constraints set the boundaries the agent must respect.

Together, these elements make assignments easier to delegate and evaluate. The agent has a defined responsibility, while reviewers have clear criteria for deciding whether its work is acceptable. This becomes especially useful when many assignments run at once.

Stripe reportedly merges approximately 1,300 AI-authored pull requests every week across its engineering organization. A pull request is a proposed code change submitted for review before it joins the main codebase. Stripe applies the same human review requirements to these changes as it does to conventional development work.

The reported volume shows how structured assignments can support substantial agent activity while preserving established approval requirements. Specifications define what agents should produce, and human reviewers evaluate the submitted changes under Stripe’s existing process.

The next opportunity builds on those specifications. Once an assignment has explicit requirements and acceptance conditions, some of the work needed to verify its output can be automated.

Automated controls make human review more scalable

Structured assignments make agent output easier to evaluate, but verification remains necessary. As more changes arrive, engineering organizations need controls that can handle routine checks consistently and identify work requiring human judgment.

A scalable approach combines automated testing, risk assessment, policy enforcement, and audit records. Together, these mechanisms help organizations apply appropriate scrutiny to each change while reducing repetitive work for reviewers. The goal is to increase verification capacity while maintaining the standards required for reliable delivery.

Assess risk before assigning review requirements

Risk assessment helps determine how each change should be handled.

A risk-scoring engine estimates the potential consequences of a proposed change. Its assessment can consider the change’s blast radius: the number and importance of components, services, or users that could be affected if something goes wrong.

For example, modifying an isolated internal utility may carry less risk than changing authentication logic or an interface used by many services. Organizations can use that difference to decide which checks and approvals are necessary. Higher-risk changes receive closer examination, while routine work follows a more automated path.

Risk scores become useful when they connect directly to the development workflow. A score should determine the next required action, whether that involves additional testing, specialist review, or escalation to an accountable engineer.

Enforce engineering rules automatically

Risk assessment determines the level of scrutiny, while policy-as-code applies specific requirements consistently.

Policy-as-code means expressing engineering and organizational rules as checks that software can enforce. Security requirements, compliance obligations, and architectural restrictions can then be evaluated against proposed changes before they advance.

For example, a policy may block a change that violates a security requirement or modifies a restricted component without approval. The system identifies the violation and returns the change for correction.

Automated enforcement reduces the need for reviewers to remember and manually apply every rule. It also keeps standards consistent as the volume of agent-generated changes grows. But engineers still need to define and maintain the policies, decide how exceptions should work, and establish who can approve them.

Evaluate output against acceptance criteria

Policy checks establish whether a change follows organizational rules. An evaluation framework determines whether the change fulfills its assigned task.

For coding work, acceptance criteria may include passing tests, expected behavior, compatibility requirements, and engineering standards. These conditions give the verification system a clear basis for assessing the result.

When a check fails, the system can return the result to the agent for correction. The agent revises its implementation and submits the updated change for another evaluation cycle.

This creates a repeatable process where failures produce specific feedback. Engineers can devote more attention to ambiguous requirements, architectural trade-offs, and risks that automated checks cannot adequately assess.

Record actions and decisions

As automated verification expands, organizations also need records of how changes were handled.

An audit trail captures agent actions, verification results, decisions, and escalations. These records help engineers understand what an agent attempted, which controls were applied, and why a change proceeded or required intervention.

Traceability becomes particularly important when multiple agents work concurrently. If a service later fails, engineers need to reconstruct the changes and decisions that led to the problem.

Audit records also help teams improve their controls. Repeated failures may expose unclear specifications, inadequate tests, or policies that need adjustment. Information collected during verification can therefore improve future development work.

How the controls work together

Consider a development agent assigned to modify a service to meet a new requirement.

After implementing the change, the agent submits it for verification. The system assesses its potential impact, applies relevant security and architectural policies, and evaluates the implementation against the task’s acceptance criteria.

A failed check sends the change back for correction. The agent can revise its work and submit it for another evaluation. Once the checks pass, the next action depends on the organization’s approval requirements.

Routine changes may proceed through automated controls, while higher-risk work or exceptions require human review. Throughout the process, an audit trail records the actions and decisions involved.

Organizations can arrange these controls in different sequences to suit their engineering environments. Whatever the order, reviewers receive consistent information about the change, its requirements, verification results, and potential consequences. They can then focus on decisions requiring contextual knowledge rather than repeating routine checks.

Choose governance based on the consequences of a change

The same verification mechanisms can support different governance models.

A stage-gated workflow requires work to pass defined checkpoints before entering the next development stage. For instance, a change might need to satisfy testing and compliance requirements before becoming eligible for deployment approval.

These checkpoints establish consistent conditions for progression. They can apply equally to work produced by human developers and AI agents.

A risk-based workflow adjusts oversight according to the potential impact of a change. Lower-risk work can follow a more automated path, while changes with greater consequences receive additional testing or approval.

The appropriate model depends on regulatory requirements, product complexity, and organizational risk tolerance. A heavily regulated system may require formal approvals at specific stages. Another organization may allow greater automation when changes satisfy predefined risk conditions.

Bain’s April 2026 survey indicates that technology leaders expect selective autonomy to become more common than fully autonomous development.

Risk-tiered development means adjusting agent autonomy and oversight according to the consequences of the work. The survey suggests that many organizations expect to delegate more execution to AI while keeping different levels of control for different types of changes.

These figures describe anticipated operating models rather than the proportion of organizations already using each approach.

The survey also found that governance, safety, and risk controls ranked above model quality, data infrastructure, and platform investment as enablers for scaling agentic AI. Agentic AI refers to systems that can carry out multistep tasks and take actions toward assigned goals.

That ranking shows how much importance respondents place on controlling automated work as its scope expands. Bain’s underlying question allowed multiple selections, with the finding drawn from the top 10 of 15 options.

For engineering leaders, the investment implication is practical. As agents take on more work, organizations must become more precise about which changes can proceed automatically and which require human approval.

Amazon applies AI to review and validation

Amazon provides an example of AI moving into verification work itself.

The company has established a mandate to incorporate AI into every development system. Under that approach, AI reportedly handles up to 70% of code reviews, while customer validation cycles that previously took weeks now take days.

The review figure represents an upper level of AI participation. Human oversight remains part of the development process.

Amazon’s approach extends AI beyond implementation. Code review examines proposed changes for correctness and quality, while customer validation checks whether delivered functionality meets its intended requirements.

Both activities can slow delivery when implementation becomes faster. Applying AI to them expands the range of development work that automation can handle.

The reduction in customer validation time is particularly relevant because validation connects technical changes with confirmation that they meet customer needs. Shorter cycles reduce the delay between completing implementation and determining whether the result is ready to advance.

Amazon’s reported results show the potential scale of AI participation in downstream engineering activities. They also demonstrate why verification tools and governance need to be designed as part of the broader development process.

The development process must become a managed product

As agents take on implementation, testing, review, and validation, engineering leaders face a coordination problem that crosses organizational boundaries.

Traditional development processes often divide responsibility among product management, engineering, quality assurance, and deployment teams. Requirements move between groups, implementation enters review, and completed work advances through testing and release.

AI agents can handle several of these activities within one workflow. An agent may receive a specification, generate code, and run tests before an engineer examines the result.

This changes the purpose of existing handoffs. Some remain necessary for accountability, security, and independent evaluation. Others create delays when work could advance through an integrated process with appropriate controls.

Engineering leaders therefore need to manage the SDLC as a product, with an accountable owner, an improvement roadmap, performance measures, and regular feedback from its users.

Give the development system an accountable owner

Product ownership starts with responsibility for the performance of the complete development system.

An accountable development-system owner coordinates improvements to agent workflows, verification procedures, tooling interfaces, and handoffs between teams. The role needs enough authority to address constraints that span engineering functions.

For example, a team may have effective coding agents but face long delays in integration testing. Its development-system roadmap should then prioritize integration and verification capacity ahead of further coding automation.

The same reasoning applies when agents repeatedly produce changes that need clarification. Better task specifications and access to engineering knowledge may eliminate more downstream work than upgrading the coding model.

Engineers and reviewers provide essential feedback for these decisions. They can identify where agents lack context, where automated controls trigger unnecessary escalations, and where manual coordination causes delays.

The owner can use that information to improve specifications, adjust verification procedures, refine interfaces, and clarify responsibilities. Each change should address a constraint observed in the delivery process.

As agents become capable of more complex assignments, organizations can reconsider which activities belong within individual teams and which should rely on shared infrastructure. Product, engineering, quality assurance, and deployment responsibilities may become more closely integrated where that improves accountability and delivery performance.

Engineers are becoming coordinators of agent work

Changes to development-system ownership also reshape the responsibilities of individual engineers.

Bain’s survey respondents anticipate smaller engineering teams and nearly five times as many agents per team. These expectations describe a possible future operating model rather than an established industry-wide outcome.

More agents per team would make coordination increasingly important. Engineers would need to define assignments, establish requirements, supervise parallel work, and evaluate results across multiple automated activities.

They would also need to resolve exceptions. An agent may encounter conflicting requirements, an architectural trade-off, or a change whose consequences exceed its assigned authority. Human engineers must decide how to handle those situations.

Quality governance becomes part of the same responsibility. Engineers need to establish appropriate acceptance criteria, decide when risks require escalation, and determine whether automated evaluations reflect organizational standards.

These activities demand substantial technical expertise. Engineers remain responsible for understanding system behavior and making decisions that determine whether automated work is safe and useful.

Smaller teams may emerge as automation reduces the effort required for implementation and routine verification. But the immediate challenge is to combine human expertise and agent capacity in a process that reliably delivers software.

Measure performance across the delivery system

As the balance of work changes, productivity measurement must evolve with it.

Google’s DevOps Research and Assessment (DORA) framework provides established measures of software delivery performance. Metrics covering delivery speed and operational reliability help organizations assess whether their development processes produce useful outcomes.

Agentic development adds questions about how the work gets done. Engineering leaders need to distinguish human and agent contributions, understand how they interact, and determine whether automation improves delivery performance.

Counting completed agent tasks can reveal how extensively the technology is being used. But task volume alone cannot establish whether release cycles are shorter or software delivery has become more efficient.

Measurement therefore needs to connect implementation throughput with downstream outcomes. Delivery speed should be assessed alongside software quality, defects, technical debt, and operational risk.

A team may complete and deploy more changes while creating additional maintenance work. Failures introduced during development can later consume engineering capacity, reducing the benefit of faster implementation.

Risk and control effectiveness also need measurement. Leaders should know whether required checks are applied, how exceptions are handled, and whether automated verification catches problems before release.

Separating human and agent contributions within these measures helps identify where automation creates value. It can also reveal activities where greater agent output leads to more coordination or review work.

The findings should feed directly into the development-system roadmap. If coding throughput rises while release-cycle performance stays unchanged, the next investment should target the activity holding up delivery.

Measurement must continue to evolve as agent capabilities advance. Development-system owners need the authority to adjust workflows, responsibilities, and success measures as automation takes on more activities.

Shared agent infrastructure also matters for smaller teams

The coordination challenge extends beyond large engineering organizations. Smaller teams can encounter the same capacity constraints when automated development increases the number of changes flowing through their systems.

Craft Docs provides an example. Its engineering team adopted a shared platform for coordinating AI agents, supported by governance controls. After the adoption, the team reported a substantial increase in weekly issue throughput.

The figures show a major increase in the team’s reported activity. Issues are tracked units of development work, so weekly issue throughput measures how many such items the team completes during that period.

The shared platform gives the team a common way to coordinate agent activity. Rather than having every developer manage agents through separate arrangements, common infrastructure can establish shared workflows and governance controls.

For a small engineering organization, these capabilities become valuable when several developers delegate work at once. Agents still need clear requirements, and their changes still require appropriate verification and integration with other ongoing work.

Craft Docs’ reported throughput increase followed the adoption of its shared environment. The figures establish the scale of the change in completed issues, while the platform and governance model explain how the team organized its agent work.

Issue throughput remains a measure of activity. The size and complexity of an issue can vary, so the increase should be understood as an improvement in issue completion rather than a direct measure of quality-adjusted delivery. Defect rates, customer outcomes, and maintenance demands still matter when evaluating the broader result.

The example raises a practical infrastructure question for smaller organizations. A shared agent platform requires investment in coordination, controls, and maintenance. Those costs need to be weighed against the time developers would otherwise spend managing agents independently.

The decision depends on how often agents are used, how much work they perform concurrently, and how frequently their output needs shared verification. As agent activity grows, the economics of maintaining common infrastructure can change.

The same calculation applies to governance. A team with a few bounded agent assignments may be able to use its existing review procedures. As automated work spreads across repositories, services, and development stages, shared controls can reduce the effort of recreating policies and approval rules for each workflow.

Craft Docs shows why team size alone is an incomplete guide to the infrastructure AI-assisted development requires. The more useful questions concern the volume of concurrent work, the dependencies between changes, and the coordination needed to deliver them reliably.

Those factors should determine when a smaller engineering organization invests in shared agent infrastructure and how much governance that infrastructure must provide.

In conclusion

AI coding tools are increasing the amount of software engineering teams can produce, but faster implementation does not automatically translate into faster delivery. As agents take on more development work, testing, review, integration, and deployment become increasingly important constraints on productivity.

For technology leaders, the investment priority is shifting from individual coding tools toward the infrastructure needed to manage agent-driven development at scale. Structured specifications give agents the context to complete assignments correctly. Automated verification and risk-based governance help organizations handle higher volumes of changes without proportionally increasing human review effort. Shared infrastructure makes these capabilities available across engineering teams.

This transition also requires changes to how development is managed. Engineering leaders need clear ownership of the software development life cycle, performance measures that connect agent activity to delivery outcomes, and defined responsibilities for human oversight. The objective is not to remove engineers from the process, but to use their expertise where technical judgment, coordination, and accountability matter most.

The business case should ultimately be measured in delivery performance rather than code output. Shorter release cycles, consistent software quality, and lower coordination costs provide stronger evidence of value than the number of tasks agents complete.

Organizations that invest only in faster code generation risk moving work into downstream bottlenecks. Those that improve the entire development system will be better positioned to convert growing AI capabilities into sustained engineering productivity.