AI Is Breaking the Old Units of Engineering Productivity

A line of code used to cost something.

Not a fixed amount. Not even a predictable amount. But writing 500 lines of production code generally implied that someone had spent meaningful time understanding a problem, designing a solution, typing, testing, debugging, and revising it.

AI is breaking that relationship.

Five hundred lines can now emerge from a few minutes of interaction with a coding assistant. A pull request that once required an afternoon may begin with a first draft generated in seconds. A developer can explore three implementations in the time it previously took to write one.

This is mostly good news.

But it creates a measurement problem.

If the cost of producing code changes dramatically, then metrics built around the amount or speed of that production become harder to interpret.

Lines of code do not suddenly become useless. Neither do commits, pull requests, cycle time, deployment frequency, or throughput.

They simply stop being sufficient on their own.

AI did not make engineering productivity impossible to measure. It made the denominator more important.

The Units Were Already Imperfect

Software engineering has struggled with productivity measurement long before generative AI.

Lines of code can reward verbosity. Commit counts depend heavily on workflow. Pull request counts can increase simply because teams make changes smaller. A developer who prevents a bad architectural decision may create less visible output than someone who spends a week implementing it.

This is why modern developer-productivity research moved away from the idea that one activity metric could represent productivity.

The SPACE framework, developed by researchers from Microsoft and GitHub, explicitly argues that developer productivity cannot be measured through a single metric or dimension. More recent work inside Microsoft follows the same principle: EngThrive organizes measurement around Speed, Ease, and Quality, combining outcome measures with diagnostic signals rather than treating activity itself as the outcome.

AI does not invalidate that research.

It makes the lesson harder to ignore.

AI Changes the Denominator Before It Changes the Numerator

Imagine an engineering team produces twice as much code after adopting AI.

What exactly doubled?

Lines?

Pull requests?

Features?

Useful functionality?

Engineering value?

Those are different claims.

If AI lowers the human effort needed to produce a first draft, then the same quantity of code can represent a very different quantity of human engineering effort.

That means the numerator may rise while the denominator changes underneath it.

This is already visible in how AI companies themselves talk about efficiency. GitHub has argued that token count alone is not a meaningful measure of AI coding efficiency: a shorter model interaction can still create more work if it lacks the context necessary to finish the task. Their framing is straightforward—optimize for the completed outcome, not the tool call.

The same principle applies one level higher.

Optimize for engineering outcomes, not merely the quantity of generated artifacts.

Activity Still Matters. It Just Answers a Different Question.

There is a temptation to respond to this problem by declaring old metrics dead.

That would be a mistake.

Commits can tell you something about activity.

Pull requests can tell you something about how work is packaged.

Cycle time can tell you how quickly work moves through the delivery system.

Deployment frequency can tell you how often changes reach production.

Review time can reveal bottlenecks.

These remain useful operational signals.

But an operational signal and a productivity measure are not necessarily the same thing.

A team can improve cycle time because it reduced batch size. Another can improve it because its work became simpler. Another may have introduced better automation. Another may simply be shipping more AI-generated code into a review process that has not yet absorbed the additional volume.

The number moved.

The explanation requires another layer.

DORA's recent work on AI-assisted development illustrates exactly this tension. AI can accelerate initial code generation, but some of the saved creation time can reappear as auditing, verification, and integration effort. DORA therefore recommends examining downstream signals rather than assuming faster generation automatically means a proportionate improvement in the whole delivery system.

AI Adoption Is an Input, Not an Outcome

The easiest AI metric to collect is often usage.

How many developers have Copilot?

How many use Claude Code?

How many tokens did the organization consume?

How many AI-assisted commits were created?

These are legitimate adoption questions.

They are not productivity answers.

DORA has warned about organizations turning raw AI token consumption into internal performance leaderboards—a dangerous pattern when token spend starts being treated as a performance indicator.

A developer using twice as many tokens has not necessarily created twice as much engineering value.

A team with 90% AI adoption has not necessarily achieved greater leverage than a team with 50%.

Usage tells you that the tool entered the workflow.

Measurement still needs to tell you what changed alongside it.

We Need to Separate Share from Leverage

This distinction becomes especially important with AI.

Suppose a large portion of a team's work appears AI-assisted.

That tells us something important about how the work was produced.

It does not tell us how much leverage the AI provided.

Those are different measurement questions.

AI Effort Share asks how much of the work appears meaningfully AI-assisted.

AI Leverage asks about the productivity relationship between the delivered baseline effort and the human effort still required.

High AI Effort Share can coexist with modest leverage if developers spend substantial time correcting, reviewing, integrating, or replacing generated work.

Lower AI Effort Share can coexist with high leverage if AI is applied selectively to tasks where it eliminates a disproportionate amount of human effort.

Neither outcome is inherently good or bad.

The important point is that adoption, share, and leverage should not be collapsed into one number.

Code Volume Becomes Especially Dangerous as a Proxy

Lines of code were never a reliable unit of engineering value.

AI makes the weakness more obvious.

Consider two hypothetical developers solving the same problem.

One adds a large new implementation.

The other recognizes that an existing abstraction can be extended with a small change.

The second developer may produce less code while creating the better engineering outcome.

Generative AI makes it possible to create the first implementation faster than ever. That does not make the second solution less valuable.

This is one reason current engineering research increasingly emphasizes outcomes and quality alongside speed.

Microsoft's EngThrive framework explicitly pairs outcome-oriented metrics with diagnostic measures, while the earlier SPACE research rejected activity as a complete representation of developer productivity.

The question is no longer:

How much code did we create?

It is:

What engineering work did we accomplish, and what did it cost us to accomplish it?

Throughput Can Rise While Other Costs Move Somewhere Else

AI makes the first part of software creation dramatically easier.

The rest of the system does not disappear.

Generated code still needs to fit an architecture.

It still needs review.

It still needs tests.

It still needs to integrate with existing code.

It still needs to survive future changes.

It still needs someone to understand it when production behaves differently than expected.

GitHub's reported expansion of AI-assisted code review points to the growing connection between generation and review capacity. GitHub reports that Copilot code review has grown substantially and continues to invest in making automated review deeper and more efficient as AI accelerates code creation.

The productivity question therefore cannot stop at how fast the first draft appeared.

It has to follow the work downstream.

Rework Is Becoming Part of the Productivity Equation

Once output becomes easier and faster to generate, correction becomes more important to measure.

How much of today's work needs to be rewritten next week?

How much survives its first review?

How much gets reverted?

How much must be replaced after requirements become clearer?

Rework is not automatically waste.

A rewrite can reflect learning.

A refactor can improve architecture.

Deletion can remove complexity.

But an organization that measures only initial production has no way to distinguish durable progress from output that repeatedly recreates the same work.

Current GitClear research illustrates why these downstream signals deserve attention. Its 2026 analysis of hundreds of millions of code changes reports rising duplication and short-term churn alongside declining refactoring and long-term legacy maintenance. That is vendor research rather than a universal industry law, but it demonstrates the kind of post-generation behavior that raw code volume cannot reveal.

The unit cannot merely be code produced.

We also need to understand what happened to that code afterward.

Durability Adds a Time Axis to Productivity

A second problem appears when measurement stops at deployment.

Two teams can deliver similar amounts of work this quarter.

Six months later, one team's earlier work may still be carrying the product forward.

The other's may have required substantial replacement, rewriting, or removal.

Both teams looked equally productive when the work shipped.

They no longer look identical when productivity is viewed through time.

This is why durability matters.

Code survival is one useful view: what remains in the evolving codebase?

Engineering-effort survival asks a related but different question: how much of the modeled engineering effort created earlier remains effective as later changes accumulate?

GitMe's Effort Survival Cohort is a cohort-based view of how much past modeled engineering effort remains effective over time.

It is not employee retention.

It is not a claim that changing code is bad.

And it is not a literal physical decay model.

It simply adds a question most productivity dashboards historically stopped asking too early:

What happened months later?

The Measurement Stack Needs More Layers

The AI era does not require us to throw away engineering metrics.

It requires us to stop asking one metric to do the work of seven.

A useful measurement stack now looks something like this:

Activity → Delivery → Effort → AI involvement → Leverage → Rework → Durability

Activity tells us what happened in the workflow.

Delivery tells us how work moved.

Modeled effort gives context to how substantial the contribution was.

AI Effort Share describes where AI appears in that work.

AI Leverage separates AI involvement from the productivity multiplier being reported.

Rework follows what happened after the first pass.

Durability extends the observation window further still.

These are complementary lenses.

A fast delivery system can still be valuable even if the work itself is complex.

A high-effort contribution is not automatically better than a low-effort one.

High AI leverage does not mean AI should be maximized everywhere.

Low rework does not prove quality.

High survival does not mean code should never be replaced.

Measurement becomes useful when these signals are interpreted together.

GitMe's Starting Point Is the Contribution

This is the measurement problem GitMe is designed around.

Real Effort Value (REV) estimates the effort a typical developer would need to deliver the same change without AI. It provides a modeled baseline rather than treating raw activity or code volume as the denominator; it is not a timesheet or a complete measure of business value.

Work categorization adds context about what kind of engineering activity that effort represents.

AI Effort Share estimates the portion appearing meaningfully AI-assisted.

AI Leverage adds a separate productivity lens.

Rework and historical comparison show what followed.

Effort Survival Cohort extends the view through time.

None of these individually defines engineering productivity.

Together, they make it harder to confuse more output with more value.

That distinction matters more as AI makes output easier to produce.

What Leaders Should Ask Instead

The useful question is no longer simply, “Are our developers producing more?”

A better measurement conversation asks:

• What kind of engineering work are we producing?
• How much modeled effort does that work represent?
• What share appears AI-assisted?
• What AI Leverage is being reported?
• Did delivery become faster, or did generation merely become faster?
• How much review and rework followed?
• What remained useful three, six, or twelve months later?
• Are our metrics rewarding engineering outcomes—or just making activity easier to count?

None of these questions replaces cycle time, DORA metrics, developer experience, or delivery analytics.

They make those metrics easier to interpret.

The Denominator Is the Real AI Measurement Problem

AI is making software development faster in places where producing the first draft previously required substantially more human effort.

That is an important productivity gain.

But it also means the artifacts we used as rough proxies for engineering work are becoming disconnected from the human effort required to create them.

A line of code does not mean what it used to mean.

A commit does not mean what it used to mean.

A pull request does not mean what it used to mean.

Even faster throughput needs context about what moved through the system.

The answer is not to stop measuring.

It is to improve the unit of measurement.

AI is not destroying engineering productivity metrics. It is exposing which ones were measuring the artifact rather than the work.

And as the cost of producing the artifact keeps falling, that distinction will only become more important.

Sources

• Microsoft: SPACE and EngThrive.
• GitHub: AI coding cost efficiency and 60 million Copilot code reviews and counting.
• DORA: Balancing AI tensions and DORA Insights (including its token-consumption warning).
• GitClear: The Maintainability Gap: AI Code Quality in 2026 (vendor-reported research).