Article reader Listen + reading controls
Article reader
Preparing the reader…
Reading settings
Software productivity is a systems question¶
Anthropic's April 28 analysis of artificial intelligence (AI) use in software development finds that a substantial share of coding interactions appears automation-oriented. It also finds user-facing application work is common, suggesting some people use AI to build beyond their previous technical reach.
These are useful observations. They still do not tell a leader whether an engineering organization is more productive.
AI can reduce the time required to write, explain, test, and modify code. Software delivery, however, is a system of queues and dependencies. Accelerating one activity changes pressure elsewhere.
Local speed can create global delay¶
If developers produce changes faster, review queues may grow. If non-specialists can create applications, security and platform teams may inherit more systems to govern. If agents make broad changes, integration failures may become harder to diagnose. If more features enter production, operations and support absorb the consequences.
This is a version of a familiar operations problem: optimizing one station does not necessarily increase throughput across the whole system. Forsgren, Humble, and Kim's software-delivery research emphasizes system-level measures such as lead time, deployment frequency, change-failure rate, and recovery time. Lines of code and prompt counts are poor substitutes.
Measure the flow of value and evidence¶
An organization should evaluate AI-assisted development across several outcomes:
- time from validated need to working capability;
- escaped defects and security findings;
- review and rework burden;
- production reliability and recovery;
- maintainability and architectural coherence;
- developer learning and cognitive load;
- and user or mission outcomes.
The evidence should be segmented by task. AI may help a team write tests while hurting performance on unfamiliar architectural changes. Aggregate productivity claims can hide those differences.
Architecture becomes more important¶
When implementation becomes cheaper, the constraint shifts toward deciding what should exist and how it should fit. Clear interfaces, automated tests, development environments, documentation, and observability give agents and people the feedback needed to work safely. A tangled codebase does not become healthy because code is generated faster.
This is why platform engineering and knowledge infrastructure are part of the AI adoption strategy. Teams need paved roads that encode good defaults while preserving room for responsible judgment.
Preserve collective ownership¶
Software is maintained by communities over time. A generated change that only its requester can explain creates a future liability. Reviews should test comprehension, not merely style and correctness. Important decisions should remain in architecture records, issue discussions, and code history where others can recover them.
Brooks warned that software engineering is dominated by essential complexity as well as accidental difficulty. AI can remove a great deal of accidental work. It does not eliminate the need to understand the problem, coordinate expertise, and make tradeoffs under uncertainty.
The productivity opportunity is real. Capturing it requires leaders to look beyond individual speed. The question is whether the complete delivery system produces more valuable, reliable, and learnable software—not whether someone generated it in fewer keystrokes.
Sources and research trail¶
- Anthropic, “Anthropic Economic Index: AI's Impact on Software Development” (April 28, 2025).
- Forsgren, Humble, and Kim, Accelerate (2018).
- Faraj and Sproull, “Coordinating Expertise in Software Development Teams” (2000).
- Herbsleb and Grinter, “Architectures, Coordination, and Distance” (1999).