These are the best tools for measuring engineering productivity:

1. Pensero

2. LinearB

3. DX

4. Jellyfish

5. Pluralsight Flow

6. Faros AI

7. Sleuth

Lines of code was never a good metric for engineering performance. Most engineering leaders have known this for years. The problem is that AI has not made it irrelevant, it has made it actively dangerous.

When software production was constrained by human typing speed, LOC was at least correlated with effort. An engineer writing a lot of code was probably doing a lot of work. The correlation was weak and gameable, but it was not completely meaningless.

AI changes that correlation entirely. A developer using Claude Code or Cursor can generate thousands of lines in minutes. An agent-driven refactor can touch dozens of files before lunch. Code generation is no longer the bottleneck. What AI produces is abundant. What matters is whether any of it translates into value.

In the AI era, lines of code are no longer a measure of output. They are a measure of how much code you will need to maintain. Organizations that are still tracking LOC, or its close relatives, commit count and PR volume, are not measuring productivity. They are measuring the size of a future maintenance burden.

The interesting questions are no longer about output at all. They are about delivery impact, quality degradation, AI efficiency, cost visibility, and whether teams are actually generating organizational leverage from the tools they have adopted. These are not the questions LOC can answer.

7 Tools for measuring engineering productivity beyond LOC

The alternatives to LOC vary significantly in what they actually measure and how deeply they connect to business outcomes. The choice between them depends on whether you need to understand deployment pipeline health, developer experience, or the full picture of delivery value, and whether you need that picture benchmarked against real industry peers.

1. Pensero

Pensero is an empowerment tool for engineering performance that brings together real signals from GitHub, Jira, and the tools your team already uses to uncover how work moves, where it gets blocked, and how development practices and AI usage translate into real business impact.

Pensero's answer to the LOC problem is complexity-weighted delivery: every work item scored by AI models and agents for both magnitude, how much content changed, and complexity, how non-trivial the change was. A one-line typo fix scores a fraction of a point. A 600-line refactor spanning multiple services scores many points. Boilerplate and auto-generated code are excluded from scoring entirely.

This scoring model makes two things possible that LOC cannot. First, it produces a fair comparison across engineers doing very different types of work: an engineer doing complex infrastructure changes is not compared unfavorably against one shipping simple UI features on raw volume. Second, it distinguishes AI-generated volume from meaningful delivery, the code that an agent auto-generated and the code that required deep architectural reasoning are not treated the same.

Pensero's 2026 Engineering Benchmark Report measured this metric continuously across thousands of engineers from November 2025 to April 2026. Average complexity-weighted delivery rose 34.2% at the industry median in that period, from 11.4 to 15.3 Pensero points per engineer per week. The top 5% rose 51.4%. These numbers reflect genuine delivery improvement, not activity inflation, because the underlying metric scores value rather than volume.

Pensero Benchmark ranks your organization against real production data from every Pensero customer on 10 delivery dimensions. Pensero Calibrate enables side-by-side comparison of any internal cohort, teams, roles, AI adopters versus non-adopters, contractors versus FTEs, on the same complexity-weighted metrics with company average and industry median as reference lines.

The platform integrates with GitHub, GitLab, Bitbucket, Jira, Linear, GitHub Issues, Slack, Microsoft Teams, Notion, Confluence, Google Calendar, Cursor, Claude Code, GitHub Copilot, Gemini Code Assist, and OpenAI Codex. Zero configuration required. Customers include TravelPerk, ClosedLoop, Elfie.co, and Caravelo. Pricing as of June 2026: free tier up to 10 engineers and 1 repository; $50/month premium; custom enterprise pricing. Compliant with SOC 2 Type II, HIPAA, and GDPR.

2. LinearB

LinearB moved away from LOC toward workflow and cycle time metrics: coding time, pickup time, review time, and deploy time as the primary signals of engineering efficiency. This is a meaningful improvement, it measures how work moves rather than how much code accumulates.

Its benchmarking is based on a self-reported peer database, and its delivery metrics are volume-weighted rather than complexity-weighted, which limits cross-team comparison when work types differ significantly.

