A new framework for developer productivity in the AI era

I. The Productivity Illusion: Deconstructing the Failure of Simplistic Measurement

A. The “Black Box” Fallacy: Why Development Defies Easy Measurement

For decades, the measurement of software developer productivity has been considered a “black box,” a challenge many in tech believed impossible to solve correctly.¹ This difficulty stems from a fundamental misunderstanding of the work itself. Unlike industrial production, software development is not a manufacturing line with predictable inputs and outputs. It is a “creative, iterative, and deeply collaborative” process.¹ This makes the link between inputs (developer time) and outputs (value) “considerably less clear”.¹

Academic and industry consensus confirms that “productivity” remains a “poorly specified” concept in this context.³ Software tasks are rarely identical, making comparisons difficult. Furthermore, the “code is a lossy representation of the real work” ⁴, meaning the visible artifact (the code) fails to capture the invisible, high-value work of problem-solving, design, and collaboration.

This ambiguity has led to a reliance on traditional “vanity” metrics ², such as Lines of Code (LOC) and ticket velocity (e.g., story points). These metrics are widely discredited by researchers and experienced developers alike.² They are criticized as “meaningless” measures that reward “busy work, not progress”.² The core failure of these metrics is that they measure output, not outcome. As one analysis notes, the “outcome matters solving the problems that truly make a difference”.²

B. Goodhart’s Law as an Iron Rule: When Measurement Becomes Counter-Productive

The persistence of these failed metrics is not just ineffective; it is actively harmful. This phenomenon is perfectly described by the economic principle Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure”.⁶

The causal impact of this law on software teams is devastating. When a simplistic metric like “quantity of lines of code” ⁸ or “story points” ⁹ is co-opted by management and tied to performance reviews, the system is immediately gamed. The consequences are severe and predictable:

• Negative Behavioral Change: Developers, under pressure to perform against the metric, may “end up writing bloated and inefficient code” ⁸ to increase LOC or “inflate estimates” to boost their perceived velocity.⁹
• Cultural Decay: This “gaming” ⁸ degrades the engineering culture. It “kill[s] innovation and creativity” ⁸, erodes the “intrinsic motivation” of developers ⁸, and destroys trust between engineers and management.⁸
• Perception of Futility: Developers express deep frustration with managers who “will interrogate a developer about their velocity” while being unable to “barely connect to the WiFi”.⁵

This reveals a critical distinction. The problem is not necessarily the metric itself, but its application. Some developers note that story points, when kept within the team, can be valuable for “planning, estimation and uncovering the complexity of different tickets”.⁵ The failure occurs when that metric “leave[s] the team” and management “wants to use those metrics for performance reviews”.⁵ The persistence of these “zombie metrics” reflects a fundamental managerial misalignment a desire for a simple numerical answer that fails to grasp the complex, creative nature of the work.¹

II. The Modern Measurement Landscape: From DevOps Throughput to Human Experience

The failures of traditional metrics prompted a search for more meaningful frameworks. This evolution has shifted the focus from individual output to system throughput and, most recently, to the human experience of the developer.

A. The DORA Framework: Measuring the System, Not the Person

The first significant advancement was the DORA (DevOps Research and Assessment) framework, co-developed by Dr. Nicole Forsgren and colleagues.¹¹ DORA became the industry “gold standard” by shifting the unit of analysis from the individual developer to the team’s delivery system.¹¹

DORA is built on four key metrics, divided into two categories of throughput and stability ¹⁴:

1. Throughput (Speed):

• Deployment Frequency: How often the team successfully deploys to production.
• Change Lead Time: The time from a code commit to its successful deployment.

2. Stability (Quality):

• Change Fail Percentage: The percentage of deployments that cause a failure.
• Failed Deployment Recovery Time (MTTR): The time it takes to restore service after a failure.

DORA’s strength is its focus on outcomes that “predict better organizational performance and well-being”.¹⁴ It helps teams balance speed and quality.¹³ However, DORA metrics are not suitable for individual performance measurement.¹⁵ Their primary limitation is that they are lagging indicators.¹⁶ They tell an organization what happened (e.g., “our lead time is slow”) but not why.¹¹ They “lack… context” ¹⁷, “don’t capture everything the team does” ¹⁸, and largely neglect the human side of development.¹⁶

B. The SPACE Framework: A Holistic, Multi-Dimensional Rebuttal

To address DORA’s limitations, the same researchers who pioneered it (including Forsgren) introduced the SPACE framework in 2021.¹² SPACE was designed to augment DORA ¹ and bust the “myth” that productivity can be captured by any single metric.²² It provides a holistic, multi-dimensional view of productivity.

The five dimensions of SPACE are ²¹:

1. Satisfaction and well-being: How developers feel about their work, tools, and culture. This is a critical leading indicator of future productivity and burnout.²³
2. Performance: The outcome of the work, defined by quality, impact, and customer satisfaction not by output volume.²⁴
3. Activity: Counts of actions (e.g., commits, PRs, code reviews). The authors warn this is the “most ubiquitous” and “most misused” dimension.²⁴ It is not a proxy for productivity.
4. Communication and collaboration: The “invisible” but essential work of mentoring, knowledge sharing, and coordination.²⁵
5. Efficiency and flow: The ability to complete work smoothly and without “friction,” or interruptions that break the state of deep focus.²⁰

