What this KPI incentivizes
This is the heart of it. Because a KPI is rarely just a metric. A KPI is an incentive system. When you measure X, you're telling people: optimize for X.
So what happens when you measure the ratio of AI lines to human lines?
Scenario 1: Generate more AI code, don't delete it. You have a task. You can write 50 elegant lines - or ask AI for 300 bloated ones. Functional result: identical. KPI impact: enormous. The choice is obvious... if you have a broken incentive system.
Scenario 2: Skip refactoring. Refactoring means removing code - it shrinks the counter. AI-generated code after refactoring becomes "more human" (fewer AI lines remain). Both moves hurt the KPI. So why refactor?
Scenario 3: Verbosity over elegance. Good developers write concisely. AI can write concisely - but it can also ramble. If the KPI rewards volume, you're rewarding verbosity. "Readability"? "Maintainability"? Nobody's asking.
Scenario 4: Hiding AI. Some organizations I heard about in comments under the post achieved the exact opposite of what they intended - developers started hiding their AI use so they wouldn't "ruin" the ratio in their disfavor, because they feared judgment.
You wanted to measure AI adoption. You measured something else entirely and triggered behaviors you never wanted.
Goodhart's Law - in plain English
There's a law economists have known for years that organizations keep rediscovering.
Goodhart's Law: when a measure becomes a target, it ceases to be a good measure.
In plain English: the moment you say you're measuring X - people stop doing what used to produce X as a side effect. They start producing X directly. And you lose the information X was supposed to give you.
Three examples from organizational life - nothing to do with AI:
Number of closed tickets as a support KPI. Result: support closed tickets without solving the problem, because "resolution" wasn't measured. Customers submitted the same issue repeatedly. Tickets closed - customer satisfaction tanked.
Story points per sprint as a velocity measure. Result: story points started growing independently of actual work. Every task was "more complex than we thought." Team velocity went up 40% - and nothing got delivered faster.
Number of client meetings for salespeople. Result: salespeople scheduled meetings that made no business sense just to hit the target. Relationships suffered because clients felt it was a numbers game.
Same mechanism. Different scale. Always the same outcome.
What to actually measure for AI adoption in a dev team
Fine. So how do you measure? Because "we don't measure" isn't an answer either.
Metrics that actually tell you something:
| What to measure | Why it makes sense |
|---|---|
| Time to feature | Is AI accelerating value delivery to users? |
| Defect rate (production bugs) | Is AI-generated code quality? |
| Deployment frequency | Is the team shipping more often thanks to AI? |
| Developer Experience Score | Do developers feel more productive and satisfied? |
| Code review cycle time | Does AI shorten review time or lengthen it (because the code is unreadable)? |
| Lead time for changes | Time from idea to production - is AI shrinking it? |
These are DORA metrics (DevOps Research and Assessment) - tested, research-backed, independent of who (or what) writes the code. Worth noting: DORA research relies heavily on self-reported data and has its own methodological limitations. These aren't dogma - they're a solid starting point.
None of them ask "how many lines did AI write." All of them ask: "are you delivering value better?"
That's the right question.
Why organizations fall into this trap
Not because management is stupid. Really.
A few mechanisms lead to KPIs like this:
Pressure to have "something measurable." Management invests in AI and wants to know if it's working. That's legitimate. Problem: "measurable" is easier to achieve than "meaningful." Lines of code are measurable immediately - deployment frequency requires tooling and culture.
KPI as a substitute for understanding. When a leader doesn't understand the technology, KPI becomes a prosthetic. "I don't know what it does, but I know the number is going up." The metric replaces knowledge. Convenient and dangerous at the same time.
Cargo cult adoption. "Other companies measure AI. We have to measure AI too." We copy the form without the substance. We have a KPI, a dashboard, numbers on a slide for the board. That those numbers say nothing about reality - that doesn't show up on the slide.
Time and difficulty. Good metrics require investment: tooling, a culture of openness to data, interpretive skills. A bad KPI can be deployed in a week.
One comment under the original post was spot-on: "In my company we've had a lines of code KPI since the 90s. We added AI to it. Now we have two bad KPIs instead of one."
One question to close
What KPIs in your organization measure activity instead of value?
Got any candidates? Probably. Every organization does. We only differ in whether someone has the courage to say it out loud in a meeting with the board.
And that's the second question: if you know a metric is meaningless - what's stopping you from saying so?
Because the problem with a KPI that counts AI lines of code isn't technical. It's organizational. Someone proposed it. Someone accepted it. Someone is now reporting these numbers every quarter.
And everyone at the table knows it's absurd.
They just don't say it out loud.