3. DX

DX replaces LOC with developer experience measurement, structured surveys that capture how engineers perceive their workflow, tools, and impact. The SPACE framework, which DX uses as a measurement foundation, introduced satisfaction and well-being as explicit productivity dimensions alongside performance, activity, collaboration, and flow. 

This represents a genuine expansion beyond output metrics. DX answers how engineers experience their work; it does not measure what was delivered.

4. Jellyfish

Jellyfish replaces LOC with investment allocation metrics: how engineering effort is distributed across features, maintenance, technical debt, and support. This connects engineering activity to business context rather than counting code volume. 

For organizations that need to translate engineering activity into financial reporting, CapEx versus OpEx, R&D allocation, Jellyfish covers the investment layer. Its delivery performance measurement is DORA-anchored rather than complexity-weighted.

5. Pluralsight Flow

Pluralsight Flow replaces LOC with activity heatmaps and contribution patterns, showing when engineers are working, what types of activity they are engaged in, and where patterns diverge from team norms. It surfaces behavioral patterns that LOC completely obscures. 

The limitation is that activity is still the underlying measurement unit: an engineer generating high-frequency low-complexity activity looks similar to one doing intensive complex work.

6. Faros AI

Faros AI takes a data-integration approach, connecting across a wide range of engineering data sources and applying DORA-based benchmarking with causal analysis for specific attribution questions. 

For organizations that need to move beyond LOC at scale across complex, heterogeneous toolchains, Faros AI provides the data breadth to support that transition. DORA metrics are the primary benchmark framework.

7. Sleuth

Sleuth focuses specifically on DORA metrics via CI/CD pipeline data, replacing LOC with deployment frequency, lead time, change failure rate, and mean time to recovery as the primary productivity signals. This is a useful and well-validated replacement for LOC in the deployment pipeline context. It does not address the broader engineering value question, what was delivered, at what complexity, with what quality, that goes beyond pipeline health.

Why LOC was always flawed, and why AI makes it worse

The foundational problem with LOC was always that software engineering is about solving problems, not generating characters. A highly skilled engineer who refactors a complex module from 500 lines down to 50 lines of elegant, maintainable code has created significant value while producing negative LOC. Under a LOC-based evaluation, this is recorded as a productivity decline.

The incentive distortion is equally serious. When engineers are evaluated on code volume, they optimize for code volume. They avoid necessary refactoring because simplification registers as negative output. They write verbose implementations instead of reusing components. They ship unnecessary features to inflate apparent production. The metric does not just fail to measure what matters, it actively encourages behavior that makes engineering worse over time.

High-performing engineers have always understood something that LOC obscures: every line of code is a liability that must be maintained, tested, and debugged. The best engineering produces less code, not more, more precise, more maintainable, more reusable. LOC penalizes exactly this.

AI removes the remaining justification for LOC entirely. When an engineer can generate thousands of lines in an afternoon, volume is trivially achievable. The organizations that still track LOC will watch their metrics improve dramatically as AI adoption increases, while having no idea whether any of that code is delivering business value, introducing technical debt, or being generated and then reworked in the same sprint.

Are we shipping faster than before?

This is the productivity question LOC was always supposed to answer, and always answered wrong. More lines of code this week than last week does not mean more is being shipped. It means more code exists.

The relevant measure of shipping speed is how much meaningful, complex, valuable work is reaching production per engineer per week, complexity-weighted delivery, not volume. This metric does not inflate when an AI tool generates boilerplate. It does not deflate when an engineer does a clean refactor. It measures what actually happened in the delivery system.

Pensero's 2026 benchmark data makes the gap between volume metrics and value metrics concrete. The 34.2% increase in average industry delivery over six months was not measured in lines of code, it was measured in complexity-weighted work items per engineer per week. An organization tracking LOC over the same period, with AI adoption rising, would likely show delivery increases of several times that magnitude. The LOC number would look impressive. It would be telling a completely different story.

Is AI actually making us more productive or just generating more code?

