LOC Counters CSV Export: Fixing Agile Review Lag

68% of engineering teams say they track developer productivity. Only 11% can actually show you the numbers.

That gap isn't from laziness. It's from tooling that doesn't speak the same language as your codebase.

I learned this the hard way. Last year, I took over a platform team running four services in Python, Go, TypeScript, and Rust. Leadership wanted quarterly productivity reports. My predecessors had been eyeballing it — Jira tickets closed, PRs merged, gut feel. When I asked for actual lines-of-code data broken down by language and contributor, I got blank stares.

So I built a workflow around a multi-language LOC counter with CSV export. What follows is what I learned, the numbers that changed how we run code reviews, and the specific setup that made it repeatable across sprints.

47,000 lines across four languages: the baseline problem

Our codebase sat at roughly 47,000 lines when I started counting properly. Python: 21,000. Go: 14,000. TypeScript: 9,000. Rust: 3,000. Those numbers came from running a single multi-language LOC counter against the entire repo — not four separate tools duct-taped together.

Here's why that matters: if you're using language-specific counters, you're creating friction at exactly the moment you need momentum. A Python counter gives you one number. A Go counter gives you another. Then you're manually pasting into spreadsheets, normalizing formats, losing time. Our previous metrics process took someone three hours per sprint just to compile.

A multi-language LOC counter solves this by detecting file types automatically and applying consistent counting rules — blank lines excluded, comment lines separated, code lines tallied — across every language in your repo. One run. One output.

What the baseline revealed

When I first exported to CSV, the data told a story nobody had articulated: our Python service was growing at 3x the rate of our Go service, but our Go service had twice the test coverage. Translation: we were shipping Python features fast and writing Go tests fast, but nobody had connected those two facts. The code review process treated them as unrelated. They weren't.

The 3 agile metrics that actually moved the needle

I tried tracking everything at first. Bad idea. After two sprints of drowning in data, I narrowed to three metrics that a multi-language LOC counter with CSV export could feed directly:

1. LOC churn per contributor per sprint — How many lines added, modified, and deleted by each developer. Not to rank people. To spot bottlenecks. When one developer accounted for 62% of all Python changes in a sprint, that was a review-load problem, not a productivity win.

2. Comment-to-code ratio by language — Our Go codebase ran at 18% comments. Our Python ran at 6%. That gap showed up in review times: Go PRs averaged 4 hours to review. Python PRs averaged 11 hours. Reviewers spent extra time reconstructing intent.

3. Test LOC vs. production LOC trend — Tracking this across sprints told us whether we were building safety nets or just shipping features. When test LOC growth dropped below 15% of production LOC growth for two consecutive sprints, we knew debt was accumulating.

Why CSV export made this possible

I tried JSON exports first. Then YAML. Both required parsing scripts before I could actually look at the data. CSV changed everything. One command, one file, open it in any spreadsheet tool or pipe it into a Python notebook. No intermediate processing.

The CSV output from our LOC counter gave me columns like: file_path, language, blank_lines, comment_lines, code_lines, contributor, last_modified. That structure let me pivot by contributor, by language, by directory. Sprint reviews went from "how did everyone feel about last sprint?" to "here's what the code actually did."

1.7x: the productivity gap our CSV data exposed

Three sprints in, the data surfaced something uncomfortable. Our TypeScript contributor was producing 1.7x more reviewed-and-merged LOC per sprint than anyone else on the team. Not because they were faster. Because their code reviews were shallower.

Here's the calculation that made it undeniable:

The CSVs feed into this spreadsheet automatically. Each sprint gets a row with columns for total LOC by language, per-contributor breakdowns, comment-to-code ratios, and test-vs-production trends. The delta column shows change from the previous sprint. When something moves more than 20% in either direction, conditional formatting flags it red or green. I don't read every number. I read the flags.

That's the whole loop. Five minutes. No dashboards, no integrations, no API tokens to manage. A command-line tool, a Git command, a Python script, and a spreadsheet. The simplicity is the feature. Every complex metrics setup I've seen has eventually collapsed under its own weight — too many moving parts, too many points of failure, too much maintenance for a process that should take minutes.

How the data actually fixed our review lag

Here's where the title of this article earns its keep. The LOC CSV export didn't just give us numbers. It changed how we run code reviews. Specifically, it fixed three review-lag problems that we'd been tolerating for months without naming them.

Problem 1: Review load was invisible

Before the CSV workflow, review load was distributed by feel. Whoever was available got the PR. The data showed that two senior developers were reviewing 74% of all PRs across all four languages. They were bottlenecks, and nobody realized it because they never complained. They just worked longer hours.

The per-contributor LOC churn data made this undeniable. When one developer accounts for 62% of Python changes in a sprint, the reviewer for those changes is doing 62% of the review work for that language. We redistributed review assignments based on the CSV data, capping each reviewer at 35% of any single language's review load per sprint. Average PR review time dropped from 14 hours to 6 hours within two sprints.

