Measure What Matters in the Age of Infinite Code

Last week when talking about AI and YAGNI, I mentioned a new kind of metric. I think it’s worth exploring a bit more this week. Explaining it in a bit more depth and getting some feedback if it’s something that holds weight in the rapidly changing world of software development.

We live in a time when more code is being written than ever before. Or, more precisely, a time when more code is being generated. One line of human input can now spin into three hundred lines of machine output. Productivity? At first glance, it feels like it. But beyond anecdotes, are we measuring success?

The question is simple: Are we actually producing more features, or are we just producing more code?

Every piece of code is a debt instrument. It’s something you’ll need to read again, patch again, extend again. It will take brain cycles from someone, human or machine, in the future.

Features, on the other hand, are assets. They generate adoption, revenue, delight. They’re why the customer sticks around.

We need a balance sheet between those two.

Bloated codebases carry hidden taxes:

• Longer reviews. More lines mean more time to scan, even if most of them don’t matter.

• Slower deployments. Higher complexity requires heavier testing and more careful merges.

• Fragile stability. Every extra conditional path is an extra opportunity for failure.

What starts as acceleration becomes drag. Like a car that’s been customized with too many “custom” accessories.

Traditional metrics like velocity or throughput were designed for an era when humans typed every line. But when machines generate more than they consume, those measures break down. What we need instead is a ratio: a way to quantify how much real user value each additional unit of code delivers.

That’s the essence of the Feature-to-Code Ratio (FCR), a measure of how much real user value (features, assets) we’re delivering compared to how much code (liability, drag) we’re adding.

At its simplest, this says:

The ratio of realized product value to the complexity and volume of code required to achieve it.

High FCR = high leverage (more user value per unit of code).

Low FCR = bloat (more code per unit of value).

And in the era of generative AI, this ratio could be the line between thriving software organizations and those quietly piling up a mountain of technical debt.

The numerator, “feature value” is deceptively tricky. Just counting them doesn’t work. Not all features are equal.

Function Points, story points, or ticket counts measure effort, not impact. They’re like counting calories burned, not strength gained.

The Art of Business Value is a good book that explores this at length.

Real feature value shows up in customer behaviour: adoption, retention, revenue, willingness to pay. It’s the difference between a feature users can’t live without and one they never find in the menu.

Spend code only on what truly moves the needle.

Now, the denominator “code mass” is where things get messy. Because code isn’t neutral. It’s a liability with compound interest.

Lines of Code (LOC) is the oldest, bluntest instrument in the drawer. It’s easy to count but meaningless to interpret. In the age of code generation, it’s even more deceptive, a single prompt can balloon the count without increasing value.

So instead of size, we should consider a measure of complexity — the cognitive and structural weight the system carries.

There are a few options that could be used to figure this out:

• Cognitive Complexity: How much mental effort does it take to understand the logic? High complexity means high future maintenance cost.

• Halstead Volume: A mathematical measure of how “dense” a program is, based on operators and operands.

• Cyclomatic Complexity: The number of independent paths through the code. Good for testing coverage, but misleading if clarity isn’t factored in.

• Rework Ratio: How much of your work week is spent fixing or refactoring what’s already been written. This is a sign of technical debt.

Measuring all of these might be overkill. My go to here would be measuring Cognitive Complexity since it’s a directly related to the developer experience. A close 2nd to factor in would be the rework ratio as a signal of code quality.

Remember that a team that generates 10,000 lines of low-complexity, consistent code may be healthier than one that ships 2,000 tangled ones. Bringing all these pieces together here’s a summary of what that looks like:

The beauty of the Feature-to-Code Ratio is that it forces conversation across silos.

If the ratio is low, is it because engineering produced too much code? Or because the product shipped with features that weren’t valuable?

The numerator (value) belongs to Product.

The denominator (code / complexity) belongs to Engineering.

But the ratio belongs to the business.

It’s a metric that forces Product and Engineering to meet in the middle.

If you’re leading a team today, here’s the playbook:

1. Adopt FCR as a first-class metric. Don’t celebrate output unless it moves the ratio.

2. Shift incentives. Reward code removal, simplification, and refactoring as much as new feature commits.

3. Elevate architects. Complexity managers are the new bottleneck. Empower them.

4. Constrain AI. Use spec-driven prompting, context-first generation, and require the AI to explain itself before it writes.

5. Fund pruning. Technical debt is real debt. Pay the interest regularly, or it will own you.

The Feature-to-Code Ratio isn’t another vanity metric. It’s a way to see whether our effort is creating value or just creating volume.

In an environment where code can be generated faster than it can be understood, our advantage will come from choosing code wisely, not producing more. Teams that learn to measure this balance will understand the real cost of what they build and the real return it delivers.

Adopting FCR means treating software health as a measurable outcome, not an afterthought. It connects product intent with engineering reality and keeps growth aligned with purpose.

The future of high-performing software organizations will belong to those who can manage this balance consistently. The ones that remember: features are assets, code is liability.