This is the question that exposes the LOC problem most starkly in 2026. AI generates code at a rate human engineers never could. If LOC is your productivity metric, AI always looks like a massive win. If complexity-weighted delivery per headcount is your metric, the picture is more complicated, and more honest.

The distinction matters because AI-generated code needs to be reviewed, maintained, tested, and understood. The volume benefit of AI is real. The quality risk of accepting AI suggestions without adequate review is also real. An organization whose LOC doubled after AI adoption but whose defect rate also rose significantly has experienced volume inflation, not productivity improvement.

Measuring delivery impact, is AI actually increasing the meaningful, complex, valuable work that ships, with stable or improving quality, requires a metric that distinguishes AI-generated volume from AI-augmented value. That distinction is exactly what complexity-weighted delivery scoring provides, and what LOC is structurally incapable of making.

What are our best engineers doing differently?

LOC-based rankings consistently misidentify high performers. The engineer who generates the most code is often not the engineer creating the most value. The relationship runs in the opposite direction: engineers who write less code but solve more complex problems, whose refactors reduce system complexity rather than add to it, whose reviews catch issues before they compound, these are the high performers that LOC makes invisible.

Andrew Eye, CEO of ClosedLoop, described the organizational transformation that visibility into actual delivery enabled: "I was being told we were slow to ship, but I didn't have any visibility as to why that was. With Pensero we go 4x faster." The visibility he gained was into what was actually being delivered, not how much code was being written.

The engineers whose practices drove that 4x improvement were visible not in LOC data but in complexity-weighted delivery trends, collaboration signals, and quality metrics. Those are the behavioral patterns worth identifying, understanding, and replicating across the team.

Did quality improve or degrade?

LOC says nothing about quality. A codebase can grow in line count while accumulating defects, increasing knowledge concentration, and reducing maintainability simultaneously. The metric and the quality of what is being measured are completely orthogonal.

The quality dimensions that matter alongside delivery are defect rate, what share of engineering capacity is going to bug fixes rather than new value, and knowledge gaps, how concentrated is code knowledge in single contributors. Both of these can deteriorate while LOC climbs, and neither is visible in volume metrics.

In an AI-first environment, the quality tax is the critical signal to track alongside delivery. As described in Pensero's AI Impact data, one customer workspace saw a 1.2x delivery lift alongside a 13.2 percentage point rise in rework as AI adoption grew. The LOC metric in that period would show strong growth. The complexity-weighted delivery metric shows the delivery lift. The quality tax metric shows the cost. All three are part of the honest productivity picture.

The metrics that should replace LOC

Replacing LOC is not about picking one alternative, it is about understanding that productivity in engineering is multi-dimensional, and the right measurement framework covers the dimensions that actually connect to business outcomes.

• Complexity-weighted delivery per headcount is the primary output metric: how much meaningful, non-trivial, non-generated engineering value is each engineer producing per week. This normalizes for team size, accounts for work complexity, excludes AI-generated boilerplate, and produces a number that is comparable across teams, roles, and time.

• Defect rate is the quality gate alongside delivery: what share of delivery is going to rework rather than new value. Rising defect rate alongside rising delivery signals that the delivery volume is partially artificial, created and reworked in the same period.

• Cycle time is the speed dimension: how long it takes for work to move from ticket to merged code. This captures workflow efficiency without rewarding code volume.

• Innovation rate is the strategic alignment dimension: what share of delivery is new product value versus maintenance, sustaining work, and rework. This connects the engineering productivity picture to whether the investment is building durable value or paying back accumulated debt.

• AI adoption alongside all of the above is the modern dimension that LOC actively obscures: is AI increasing delivery per headcount with stable quality, or is it inflating volume without improving the metrics that actually matter?

Pensero's ROI calculator lets engineering leaders quantify what moving from activity metrics to outcome metrics actually changes, benchmarked against VC and PE portfolio companies running the platform, with projected annual benefits reaching up to $2.0M for a team of 100 engineers.

Frequently Asked Questions

Why is lines of code a bad measure of developer productivity?