The “C” in SPACE Communication and Collaboration is a vital contribution. It formally acknowledges the “dark matter” of senior talent: high-value work like mentoring, conducting high-quality reviews, and unblocking other team members. This work is invisible to “Activity” metrics and traditional measures but is often the largest contribution a senior developer makes to team performance.

C. The DevEx Framework: Operationalizing the Human Dimension

The Developer Experience (DevEx) framework represents the next evolution, drilling deep into the human-centric dimensions of SPACE (specifically “Satisfaction” and “Efficiency and Flow”).²⁶ DevEx is founded on the principle that to improve team outcomes, one must first improve the daily experience of the developer.

The DevEx framework isolates three core pillars that are the causal inputs to productivity ²⁶:

1. Feedback Loops: How quickly a developer learns if something works. This includes CI/CD build times, test speed, and, critically, code review turnaround time.²⁷ Slow loops create frustration and kill momentum.
2. Cognitive Load: The mental effort required to perform tasks. High cognitive load is caused by unnecessary friction, such as poor documentation, complex tools, and system complexity.²⁷
3. Flow State: The state of deep, uninterrupted focus essential for complex problem-solving.²⁶

This DORA -> SPACE -> DevEx evolution represents a strategic paradigm shift. DORA measures lagging outcomes (the what). DevEx measures leading, causal inputs (the why). Research from GitHub, Microsoft, and DX has empirically validated this causal link, showing “strong support for the positive impact of flow state and low cognitive load on individual, team, and organization outcomes”.²⁹

An organization’s goal, therefore, should not be to “improve DORA metrics,” which can trigger Goodhart’s Law. The goal should be to “improve DevEx by reducing cognitive load and shortening feedback loops.” High-performance DORA metrics will be the natural result.

III. The AI Productivity Paradox: Reconciling Conflicting Realities

The integration of generative AI tools like GitHub Copilot has shattered the measurement landscape, introducing a profound conflict between perceived productivity and actual performance. This has created an “AI Productivity Paradox” defined by two contradictory, high-profile studies.

A. The “55% Faster” Narrative: AI for Isolated Tasks

The first narrative, heavily promoted by Microsoft and GitHub, positions AI as a massive productivity accelerant. This is based on a 2022 controlled experiment on GitHub Copilot.³¹

• Methodology: The study recruited 95 professional developers and split them into two groups. The task was self-contained and greenfield: “implement an HTTP server in JavaScript”.³³
• Quantitative Finding: The group with access to GitHub Copilot completed the task 55% faster than the control group.³³
• Qualitative Finding: The results were reinforced by large-scale surveys where developers felt dramatically more productive. 60-75% reported feeling “more fulfilled” and “less frustrated” ³³, and 73% felt AI helped them “stay in the flow”.³³

This narrative supports the use of AI for “garden-variety tasks” ³⁴ and “expediting manual and repetitive work” ³⁴, thereby reducing the task-level cognitive load of typing.

B. The “19% Slower” Reality: AI for Complex Workflows

In July 2025, a groundbreaking study from the non-profit research group METR provided a stark counter-narrative.³⁵

• Methodology: The METR study used a strict Randomized Controlled Trial (RCT) with 16 highly experienced open-source developers.³⁶ The tasks were not self-contained. They were real-world issues (bugs, features, refactors) selected from large, mature, and familiar repositories that the developers actively maintained.³⁶
• Quantitative Finding: Experienced developers using early-2025 AI tools (like Cursor Pro and Claude 3.5/3.7) ³⁵ took 19% longer to complete their tasks than the group without AI.³⁵
• The Perception Gap: The study’s most critical finding was the “large disconnect between perceived and actual AI impact”.³⁷ The same developers who were 19% slower perceived themselves to be 20-24% faster.³⁵

C. Reconciling the Paradox: Task-Work vs. Workflow-Overhead

These findings are not contradictory. They are measuring two different things. The GitHub study measured the micro-task of code generation, where AI excels. The METR study measured the entire macro-workflow of a professional developer, which includes not just coding but also:

1. Understanding the context of a large, mature codebase.³⁶
2. The new, hidden cognitive overhead of “writing and rewriting prompts, managing context, [and] reviewing code that you didn’t write”.³⁹

A follow-up METR blog (August 2025) provided a hypothesis for why this overhead exists: AI-generated code, while often functionally correct (it passes tests, the benchmark metric), “cannot be easily used as-is”.⁴⁰ It often fails on “test coverage, formatting/linting, or general code quality”.⁴⁰

This resolves the paradox: AI compresses the “Activity” (typing) portion of the task but massively inflates the “Cognitive Load” (validation, integration, debugging) required for a real-world workflow. The “flow state” developers feel ³³ is the absence of typing, but this is a deceptive sensation. The total time-to-value (DORA’s Lead Time) actually increases in complex scenarios.³⁹

This perception gap is the single greatest risk for strategic decision-makers. Executives are at high risk of making multi-million dollar investments in AI tooling ⁴¹ based on a cognitive bias shared by their entire engineering team. They are measuring “developer happiness” ³³, which, in this case, is an unreliable proxy for actual business value.

IV. The New Risks: Productivity Metrics as a Tool of Surveillance and Bias

The drive to quantify AI’s ROI, combined with the new capabilities of AI-driven analytics, has created a new generation of risks: the algorithmic panopticon, automated bias, and the devaluation of “invisible” work.

A. The Algorithmic Panopticon: AI Monitoring and Developer Mental Health

