How AI changes the economics of software development

The productivity claims for AI coding tools are substantial and, in narrow terms, accurate. Tasks that took hours take minutes. Boilerplate that required careful attention gets generated in seconds. Junior engineers produce code at a pace that would have required significantly more experience a few years ago. The tools are genuinely useful.

The disconnect between the productivity claims and the actual economics of software development is that the claims are measured against the wrong cost center. The expensive parts of software development are not the parts that AI coding tools primarily accelerate.

Where the money actually goes

In a typical software organization, the distribution of engineering time breaks down roughly as follows: a significant fraction goes to meetings, coordination, and communication; another large fraction goes to understanding existing code, debugging, and investigation; some goes to review, testing, and quality assurance; and a smaller fraction than most people expect goes to writing new code from scratch.

AI coding tools primarily accelerate the last category: writing new code from scratch. The tools are genuinely impressive at this. They can generate a function from a docstring, complete a repetitive pattern across a file, suggest an implementation from a test case. The speed gains in this narrow category are real.

But if writing new code from scratch represents, say, 20-30% of an engineer’s time, and AI tools accelerate that activity by 50%, the improvement in overall productivity is 10-15%. That is meaningful but not transformative. The transformative gains require accelerating the activities that consume most of the time: understanding existing code, coordinating across teams, debugging complex systems, making good architectural decisions.

This is not a criticism of AI coding tools. They do what they do well. It is an observation about where the limits of their economic impact are, which matters for how organizations should allocate their investment and set their expectations.

The activities AI does not yet accelerate well

Understanding existing code. Most of an engineer’s time in a mature codebase is spent reading code rather than writing it. Understanding why a system behaves the way it does, what the original design intent was, where a bug is likely to be hiding: these require navigating a large, interconnected body of code and reasoning about it. AI tools can help with specific questions (“what does this function do?”) but do not yet substitute for the deep contextual understanding that experienced engineers develop through extended work on a system.

Coordination and communication. Software development is a team activity. Decisions about architecture, prioritization, and scope require people with different knowledge to reach shared understanding. The coordination cost grows with team size, organizational complexity, and the number of stakeholders who have legitimate interests in the outcome. AI tools do not reduce this cost in any meaningful way.

Debugging complex systems. Debugging at the system level (where a bug in a distributed system manifests far from its cause, or where an intermittent failure is caused by a timing condition that is hard to reproduce) requires a combination of systematic investigation, deep system knowledge, and intuition built from experience. AI tools can help with specific debugging tasks but do not yet substitute for the investigative process itself.

Architectural decision-making. The decisions that determine whether a system is maintainable, scalable, and correct over time are not primarily code-writing decisions. They are design decisions made before much code is written. AI tools can suggest patterns and flag obvious problems, but the judgment required to make good architectural decisions for a specific organization’s context is not yet well-served by current tools.

What does change

The economic impact that is real and underappreciated is not the productivity of individual engineers on individual tasks. It is the change in the ratio between the cost of producing code and the cost of maintaining it.

AI tools lower the cost of producing code significantly. A task that would have taken a senior engineer a day can be drafted in an hour. This is a genuine cost reduction. But it does not lower the cost of maintaining that code once it is in production. Maintenance costs are driven by complexity, not by how the code was originally written. Code generated quickly by an AI tool that is not carefully reviewed and integrated into the existing architecture creates the same maintenance burden as code written slowly by a junior engineer who did not understand the system.

The risk is that organizations respond to the lower production cost by producing more code, faster, without proportionally investing in the review, testing, and architectural work that determines the maintenance cost. The short-term productivity gain is real. The long-term maintenance cost increase is also real. Organizations that track the former without tracking the latter will be surprised when their velocity slows down in eighteen months as the accumulated complexity of rapidly-generated code begins to dominate engineering time.

The skill distribution shift

The economic model of software teams is changing in a way that is more consequential than the productivity gains on individual tasks.

AI tools are most useful to engineers who can evaluate the output they receive. A senior engineer using an AI coding tool can quickly assess whether the generated code is correct, whether it fits the existing architecture, and what edge cases it misses. A junior engineer using the same tool receives code they may not be equipped to evaluate. The tool increases their output volume without necessarily increasing their output quality.

This creates a shift in the value distribution of different skill levels. The activities that AI tools cannot perform well (architectural judgment, system understanding, code review, debugging complex failures) are predominantly senior-engineer activities. The activities that AI tools accelerate most significantly are predominantly junior-engineer activities. The result is that the economic gap between senior and junior engineers may widen rather than narrow, because the tools make the junior-level work more productive while leaving the senior-level work relatively unchanged.

For organizations, this has staffing implications. The teams that use AI tools most effectively are likely to be leaner at the junior level and require the same number (or more) senior engineers to maintain the judgment and review work that the tools cannot do. The naive prediction that AI tools will reduce total headcount assumes that the time spent writing code is the binding constraint. In most software organizations, it is not.

How to actually measure the economic impact

If the productivity gains from AI coding tools are real but narrower than claimed, the right way to measure them is against the activities they actually affect, not against total engineering output.

Measure the time from task specification to working, reviewed, deployed code. If AI tools are genuinely compressing the development cycle, this metric should improve. If it is not improving, the tools are accelerating one phase while adding friction elsewhere (longer review times, more debugging of generated code, more integration work).

Measure the defect rate in code produced with AI assistance versus without. If AI-generated code has a higher defect rate (because it is produced quickly without the careful consideration that slower production encourages), the productivity gain in production speed will be partially offset by the cost of defects in production.

Measure the maintenance burden of code produced with AI assistance over a 12-month horizon. Code that is easy to generate is not always easy to maintain. If AI-generated code accumulates technical debt faster than handwritten code, the long-term economics may be worse than the short-term productivity metrics suggest.

The honest accounting

AI coding tools are valuable. They are most valuable to engineers who are already skilled enough to evaluate and integrate their output effectively. They shift some cost from production to review and quality assurance. They do not change the fundamental economics of the activities that consume most of the time and cost in a mature software organization.

Organizations that treat AI coding tools as a headcount reduction tool will be disappointed. Organizations that treat them as a productivity tool for specific tasks, invest in the review and architecture work that makes generated code maintainable, and measure the right metrics will see genuine gains.

The tools are better than they were and will continue to improve. The activities they do not yet address well are the ones that matter most for the long-term economic health of a software organization. Keeping that distinction clear is the work.