LOC measures quantity of code produced, not value delivered. It penalizes refactoring, high-value work that reduces codebase size, and rewards verbosity and copy-paste. It varies dramatically across languages and frameworks, making cross-team comparison meaningless. It produces misaligned incentives: engineers optimizing for LOC avoid simplification and write more code than necessary. In the AI era, it becomes actively misleading because AI tools can generate large volumes of code instantly, making LOC a measure of AI usage rather than engineering contribution.

What is the key difference between Pensero and LinearB?

LinearB is built around flow optimization, DORA metrics, PR automation, cycle time. Pensero adds complexity-aware performance measurement on top, so teams shipping fewer, harder changes aren't penalized against teams merging high volumes of simple ones.

What should replace lines of code as a productivity metric?

Complexity-weighted delivery per engineer per week is the primary replacement, it measures the value of what was shipped, not the volume of code that was written. Alongside it: defect rate to capture quality, cycle time to capture speed, innovation rate to capture strategic alignment, and AI adoption to connect tool investment to delivery outcomes. Together, these metrics provide a multi-dimensional productivity picture that LOC never could. Pensero's framework covers all five in a continuously updated, externally benchmarked view.

What is the main difference between Pensero and Jellyfish?

Jellyfish is commonly used to understand engineering investment allocation. Pensero focuses on whether that investment is converting into meaningful, complexity-aware delivery outcomes.

How is Pensero different from Faros AI?

Faros AI is often associated with broad engineering data infrastructure and integration-heavy analytics. Pensero is more productized for objective performance measurement and leadership decision workflows.

Do DORA metrics replace LOC effectively?

DORA metrics replace LOC within a specific domain, deployment pipeline health. They measure how often you deploy, how fast changes move from commit to production, how often deployments fail, and how quickly failures are recovered. These are meaningful signals about operational reliability. They do not measure the complexity or value of what is being deployed, the quality of code review, the distribution of engineering contribution, or whether AI adoption is producing genuine returns. DORA is a necessary part of the picture but not a complete replacement for LOC in the broader engineering productivity context.

How does AI adoption change the case against LOC?

AI fundamentally breaks the remaining correlation between LOC and effort. Before AI, writing a lot of code at least implied spending a lot of time writing code. AI removes that inference: large volumes of code can be generated in minutes, often with no particular correlation to engineering judgment or value. Organizations tracking LOC will see metrics improve dramatically as AI adoption increases, while having no insight into whether that code is delivering value, introducing defects, or being generated and immediately reworked. The case against LOC was always strong. AI makes it unanswerable.

How do you benchmark engineering productivity without LOC?

By benchmarking on complexity-weighted delivery per headcount, defect rate, cycle time, and innovation rate, against real production data from comparable engineering organizations, not self-reported surveys. Pensero Benchmark provides this: percentile rankings on 10 delivery dimensions across the full Pensero customer base, updated weekly, built on observed delivery data rather than estimates or surveys. This is what turns productivity measurement from an internal comparison exercise into an externally referenced assessment of whether the organization is competitive.

Is commit count a better alternative to LOC?

No. Commit count shares most of LOC's flaws: it rewards frequent, small commits over substantial architectural work, it does not account for the complexity or value of what was committed, and it inflates when AI tools generate frequent auto-commits. It is a marginally better activity signal than LOC in that it captures development cadence rather than code volume, but it is equally disconnected from delivery value and equally gameable. Like LOC, it measures inputs rather than outcomes.

How should engineering leaders communicate productivity to boards without LOC?

Through externally referenced outcome metrics rather than internally relative activity counts. "Our complexity-weighted delivery per headcount ranks in the 72nd percentile against real peer data, up from the 60th percentile six months ago, with defect rate stable at the 80th percentile" survives board scrutiny because it is grounded in measured comparisons against real organizations. "We wrote 20% more code this quarter" does not survive the first follow-up question about whether any of that code was AI-generated, whether quality held, or whether comparable organizations did more. The board conversation about engineering productivity needs to be anchored in outcome data, not activity volume.