When AI analytics are used for monitoring, they become a tool of surveillance, inflicting significant psychological harm. The 2023 “Work in America” survey by the American Psychological Association (APA) provides a stark baseline for the impact of any workplace monitoring, which AI tools now automate and scale.⁴²

Key findings from the APA study show that monitored workers, “compared with those who are not monitored,” report ⁴²:

• Emotional Exhaustion: 39% vs. 22%
• Feelings of Ineffectiveness: 20% vs. 15%
• Desire to Keep to Themselves at Work: 30% vs. 19%
• Irritability or Anger: 23% vs. 14%

This is a clinical profile of “digital burnout”.⁴⁴ The “relentless pressure and psychological strain” of constant AI monitoring ⁴⁵ “undermines human dignity and human rights”.⁴⁶ This creates a destructive feedback loop: the APA data shows that monitored employees are 68% more likely to “desire to keep to themselves”.⁴² In the context of the SPACE framework, the act of monitoring directly causes a decline in “Communication and Collaboration,” thereby destroying the very team productivity it purports to measure.

B. “Bias In, Bias Out”: The Risk of Discriminatory AI Analytics

AI-driven productivity tools are not objective. They are “only as unbiased as the humans behind them”.⁴⁷ These systems, which are often “black boxes” ⁴⁸, are trained on historical data, and they risk absorbing and amplifying existing societal and organizational biases.⁵⁰

This “algorithmic bias” ⁴⁷ has been proven in other domains, such as recruiting tools that discriminate against women or criminal justice software biased against Black defendants.⁵³ In software engineering, a productivity algorithm trained on a company’s historical data might learn that “high-performing” developers (e.g., those promoted) share a common, narrow profile. The model could then systematically down-rank developers who do not fit that mold, such as those from non-traditional backgrounds ⁵⁴, neurodivergent individuals, or those with different collaboration styles. This creates catastrophic legal, ethical, and reputational risk.⁴⁷

C. The “Dark Matter” Problem: Penalizing High-Value, Invisible Work

Perhaps the most insidious risk is that AI analytics are blind to the most valuable work senior engineers do. Forrester estimates developers spend only 24% of their time coding.⁵⁶ The other 76% is “software engineering dark matter” ⁵⁷, a concept that includes:

• Collaboration: Mentoring junior developers, participating in high-quality code reviews ⁵⁸, and cross-team alignment.
• Strategic Work: Architectural design, systems thinking, migrating legacy systems, and, most importantly, preventing future bugs and incidents.⁶⁰

AI-driven analytics platforms, which primarily “plug into your repos and issue trackers” ⁴, cannot “see” this work.⁶¹ They measure the “light matter” of “Activity” (commits, PRs).²⁴

If an organization ties performance reviews to these AI-driven dashboards, it automates Goodhart’s Law. Senior developers are put in an impossible position:

1. Do the high-value “dark matter” work (mentoring, planning) and be penalized by the algorithm for low “Activity.”
2. Abandon this high-value work to “feed the algorithm” with visible-but-low-value activity.

This system actively encourages the organization’s most valuable, experienced talent to behave like junior developers, destroying their true impact.

V. The Regulatory Environment: Navigating a High-Risk Landscape (2025-2030)

The risks of AI-driven workplace surveillance and bias are so significant that governments are intervening. This has transformed the procurement of productivity tools from an IT decision into a high-stakes legal and compliance challenge.

A. The EU AI Act: “Employment” as a “High-Risk” Application

The European Union’s AI Act is the first major global standard, setting a benchmark for AI governance.⁴⁸ The Act classifies AI systems into risk tiers.⁶²

Crucially, Annex III of the Act explicitly lists “Employment, workers management and access to self-employment” as a “HIGH-RISK” category.⁶³ This classification directly applies to any AI tool used for “monitoring and evaluating the performance and behaviour” of workers.⁶³

This “high-risk” designation does not ban these tools, but it subjects them to heavy regulation.⁶² Both providers and deployers of these systems must adhere to strict obligations, including:

• Establishing a robust risk management system.
• Ensuring high-quality data governance to prevent bias.
• Maintaining detailed technical documentation and record-keeping for audits.
• And critically, ensuring “human oversight”.⁶²

This “human oversight” mandate is a legal game-changer. It makes fully automated, “black box” decisions about performance or termination legally untenable.⁴⁹ The law effectively enforces a “coaching” model over a “monitoring” model. An AI tool can be used as a diagnostic or coaching aid, but the final, accountable decision must be made by a human.

B. US Policy: A Converging Consensus on Surveillance and Rights

While the US lacks a single federal law, a clear policy consensus is emerging that mirrors the EU’s concerns.

• The White House Blueprint for an AI Bill of Rights establishes five key principles, including “Notice and Explanation” and “Algorithmic Discrimination Protections”.⁴⁶
• Most relevantly, the Blueprint explicitly states: “Continuous surveillance and monitoring should not be used in… work” as it is “likely to limit rights, opportunities, or access”.⁶⁵
• This framework, along with proposed legislation aimed at “robot bosses” ⁶⁷ and new state-level AI laws ⁶⁸, signals that the legal and reputational risk of deploying surveillance-based productivity tools is becoming untenable globally.

VI. Industry in Practice: The Rise of AI-Native Developer Analytics

The market is adapting to this complex landscape of unproven ROI and high legal risk. A new generation of “Engineering Intelligence” platforms such as Jellyfish, Waydev, LinearB, GetDX, and Codacy has emerged, claiming to be the solution.⁶⁹

