A normalized measure of engineering output: Work Units

As engineering teams look to ‘make every token count’, tokenomics is suddenly a very hot topic.

Tokenomics (AI token economics) sets out to quantify the ROI of AI spend across engineering teams.

Measuring the fully loaded cost of AI use is relatively easy. Measuring its benefit is far harder, because it leads back to the oldest question in software engineering: how do you measure engineering output, and how does it translate into value?

Work Units answer the first half. They size each Pull Request by the implementation work it actually contains, so a one-line config tweak and a multi-file refactor no longer count the same. The result is a practical, scalable measure of engineering output, consistent enough to anchor AI ROI calculations and broader business decision-making, when read alongside quality signals.

What is a Work Unit?

A Work Unit is Plandek’s normalized measure of the implementation work in a pull request. It sizes each pull request by the scale of its code change. The score accounts for whether code is new or reworked, how many files and folders the change touches, and the fact that each additional line adds less than the last. Auto-generated code, dependency lockfiles and vendored libraries are excluded. 

Because every pull request is scored the same way, Work Units can be compared across teams and over time. That makes them a consistent measure of engineering output, including when assessing the return on AI spend.

The problem: why PR throughput isn’t the full picture

To “quote” George Orwell: ‘All PRs are equal, but some PRs are more equal than others.’

Relying on raw PR (Pull Request) counts to measure engineering output assumes all PRs represent similar effort, creating a distorted picture of delivery that is not robust enough to use in an ROI calculation.

Relying on raw PRs creates a false equivalence. A 1-line configuration change, an updated dependency lockfile, a brand-new feature endpoint, and a complex multi-file refactor are all treated as "1 PR."

One team might ship 50 single-line config tweaks in a month, while another ships 5 complex architectural overhauls. On paper, the first team appears 10x more active despite doing a fraction of the implementation work.

In essence, PRs are inherently incomparable without understanding the underlying scope and nature of the change – and hence cannot be considered a ‘normalized’ measure of engineering output.

The first step to normalized PRs: the PR Efficiency Quotient

The PR Efficiency Quotient is a simple measure of ‘PR efficiency’: it compares PR output with team size (excluding AI agents) and with the time PRs take to merge.

Where:

• PR Throughput = total number of pull requests merged

• Time to Merge PR = average time taken from PR creation to merge

• Number of Developers = total active contributors involved in PR activity

It is a reasonable starting point, but it still treats every PR as the same size. It rewards a stream of tiny changes and doesn’t recognize that a sizeable change is a different proposition altogether. Sizing each PR with Work Units fixes this, normalizing for size and creating a more accurate measure of output and a sounder basis for the AI ROI calculations used by commercial finance teams.

Introducing Work Units

The Plandek data science team has established a Work Units model: a size signal designed to reflect the real volume of implementation work inside a Pull Request.

Work Units measure the code changes themselves, not ideation, architectural design, planning or debugging, to answer one core question: how much actual implementation work is in this change? Whether a person or an AI agent wrote the code, Work Units measure the scale of the change, not the human time or effort behind it. Combined with other Plandek metrics, Work Units provide valuable insight into what is happening across your system.

What the Work Units model accounts for (high level):

• Rework vs. additions: Rewriting existing code requires more context and effort than simply adding new lines, so the model weights rework differently from raw additions.

• Diminishing effort per line (the “in-the-flow” principle): The effort behind a change isn’t linear. The hardest part is building the mental context for the first few lines; by the 101st line you’re in the flow, and each extra line takes less incremental work than a precise 2-line targeted change. The scale reflects this natural curve, which also means one large bundled PR scores less than the same work split into smaller PRs, so the measure doesn’t reward the oversized PRs that carry the most risk. That reflects real work too: deciding where to split a change takes thought, and each PR has to be raised and merged.

• Filtering out noise: Automatically identifies and excludes auto-generated code, vendored libraries, dependency lockfiles and bulk exports, so machine-generated churn doesn’t inflate scores.

• Breadth of impact: Takes structural reach into account, recognizing that spreading changes across multiple files or folders represents a broader scope than modifying a single localized file.

The chart above shows Work Units across more than 1.1 million PRs. As you’d expect, most changes are small, with a long tail of larger ones. PRs scoring over 100 are grouped together on the right, and include large changes such as release merges into main.

Why a first-principles model

Measuring engineering effort has a fundamental problem: there is no objective record of the “right answer” to learn from. Hours logged, story points and review time are all noisy, subjective, or measure something else entirely.

