Engineering Output is Larridin's new top-line metric for engineering velocity. It starts from the same delivery data teams already collect — pull requests, lines of code, commits — weights every merged PR by its real complexity, and then subtracts penalties for quality problems such as missing tests and AI slop. The result is a single number that reflects how much real engineering work shipped, not how much activity occurred.
Today we are introducing it as the successor to complexity-adjusted output, the metric we launched earlier this year. This post explains why measuring engineering output has been so hard, what complexity adjustment got right, where it fell short, and how Engineering Output closes the gap.
Key Findings
| Finding | What It Means for Engineering Leaders |
|---|---|
| Activity metrics were always proxies. | PR counts, lines of code, net lines, and lines touched correlate with output directionally, but they measure motion, not work delivered. |
| Complexity adjustment fixed the volume problem. | Weighting each PR by difficulty stops a hundred-line CSS tweak from outscoring a ten-line concurrency fix. |
| Complexity alone still misses quality. | A complex change that ships without needed tests, or that rots into rework and incidents, is not the same output as one that holds. |
| The complexity curve is not linear. | In real delivery data, the effort gap between a complexity 2 and a complexity 3 is far more than one step, and it compounds toward 5. Points have to grow superlinearly. |
| Engineering Output is complexity minus quality debt. | Each PR earns complexity points on a superlinear curve, then loses points for missing tests and AI slop. Summed across the org, it is one defensible velocity number. |
Measuring Activity Was Never Measuring Output
Engineering output has resisted measurement for decades. Because output itself was hard to see, the industry measured what was easy to count instead: pull requests merged, commits pushed, lines of code written, net new lines, lines touched.
None of these numbers are useless. Across a large enough team and a long enough window, they move in roughly the same direction as real output. But they are activity metrics. They count how often engineers touched the codebase, not how much engineering was accomplished — and the difference between those two things is exactly where the metrics break.
AI made the gap impossible to ignore. Coding assistants and agents can multiply PR counts and line counts overnight. GitClear's analysis of 211 million changed lines found that heavy AI users produce dramatically more commits — along with far more churn and duplicated code — while METR's randomized trial found experienced developers using AI tools completed tasks 19% slower while believing they were 20% faster. Activity went up. Output did not go up to match. Any metric that cannot tell the two apart now inflates by default, which is the same failure mode that breaks DORA metrics in the AI era.
What Complexity-Adjusted Output Got Right
Earlier this year we introduced complexity-adjusted output to attack this problem directly. Instead of counting PRs, we scored the complexity of each PR. A ten-line change to distributed locking logic earns a higher weight than a hundred-line batch of simple CSS changes, because it embodies more engineering.
Each pull request is scored across five dimensions:
| Dimension | Question It Answers |
|---|---|
| Logic | How intricate is the reasoning in the change — algorithms, control flow, edge cases? |
| Scope | How much of the system does the change touch — files, modules, services, teams? |
| Architecture | Does the change alter interfaces, data models, or the structure of the system? |
| Risk | What is the blast radius if this change is wrong? How critical is the path it sits on? |
| Novelty | Is this a well-worn pattern, or new ground for this codebase and team? |
Complexity adjustment was a real improvement. It gave senior engineers credit for the hard, small changes that raw metrics made invisible, and it stopped AI-generated boilerplate from reading as a productivity miracle. Teams that adopted it — including through our earlier complexity-adjusted throughput work — got a far more honest view of velocity than PR counts ever gave them.
But as we watched the metric operate against real engineering organizations, two problems became clear.
Two Problems We Had to Fix
Complexity carried no quality signal
Complexity-adjusted output scored what a PR attempted, not what it delivered over time. A complex change that shipped without the tests it obviously needed scored the same as one that pinned its behavior down. A change that looked impressive at merge time and then generated bugs, incidents, and rework scored the same as one that survived production untouched.
That is a serious blind spot in the AI era specifically, because AI-assisted code fails in a characteristic way: it looks polished and merges cleanly, then quietly becomes maintenance burden. We built the AI Slop Index to detect exactly this pattern, and the data behind it — duplication growing 4–8x, refactoring collapsing, 9x churn among heavy AI users in GitClear's research — shows how much apparent output is really future cleanup. A velocity metric that cannot see quality rewards precisely the wrong behavior.
The complexity curve is not linear
The second problem was subtler. Complexity scores run from low to high, and the natural assumption is that the steps between them are even — that a 3 is one unit harder than a 2, and a 5 is one unit harder than a 4.
The real world does not behave that way. When we compared complexity ratings against the effort the work actually demanded — how long changes took, how much review they consumed, how much expertise they required — the curve bent sharply upward. The jump from 2 to 3 was much bigger than one step. By the time you approach complexity 5, the growth is close to exponential: a 5 represents the kind of architectural, high-risk, novel work that can consume a senior engineer for weeks.
A linear points scale therefore systematically under-credited the hardest work in the organization — the exact work the metric existed to surface.
What Is Engineering Output?
Engineering Output is the metric that resolves both problems. It keeps everything complexity adjustment got right and adds what it was missing.
It works in three layers:
- Core delivery data. Engineering Output starts from the ground truth teams already have: merged pull requests, the code they change, and the delivery metadata around them.
- Complexity points on a superlinear curve. Every PR is scored for complexity across logic, scope, architecture, risk, and novelty, and the score is converted to points on a curve that reflects the real cost of hard work. A complexity-5 change is worth many multiples of a complexity-2 change — not two and a half times.
- Quality penalties. Points are then reduced for concrete, observable quality failures in the change itself.
The launch set of penalties targets the two failure modes we see most often in AI-assisted delivery:
| Penalty | What Triggers It |
|---|---|
| Missing tests | The change alters behavior in a way that clearly warrants tests, and no tests were added or updated. |
| AI slop | The change exhibits the slop patterns the AI Slop Index scores: low signal-to-noise, unnecessary abstractions, unreviewed paste, defensive bloat, and reinventing the wheel. |
The penalty framework is deliberately extensible. Missing tests and AI slop are leading indicators we can score at merge time; downstream durability signals such as code turnover, rework, and incident-linked changes complete the same picture over time.
What comes out the other side is one number: complexity-weighted work delivered, net of quality debt created. Summed per team or per organization, week over week, it tells an engineering leader how quickly the org is actually moving.
Evidence and Methodology
Engineering Output is computed per pull request and aggregated upward.
- Scoring. Each merged PR receives a complexity score informed by the five dimensions above — logic, scope, architecture, risk, and novelty. Scoring is holistic rather than a mechanical formula over the dimensions, and it is calibrated against the norms of the repository, so a routine change in one codebase does not masquerade as novel work in another.
- Superlinear weighting. Complexity scores map to points on a superlinear curve fitted to observed effort, not to a linear scale. This is the correction for the slope problem: the point gap between 4 and 5 is much larger than the gap between 1 and 2.
- Penalty assessment. The same PR is evaluated for missing tests and for the five AI slop signals. Penalties subtract from the PR's earned points. Clean, well-tested work keeps everything it earned; a high-complexity PR that arrives untested and padded with slop keeps much less.
- Aggregation. Points net of penalties are summed per engineer, team, and organization over a reporting window. The trend line, and the decomposition beneath it, is the product.
Because both the complexity score and the penalties are computed from the change itself, Engineering Output is a leading indicator. It moves at merge time, weeks before churn, incident, and rework metrics confirm what happened — and it pairs with behavioral signals like verification discipline to show not just what shipped but whether anyone actually checked it.
Concrete Operator Scenario
An engineering leader runs two platform teams through a quarter of aggressive AI adoption.
Team A's dashboard looks spectacular: PR count up 60%, lines of code up 3x. Team B's dashboard looks flat: roughly the same PR count as last quarter.
Under Engineering Output, the picture inverts. Team A's new volume is concentrated in low-complexity changes, and a growing share of it draws penalties — scaffolding merged without tests, duplicated utilities, defensive bloat around code nobody read closely. Its Engineering Output rose only modestly, and its penalty share is climbing, which predicts the rework wave before it arrives.
Team B's PR count is unchanged, but its engineers are using agents to take on higher-complexity work — an architectural migration and two high-risk fixes that score at the top of the curve, all tested, none drawing slop penalties. Its Engineering Output is up 40%.
Every activity metric said Team A accelerated and Team B stalled. The truth was the opposite, and Engineering Output is the number that says so — with the decomposition to prove it, PR by PR.
Measurement Approach
For leaders adopting Engineering Output, the practices that make it useful are the same ones we recommend for any AI-native developer intelligence metric:
- Track trends, not absolutes. The week-one number matters less than the slope over a quarter and the mix underneath it.
- Decompose before acting. When output moves, look at the components: did complexity mix shift, did penalties spike, did volume change? Each points to a different intervention.
- Watch the penalty share. Rising penalties with rising volume is the signature of AI adoption outrunning review capacity — the earliest actionable warning the metric produces.
- Segment by AI involvement. Comparing AI-assisted and human-only work reveals whether agents are absorbing real complexity or only manufacturing activity.
- Keep it at team altitude. Engineering Output is a system diagnostic, not an individual leaderboard. Use it to fix workflows, tooling, and review practice — not to rank people.
Caveats And Failure Modes
A single top-line number is powerful, which is exactly why it needs guardrails.
| Failure Mode | Better Approach |
|---|---|
| Ranking individual engineers by output score. | Complexity mix is largely assigned, not chosen. Use the metric at team and org level to diagnose the system. |
| Treating the number as the goal. | Any target metric invites gaming. Keep the decomposition visible so inflated complexity or penalty avoidance shows up immediately. |
| Reading penalties as blame. | Penalties localize quality debt to the change that created it. They are a coaching and process signal, not a disciplinary one. |
| Using Engineering Output alone. | It measures shipped engineering work. Pair it with delivery outcomes like AI-native DORA metrics and durability signals like code turnover for the full picture. |
| Assuming all untested changes are equal. | The missing-tests penalty applies where tests were clearly warranted. Documentation tweaks and generated configuration are not scored like behavior changes. |
What To Do Next
If you lead an engineering organization, start with an honest audit of what your current dashboard rewards. If the answer is volume — PRs, lines, commits — then every AI tool you roll out will make the dashboard better and your visibility worse.
Then instrument the two corrections this post describes. Weight work by complexity so hard engineering stops being invisible, and net out quality so slop stops counting as progress. That is the whole idea of Engineering Output, and it is how we now measure engineering velocity at Larridin: one number an engineering leader can take to the board, backed by a PR-level decomposition an EM can act on Monday morning.
Engineering Output is rolling out to Larridin customers now. If you want to see your organization's number — and what is inside it — reach out through larridin.com.
Related Pages
- Complexity-Adjusted Velocity: The Right Way to Measure AI-Powered Engineering Teams
- Developer Intelligence: What Is the AI Slop Index?
- What Is AI Slop? How to Detect and Prevent Low-Quality AI-Generated Code
- What Is Code Turnover Rate? The AI Code Quality Metric
- What Is Verification Discipline?
- AI-Native DORA Metrics: How to Measure Delivery in the Agent Era
FAQ
What is Engineering Output?
Engineering Output is Larridin's metric for real engineering velocity. Every merged pull request earns complexity points — scored across logic, scope, architecture, risk, and novelty on a superlinear curve — and then loses points for quality failures such as missing tests and AI slop. Summed across a team or organization, it is one number for how much engineering work actually shipped.
How is Engineering Output different from complexity-adjusted output?
Complexity-adjusted output weighted PRs by difficulty but stopped there. Engineering Output keeps the complexity core and adds two corrections: complexity points grow superlinearly, matching the real effort curve between low and high complexity work, and quality penalties subtract for changes that ship without warranted tests or with AI slop patterns.
What counts as AI slop in the penalty?
The penalty uses the same five signals as the AI Slop Index: low signal-to-noise, unnecessary abstractions, unreviewed paste, defensive bloat, and reinventing the wheel. These patterns mark code that looks productive at merge time but creates avoidable maintenance and correctness cost later.
Is Engineering Output a per-engineer performance score?
No. It is computed per PR and aggregates to any level, but it is designed as a team and organization diagnostic. Complexity mix is largely a function of what work gets assigned, so individual rankings mostly measure ticket routing. Use it to find where the system — review practice, agent workflows, test culture — needs attention.
Does Engineering Output replace DORA metrics?
It complements them. DORA measures delivery outcomes like deployment frequency and failure rate; Engineering Output measures the engineering work content flowing through that pipeline, net of quality debt. Together they answer both "are we shipping reliably?" and "are we actually building at the rate the dashboards claim?"