These platforms market themselves as the “single pane of glass” for engineering leaders, integrating DORA, SPACE, and DevEx frameworks to provide a holistic view.²³

A. Case Study: The “Coaching” Pivot of LinearB

The positioning of these tools is a masterclass in navigating the ethical and legal minefield. Instead of “monitoring,” the platforms are framed as “Developer Coaching” tools ⁷⁶ focused on “DevEx” and “well-being”.⁷⁷

This is more than marketing; it is a necessary commercial strategy to defuse developer resistance ⁵ and provide “human-in-the-loop” legal cover for the EU AI Act.⁶²

LinearB, for example, offers two key features ⁷⁸:

1. Burnout Alert: Flags developers who have worked “90% of the days in a current sprint.”
2. Cognitive Overload Alert: Flags developers with “over 6 active branches,” identifying harmful context-switching.

This is a brilliant repositioning. It takes surveillance data (commit timestamps, active git branches) and reframes it as a benevolent, human-centric feature designed to prevent burnout, not to cause it. This pivot is essential for gaining the trust required for adoption.

The healthy and legally compliant use of these platforms is therefore not for individual scoring, but for system-level bottleneck discovery. The data should be anonymized and aggregated to answer team-level questions like, “What is our average code review time?” or “Where are our CI/CD bottlenecks?”.⁵

B. The Next Frontier: Measuring the Impact of Generative AI

The industry is now turning this technology stack on itself. The new frontier is using AI analytics to measure the impact of generative AI tools.⁸⁰

Platforms now claim to track ⁸⁰:

• Adoption: Which developers are (and are not) using AI tools.
• Behavior: The “acceptance rate” of AI-generated suggestions.
• Impact: Comparing “AI-assisted” vs. “human-only” workflows to quantify outcomes.

This creates the full measurement loop: AI is being used to measure the productivity impact of other AI tools, in an environment where the baseline productivity measurement is already fraught with paradoxes and risks.

VII. High-Level Strategic Guidance: The Roadmap to Human-Centric Productivity

For C-level executives, policymakers, and engineering leaders, navigating this landscape requires a complete shift in strategy, moving away from “productivity” and toward “experience” and “impact.”

The Top 5 Strategic Findings & Recommendations (2025-2030)

1. Finding: You Are Measuring the Wrong Thing.

Recommendation: Immediately cease all attempts to measure individual developer productivity using quantitative “activity” metrics.81 Shift all focus to measuring Developer Experience (DevEx) at the team level.82 The goal is not a “productivity number” but an “experience score.” Focus investment on the causal inputs to productivity: protecting Flow State (e.g., “no-meeting” blocks), reducing Cognitive Load (e.g., better documentation, platform engineering 79), and shortening Feedback Loops (e.g., faster builds, sub-24-hour review times).27

2. Finding: The “AI Productivity Paradox” is Real; Your Team’s “Perception” is Deceptively Unreliable.

Recommendation: Do not make multi-million dollar investments in generative AI tools based on developer perception, satisfaction surveys, or “hours saved” estimates.80 The “perception gap” (feeling 20% faster while being 19% slower) is a massive financial risk.39 Mandate internal, real-world pilots (modeled on the METR study 36) that measure the actual impact on DORA metrics (e.g., Change Lead Time) and real-world task completion in your own mature codebases before scaling.

3. Finding: AI Monitoring Creates Legal Risks and Kills Productivity.

Recommendation: Treat all AI-driven analytics tools as “High-Risk” under the EU AI Act framework 63, regardless of your geography. This is the emerging global standard. Mandate “human-in-the-loop” oversight for all performance evaluations.52 Ban “black box” automated scoring.49 To build trust, reframe all tool usage around “coaching” and system-level diagnostics, and provide a “no-surveillance” guarantee to create psychological safety.83

4. Finding: AI Will Not Replace Your Developers; It Will Reshape Your Management.

Recommendation: Stop planning for AI to replace developers. A Forrester prediction states that “At least one organization will try to replace 50% of its developers with AI and fail”.56 The real shift is that AI augments the developer 34 and automates many managerial tasks (reporting, coordination). Your primary investment must be in “AI-First Leadership” 83 and upskilling your developers, shifting their focus from writing code to architectural skills and business domain expertise.84

5. Finding: The Goal of AI is “Superagency,” Not Just Efficiency.

Recommendation: The biggest barrier to AI maturity is leadership, not employees.85 The strategic goal of AI is not to cut costs or enforce compliance. It is to “amplify human agency” and “unlock new levels of creativity and productivity”.85 This is achieved by using AI to get developers into “flow” sooner 34 and to “foster… collaboration”.86 These outcomes creativity, agency, collaboration require a high-trust environment, the exact opposite of a surveillance-driven one.

VIII. Technical Insights for Engineers: A Playbook for Responsible Implementation

For engineering leaders and developers, the goal is to harness AI and analytics responsibly to improve the team’s experience and capabilities.

A. Use AI to Fight Toil, Not to Create It

The primary “toil” to eliminate is not typing. It is cognitive load.²⁷ Technical leaders should focus AI on the “tasks beyond code generation” ⁶⁰ that developers hate and that add the most friction:

• Legacy Systems: Use AI for “refactoring tangled code, migrating legacy systems, and hunting down race conditions”.⁶⁰
• Documentation: Use AI to “plug documentation gaps” ²⁸, generating and maintaining documentation from code and intent.
• Platform Engineering: Integrate AI into the developer platform to abstract away complexity (e.g., “AI, configure this deployment pipeline”).⁷⁹

