Engineering Productivity Needs a Half-Life

Team A and Team B ship a similar amount of work this quarter.

Both teams close tickets. Both merge pull requests. Both deliver visible product changes. On the dashboard, they look equally productive.

Six months later, the picture is different.

Team A's work is still active. The feature has been extended twice, the underlying abstractions still make sense, and later changes build on the original effort.

Team B's work has been rewritten, replaced, or removed in pieces. Some of that change was healthy iteration. Some was necessary adaptation. Some was cleanup that followed rushed implementation. The original output still happened, but much less of the original engineering effort is carrying the product forward.

If productivity was measured only at shipment, both teams looked similar.

If productivity is viewed over time, they are not.

That is the missing dimension in many engineering productivity conversations: output at T=0 is not the same thing as engineering value over time.

Productivity should not stop being measured when the code ships.

We Measure Engineering Work Too Early

Most engineering metrics observe work near the moment it is created, reviewed, merged, or deployed.

That is not a flaw. It is useful.

Cycle time helps leaders understand how quickly work moves. Deployment frequency shows how often value reaches production. Change failure rate and deployment rework rate help teams see whether releases create immediate instability. Review time, pull request throughput, and work-in-progress metrics help teams identify delivery friction.

DORA's current software delivery metrics explicitly separate throughput from instability: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. DORA also warns teams not to turn one metric into the only metric or compare unlike systems without context.

That is the right posture. Established metrics answer important questions.

They just do not answer every question.

Cycle time asks: how quickly did the work move?

Deployment frequency asks: how often did change reach production?

Change failure and deployment rework ask: how much immediate correction followed deployment?

Durability asks a different question: how much of earlier work or effort remains effective later?

Those layers can coexist. A strong engineering measurement system should not replace speed with durability. It should connect them.

Shipping Is a Measurement Point, Not the Finish Line

After software ships, several things can happen.

The code may remain stable. It may be extended. It may be refactored into a better shape. It may be replaced by a better design. It may be removed because the product changed. It may require repeated correction because the first version did not fit reality.

Those outcomes do not mean the original team was good or bad in a simple way. Software exists in changing markets, changing architectures, changing dependencies, and changing user expectations.

The point is not that all replacement is waste.

The point is that engineering work has a time dimension.

A dashboard that stops at merge sees the act of production. A dashboard that follows work after merge can start to distinguish several different patterns:

work that remains useful and becomes a foundation for later work
work that changes because the product learned something important
work that gets simplified because the first version exposed a better design
work that churns because intent, ownership, or quality was unclear
work that disappears because it was never as valuable as it appeared at shipment

Those are different management stories. They should not collapse into the same productivity score.

Rework Is Not Automatically Waste

Rework is easy to misuse as a moral category. It should not be.

Some rework is healthy iteration. Customers respond differently than expected. Compliance requirements change. A prototype proves an idea and then deserves a stronger implementation. A refactor removes complexity that the team could not see before production usage. A subsystem is replaced because the business has outgrown it.

That kind of rework can be a sign of learning.

The question is not: did the code change?

The better question is: what happened to the engineering effort after the first pass?

Did later work preserve the original intent while improving the implementation? Did it amplify the value of the original effort? Did it retire obsolete work cleanly? Or did it repeatedly revisit the same surface because requirements, review, tests, architecture, or ownership were weak?

Code churn and rework are signals, not verdicts. Academic research has long treated churn as a risk indicator rather than a universal diagnosis. Nagappan and Ball's work on relative code churn found that churn measures can help predict defect density, while absolute churn alone is a weaker signal. That distinction matters: the context and relationship of change are often more informative than raw change volume.

Engineering leaders need the same discipline. Rework is not automatically waste, but rework without context is not automatically productivity either.

The Missing Dimension Is Time

"Half-life" is a metaphor, not a literal physics model.

Engineering work does not decay according to a neat exponential curve. GitMe does not need to invent a radioactive-decay formula for software. The useful idea is simpler:

How much of the effort we created earlier is still carrying value later?

Today asks:

What did we produce?
What type of work was it?
How much modeled engineering effort did it represent?
Where did AI appear to participate?

Later asks:

How much rework followed?
Was the work extended, replaced, removed, or repeatedly corrected?
How much of that earlier modeled effort remains effective?
Did the organization become easier or harder to change because of that work?

This is where productivity measurement becomes more durable. A team can be fast and durable. A team can be fast and fragile. A team can look slow because it is paying down structural debt that will make future delivery faster. A team can produce a large volume of work that has a short useful life.

None of those patterns is visible from output at T=0 alone.

AI Makes First-Draft Productivity Easier to Overestimate

AI raises the stakes because it lowers the cost of first drafts.

That is useful. AI can reduce blank-page friction, help with unfamiliar APIs, draft tests, explain existing code, summarize documentation, and accelerate implementation. GitHub's controlled Copilot study found statistically significant improvements in functionality, readability, reliability, maintainability, conciseness, and approval likelihood for a defined coding task.

The evidence is not simply anti-AI. It should not be read that way.

But faster generation changes what leaders need to measure next.

DORA's generative AI research reports productivity and well-being gains, while also emphasizing governance, trust, review, and delivery fundamentals. DORA's 2026 writing on AI tensions describes a recurring pattern: time saved in creation is often reallocated to auditing and verification, and teams should measure impact rather than narrow output.

GitClear's 2026 maintainability research makes the durability question even sharper. Its public analysis of hundreds of millions of changes reports rising duplication, copy/paste, error-masking constructs, and short-term churn alongside declines in refactoring, cross-file connectivity, and legacy-code updates. GitClear is measuring code-level survival and maintainability signals, not GitMe's modeled-effort view, but the management implication is related: more generated or AI-assisted code is not automatically more durable engineering value.