Problem 2: Comment density was uneven

The comment-to-code ratio column in our CSV export revealed a 12-point gap between our Go codebase (18% comments) and our Python codebase (6% comments). This wasn't a style preference. It was a review-time tax. Python PRs took 11 hours to review on average. Go PRs took 4 hours. The difference wasn't code complexity. It was documentation density.

Reviewers were reconstructing intent from scratch on Python PRs because the code didn't explain itself. We didn't mandate a specific comment ratio. We made the data visible. Each sprint review included the comment-to-code trend by language. Python developers saw the gap. They closed it voluntarily over three sprints, bringing Python comment density to 14%. Python PR review time dropped to 7 hours. Not as fast as Go, but a 36% improvement.

Problem 3: Test coverage was decoupled from review priority

The test LOC vs. production LOC trend exposed something subtle. When TypeScript test LOC growth dropped to 8% of production LOC growth for two consecutive sprints, we kept reviewing TypeScript PRs with the same rigor as before. But the safety net was thinning. A bug that would have been caught by a test was now depending on a reviewer to catch it manually.

We started flagging PRs in languages where test LOC growth had dropped below 15% of production LOC growth. Those PRs got a second reviewer automatically. Not because the code was bad, but because the testing infrastructure wasn't keeping up. This added 90 minutes to those specific PRs but caught three regressions in Sprint 14 that would have shipped to production.

What I'd do differently

If I were starting over, three things would change.

First, I'd start with CSV export from day one. I wasted two weeks trying to build a JSON-based pipeline. JSON is great for APIs. It's terrible for human review. CSV opens in any spreadsheet tool. Anyone on the team can look at it. Anyone can sort, filter, pivot. The format itself democratizes the data.

Second, I'd track contributor data from the first sprint, not the third. The Git shortlog join takes two minutes. I delayed it because I thought per-contributor data was premature. It wasn't. The review-load imbalance was there from Sprint 1. I just couldn't see it.

Third, I'd share the spreadsheet with the whole team from the beginning. I kept it to myself for the first month because I wanted to make sure the numbers were right before exposing them. That was paternalistic. The team needed to see their own patterns. When I finally shared it, the comment-density improvement happened organically because developers could see the gap and self-correct.

Common mistakes with LOC counting

Having run this workflow for over a year, I've seen teams make the same mistakes repeatedly.

• Using LOC as a productivity score. This is the most common and most damaging mistake. LOC measures volume, not value. A developer who deletes 500 lines of dead code had a great sprint. The LOC counter shows negative numbers. If you're ranking developers by LOC, you're incentivizing the wrong behavior and you'll lose your best engineers.
• Counting generated code. If your repo includes generated files, protobuf outputs, or vendored dependencies, your LOC numbers are inflated and meaningless. Configure your counter to exclude these directories. Our counter skips /vendor, /generated, and *.pb.go files.
• Ignoring comment lines. Some teams only track code lines and discard comment counts. That throws away the most actionable metric in the export. Comment-to-code ratio tells you where reviewers are spending extra time reconstructing intent.
• Running the counter manually at random times. If you run it mid-sprint, the numbers are incomplete. Run it at sprint boundaries, consistently. Tag the filename with the sprint number. Consistency is what makes trend data meaningful.
• Not joining with review metadata. LOC data alone tells you what changed. Review metadata tells you how it changed. Without the join, you're missing the lag signal entirely.

The tooling question

I'm often asked which LOC counter I use. The honest answer: it matters less than you think. What matters is that the tool supports multi-language counting, applies consistent rules across languages, and exports to CSV. I've used three different counters over the past year. They all produced slightly different numbers — usually within 2-3% of each other due to differences in how they handle edge cases like multi-line comments and shebang lines. That variance doesn't change the trends. A 3x growth rate in Python is 3x regardless of whether the absolute number is 21,000 or 21,600.

Pick a tool. Run it consistently. Export to CSV. Join with Git data. Look at trends. The tool is a commodity. The workflow is the asset.

The bottom line

Agile review lag isn't a motivation problem. It's a visibility problem. When you can't see review load distribution, comment density gaps, or test coverage trends, you're reviewing in the dark. A multi-language LOC counter with CSV export gives you the raw material. The five-minute-per-sprint workflow turns it into actionable signal.

Our review times dropped from an average of 14 hours to 6 hours per PR. Our test coverage trend reversed direction. Our review load balanced across the team. None of that came from a new process framework or a motivational speech. It came from counting lines, exporting to CSV, and actually looking at the numbers.

If you're still eyeballing productivity, start here. One command. One CSV file. Five minutes per sprint. The data will tell you what your gut can't.