AI Is Making Developers Faster. So Why Are We Still Measuring Productivity by Lines of Code?

Writing code is not the most challenging aspect of software engineering. Rather, understanding the problem, making appropriate trade-offs, debugging issues, and maintaining the system over time often proves far more difficult. Nonetheless, the prevailing notion still associates increased code production with enhanced developer performance. However, the advent of AI challenges this assumption.

Consider two developers. Developer A utilizes AI to write 1,000 lines of code in a day. While the feature functions, it has not undergone review for edge cases, failure scenarios, or long-term maintenance considerations. In contrast, Developer B generates only 100 lines of code. The implementation has been tested, failure modes comprehended, and the feature effectively addresses the problem without introducing excess complexity.

Who is more productive? If you answer Developer A due to their tenfold increase in code output, you are measuring productivity based on quantity rather than quality. These two factors are not synonymous.

AI coding tools can create functions, write tests, elucidate unfamiliar code, and expedite routine implementation. These functionalities are undoubtedly valuable. However, merely disregarding these tools does not make someone a superior engineer. Generating code constitutes only a fraction of software development. Someone must still determine whether the generated solution: accurately addresses the problem, effectively handles edge cases and unexpected input, introduces security vulnerabilities, aligns with the existing architecture, is comprehensible and maintainable by other developers, and justifies its implementation.

The more rapidly code is produced, the more critical it becomes to evaluate what should ultimately be implemented. Otherwise, we are merely generating technical debt at an accelerated pace. A pertinent question arises: if AI can generate a significant portion of routine code, what precisely should companies compensate developers for?

Typing speed? Familiarity with frameworks? The ability to transform a specification into functioning code? Or the discernment to identify the correct solution, acceptable trade-offs, and features that should not be developed?

My perspective is that implementation skills remain crucial. You cannot reliably assess a system you do not fully comprehend. However, implementation alone is becoming an increasingly weaker differentiator between developers. The true advantage lies in the amalgamation of technical understanding, problem-solving, verification, and sound engineering judgment.

Therefore, what should we measure instead? Counting lines of code is straightforward. Measuring engineering value, on the other hand, is far more complex. A superior evaluation should consider several dimensions: Correctness - Does the software function as intended? Reliability - Does it handle failures and edge cases effectively?

Maintainability - Can the team modify the codebase safely in the future? Delivery - Does it solve the problem within acceptable constraints? Impact - Does it yield a meaningful improvement for users or the business?

None of these metrics stands isolated. Even assessing impact can be challenging when results depend on factors beyond an engineer's control. Yet, this does not render lines of code a suitable substitute. I pose a question to developers and engineering managers: if AI enables one developer to produce five times the amount of code, should that developer be deemed five times more productive?

Or should we abandon the notion of code volume as a proxy for engineering value? And a more contentious inquiry: if a developer consistently delivers superior software by writing less code and leveraging AI judiciously, is the developer who writes everything manually actually more skilled, or merely less efficient? I am eager to hear perspectives from both sides.