That is the AI productivity trap.

AI adoption is not the same thing as AI value.

AI Effort Share is not the same thing as AI Leverage.

More generated code is not the same thing as durable contribution.

The better AI question is not only "How much AI did we use?" It is:

What kind of work appeared AI-assisted?
What AI Leverage was reported?
Did the work survive review, release, and later product change?
Was it followed by unusual rework?
Did it improve maintainability, testability, or knowledge distribution?
Did it help with features, refactoring, tests, bug fixes, documentation, security, or configuration?

AI makes first-draft productivity easier to see. It makes downstream productivity more important to inspect.

Code Survival and Effort Survival Are Not the Same Thing

Durability already has competing meanings.

Some tools analyze code survival: whether code remains in the evolving codebase after days, weeks, or months. That is a useful question. If a line or block disappears shortly after it is written, leaders may want to understand whether it was exploratory work, healthy refactoring, a defect fix, duplicate generation, or throwaway output.

GitClear publicly analyzes several code-level durability and maintainability signals, including churn percent, throwaway percent, duplicate code, moved lines, and mature-code update percent. Those signals ask what happened to code.

GitMe's durability question is related but different.

Code survival asks: does code remain in the evolving codebase?

Effort survival asks: how much of an earlier cohort's modeled engineering effort remains effective over time?

Those concepts overlap, but they are not identical. Code can remain while its engineering value changes. Implementation details can evolve while earlier engineering effort still matters. A refactor can remove code while preserving or improving the original intent. A deletion can be cleanup, not failure.

This is why GitMe should not claim to have invented durability measurement, and it should not treat code survival and effort survival as interchangeable.

They are related lenses on a time-based productivity problem.

Effort Survival Cohort

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

"Cohort" simply means that work created during the same period is grouped together and then followed forward through later changes.

The value is not in pretending there is a perfect universal formula. The value is in giving leaders a disciplined way to ask what happened after work first appeared productive.

GitMe's own public September 2026 research snapshot used this kind of durability framing carefully. It reported modeled-effort loss across a 12-month cohort window, while also warning that later cohorts were small and that observed relationships around test deficit and AI-intensive months were associations, not causal findings.

That caution is the point.

Durability metrics should make leaders more precise, not more reckless. They should support investigation, not replace judgment.

What a Productivity Dashboard Should Show Over Time

A useful productivity dashboard should show engineering work across time, not just at a single measurement point.

At creation, leaders need to understand:

Real Effort Value (REV)
work categorization
AI Effort Share
AI Leverage
the mix of feature work, refactoring, tests, bug fixes, documentation, security, and configuration

Shortly afterward, they need to understand:

rework
historical comparison
review and release friction
whether work required quick correction

Over longer periods, they need to understand:

Effort Survival Cohort
whether modeled engineering effort remains effective
which work categories tend to produce durable value
whether AI-assisted work patterns differ by category and context

Around all of it, they need context:

company-level benchmarking
GitMe certification where a defined measurement result needs to be communicated externally
clear caveats about what the data can and cannot prove

This is not a pure GitMe feature checklist. It is a measurement architecture.

Speed tells leaders whether work is moving. Volume tells them how much work appeared. REV helps compare modeled engineering effort. AI Effort Share and AI Leverage separate adoption from leverage. Work categorization explains the portfolio. Rework shows what followed. Effort Survival Cohort adds the long view.

That long view is what makes productivity measurement harder to game and easier to govern.

A Fast Team and a Durable Team Are Not Necessarily the Same Team

Engineering leaders often need to separate five ideas that get blended together:

speed
volume
effort
leverage
durability

A fast team moves work quickly.

A high-volume team produces a lot of visible output.

A high-effort team carries complex or difficult engineering work.

A high-leverage team turns human and AI-assisted effort into more modeled output than the baseline would suggest.

A durable team creates work that remains useful as the product, codebase, and organization evolve.

One team can be strong across all five. Many are not.

That does not make one dimension the "real" metric and the others fake. It means leaders should stop forcing all productivity questions into one number.

A throughput metric can be healthy while durability is weak. A durability metric can be strong while throughput is blocked. AI Effort Share can rise while AI Leverage stays ambiguous. AI Leverage can look promising while rework later increases. A team can improve company-level benchmark position while masking concentration risk or long-term maintainability pressure.

The management job is to understand the pattern.

What Leaders Should Ask

The next generation of engineering productivity review should ask time-aware questions:

How much modeled engineering effort did we create?
What kind of work was it?
What share appears AI-assisted?
What AI Leverage was reported?
How much rework followed?
How did this compare with our own history?
What happened three, six, or twelve months later?
How much earlier modeled effort remains effective?
Which work categories remain durable?
Which patterns create repeated correction?
Are we optimizing for output today or sustainable contribution over time?
What claim should we avoid making from this metric alone?

The last question is important.

Durability metrics can be abused too. They should not punish teams for healthy refactoring, strategic rewrites, or product learning. They should not become individual surveillance. They should not be used to claim causality from observational patterns.

They should make the conversation better.

Conclusion

Engineering productivity should not end at merge, deployment, or shipment.

Those moments matter. They are just not the whole story.

A more complete view asks not only:

"How much did we create?"

but also:

"How much of what we created is still carrying the product forward?"

That is why engineering productivity needs a half-life.

Not as a literal formula. Not as a replacement for speed. Not as a new vanity metric.

As a reminder that engineering value lives in time.