B. Build an AI-Augmented Code Review Process

Code review is one of the most significant “Feedback Loops” in the DevEx framework.²⁷ It is also a source of friction and “dark matter” work.⁵⁸ Use AI to assist the human reviewer, not replace them.

1. AI-Driven Triage: Use LLMs to automatically “detect inconsistencies between issues and pull requests” ⁸⁷, saving the reviewer time.
2. Sentiment Analysis: Use NLP to “detect… the language used in the code review process”.⁵⁸ Flag potentially negative or “toxic” comments (e.g., “error,” “fail”) ⁵⁸ for a team lead to review, protecting psychological safety.
3. Smart Reviewer Recommendation: Use models to suggest the best human reviewer based on code familiarity, not just team rotation.⁸⁸

C. Create Telemetry for Diagnostics, Not Judgment

Engineers must be the guardians of their own culture. The most effective principle for using metrics is: “data doesn’t leave the team”.⁵

• Build internal telemetry (similar to Meta’s approach ⁵⁷) to “diagnose problems when the team agrees there is a problem”.⁵
• The data should be aggregated and used only to answer system-level questions: “Where are our CI/CD bottlenecks?” “What is our average PR review time?” “Where is our “developer toil” ²⁸ concentrated?”
• Never use raw, AI-generated metrics (e.g., “AI acceptance rate” ⁸⁰) in an individual performance review. This will trigger Goodhart’s Law ⁶, encourage “gaming,” and destroy the team’s trust and intrinsic motivation.

IX. Future Proofing (2030-2035): The Dawn of Software Engineering 3.0

The current paradigm of AI-assisted development is only a transitional phase. The period from 2030-2035 will be defined by the shift to a truly AI-native workflow.

A. The Failure of SE 2.0: The “Copilot” Ceiling

The current era (2020-2025) is best defined as Software Engineering 2.0 (AI-Assisted).⁸⁹ This paradigm is characterized by “FM-powered copilots”.⁸⁹ Its “inherent limitations,” as identified in academic literature, are “cognitive overload on developers and inefficiencies”.⁸⁹

The 2025 METR study ³⁵ provided the first empirical proof of this academic theory. The “inefficiency” is the 19% slowdown. The “cognitive overload” is the hidden, frustrating work of prompt engineering, context-wrangling, and validating low-quality AI-generated code.³⁹ SE 2.0 has hit a ceiling, where the human is the bottleneck, forced to act as a validator for a tool that feels fast but is slow.

B. The Vision of SE 3.0: The AI-Native “Teammate”

The 2030-2035 horizon is Software Engineering 3.0 (AI-Native).⁸⁹ This is not a “copilot” tool that assists with typing. It is a “symbiotic relationship” ⁹⁰ with an “AI teammate”.⁸⁹

This new paradigm is defined by “intent-first, conversation-oriented development”.⁸⁹

The workflow will be inverted. The human developer, acting as an “Architect” or “Designer” ⁸⁴, will express intent at a high level (e.g., “Refactor the authentication service to be multi-region fault-tolerant and compliant with our new security standards”). The “AI Teammate.next,” which “deeply understand[s]… software engineering principles” ⁸⁹, will handle the entire SDLC: design, coding, testing, refactoring, and deployment. The human’s role becomes one of guidance, validation, and strategic intent.

C. The Future of Productivity Measurement in SE 3.0

In a world where an AI teammate performs all of the “Activity” and “Performance” (from the SPACE framework), what is left to measure for the human?

This future represents the final and total death of all “activity” metrics (LOC, commits, PRs). The only metrics that will matter for the human developer are those that measure their unique, high-level contributions:

1. Intent Quality: A qualitative assessment of the human’s “prompts,” architectural designs, and business-domain specifications.
2. Collaboration Quality: How effectively the human guides, corrects, and collaborates with their AI teammate to achieve the goal (the “C” in SPACE).
3. Business Impact: The “dark matter” of senior talent ⁵⁷ will become the only matter. The human developer will be measured exclusively on the business value, customer satisfaction, and strategic impact of their intent.²

Geciteerd werk

