Why lines of code fall short as a developer productivity metric in the age of AI
AI has made code easier to produce and harder to trust. Here's what engineering leaders should measure instead.
Taylor Bruneaux
Analyst
Lines of code (LOC) has been a default proxy for developer output for as long as engineering has been managed like a business function. It has been an unreliable one for just as long. Organizations return to it under pressure to show a number that moves, and the same pattern follows: teams optimize for the metric, not the outcome, and the number rises while the value it was meant to represent does not.
This article explains why physical line counts, logical Source Lines of Code (SLOC), or any variant of counting lines fall short as a measure of software development productivity. It also covers where LOC still has a narrow, legitimate use, and what a more complete measurement approach looks like.
That question matters more now because of AI. As coding assistants and agents generate a growing share of the codebase, engineering leaders face real pressure to show the investment is working. Recent industry survey data of 12,000+ knowledge workers and 170+ executives at Fortune 1000 companies, published by the Atlassian Teamwork Lab, found that only 6% of executives feel confident they can point to specific, organization-wide AI ROI.
Only 6% of executives feel confident they can point to specific, organization-wide AI ROI. Volume metrics won’t close that gap, they can make it harder to see.
Code volume metrics, lines of AI-generated code, token counts, percentage of AI-authored code, feel like an answer to that gap. They describe how work is changing. They don’t show whether it’s producing better outcomes, and used on their own, they can make the ROI question harder to answer honestly, not easier.
What this means for leaders
- LOC is a size metric, not a value metric. It has legitimate, narrow uses, and no legitimate use as a stand-in for productivity or ROI.
- Our research shows the share of AI-authored code climbed from 24% to 52.7% over three quarters, and pull request size has trended toward nearly double what it was before AI tools became widespread.
- Over the same period, code maintainability improved 3.8%, but developers’ confidence that a change won’t break something, change confidence, fell 6.1%. Output moved. Trust did not.
- The Developer Experience Index (DXI) fell from 67 to 65 in this window. This is the kind of signal a volume metric can’t surface.
- The direction forward isn’t a better volume metric. It’s pairing every output number with a quality or effectiveness counterweight, which is what the DX Core 4 and AI Measurement Framework are built to do.
What is LOC in software engineering?
LOC stands for lines of code. It’s a metric in software engineering that attempts to quantify the size of the code, measuring a software program’s size by counting the number of lines in its source code. Some teams call this same idea code lines, coding lines, or simply line code, and shorten it to LOC or, informally, LOC code. Broken down letter by letter, L stands for lines, O stands for of, and C stands for code.
Teams use LOC to size a codebase or a piece of work. It’s one of the oldest metrics in software engineering, and one of the most commonly misapplied.
There are two common variants of the lines of code metric. Physical LOC counts every line, including blank lines and comments. Logical Source Lines of Code, or SLOC, isolates only the lines that contribute to functionality, executable statements and declarations, excluding comments and whitespace. A given file’s SLOC value is typically lower than its physical LOC value, since comments and blank lines are stripped out.
Neither definition is standardized across tools or teams. A metric that can’t be measured consistently can’t support a fair comparison.
This concept goes by different names outside English-language contexts as well, including línea de código or líneas de código (Spanish) and linha de código or linhas de código (Portuguese). The definition is the same: a count of the lines that make up a piece of source code.
Lines of code example: Python, Java, and HTML
The gap between physical and logical counts, and between languages, is clearest side by side.
Python (logical LOC)
This Python script has three logical LOCs: the function definition line, the return statement, and the print function call. Comments and blank lines would be included in physical LOC but not logical LOC.
def add(a, b):
return a + b
print(add(2, 3))
Java (logical LOC)
This Java example has 7 logical LOC: the class declaration, main method declaration, println statement, add method declaration, and the return statement. As with Python, comments and blank lines are excluded.
public class Addition {
public static void main(String[] args) {
System.out.println(add(2, 3));
}
public static int add(int a, int b) {
return a + b;
}
}
HTML (physical LOC)
Counting physical LOC in this HTML document produces 9 lines. Logical LOC doesn’t typically apply to markup languages like HTML, since they don’t contain executable code in the same sense as programming languages.
<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
</head>
<body>
<h1>This is a Heading</h1>
<p>This is a paragraph.</p>
</body>
</html>
The same functionality, adding two numbers and printing the result, produces very different counts depending on the language and the counting method. Across a portfolio of teams working in different stacks, that inconsistency compounds. Cross-team comparisons built on LOC are not comparing like with like.
Where LOC still earns its keep
LOC has a real, narrow use case. It’s worth naming before explaining where it breaks down, because the argument against LOC as a productivity metric is stronger when it isn’t overstated.
Cost-estimation models have used LOC as an input for decades. It’s not precise, but codebase size is a real driver of maintenance burden and migration effort. A sudden, unexplained spike or drop in a repository’s line count is a useful trigger to investigate, even though the number itself doesn’t explain the cause.
When scoping a legacy migration or acquisition, a line count is a reasonable first input for a project plan or budget. And a pull request that’s 50 lines versus one that’s 5,000 lines is a legitimate signal that the two changes need different review approaches, before anyone reads either diff.
What LOC has never been suited for is standing in for productivity, skill, or the value delivered by a person, team, or AI investment. Size and value are different questions. Everything below follows from asking LOC to answer the second one.
The misleading nature of LOC
More lines, more output, is an intuitive read. It’s also wrong in a way that distorts behavior the moment it’s tied to evaluation, budget, or recognition.
Skilled engineers routinely solve problems with less code, not more. A metric that rewards volume rewards the opposite of skill.
The variability across programming languages
LOC measures don’t account for variability across programming languages. A task accomplished with a hundred lines of code in one language (e.g., C++) might take a few lines in another (e.g., Python). Most organizations run a polyglot stack, which means teams are compared on a metric shaped more by language choice than by skill or effort.
The quality over quantity paradigm
In software development, quality often trumps quantity. A smaller, well-refined codebase is usually more valuable than a large one, because it determines maintenance cost, incident rate, and how fast the next feature ships.
Bill Atkinson wrote substantial portions of the Macintosh operating system with concise, efficient code. One example doesn’t prove a rule, but it illustrates the pattern research on this topic keeps surfacing: engineers who produce the most value often produce the least code per unit of that value.
The impact of code complexity and refactoring
More lines of code tend to increase cognitive complexity, making software harder to maintain and more prone to defects. Refactoring, restructuring code without changing its behavior, often shrinks the line count while improving quality and maintainability.
A metric built around LOC discourages the practice that keeps a codebase healthy.
The role of non-executable statements
LOC counts don’t distinguish between executable and non-executable statements. Comments matter for maintainability but contribute nothing to functionality. Folding them into a productivity number implies that more comments, or more blank lines, make someone more productive. They don’t.
LOC in the age of AI: what the data shows
AI coding assistants and agents haven’t resolved the problems above. They’ve removed the natural limit on them. A developer’s output was historically bounded by how fast a person could think and type. That constraint is gone.
Recent research across 500+ engineering organizations shows a consistent pattern.
The share of AI-authored code climbed from 24% to 34% to 52.7% over three consecutive quarters. Once AI tooling is in place, its output spreads through a codebase quickly. Pull request size trended toward nearly double what it was before AI tools became widespread, over the same window.
Overall throughput did increase. Median weekly pull-request output, measured with TrueThroughput, rose 37% over four quarters. That’s genuine acceleration in raw output, but output and velocity aren’t the same thing, and that distinction is where the rest of this story lives.
The concern is what moved alongside it. The DXI, DX’s validated measure of developer productivity, fell from 67 to 65 over the same period, driven in part by declining incremental delivery, the practice of shipping small, testable changes rather than large batches, and slower review turnaround.
Code maintainability and change confidence usually move together. In this data, they decoupled. Maintainability, how easy code is to read and understand, improved 3.8%. Change confidence, whether developers trust a change not to break something, fell 6.1% in the same window.
Change failure rate also became more volatile, not just higher. Some organizations are now seeing swings of +/-3 percentage points against a roughly 4% industry benchmark. This is a pattern that predates AI, but AI has amplified it.
The innovation ratio, time spent on new capabilities versus maintenance and toil, held essentially flat at 57-58% across the same four quarters, despite the gains in throughput and code volume. And developers’ perceived rate of delivery stayed flat in the 67-70% range over the same period that objective throughput rose 37%.
This matters because none of that distinction, real functionality versus inflated volume, is visible if the only thing being measured is lines. It shows up instead in the metrics downstream of volume: rising PR size correlates with slower reviews, more volatile failure rates, and less incremental delivery. An organization that rewards lines of AI-generated code as a success signal is incentivizing the behavior that erodes the return on its AI investment, whether it intends to or not.
This isn’t an argument that AI-driven throughput and quality can’t improve together. Intercom’s AI-first engineering strategy doubled pull request throughput in nine months and cut its defect backlog by more than 50% in about four months. Intercom reinvested the time AI saved into paying down technical debt, rather than treating throughput as the only number that mattered.
One engineering leader described the same tension this way, discussing how their organization is managing AI-driven code volume: “if your code throughput goes up by 3x tomorrow, would your SDLC be able to absorb it? We have seen some early signs it is not the case. It breaks everywhere.”
Developers report a related, harder-to-quantify shift. AI-generated code is often easier to read, since models are good at producing plausible-looking, well-commented output. It is not automatically easier to trust. That gap between readability and trust is exactly the kind of signal a volume metric has no way to represent.
None of this makes AI-generated code volume useless. It’s a legitimate signal of adoption depth, worth tracking as exactly that. The mistake is treating it as an outcome metric on its own. It answers how much AI is being used. It says nothing about whether that use is translating into faster delivery, better software, or a healthier engineering organization.
A more complete measurement approach
A more complete measurement approach means checking output against structured frameworks that force gains in one dimension to be reported next to their cost in another.
The DX Core 4 evaluates engineering health across four pillars: speed, effectiveness, quality, and impact. A spike in code volume can’t be reported in isolation against this framework. The AI Measurement Framework applies the same discipline specifically to AI tools and agents, tracking utilization, impact, and cost, so leaders can separate how much AI is being used from whether that use is paying off.
Effectiveness
Effectiveness measures the conditions developers need to deliver effectively: clear direction, an understandable and well-documented codebase, low friction in cross-team collaboration, and efficient surrounding processes, from build times to incident response. A team unblocked by clear priorities and fast builds will consistently outperform a team generating more raw code under worse conditions.
Quality
Quality metrics, change failure rate and code maintainability chief among them, exist to counterbalance speed and volume metrics. If code volume, deploy frequency, and change failure rate are all rising together, that isn’t acceleration. It’s an organization shipping defects faster. Pairing every speed metric with a quality counterweight keeps a productivity story grounded in evidence.
Impact
Impact metrics connect engineering activity to business outcomes, including the innovation ratio referenced above. More code, or more AI usage, is only valuable if it frees developers to do higher-value work. If the innovation ratio isn’t moving even as output climbs, that’s a prioritization problem, not a tooling problem.
Utilization
The AI Measurement Framework’s utilization dimension tracks how deeply AI tools are embedded in daily workflows, including active AI tool usage and the percentage of AI-generated code. This is where lines-of-AI-code and similar activity metrics belong: as a signal of adoption depth, not as a stand-in for productivity or ROI.
Where leaders should focus next
AI utilization doesn’t need to replace the standards that have always defined a well-run engineering organization. It needs to be measured alongside them.
Activity-level metrics, AI-generated code volume, tool usage, show how and where AI is being used. Core 4 metrics, throughput, change confidence, effectiveness, show whether that use is moving the organization in the right direction. The data reveals a consistent pattern: organizations that report only the first set of metrics are describing activity, not outcomes.
Start with one exercise this week. Pull your team’s PR size trend and change confidence score, side by side, over the last two quarters. If PR size is climbing and change confidence is flat or falling, that gap is where AI is costing you more than the dashboard shows, and it’s a better starting point than an AI adoption number for deciding what to fix next.
That’s also the version of this story a CFO or board can act on. “AI usage is up” invites the follow-up question “so what?” “Throughput is up 37% and change confidence is down 6%, and here’s our plan to close that gap” is a position leaders can defend, and one their engineers will recognize as true.
Frequently asked questions about LOC
Should engineering leaders use lines of code to measure AI ROI?
No. LOC measures how much code was produced, not what it was worth. AI can inflate line counts without any corresponding gain in delivery speed, code quality, or developer trust in the result, which makes it a misleading basis for an ROI claim.
What should VPs of engineering track instead of lines of code?
Pair AI utilization metrics, adoption and AI-generated code share, with Core 4 quality and effectiveness metrics: change failure rate, change confidence, code maintainability, the DXI, and the innovation ratio. Utilization shows how much AI is being used. The Core 4 shows whether that use is actually working.
Does more AI-generated code mean higher engineering productivity?
Not on its own. Recent research shows AI-authored code share rising sharply while change confidence fell and pull request size nearly doubled, meaning output rose while trust and delivery discipline moved in the other direction. AI-generated code volume is a utilization signal, not evidence of higher productivity.
The questions below cover the mechanics of the LOC metric itself.
What is LOC in software engineering?
LOC stands for lines of code. It’s a metric that attempts to quantify the size of the code by counting the number of lines in a program’s source code.
What is the full form of LOC?
The full form of LOC is lines of code.
What does the C stand for in LOC?
In LOC, the C stands for code. The L stands for lines and the O stands for of.
What is SLOC?
SLOC stands for Source Lines of Code. It’s a logical LOC count that includes only the lines contributing to a program’s functionality, excluding comments and blank lines.
What is an LOC?
An LOC, or a line of code, is a single line in a program’s source code. LOC as a metric is a count of those lines, used to estimate the size of a codebase or a piece of work.
Go deeper: for everything we’ve published on measuring engineering performance, from the Core 4 to real-world leader practices, see our developer productivity metrics guide.