Lines of Code

One of the things I’m struggling to reconcile is the way we discern between human and machine productivity.

We as an industry have largely condemned the practice of using lines of code written as a metric for gauging developer productivity. See, for example, this quote from Accelerate:

“Rewarding developers for writing lines of code leads to bloated software that incurs higher maintenance costs and higher cost of change. Ideally, we should reward developers for solving business problems with the minimum amount of code—and it’s even better if we can solve a problem without writing code at all or by deleting code (perhaps by a business process change).”

— Forsgren PhD, Nicole; Humble, Jez; Kim, Gene. Accelerate (p. 37). IT Revolution Press. Kindle Edition.

At the same time we are frequently seeing lines of code used in the marketing campaigns for AI tools. See, for example, this quote from GitHub’s blog post about GitHub Copilot.

“Today, GitHub Copilot has been activated by more than one million developers and adopted by over 20,000 organizations. It has generated over three billion accepted lines of code, and is the world’s most widely adopted AI developer tool.”

— The economic impact of the AI-powered developer lifecycle and lessons from GitHub Copilot, 2023-06-27. (emphasis mine)

I understand that vendors of AI tools are using lines of code as a proxy metric in this context. The story is essentially one of social proof: “look at how many of our customers have found value in our tool!” But if we say that rewarding developers based on the number of lines of code written can lead to software bloat, shouldn’t that same logic also apply to machine-written code?

^{Image: Midjourney
Prompt: a black computer monitor with code written in green text}

Right now the AI tooling market is centered around the word “generative.” And while generative AI has indeed been a breakthrough force in technology, generating more code is not enough. Making it easier for developers to write code is a good thing, but it can’t be the only thing. Now more than ever, we are going to need additional tools to help manage code quality and improve our processes around code deprecation.

Disclosure: GitHub is a RedMonk client.