1. Yes, you can measure software developer productivity – McKinsey, geopend op november 7, 2025, https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity
2. 13 Developer Productivity Metrics You Should Be Measuring – Early AI, geopend op november 7, 2025, https://www.startearly.ai/post/developer-productivity-metrics
3. No Silver Bullets: Why Understanding Software Cycle Time is Messy, Not Magic – arXiv, geopend op november 7, 2025, https://arxiv.org/html/2503.05040v1
4. Everything Wrong With Developer Productivity Metrics : r/programming – Reddit, geopend op november 7, 2025, https://www.reddit.com/r/programming/comments/1nf85j7/everything_wrong_with_developer_productivity/
5. Just dont bother measuring developer productivity : r/ExperiencedDevs – Reddit, geopend op november 7, 2025, https://www.reddit.com/r/ExperiencedDevs/comments/19awh25/just_dont_bother_measuring_developer_productivity/
6. What is Goodhart’s Law? – Splunk, geopend op november 7, 2025, https://www.splunk.com/en_us/blog/learn/goodharts-law.html
7. Goodhart’s law – Wikipedia, geopend op november 7, 2025, https://en.wikipedia.org/wiki/Goodhart%27s_law
8. Goodhart’s Law: The Danger of Making Metrics into Targets – ILMS Academy, geopend op november 7, 2025, https://www.ilms.academy/blog/goodharts-law-the-danger-of-making-metrics-into-targets
9. Goodhart’s Law: The Hidden Risk in Software Engineering Metrics – Axify, geopend op november 7, 2025, https://axify.io/blog/goodhart-law
10. Building less-flawed metrics: Understanding and creating better measurement and incentive systems – PMC, geopend op november 7, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC10591122/
11. What are DORA Metrics and How to Unlock Elite Engineering Performance | LinearB Blog, geopend op november 7, 2025, https://linearb.io/blog/dora-metrics
12. How to measure and improve developer productivity | Nicole Forsgren (Microsoft Research, Github) – YouTube, geopend op november 7, 2025, https://www.youtube.com/watch?v=dP8NmcEkxJI
13. DORA Metrics: How to measure Open DevOps Success – Atlassian, geopend op november 7, 2025, https://www.atlassian.com/devops/frameworks/dora-metrics
14. DORA’s software delivery metrics: the four keys, geopend op november 7, 2025, https://dora.dev/guides/dora-metrics-four-keys/
15. Are DORA, and other dev productivity metrics a sham? : r/ExperiencedDevs – Reddit, geopend op november 7, 2025, https://www.reddit.com/r/ExperiencedDevs/comments/1c640cb/are_dora_and_other_dev_productivity_metrics_a_sham/
16. Why DORA Metrics Aren’t Enough for Engineering Teams – OpsLevel, geopend op november 7, 2025, https://www.opslevel.com/resources/why-dora-metrics-arent-enough-for-engineering-teams
17. DORA vs SPACE Metrics: A Guide to the Science of DevOps & DevEx, geopend op november 7, 2025, https://www.hivel.ai/blog/dora-vs-space-metrics
18. Limitations in Measuring Platform Engineering with DORA Metrics – DEV Community, geopend op november 7, 2025, https://dev.to/signadot/limitations-in-measuring-platform-engineering-with-dora-metrics-46hm
19. DORA Metrics and SPACE Metrics: A Comparative Overview for Software Development Leaders | Article | BlueOptima, geopend op november 7, 2025, https://www.blueoptima.com/dora-metrics-and-space-metrics-a-comparative-overview-for-software-development-leaders
20. Mastering Developer Productivity with the SPACE Framework | by typo – Medium, geopend op november 7, 2025, https://medium.com/beyond-the-code-by-typo/mastering-developer-productivity-with-the-space-framework-5dbef28a1b84
21. What is the SPACE developer productivity framework? – Redgate Software, geopend op november 7, 2025, https://www.red-gate.com/blog/database-devops/what-is-the-space-developer-productivity-framework
22. The SPACE of Developer Productivity – ACM Queue, geopend op november 7, 2025, https://queue.acm.org/detail.cfm?id=3454124
23. An Introduction to The SPACE Framework – DevDynamics, geopend op november 7, 2025, https://devdynamics.ai/blog/the-space-framework-for-developer-productivity-3/
24. Measuring enterprise developer productivity – The GitHub Blog, geopend op november 7, 2025, https://github.blog/enterprise-software/devops/measuring-enterprise-developer-productivity/
25. Understanding DevOps Metrics: DORA Metrics, SPACE Framework and DevEx – Travis CI, geopend op november 7, 2025, https://www.travis-ci.com/blog/understanding-devops-metrics-dora-metrics-space-framework-and-devex/
26. DevEx: What Actually Drives Productivity – ACM Queue, geopend op november 7, 2025, https://queue.acm.org/detail.cfm?id=3595878
27. What is developer experience? Complete guide to DevEx … – DX, geopend op november 7, 2025, https://getdx.com/blog/developer-experience/
28. New Atlassian research on developer experience highlights a major disconnect between developers and leaders, geopend op november 7, 2025, https://www.atlassian.com/blog/developer/developer-experience-report-2024
29. Quantifying the impact of developer experience | Microsoft Azure Blog, geopend op november 7, 2025, https://azure.microsoft.com/en-us/blog/quantifying-the-impact-of-developer-experience/
30. Yes, good DevEx increases productivity. Here is the data. – The GitHub Blog, geopend op november 7, 2025, https://github.blog/news-insights/research/good-devex-increases-productivity/
31. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot – Microsoft, geopend op november 7, 2025, https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/
32. [2302.06590] The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, geopend op november 7, 2025, https://arxiv.org/abs/2302.06590
33. Research: quantifying GitHub Copilot’s impact on developer …, geopend op november 7, 2025, https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
34. Unleash developer productivity with generative AI – McKinsey, geopend op november 7, 2025, https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/unleashing-developer-productivity-with-generative-ai
35. [2507.09089] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity – arXiv, geopend op november 7, 2025, https://arxiv.org/abs/2507.09089
36. Measuring the Impact of Early-2025 AI on Experienced Open …, geopend op november 7, 2025, https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
37. Surprise Research Finding: Developers Using AI Take 19% Longer on Tasks – eWeek, geopend op november 7, 2025, https://www.eweek.com/news/news-ai-tools-slow-developer-productivity-study/
38. Study: The paradoxical effects of AI tools on the productivity of software developers, geopend op november 7, 2025, https://www.obviousworks.ch/en/study-the-paradoxical-effects-of-ki-tools-on-the-productivity-of-software-developers/
39. Study: Experienced devs think they are 24% faster with AI, but they’re actually ~20% slower : r/ExperiencedDevs – Reddit, geopend op november 7, 2025, https://www.reddit.com/r/ExperiencedDevs/comments/1lwk503/study_experienced_devs_think_they_are_24_faster/
40. Research Update: Algorithmic vs. Holistic Evaluation – METR, geopend op november 7, 2025, https://metr.org/blog/2025-08-12-research-update-towards-reconciling-slowdown-with-time-horizons/
41. Measuring Impact of GitHub Copilot, geopend op november 7, 2025, https://resources.github.com/learn/pathways/copilot/essentials/measuring-the-impact-of-github-copilot/
42. 2023 Work in America survey: Artificial intelligence, monitoring …, geopend op november 7, 2025, https://www.apa.org/pubs/reports/work-in-america/2023-work-america-ai-monitoring
43. Worries about artificial intelligence, surveillance at work may be connected to poor mental health – American Psychological Association, geopend op november 7, 2025, https://www.apa.org/news/press/releases/2023/09/artificial-intelligence-poor-mental-health
44. Mental health in the “era” of artificial intelligence: technostress and the perceived impact on anxiety and depressive disorders an SEM analysis – Frontiers, geopend op november 7, 2025, https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2025.1600013/full
45. geopend op november 7, 2025, https://prism.sustainability-directory.com/scenario/ai-monitoring-impact-on-employee-mental-health/#:~:text=The%20relentless%20pressure%20and%20psychological,algorithmic%20surveillance%20and%20performance%20optimization.
46. A policy primer and roadmap on AI worker surveillance and productivity scoring tools – NIH, geopend op november 7, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC10026198/
47. Algorithmic Bias in AI Employment Decisions, geopend op november 7, 2025, https://jtip.law.northwestern.edu/2025/01/30/algorithmic-bias-in-ai-employment-decisions/
48. Ethical implications of AI in software development for the enterprise – HCLTech, geopend op november 7, 2025, https://www.hcltech.com/blogs/ethical-implications-ai-software-development-enterprise
49. AI and Employee Data Protection in the European Union: 8 Key Takeaways for Multinational Businesses | Fisher Phillips, geopend op november 7, 2025, https://www.fisherphillips.com/en/news-insights/ai-employee-data-protection-european-union-takeaways-for-multinational-businesses.html
50. Fairness and Bias in Artificial Intelligence: A Brief Survey of Sources, Impacts, and Mitigation Strategies – MDPI, geopend op november 7, 2025, https://www.mdpi.com/2413-4155/6/1/3
51. Algorithmic bias detection and mitigation: Best practices and policies to reduce consumer harms | Brookings, geopend op november 7, 2025, https://www.brookings.edu/articles/algorithmic-bias-detection-and-mitigation-best-practices-and-policies-to-reduce-consumer-harms/
52. What Is Algorithmic Bias? – IBM, geopend op november 7, 2025, https://www.ibm.com/think/topics/algorithmic-bias
53. Addressing issues of fairness and bias in AI – Thomson Reuters Institute, geopend op november 7, 2025, https://www.thomsonreuters.com/en-us/posts/news-and-media/ai-fairness-bias/
54. Bias and Productivity in Humans and Algorithms: Theory and Evidence from Résumé Screening – IZA – Institute of Labor Economics, geopend op november 7, 2025, https://conference.iza.org/conference_files/MacroEcon_2017/cowgill_b8981.pdf
55. Algorithm Bias: Understanding the Hidden Biases in AI – DragonSpears, geopend op november 7, 2025, https://www.dragonspears.com/blog/algorithm-bias
56. Predictions 2025: GenAI Reality Bites Back For Software Developers – Forrester, geopend op november 7, 2025, https://www.forrester.com/blogs/predictions-2025-software-development/
57. Measuring the Impact of AI on Developer Productivity at Meta – YouTube, geopend op november 7, 2025, https://www.youtube.com/watch?v=1OzxYK2-qsI
58. Analysing Quality Metrics and Automated Scoring of Code Reviews – MDPI, geopend op november 7, 2025, https://www.mdpi.com/2674-113X/3/4/25
59. “Looks Good To Me ;-)”: Assessing Sentiment Analysis Tools for Pull Request Discussions, geopend op november 7, 2025, https://www.researchgate.net/publication/381305908_Looks_Good_To_Me_-_Assessing_Sentiment_Analysis_Tools_for_Pull_Request_Discussions
60. Can AI really code? Study maps the roadblocks to autonomous software engineering, geopend op november 7, 2025, https://news.mit.edu/2025/can-ai-really-code-study-maps-roadblocks-to-autonomous-software-engineering-0716
61. Enhancing Software Engineering Productivity: AI-Driven Metrics and Workforce Analytics, geopend op november 7, 2025, https://www.researchgate.net/publication/388835075_Enhancing_Software_Engineering_Productivity_AI-Driven_Metrics_and_Workforce_Analytics
62. High-level summary of the AI Act | EU Artificial Intelligence Act, geopend op november 7, 2025, https://artificialintelligenceact.eu/high-level-summary/
63. Annex III: High-Risk AI Systems Referred to in Article 6(2) | EU …, geopend op november 7, 2025, https://artificialintelligenceact.eu/annex/3/
64. Employee monitoring: A moving target for regulation – Eurofound – European Union, geopend op november 7, 2025, https://www.eurofound.europa.eu/en/publications/all/employee-monitoring-moving-target-regulation
65. Blueprint for an AI Bill of Rights | OSTP | The White House, geopend op november 7, 2025, https://bidenwhitehouse.archives.gov/ostp/ai-bill-of-rights/
66. Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, geopend op november 7, 2025, https://www.federalregister.gov/documents/2023/11/01/2023-24283/safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence
67. 3 AI Bills in Congress for Employers to Track: Proposed Laws Target Automated Systems, Workplace Surveillance, And More | Fisher Phillips, geopend op november 7, 2025, https://www.fisherphillips.com/en/news-insights/3-ai-bills-in-congress-for-employers.html
68. Artificial Intelligence 2025 Legislation – National Conference of State Legislatures, geopend op november 7, 2025, https://www.ncsl.org/technology-and-communication/artificial-intelligence-2025-legislation
69. LinearB vs Jellyfish | Productivity Platform vs. Generic Dashboards, geopend op november 7, 2025, https://linearb.io/compare/jellyfish-vs-linearb
70. Waydev vs LinearB: A Comprehensive Comparison – Graph AI, geopend op november 7, 2025, https://www.graphapp.ai/blog/waydev-vs-linearb-a-comprehensive-comparison
71. Competitors – Waydev, geopend op november 7, 2025, https://waydev.co/competitors/
72. 8 Best LinearB Alternatives & Competitors on the Market Now – Jellyfish, geopend op november 7, 2025, https://jellyfish.co/blog/linearb-alternatives-competitors/
73. DX Comparisons, geopend op november 7, 2025, https://getdx.com/dx-comparisons/
74. SPACE Framework & Metrics: Measure Your Developer Productivity – Waydev, geopend op november 7, 2025, https://waydev.co/space-framework-metrices-key-indicators-of-developer-productivity/
75. SPACE Framework: How to Measure Developer Productivity – Codacy | Blog, geopend op november 7, 2025, https://blog.codacy.com/space-framework
76. Dev Coaching: Drive Developer Productivity & Operational Excellence | LinearB Blog, geopend op november 7, 2025, https://linearb.io/blog/dev-coaching-drive-developer-productivity-and-operational-excellence
77. From Burnout to Breakthrough: How AI Addresses Software Engineer Burnout – Turing, geopend op november 7, 2025, https://www.turing.com/blog/how-ai-addresses-software-engineer-burnout
78. What are LinearB Burnout Indicators? – HelpDocs & User Setup …, geopend op november 7, 2025, https://linearb.helpdocs.io/article/m922k2p59d-burnout-indicators
79. How platform engineering fills skill gaps to improve developer experience | LinearB Blog, geopend op november 7, 2025, https://linearb.io/blog/how-platform-engineering-fills-skill-gaps-to-improve-developer-experience
80. Closing the AI Gap: How to Measure Adoption and Impact in Engineering (Without Falling Into the ROI Trap) | LinearB Blog, geopend op november 7, 2025, https://linearb.io/blog/closing-the-ai-gap
81. Your Focus On Developer Productivity Is Killing You – Forrester, geopend op november 7, 2025, https://www.forrester.com/report/your-focus-on-developer-productivity-is-killing-you/RES181873
82. Developer Experience (DevEx) as a Key Driver of Productivity – Gartner, geopend op november 7, 2025, https://www.gartner.com/en/software-engineering/topics/developer-experience
83. AI-First Leadership: Embracing the Future of Work – Harvard Business Impact, geopend op november 7, 2025, https://www.harvardbusiness.org/insight/ai-first-leadership-embracing-the-future-of-work/
84. ​​Don’t Fire Your Developers! What AI-Enhanced Software Development Means For Technology Executives – Forrester, geopend op november 7, 2025, https://www.forrester.com/blogs/dont-fire-your-developers-what-ai-enhanced-software-development-means-for-technology-executives/
85. AI in the workplace: A report for 2025 – McKinsey, geopend op november 7, 2025, https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/superagency-in-the-workplace-empowering-people-to-unlock-ais-full-potential-at-work
86. The Impact of AI on Software Development – Digital WPI, geopend op november 7, 2025, https://digital.wpi.edu/downloads/qj72pc43b?locale=en
87. PReview: A Benchmark Dataset for Pull Request Outcomes and Quality Analysis – OpenReview, geopend op november 7, 2025, https://openreview.net/pdf?id=cdwp8BXTVV
88. Reviewer recommendation for pull-requests in GitHub: What can we learn from code review and bug assignment? – Semantic Scholar, geopend op november 7, 2025, https://www.semanticscholar.org/paper/Reviewer-recommendation-for-pull-requests-in-What-Yu-Wang/9b4df30d4019ad196ca0d5c34b8ef6ae5e5fc7ca
89. (PDF) Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap – ResearchGate, geopend op november 7, 2025, https://www.researchgate.net/publication/384770605_Towards_AI-Native_Software_Engineering_SE_30_A_Vision_and_a_Challenge_Roadmap
90. [2410.06107] Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap – arXiv, geopend op november 7, 2025, https://arxiv.org/abs/2410.06107
91. [PDF] Towards AI-Native Software Engineering (SE 3.0): A Vision …, geopend op november 7, 2025, https://www.semanticscholar.org/paper/Towards-AI-Native-Software-Engineering-%28SE-3.0%29%3A-A-Hassan-Oliva/a80cb0325b78c303916cb66d6d33fe0aed8c8311