AI 令開發人員工作更快，為何我們仍以程式碼行數衡量生產力？

Let's be honest.

Writing code has never been the hardest part of software engineering.

Understanding the problem, making the right trade-offs, debugging unexpected behavior, and maintaining a system over time are often much harder.

Yet, for some reason, we still associate writing more code with being a better developer.

AI makes that assumption even more questionable.

The productivity illusion

Imagine two developers.

Developer A writes 1,000 lines of code in a day using AI. The feature works, but nobody has reviewed the edge cases, tested failure scenarios, or considered the long-term maintenance cost.

Developer B writes 100 lines of code. The implementation is tested, the failure modes are understood, and the feature solves the actual problem without introducing unnecessary complexity.

Who is more productive?

If your answer is Developer A because they produced ten times more code, you're measuring output, not value.

And those two things are not the same.

AI didn't eliminate the hard part

AI coding tools can generate functions, write tests, explain unfamiliar code, and accelerate routine implementation.

That's useful. Ignoring these tools doesn't make someone a better engineer.

But generating code is only one part of building software.

Someone still needs to determine whether the generated solution:

• Solves the correct problem.
• Handles edge cases and unexpected input.
• Introduces security vulnerabilities.
• Fits the existing architecture.
• Can be understood and maintained by another developer.
• Is worth implementing in the first place.

The faster code is generated, the more important it becomes to evaluate what should actually be shipped.

Otherwise, we're just producing technical debt at a higher speed.

Here's the uncomfortable question

If AI can generate a significant portion of routine code, what exactly should companies pay developers for?

Typing speed?

Framework knowledge?

The ability to turn a specification into working code?

Or the judgment to know which solution is correct, which trade-offs are acceptable, and which features shouldn't be built at all?

My view is that implementation skills still matter. You cannot reliably evaluate a system you don't understand.

But implementation alone is becoming a weaker way to distinguish one developer from another.

The real advantage is increasingly the combination of technical understanding, problem-solving, verification, and sound engineering judgment.

So what should we measure instead?

Lines of code are easy to count. Engineering value is harder to measure.

A better evaluation considers several dimensions:

• Correctness: Does the software behave as intended?
• Reliability: Does it handle failures and edge cases?
• Maintainability: Can the team safely change it later?
• Delivery: Does it solve the problem within reasonable constraints?
• Impact: Does it improve a meaningful outcome for users or the business?

None of these metrics is perfect in isolation. Even measuring impact can be difficult when results depend on factors outside an engineer's control.

But that doesn't make lines of code a good substitute.

My question to developers and engineering managers

If AI lets one developer produce five times as much code, should that developer be considered five times as productive?

Or should we stop treating code volume as a proxy for engineering value?

And here's the more controversial question:

If a developer can consistently deliver better software by writing less code and using AI intelligently, is the developer who writes everything manually actually more skilled, or just slower?

I'd like to hear arguments from both sides.