By ByteBot
66% of developers don’t believe the metrics used to measure their productivity actually reflect their real contributions—an extraordinary vote of no confidence revealed by JetBrains’ 2025 survey of 24,500+ developers across 194 countries. Organizations have proliferated frameworks trying to solve this crisis: DORA metrics for delivery performance, SPACE for holistic balance, DevEx for developer experience, and now DX Core 4 to unify all three. Yet the trust gap persists, exposed dramatically by the 2024 DORA report‘s finding that every 25% increase in AI adoption decreased team delivery throughput by 1.5% and stability by 7.2%—even as individual developers reported productivity gains. The disconnect is clear: we’re measuring the wrong things, or perhaps measurement itself is the problem.
The AI Paradox: When Individual Gains Meet Team Slowdowns
The 2024 DORA report documented a striking paradox that exposes how fundamentally broken developer productivity metrics have become. As AI adoption increased by 25%, individual developers reported 2.1% productivity gains and 2.6% higher job satisfaction—but team-level delivery throughput decreased by 1.5% and stability dropped by 7.2%. For the second consecutive year, DORA’s research showed AI tooling correlating with worsened software delivery performance, not improved. Gene Kim, DORA co-founder, called it “the DORA 2024 anomaly” in his 2025 paper, yet the pattern persists.
The numbers make the paradox stark: 85% of developers regularly use AI tools, 62% rely on AI coding assistants, and 89% save a minimum of 1 hour weekly—with 20% reclaiming a full workday. Individual developers are measurably faster. Yet delivery metrics at the team level declined. Consequently, if traditional metrics like deployment frequency and lead time can show teams slowing down while every individual speeds up, what are those metrics actually measuring? The answer: activity (code written, PRs submitted, commits made) not outcomes (value delivered, problems solved, customer needs met). Therefore, when the map contradicts the territory this dramatically, the map is wrong.
We Measure Code, But Developers Don’t Code
IDC’s February 2025 research revealed developers spend just 16% of their time on application development—yet the vast majority of developer productivity metrics (velocity, story points, lines of code, PR count) measure only code output. The remaining 84% of developer time goes to operational tasks like CI/CD setup and infrastructure monitoring, security work (which jumped from 8% to 13% year-over-year, the largest single shift), documentation, testing, deployment, meetings, and context switching. Organizations measure the minority of work and miss the majority of value.
The disconnect deepens when you examine what developers themselves say matters. JetBrains’ detailed productivity research found 89% of developers report non-technical factors—communication quality, collaboration effectiveness, peer and manager support, actionable feedback—influence their productivity. However, 51% are measured primarily on technical output alone. Furthermore, it’s the equivalent of evaluating a doctor based only on time spent performing surgery while ignoring diagnosis, patient communication, and post-operative care. The 16% coding reality proves traditional metrics fundamentally misunderstand the job being measured.
When Metrics Become Targets, They Lose Meaning
Every major productivity metric is gamed at scale. Developers inflate story points to protect velocity targets (“this is probably a 3, but let’s call it 5 to build in slack”). Moreover, they write verbose code with unnecessary line breaks to boost lines-of-code counts, knowing good code often means less code through effective refactoring. Similarly, teams avoid complex-but-valuable work that might slow PR throughput in favor of easy point gains. GitClear documented 17 distinct gaming strategies across popular metrics, turning what should be diagnostic tools into what one LinearB analysis calls “shared fiction.”
Goodhart’s Law states “when a measure becomes a target, it ceases to be a good measure”—and developer productivity metrics prove it daily. Gaming isn’t a peripheral problem that better enforcement can solve; it’s the inevitable outcome of using metrics for performance evaluation. Therefore, when developers optimize for the measurement instead of the outcome, the measurement becomes useless. Additionally, the 66% trust gap exists because developers know they game the metrics, making them feel dishonest while being evaluated on dishonest measures. The system creates its own illegitimacy.
Framework Proliferation: Fixing or Repeating Mistakes?
The industry’s response to broken metrics has been framework proliferation. DORA metrics emerged in 2015 focusing on delivery performance: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. When DORA’s narrow system-level focus missed developer experience, the SPACE framework arrived in 2021 with five holistic dimensions (Satisfaction, Performance, Activity, Communication, Efficiency). When SPACE proved too vague to implement consistently, DevEx research in 2022-2023 emphasized developer experience surveys. Now DX Core 4 has launched to unify all three into four balanced dimensions.
Adopted by 300+ companies, DX Core 4 achieved measurable outcomes: 3-12% efficiency gains and 14% more R&D time spent on features rather than maintenance. The framework’s four dimensions—Speed (diffs per engineer, lead time), Effectiveness (Developer Experience Index via 14-question survey), Quality (change failure rate), and Impact (percentage of time on new capabilities, revenue per engineer)—address the limitations of predecessors. DORA was too narrow (system performance only), SPACE too abstract (pick your own metrics from five dimensions), DevEx too isolated (developer satisfaction without business impact). Consequently, DX Core 4 attempts comprehensive balance.
Yet fundamental questions remain: Is this the solution, or just the next framework that’ll be gamed when metrics become targets? The Developer Experience Index, being survey-based, is harder to manipulate than velocity counts. Similarly, revenue per engineer ties engineering directly to business outcomes. Nevertheless, gaming is creative. When the pressure to hit targets meets the ambiguity of knowledge work, developers find ways to optimize for measurements that diverge from actual value. The track record suggests skepticism is warranted.
What Developers Actually Want: Transparency Over Dashboards
JetBrains’ 2025 survey revealed what developers prioritize: transparency in how they’re evaluated, constructive and timely feedback, clear goal articulation, quality of internal collaboration, and communication effectiveness. Technical managers echo this, advocating for twice as much focus on communication issues and nearly twice the investment in technical debt reduction compared to current company allocations. However, as JetBrains notes, “most companies don’t have specialist roles dedicated to developer productivity”—responsibility falls on already-overloaded team leads who lack the expertise and bandwidth to implement sophisticated measurement frameworks.
The disconnect is striking. Developers don’t want more sophisticated dashboards showing velocity trends and story point burndowns. Instead, they want meaningful feedback about whether their work creates value, clear expectations about what “good” looks like, and trust that evaluation reflects their actual contributions rather than easily-gamed proxies. When 66% reject current metrics as inaccurate representations of their work, the solution isn’t more measurement sophistication—it’s alignment between what’s measured and what developers believe creates value. Activity metrics (PRs, commits, lines of code) will never capture the problem-solving, collaboration, and strategic thinking that separate good developers from mediocre ones.
Key Takeaways
- 66% of developers don’t trust productivity metrics to reflect their real contributions, according to JetBrains’ 2025 survey of 24,500+ developers—a crisis of legitimacy in how we measure knowledge work
- The AI productivity paradox proves metrics are broken: DORA 2024 found every 25% increase in AI adoption decreased team throughput 1.5% and stability 7.2%, even as individual developers reported productivity gains
- Developers spend only 16% of time coding, yet most metrics measure code output (IDC 2025)—we’re measuring the minority of work while missing the majority of value
- Gaming is inevitable when metrics become targets: Story point inflation, velocity manipulation, and LOC gaming are documented at scale, making metrics “shared fiction” rather than diagnostic tools
- Framework evolution from DORA to SPACE to DevEx to DX Core 4 attempts to fix measurement gaps, achieving real outcomes (3-12% efficiency gains) but raising the question: solution or next thing to be gamed?
The uncomfortable truth: maybe productivity can’t be meaningfully quantified in knowledge work. When measurement focuses on what’s easy to count (commits, PRs, velocity) rather than what actually matters (value delivered, problems solved, customers helped), it will always miss the target. DX Core 4’s balanced approach is promising, combining delivery metrics with developer experience surveys and business impact measurements. However, until the fundamental tension between measurement-as-diagnosis and measurement-as-target resolves, the 66% trust gap will persist. When the map contradicts the territory—individual AI gains versus team delivery declines, 89% saying non-technical factors matter while 51% are measured technically—we should question the map, not the territory.
