For most of software engineering’s history, writing and debugging code consumed the largest share of feature development.
That is rapidly changing.
I have spent 2026 fully embracing agentic coding as an engineering manager on a product development team. I have adopted coding agents in my own work, guided my team through adopting them, experimented with different workflows, and pushed on the boundaries of how much more software we can deliver.
The productivity gains are real.
Coding agents can explore a repository, identify existing patterns, plan a change, write the implementation, generate tests, update APIs and data models, run the test suite, refactor existing code, and open a pull request. Depending on the complexity of the task and how closely the engineer stays involved, work that once took days can now be completed in minutes or hours.
But this acceleration has introduced a new tension.
A prototype that once took a week can now be demonstrated in an afternoon. A feature can appear nearly complete after a few hours of agent-assisted development. Engineering leaders and product stakeholders understandably look at that progress and ask:
Why can’t we ship it just as quickly?
The answer is that coding agents have accelerated implementation more than they have accelerated software delivery.
The agent can produce a plausible implementation in an afternoon. That does not mean the feature is an afternoon away from production.
In mature software systems, the work that remains after the initial implementation is often the work that determines when (and whether) the feature can safely reach customers.
AI has accelerated the first 80% of feature development. The next major productivity gains will come from compressing the stubborn final 20%: integration, missing requirements, cross-team dependencies, code review, validation, deployment, observability, and organizational decision-making.
AI Has Changed Where the Work Happens
Before coding agents, a typical feature-development process looked something like this:
Product defined a feature and wrote a product requirements document. Engineering translated that document into a technical design, gathered feedback, received approval, and decomposed the work into individual tickets.
The team estimated those tickets, assigned them to engineers, and began implementation.
Engineers then had to research the existing codebase, understand the relevant architecture, determine where the new behavior belonged, write and debug the code, create tests, integrate the change with the surrounding system, validate it in a shared environment, and eventually release it to production.
Every stage mattered, but implementation was frequently the largest and most visible portion of the work.
Coding agents have compressed much of that implementation phase. They can explore a repository, recognize existing patterns, propose an implementation plan, modify code across several layers, generate tests, run validation, and prepare a pull request.
Depending on the complexity of the change and how closely the engineer remains involved, work that once took days can now be completed in minutes or hours.
Then the agent finishes, the engineer begins functional testing, and the real constraints emerge.
The endpoint the implementation depends on does not return all the required data.
A small user-interface change actually requires a new backend capability.
The product specification does not explain what should happen in an important edge case.
The change affects another service owned by a different team.
The code works locally but fails in a shared environment.
The pull request is complete, but the necessary reviewers are already overloaded.
The feature is approved, but the next production release is two weeks away.
This is where the sense of acceleration comes to a screeching halt.
The code was generated quickly. The system surrounding the code was not designed to move at the same speed.
The Old 80/20 of Software Development
Historically, engineering organizations often treated implementation as the primary unit of productivity.
We asked questions such as:
- How many tickets were completed this sprint?
- How many story points did the team deliver?
- How quickly could an engineer implement a feature?
- How many bugs were resolved?
- How much work moved from “in progress” to “done”?
This model was imperfect, but it made some intuitive sense when implementation itself was slow.
A rough mental model might have been:
80% implementation and 20% everything required to turn that implementation into a production feature.
That was never a precise measurement. It simply reflected where much of the hands-on effort, attention, and perceived difficulty lived.
Writing software was expensive. The processes around it were treated as smaller administrative costs.
AI coding agents are changing that ratio.
The New 80/20 of Software Engineering
Coding agents have not eliminated the software development lifecycle. They have compressed the part that historically consumed most of an engineer’s hands-on-keyboard time.
What remains is not necessarily harder than it was before. It is simply no longer hidden behind days or weeks of implementation.
The stubborn final 20% includes:
- Missing or ambiguous requirements
- Undocumented system behavior
- Hidden technical dependencies
- Integration with existing services
- Changes spanning multiple repositories
- Backward compatibility
- Data migrations
- Security and authorization
- Cross-team coordination
- Code review cycles
- Environment-specific failures
- Functional validation
- Deployment windows
- Production observability
- Organizational decision-making
These constraints now account for a much larger share of elapsed delivery time.
If implementation once took eight days and the remaining delivery work took two, implementation dominated the schedule.
If an agent reduces those eight days to one afternoon while the remaining work still takes two days (or two weeks) the surrounding system now determines almost the entire timeline.
That is the new 80/20.
Writing code is becoming fast and abundant. Context, verification, attention, and coordination are becoming the scarce resources.
Why the Final 20% Feels Larger
The final 20% has not necessarily grown in absolute terms. It has become more visible because the work before it has shrunk.
If implementation once took eight days and the remaining delivery work took two, implementation dominated the schedule.
If an agent reduces those eight days to one afternoon while the remaining work still takes two days (or two weeks) the surrounding constraints now determine almost the entire delivery timeline.
Several effects make this especially noticeable.
Rapid Prototypes Reveal Missing Requirements
One of the benefits of coding agents is that they dramatically reduce the cost of creating something concrete.
Instead of debating an abstract specification for a week, a team can build a working prototype and put it in front of stakeholders almost immediately.
That is valuable. A working feature often exposes gaps that no product requirements document could have predicted.
Stakeholders can see:
- Which interactions feel awkward
- Which states were not considered
- Which data is missing
- Which assumptions were incorrect
- Which parts of the experience need refinement
- Which “small” requests imply much larger system changes
Rapid prototyping improves the quality of product discovery, but it can also create the appearance that the feature is nearly finished when it has actually just entered a new phase.
The prototype is not evidence that all of the requirements were correct. It is often the mechanism through which the missing requirements are discovered.
AI reduces the cost of getting the first version wrong. That is a significant improvement. But the resulting cycles of clarification, refinement, and rework still affect delivery time.
Local Correctness Is Not System Correctness
Coding agents are strongest when the problem is contained within a legible codebase.
They can inspect the files they have access to, recognize established patterns, and create an internally coherent implementation.
Production systems, however, are rarely defined by one repository alone.
A change may depend on:
- A backend service in another repository
- An event schema owned by another team
- A production-only configuration
- An undocumented API consumer
- A historical data migration
- An external vendor
- A permission model encoded across several systems
- Operational knowledge that lives only in an engineer’s memory
The agent may produce code that compiles, passes its new tests, and looks convincing in isolation while still being incomplete in the context of the larger system.
This is one of the central limitations of AI-assisted software development: agents can reason about the context they can access, but mature systems are often shaped by context that has never been made explicit.
Code-Rich, Reviewer-Poor
Code review has become one of the clearest bottlenecks in our agentic development workflow.
When every engineer can produce more code, code owners and senior reviewers inherit more pull requests to evaluate.
That results in:
- More changes moving concurrently
- Larger pull requests
- More requests competing for reviewer attention
- Greater cognitive load
- Increased review fatigue
- A higher risk of plausible but incorrect code
- More pressure to approve changes quickly
The organization can become code-rich and reviewer-poor.
AI-assisted code review can help. Agents can summarize changes, identify common problems, check for missing tests, enforce conventions, and flag deviations from established patterns.
But human review remains essential in large, mission-critical systems.
A reviewer must still determine whether the change:
- Solves the correct problem
- Meets the actual requirements
- Fits the architecture
- Reuses existing systems appropriately
- Introduces security or privacy risks
- Handles failure modes
- Can be operated safely in production
The review process must therefore become more intentional.
Not every concern deserves equal weight.
We should maintain a high bar for:
- Correctness
- Requirement coverage
- Security
- Test coverage
- Appropriate reuse of existing components
- Architectural fit
- Production safety
We can lower the amount of human attention spent on:
- Formatting
- Styling preferences
- Naming conventions that can be automated
- Minor paradigmatic disagreements
- Issues that a linter or review agent can reliably enforce
Human attention should be reserved for decisions that require human judgment.
Human Processes Do Not Automatically Accelerate
A feature may be implemented in two hours and then spend:
- Two days waiting for code review
- A day waiting for product clarification
- Three days waiting for another team
- A week waiting for environment access
- Two weeks waiting for a release window
Generating code faster does not shorten a queue elsewhere in the system.
In fact, faster implementation can make those queues worse by pushing more work into them.
If every engineer doubles their implementation throughput but the number of reviewers, product stakeholders, QA engineers, and deployment windows remains fixed, the team has not doubled its delivery throughput.
It has increased the amount of unfinished work waiting inside the system.
This distinction is critical:
Engineering output is not the amount of code produced. It is the amount of customer value safely delivered.
Deployment Cycles Become an Albatross
Our team originally practiced continuous deployment.
As the system, organization, and volume of changes grew, we eventually introduced two-week release cycles. That gave QA time to validate a growing number of changes, expand automated integration coverage, and reduce the risk of regressions reaching customers.
At the time, that tradeoff made sense. The cost of production failures was high, and our ability to diagnose and correct them was slower.
Agentic coding changes part of that equation.
When teams can diagnose problems and ship fixes more quickly, long release cycles increasingly become an artificial constraint on feature velocity.
The answer is not to become careless. It is to make deployments smaller, safer, more observable, and more reversible.
That means investing in:
- Comprehensive feature flags
- Frontend and backend gating
- Progressive rollouts
- Automated deployment
- Strong integration testing
- Real-time observability
- Rapid rollback
- Clearly defined shutoff mechanisms
- Cleanup tickets for temporary flags and transitional code
The goal should be:
Deploy quickly, observe immediately, fix rapidly, and retain the ability to shut a feature off safely.
A team capable of generating software continuously but capable of releasing only every two weeks has optimized the wrong part of the system.
Where the Next Productivity Gains Will Come From
Our team still measures success in terms of features delivered and their impact on business objectives.
Code is a means to that end.
We want to capture more of the productivity gains that agentic coding makes possible, but doing so requires focusing beyond code generation.
The next phase of our work is centered on compressing the final 20%.
Better Requirements and Agent-Ready Context
Coding agents perform better when the problem is explicit and the system is legible.
We are investing in better product requirements, clearer acceptance criteria, clickable prototypes, and technical context documents that engineers can hand directly to agents.
Useful context includes:
- Expected behavior
- Important edge cases
- Permissions and access rules
- Existing components that should be reused
- Relevant services and repositories
- API contracts
- Failure modes
- Observability expectations
- Rollout plans
- Rollback plans
This does not mean every feature requires a massive specification.
It means resolving the questions most likely to create expensive interruptions after implementation begins.
Documentation increasingly serves two audiences: the humans who maintain the system and the agents that help modify it.
Feature Flags Across Every Surface
Feature flags allow teams to separate deployment from release.
A feature can be deployed without immediately exposing it to every customer. It can be tested in production, enabled for internal users, rolled out to a percentage of customers, and disabled quickly if problems emerge.
For that model to work, gating must cover the entire feature surface:
- Frontend experiences
- Backend behavior
- Scheduled jobs
- Event consumers
- Data migrations where possible
- External integrations
Temporary flags also create long-term maintenance costs, so every epic involving feature gating should include cleanup work from the beginning.
More Review Capacity and Shared Authority
When review becomes the bottleneck, the organization needs more people capable of safely approving changes.
That means:
- Developing more code owners
- Distributing architectural knowledge
- Giving engineers broader ownership
- Training reviewers to focus on high-risk concerns
- Maintaining appropriate approval requirements
- Avoiding dependence on one or two senior engineers
- Using merge queues to keep approved changes moving
Shared authority is not the same as lowering standards.
It means ensuring that quality and decision-making capacity scale alongside implementation capacity.
Agent-Assisted Review
Coding agents should not only generate code. They should participate throughout the delivery lifecycle.
Review agents can help:
- Summarize pull requests
- Compare changes with established patterns
- Identify missing tests
- Flag likely regressions
- Detect unrelated changes
- Check acceptance criteria
- Highlight risky migrations
- Enforce conventions
- Generate reviewer checklists
These tools can reduce the volume of mechanical review work so humans can focus on correctness, architecture, product intent, and operational risk.
Continuous Integration and Deployment
Faster code generation increases the importance of fast verification.
Teams need:
- Reliable automated tests
- Fast CI pipelines
- Contract tests between services
- Ephemeral test environments
- Automated migration validation
- Visual regression testing
- Merge queues
- Progressive deployment
- Automated rollback mechanisms
An agent’s speed matters only when the organization can quickly determine whether its output is correct.
Observability as Part of the Agentic Workflow
Generated code should not disappear into production and wait for a customer to discover its failures.
We are increasing observability and integrating operational tools such as Sentry and Grafana into the agentic workflow.
Agents should be able to help engineers:
- Inspect errors
- Query logs
- Review traces
- Compare metrics before and after deployment
- Identify anomalous behavior
- Correlate failures with recent releases
- Suggest likely causes
- Validate whether a fix worked
The loop should extend beyond writing code:
Implement, deploy, observe, diagnose, correct, and validate.
Shared Responsibility for Production Quality
As deployment throughput increases, teams need a clear model for responding to issues.
Bug fixes should be a shared engineering responsibility, with on-call engineers empowered to prioritize production problems immediately.
Fast delivery requires fast recovery.
Teams should not treat post-release issues as interruptions to the “real” roadmap work. Operating and improving released software is part of delivering the feature.
Greater Product and UX Autonomy for Engineers
Coordination latency becomes especially expensive when every small product decision requires another meeting or approval cycle.
Engineers working with agents should have enough context and authority to make reasonable product and UX decisions within established boundaries.
The mindset should favor iteration:
- Make the best decision available
- Ship behind a flag
- Observe behavior
- Gather feedback
- Refine quickly
Not every uncertainty needs to halt implementation.
The goal is not to eliminate product collaboration. It is to prevent low-risk decisions from waiting unnecessarily in organizational queues.
Measuring Feature Velocity in the AI Era
Traditional sprint metrics become even less useful when agents can produce implementation output at dramatically different rates.
Story points, ticket counts, lines of code, and pull request volume tell us little about whether customers are receiving value faster.
The more important question is:
How long does it take for a feature to move from an approved product specification into a customer’s hands?
From there, teams should examine the entire delivery pipeline:
- How long does implementation take?
- How long does a pull request wait for review?
- How many review cycles does it require?
- How frequently are requirements reopened?
- Where does work spend time waiting?
- How often do hidden dependencies appear?
- How frequently do integration failures occur?
- How long does validation take?
- How quickly can a change be rolled back?
- How much rework occurs after the initial implementation?
- How many bugs or support requests appear after release?
- How quickly are those issues resolved?
- How much time passes between merge and production deployment?
The objective is not to maximize the amount of work entering the system.
It is to minimize the amount of time valuable work spends trapped inside it.
The Next Era of AI-Assisted Software Development
The first phase of AI engineering productivity has focused on code generation.
Organizations ask:
- How much of our code is generated by AI?
- How many engineers are using coding agents?
- How many more pull requests are we creating?
- How quickly can an agent complete a ticket?
Those questions are understandable, but they focus on the part of the lifecycle that is already becoming cheap.
The next era will focus on:
- Generating clarity around requirements
- Making organizational context accessible
- Improving product and UX feedback loops
- Accelerating code review
- Automating verification
- Reducing integration friction
- Shortening deployment cycles
- Increasing observability
- Reducing coordination latency
- Making releases continuous and safe
We may already be approaching the point where some teams can generate code faster than they can identify and define valuable features.
That does not make engineers less important. It changes where engineering judgment creates the most leverage.
The strongest engineers will not merely be the people who can generate the most code with agents.
They will be the people who can:
- Define the right problems
- Recognize incomplete requirements
- Understand system-wide consequences
- Evaluate generated implementations
- Design reliable verification loops
- Reduce organizational friction
- Turn changes into dependable production outcomes
AI coding agents have accelerated the first 80%.
Now the real opportunity is redesigning the final 20%.