November 5, 2026 
14 Min
AI coding tools are changing how software is developed. Developers can now generate implementations, write tests, refactor existing code, and explore unfamiliar codebases in a fraction of the time these activities previously required. As AI becomes part of everyday development workflows, engineering organizations are starting to reconsider how they measure productivity.
Traditional developer productivity metrics, including lines of code, commit counts, pull request volumes, and development velocity, were designed around observable engineering activity. While these metrics have always had limitations, AI-assisted development makes those limitations more significant. Code that previously required hours of manual effort can now be generated in minutes, weakening the relationship between development activity and actual engineering effort.
The challenge for engineering leaders is no longer simply measuring how much developers produce. It is understanding whether AI improves the efficiency, quality, and outcomes of the entire software development process.
Why Traditional Metrics Need a Different Interpretation in the AI Era
Engineering metrics have long played an important role in understanding software development performance. Metrics such as cycle time, delivery throughput, code churn, and review efficiency help organizations identify bottlenecks, monitor improvements, and make informed decisions about their development processes.
However, not all metrics serve the same purpose. Activity-based measurements, such as lines of code, commit counts, and pull request volumes, provide useful visibility into development activity but become misleading when treated as direct indicators of productivity.
AI makes this distinction even more important. Previously, producing substantial amounts of code generally required considerable manual effort. With AI, developers can generate the same amount of code much faster, weakening the relationship between code volume and engineering effort. Similarly, an increase in commits or pull requests may reflect greater coding capacity without necessarily indicating faster delivery or better outcomes.
The solution is not to abandon traditional engineering metrics, but to interpret them in the context of the entire software development lifecycle. By connecting development activity with delivery performance, code quality, and collaboration, organizations can distinguish between increased output and meaningful productivity improvements.
1. Lines of Code No Longer Reflect Development Effort
Lines of code (LOC) has always been a controversial productivity metric, but AI makes its weaknesses particularly obvious. When developers can generate hundreds of lines of code through a single prompt, code volume becomes an increasingly unreliable indicator of the effort required to implement a change.
Consider two developers working on comparable features. One manually writes 200 lines of code, carefully integrating the implementation into an existing system. The other uses AI to generate 800 lines, including additional abstractions, helper functions, and tests. Based on code volume alone, the second developer appears four times more productive. However, the generated implementation might be better structured and more thoroughly tested, or it might contain unnecessary complexity and duplicated logic. The number of lines tells us very little about which outcome is better.
AI also introduces a distinction between generating code and making that code usable. An implementation might be generated in minutes but require substantial time to understand, validate, modify, and integrate. If measurement stops at code generation, that additional engineering effort remains invisible.
LOC can still help engineering teams understand change size and review workload. What it cannot reliably establish, particularly in AI-assisted development, is how productive a developer has been.
2. More Commits and Pull Requests Don’t Necessarily Mean More Progress
Commit counts and pull request volumes are often used to understand how actively developers contribute to a project. AI coding tools can increase both by making it easier to generate implementations, tests, and smaller changes. However, higher activity does not automatically translate into more completed work.
Imagine a team that previously created 100 pull requests per week and now creates 160 after adopting AI coding tools. That represents a 60% increase in pull request volume, but it doesn’t establish that the team is delivering 60% more functionality. Some of those changes may be smaller, others may require additional corrections, and some may spend more time waiting for review.
This matters because every pull request creates work beyond its initial implementation. Changes must be reviewed, tested, integrated, and eventually deployed. If developers can produce changes faster than reviewers can process them, the review queue grows. Feedback takes longer, developers move between unfinished tasks, and the overall delivery process can become less predictable.
For example, a team producing 20 pull requests per day while processing only 15 will accumulate unfinished work, even though its coding activity appears to be increasing. The bottleneck has simply moved from implementation to review.
Commit and pull request metrics therefore need to be evaluated alongside completed work, review throughput, and delivery performance. A growing number of contributions is much more meaningful when those contributions can move through the development process efficiently.
The distinction is between generating development activity and making actual progress. AI can accelerate the former without necessarily improving the latter.
3. Faster Coding Doesn’t Always Lead to Faster Delivery
One of the most important changes AI introduces is the growing difference between coding speed and overall delivery speed. Software development involves more than implementation. Requirements must be understood, changes reviewed, tests executed, and releases deployed. Improving coding speed only affects one part of this process.
Consider a team where coding takes three days, waiting for review takes two days, review and rework require another day, and deployment takes two more days. The total cycle time is eight days. After adopting AI, coding time falls to one day, but review and rework increase slightly because generated changes require additional validation.
| Development phase | Before AI | After AI |
|---|---|---|
| Coding | 3 days | 1 day |
| Waiting for review | 2 days | 2 days |
| Review and rework | 1 day | 1.5 days |
| Deployment | 2 days | 2 days |
| Total cycle time | 8 days | 6.5 days |
In this hypothetical example, coding time improves by approximately 67%, while end-to-end cycle time improves by less than 19%. AI has delivered a genuine improvement, but its impact on overall delivery is considerably smaller than the coding metric suggests. Faster implementation creates bottlenecks in review, testing, and deployment, potentially offsetting some of the time saved during coding.
Organizations should also look beyond average values. Median cycle time can describe typical performance, while upper-percentile measurements reveal whether a smaller group of changes continues to experience significant delays. AI may improve the speed of routine work without addressing the complex changes responsible for the longest delivery times.
Ultimately, faster coding matters when it helps teams deliver working software faster, not simply when it reduces the time between starting implementation and opening a pull request.
4. AI-Generated Code Can Shift Effort From Coding to Review and Rework
AI coding tools can significantly reduce the effort required to produce an initial implementation. However, the generated code still needs to meet the same requirements for correctness, security, maintainability, and architectural consistency as manually written code.
Consider a developer who uses AI to generate an API endpoint in ten minutes. The implementation appears functional, but during review, the team discovers duplicated business logic, inconsistent authorization checks, and an inefficient database query. Correcting these problems requires additional coding, testing, and review. The initial implementation was fast, but the total engineering effort may not have decreased.
This is not an argument that AI-generated code is inherently lower quality. AI can also help developers write better tests, identify potential problems, and improve existing implementations. The point is that code generation speed alone cannot tell us whether the overall process has become more efficient.
These metrics measure related but different aspects of development. A change may require substantial manual refinement before its first review and then pass immediately. Another may need little initial intervention but undergo several rounds of corrections afterward. Looking at only one of these measurements would miss part of the picture.
The objective is to understand whether AI reduces the total engineering effort required to deliver reliable software, including the work involved in reviewing, correcting, and maintaining what it generates.
5. Individual Productivity Metrics Overlook Team-Level Impact
Traditional productivity measurement frequently focuses on individual developers because commits, pull requests, and code changes can be attributed to specific contributors. However, software engineering is a collaborative activity, and the value created by one developer often depends on the work of others.
AI makes this particularly important because it can change how effort is distributed across a team. A developer using AI might double the number of pull requests they create each week. From an individual activity perspective, this appears to be a significant productivity improvement. But if those changes require additional attention from senior engineers, part of the apparent gain may represent work transferred from implementation to review. AI-generated code can also create integration problems, increase maintenance responsibilities, or require other developers to investigate unexpected behavior. None of these additional costs may be visible in the original developer’s activity metrics.
Engineering organizations therefore need to consider individual contributions alongside team-level delivery performance, review participation, and collaboration. Review workload distribution can reveal whether increased coding capacity is creating additional pressure on particular contributors. Human intervention measurements can also provide insight into the effort required to make AI-assisted changes ready for delivery.
Developer experience adds context that engineering telemetry cannot always capture. AI may reduce repetitive work and improve focus for some developers while increasing verification responsibilities or context switching for others. Combining development metrics with direct feedback helps organizations understand these differences.
Individual metrics remain useful for identifying contribution patterns and opportunities for improvement. However, they should not be treated as independent measures of value when the outcome depends on the collective work of the team.
6. AI Adoption Is Not the Same as AI Effectiveness
As organizations invest in AI coding tools, they naturally want to know whether those investments are producing measurable results. This has increased interest in adoption rates, accepted suggestions, and the percentage of code generated by AI.
These measurements provide useful information about how AI is being used, but they don’t establish whether it improves productivity. A developer generating 70% of their code with AI is not necessarily more productive than someone generating 20%. The first may be working on repetitive implementation tasks, while the second handles complex architectural changes requiring extensive reasoning and relatively little code.
Even measuring the percentage of AI-generated code introduces challenges. A developer may generate an implementation, modify it manually, ask AI to refactor part of it, and make further changes before committing. Different attribution methods may classify the resulting code differently. Tracking accepted suggestions can miss code copied from external tools, while code similarity analysis may struggle to distinguish generated code from common programming patterns.
AI attribution is therefore useful, but its measurement method and limitations need to be understood. More importantly, attribution becomes valuable when connected to engineering outcomes.
Organizations should compare AI-assisted and non-AI-assisted work across delivery speed, rework, first-pass success, quality, and human intervention. However, these comparisons require care because developers may use AI more frequently for straightforward tasks than for complex changes.
Reliable comparisons should therefore account for differences in task complexity, developer experience, and repository characteristics wherever possible. Tracking results over time can help identify whether improvements persist as developers gain experience with AI tools and workflows evolve.
The goal is not simply to determine how extensively AI is used. It is to establish whether that usage produces better engineering outcomes, under what conditions, and with what tradeoffs.
What Should Engineering Organizations Measure Instead?
The limitations of traditional productivity metrics do not mean organizations need to abandon existing engineering measurements. Cycle time, throughput, code churn, review activity, and delivery reliability remain valuable. What needs to change is how these measurements are connected and interpreted.
For evaluating AI coding effectiveness specifically, five metrics provide a practical foundation:
| Metric | What it measures |
|---|---|
| Delivery Speed Improvement | Whether AI-assisted work reduces end-to-end delivery time compared with similar work without AI assistance. |
| Rework / Churn Rate | How frequently AI-assisted code requires subsequent modification, replacement, or correction. |
| First-Pass Success Rate | How often AI-assisted changes pass initial validation or review without additional corrections. |
| Quality / Defect Rate | Whether AI-assisted changes introduce more or fewer defects, quality issues, or reliability problems. |
| Human Intervention Rate | How much manual correction or refinement is required after AI generates code. |
Together, these metrics reveal whether AI improves delivery speed, reduces rework and manual intervention, and maintains code quality. Faster coding alone doesn’t guarantee higher productivity if the resulting changes require extensive corrections or additional reviews.
For example, an AI-assisted implementation may reduce coding time by 60%, but if it requires extensive manual correction and multiple review iterations, the actual productivity improvement may be considerably smaller. Conversely, high first-pass success and low intervention rates are encouraging, but they do not necessarily establish that AI improves delivery speed.
Broader engineering metrics, such as cycle time, review efficiency, and deployment frequency, provide context for understanding AI’s impact across the SDLC. To evaluate effectiveness reliably, organizations should compare similar AI-assisted and non-AI-assisted work against a baseline, accounting for differences in task complexity, developer experience, and repository characteristics.
Organizations should also combine engineering telemetry with developer feedback. Repository activity and delivery metrics reveal what is happening, while feedback can help explain why certain improvements or bottlenecks emerge.
Rather than searching for a universal productivity score, engineering leaders should focus on understanding where AI creates measurable improvements, where additional costs appear, and which changes can improve overall engineering performance.
From Measuring Activity to Understanding Engineering Impact
AI is changing the economics of software development. Generating code is becoming faster and less expensive, but reviewing, integrating, maintaining, and delivering software still requires engineering judgment and coordination.
This shifts the focus of productivity measurement. The most important question is no longer how much code developers can produce with AI. It’s whether engineering organizations can turn that increased coding capacity into better delivery outcomes without compromising quality.
At Valven, we approach this challenge by connecting engineering metrics across the software development lifecycle, combining development activity, delivery performance, code quality, AI usage, and developer feedback.
This helps engineering leaders move beyond isolated productivity numbers and understand where AI is improving engineering performance, where bottlenecks remain, and which changes can make the greatest difference.