Rather than training a system to imitate an imperfect proxy, Work Units starts from explicit reasoning about what drives implementation effort: how effort scales with the size of a change, which changes are machine-generated, and what a deletion or a wide-reaching change really represents.

Data science plays a central role, surfacing patterns across real codebases and checking each factor against real score distributions, but the rules themselves stay explicit and versioned. The same change is always scored the same way in each version, and every score has a clear, explainable basis. The result is a measure that is consistent and comparable across teams and over time - which is what a figure underpinning ROI decisions needs to be.

The model was developed with Plandek’s own engineers and tuned by checking scores against PR authors’ and team leads’ judgment of their own work. It runs in our own code reviews, where authors see each score straight after making the change, and we have reviewed scores with two customers against PRs from their own codebases.

How to use Work Units to measure engineering output

As an accurate and scalable measure of engineering output, Work Units have huge value in a number of use cases:

• Tracking true codebase movement: Measure how much the codebase is actually changing over time, independent of artificial spikes in PR count or vendor auto-generations.

• Keeping PR size in check: Large, bundled changes carry risk from volume alone. Work Units let teams set size targets, flag oversized PRs early, and encourage smaller, safer, more continuous delivery.

• Estimating review burden: Work Units show the scale of a change, so before a review you can use them alongside the PR description and context to judge how much time to set aside.

• Evaluating engineering trends with context: Compare delivery trends across teams and timeframes using a standardized, human-readable size scale (1 to 50+) rather than misleading raw line or PR counts.

• Sizing implementation investment across Value Streams & Epics: Aggregating Work Units estimates how much technical implementation work went into an initiative or Epic. While it doesn’t capture planning, design or discovery, it gives product and engineering leaders a grounded, readable signal of the code-level effort behind that business value, making capacity and effort comparisons across features far more realistic.

What Work Units are (and what they are not)

Work Units are an extremely useful tool to more accurately measure engineering output, but care does need to be taken in how/where they are applied. They should never be used to rank or target individual developers: like any output measure, they lose their value once people are rewarded for inflating them.

• What Work Units ARE: A readable sizing signal and comparison tool for engineering changes, most powerful when analyzed in aggregate over time.

• What Work Units ARE NOT:

  • A value or quality judgment: A 2-unit PR that fixes a critical production bug delivers far more business value than a 40-unit internal cleanup. When judging AI ROI, pair Work Units with quality signals such as change failure rate and rework: output alone doesn’t show whether the extra code was worth having. A rise in Work Units between two periods shows more output only when the mix of work and the quality of what ships are comparable.

  • A time estimate: It reflects implementation scale, not the hours spent thinking, testing, or designing the fix.

  • A full view on complexity: a wide ranging PR that does a lot of refactoring is recognized, but we only look at the metadata (e.g. file types, number of changes) and so the modeling doesn’t include code complexity or impact.

Looking forward

Work Units is refined continuously. Real codebases keep surfacing edge cases worth handling better, and every refinement is measured against score distributions across real codebases before it is adopted. When the rules change, the full history is rescored under them, so trends always compare like with like.

AI is changing the shape of engineering work, and one of the clearest effects is size. AI-assisted development is pushing PRs larger, and a release that bundles a large volume of change carries more risk from volume alone. As the typical PR grows, a raw PR count hides the shift entirely.

Work Units makes it visible. Teams can see how their median PR size is moving, set targets that keep changes reviewable, and stay ahead of the trend rather than being surprised by it. And because every rule is explicit, the model can be adapted deliberately as new patterns emerge, without losing the consistency that ROI comparisons depend on.

Consistent scoring has another benefit: over time, Work Units build into a reliable history of completed work. That history opens the door to forecasting, whether that’s estimating how much your current capacity is likely to deliver, or sizing a backlog, a body of tech debt or a set of bug fixes before committing to a plan.

Which brings us back to where we started. Tokenomics asks whether AI spend is paying off, and that question can only be answered with a measure of output that is consistent, explainable and comparable over time. Raw PR counts can’t provide that; Work Units can. Paired with quality signals such as change failure rate and rework, they give engineering and finance leaders a shared, defensible view of what their teams, and their AI tools, are really delivering, so that every token can be made to count.

What is your AI spend delivering?

Plandek’s free AI Impact Report uses your own Git and AI tool data to show whether your engineers are producing more output, how much AI-assisted work ships and how many tokens each piece of work takes. 

Your results are benchmarked against 2,500+ engineering teams. We handle the setup, and your report arrives within seven days. No subscription, no commitment.

Get your free AI Impact Report