Guides
AI Strategy
How Should You Structure Software Engineering Capacity in the AI Era?
CH2 Solutions
.
10
min read
AI can increase how quickly your team builds. That makes where you apply human judgment more important, not less.
LEADERSHIP CHALLENGE
If AI allows your team to build faster, where should your engineering capacity go?
For years, engineering capacity planning was largely a question of people and time.
How many engineers do we have? How much can they build? How much work is on the roadmap?
AI is changing that equation.
As engineers use AI to write code, generate tests, troubleshoot problems, create documentation, and accelerate other parts of development, the capacity of some kinds of engineering work can increase substantially.
But increasing one kind of capacity doesn’t automatically increase the capacity of the entire organization.
Someone still needs to decide what should be built. Someone needs to make architectural decisions, understand the implications of those decisions, validate that what was produced actually works, manage security and risk, integrate new capabilities into existing systems, and determine whether the result solves the intended business problem.
And the impact of AI isn’t uniform. It may dramatically accelerate some work, have little effect on other work, and in some contexts introduce additional review or coordination.
If implementation accelerates while those other capabilities don’t, the bottleneck simply moves.
That changes the capacity conversation.
The question is no longer only:
How many developers do we need?
Increasingly, it is:
What capabilities does this team need, and where should we concentrate human expertise and judgment?
Executive Summary
AI-assisted software development is changing the capacity of engineering organizations, but its impact is not distributed evenly across the software delivery lifecycle.
Development teams may be able to generate code, tests, documentation, prototypes, and potential solutions faster. In the right context, that can increase implementation capacity significantly.
Other parts of the system may not accelerate at the same rate.
Product decisions still require understanding customers and business priorities. Architecture requires judgment about tradeoffs and long-term consequences. AI-generated output needs validation. Security and compliance requirements remain. New functionality must integrate with existing systems. Production environments still need to be operated and supported.
The impact isn’t uniform. AI may dramatically accelerate some work, have little effect on other work, and in some contexts introduce additional review or coordination. That makes understanding where capacity is actually changing more important than assuming a universal productivity gain.
As one part of the development process becomes faster, constraints can move elsewhere.
This makes capacity planning increasingly a question of skills distribution rather than headcount alone.
Technology leaders need to understand where human expertise creates the most leverage, which activities AI can accelerate, where additional review or oversight is needed, and whether the current team has the right mix of capabilities for the roadmap ahead.
The goal isn’t to maximize how much code the organization can produce.
It’s to build an engineering organization capable of turning increased development speed into better business outcomes.
BUILD
Create faster
DECIDE
Apply judgment
VALIDATE
Verify quality
INTEGRATE
Connect systems
OPERATE
Run reliably
AI accelerates work unevenly. Capacity planning means finding where the constraint moves next.
Key Takeaways
AI changes capacity unevenly. Productivity gains vary by task, developer, codebase, team, and organizational environment.
More implementation capacity can move the bottleneck. Faster coding does not automatically accelerate product decisions, architecture, validation, integration, security, or operations.
Skills distribution matters more as the work changes. Leaders need to determine where human expertise and judgment create the most leverage.
More output is not the same as better delivery. Engineering performance should be evaluated through outcomes, quality, stability, and the team’s ability to turn work into business value.
Human judgment becomes more important, not less. Engineers increasingly need to direct AI-assisted work, evaluate output, understand the broader system, and recognize when a generated solution is not good enough.
Find the constraint before adding capacity. The right answer may be more developers, but it may also be architecture, QA, product, security, AI expertise, integration, or a different seniority mix.
What does engineering capacity mean in the AI era?
Engineering capacity in the AI era is the combination of people, skills, judgment, tools, and organizational capabilities available to move software from idea to reliable business outcome.
Historically, capacity planning often focused heavily on engineering headcount and implementation time. AI-assisted development makes that view less complete because it can change the amount of work an engineer can perform in some activities without changing every other constraint in the delivery system.
A useful way to think about capacity is across five areas:
Build: creating code, tests, documentation, prototypes, integrations, and other implementation artifacts.
Decide: determining what to build, how to build it, which tradeoffs are acceptable, and which technical approaches support the business over time.
Validate: determining whether software is correct, secure, reliable, maintainable, and actually solves the intended problem.
Integrate: connecting new capabilities to existing products, platforms, data, workflows, architecture, and business processes.
Operate: deploying, monitoring, securing, supporting, governing, and improving software in production.
AI can affect each of these areas differently. Effective capacity planning means understanding where capability has increased, where constraints remain, and whether the team’s skills distribution still matches the work ahead.
How should you redistribute engineering capacity as AI changes the work?
Start by looking at where work is actually waiting.
If engineers are waiting for implementation capacity, additional development resources may still be the answer.
But if developers are producing work faster than the organization can make product decisions, review architecture, validate output, resolve security questions, integrate systems, or move software safely into production, adding more implementation capacity may make the imbalance worse.
Look for signals such as:
Work is being built faster than it can be reviewed.
Senior engineers are becoming decision bottlenecks.
Architecture decisions are being deferred because experienced people don’t have enough time.
AI-generated code is increasing review, testing, or remediation work.
QA and validation aren’t keeping pace with development.
Teams can prototype AI functionality quickly but struggle to integrate it into production systems.
Product decisions can’t keep pace with engineering execution.
Security, governance, or compliance reviews are delaying releases.
Engineers are producing more output, but delivery outcomes aren’t improving proportionally.
The team’s historical mix of roles no longer matches the capabilities required by the roadmap.
These are not necessarily signs that AI isn’t creating value.
They may be signs that the organization’s capacity needs to be redistributed.
The appropriate response could be additional engineers. It could also mean adding architecture expertise, strengthening QA, changing the seniority mix, improving product capacity, adding AI-specific expertise, automating another part of the delivery system, or removing work that no longer deserves engineering attention.
Find the constraint before adding capacity.
Leadership Lens
One of the risks of AI-assisted development is that productivity becomes confused with output.
More code is easy to measure.
Better engineering is harder.
A team can produce significantly more code without increasing the rate at which the organization delivers valuable, reliable software. Increasing implementation output without increasing the organization’s ability to evaluate and absorb that output can simply create more work elsewhere.
That is why technology leaders should resist applying yesterday’s engineering ratios to an AI-enabled organization.
The right team structure may change.
Some teams may need less capacity devoted to repetitive implementation and more expertise in architecture, integration, validation, AI system design, security, or technical decision-making. Some software engineers will evolve toward work that combines development with AI orchestration and system design. Others will use AI to increase what they can accomplish within existing roles.
The engineer’s value increasingly isn’t just the ability to produce code. It is the ability to direct the work, evaluate what was produced, understand the broader system, make good tradeoffs, and know when the output isn’t good enough.
There probably won’t be one universal model.
The important thing is to design the team around the work rather than preserve a historical distribution of roles because that’s how software organizations have always been structured.
AI gives us an opportunity to reconsider that structure.
The goal shouldn’t be to build the same way with fewer people. It should be to build a stronger engineering organization with a different distribution of human expertise.
FAQ
Does AI mean software engineering teams need fewer developers?
Not necessarily. Current research does not support a universal formula for reducing engineering headcount because developers use AI. Productivity effects vary by task, experience level, codebase, tools, and organizational environment. AI may reduce the effort required for some implementation work while increasing the importance of architecture, review, validation, integration, security, and other capabilities. Leaders should evaluate how the work is changing before making assumptions about team size.
How is AI changing software engineering roles?
AI is shifting some engineering work away from producing every artifact manually and toward directing, evaluating, integrating, and improving AI-assisted output. Engineers may spend more time defining problems, making architectural decisions, reviewing generated code, testing assumptions, integrating systems, and managing technical tradeoffs. The exact shift will vary by team and product.
What skills do software engineering teams need in the AI era?
Traditional software engineering fundamentals remain important, but teams may need a different distribution of skills. Architecture, system design, AI orchestration, model and agent integration, evaluation, security, data, QA, product judgment, and the ability to review AI-generated output can become more important as implementation accelerates. Strong engineers also need enough technical depth to recognize when an AI-generated solution is incomplete, unsafe, or inappropriate for the broader system.
What is an AI architect?
AI architect is an emerging role rather than a universally standardized job title. In practice, it often describes someone responsible for designing how AI capabilities fit into a larger product or technology environment. That can include selecting models and tools, designing agent or retrieval architectures, integrating AI with existing systems and data, establishing evaluation and guardrails, addressing security and governance, and making tradeoffs among cost, reliability, performance, and business value.
How should leaders measure engineering capacity when developers use AI?
Avoid relying on code volume or individual activity as the primary measure of capacity. Look at the entire delivery system: how quickly useful work moves from idea to production, where work waits, quality and stability, review and remediation effort, and whether the team is delivering better outcomes. AI can increase output in one stage while creating a new constraint somewhere else.
How do you identify the next bottleneck as AI increases development speed?
Follow the work. Look for queues, delays, repeated handoffs, overloaded senior people, slow reviews, unresolved architecture decisions, QA backlogs, integration problems, security gates, and work that reaches production more slowly than it is created. The next capacity investment should address the constraint that is limiting the system, not simply the activity where AI is producing the most visible output.
Sources and Further Reading
DORA — 2025 State of AI-assisted Software Development
Research into how AI adoption interacts with software delivery, organizational systems, team performance, developer effectiveness, and the underlying capabilities of technology organizations.
Microsoft Research — The SPACE of AI: Real-World Lessons on AI’s Impact on Developers
Research showing that AI’s impact on developer productivity varies by task, individual, team adoption, and working environment, with particular benefits in some routine development activities.
Randomized field experiments involving thousands of software developers examining how access to generative AI coding tools affected completed development tasks.
METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
A randomized study of experienced open-source developers working in mature repositories that provides an important counterpoint to assumptions that AI produces universal productivity gains.
