When AI Usage Becomes a Performance Target, People Optimize the Metric, Not the Work

WIRED reported on September 2, 2026 that Meta updated performance-review guidance to reduce emphasis on AI-tool usage while still encouraging employees to experiment with Hatch, its new agentic AI system.

According to WIRED, engineers were reportedly told that AI adoption dashboards or token counts would not be used to evaluate impact. Some employees told WIRED they had previously felt pressure to demonstrate AI usage. Meta spokesperson Tracy Clayton told WIRED that the company evaluates employees based on contributions and said labels such as "AI Native" were not used for performance evaluation.

The episode illustrates the difference between encouraging AI adoption and turning visible AI usage into a performance target.

AI usage is a useful signal. It should not become the performance target.

That distinction matters because AI adoption is becoming visible in ways traditional developer tooling rarely was. Leaders can see active users, prompt volume, accepted suggestions, agent activity, lines changed, pull request counts, and adoption cohorts. Those dashboards are valuable during rollout. They help companies answer basic operating questions: are people trying the tools, where is usage spreading, and which teams need enablement?

But when the same numbers become goals for managers or developers, the system changes. People do not only use AI where it improves the work. They learn to create evidence of AI usage.

The result is a familiar measurement failure in a new wrapper: the metric improves while the work may not.

The target changes the behavior

Campbell's Law warns that quantitative indicators become vulnerable to distortion when they are used for social decision-making. In plain engineering terms: once a proxy becomes tied to status, budget, promotion, manager evaluation, or team ranking, people adapt to the proxy.

That adaptation is not always dishonest. Most of it looks like normal workplace behavior.

If leaders ask every team to increase AI usage, teams will increase AI usage. If leaders ask every developer to demonstrate AI adoption, developers will find ways to demonstrate AI adoption. If leaders celebrate accepted suggestions, agent-created pull requests, or AI-assisted lines of code, those signals will rise.

The problem is that none of those signals guarantees better software.

AI usage metrics are useful until they become compliance metrics

GitHub's Copilot usage metrics show how quickly AI measurement is maturing. GitHub groups Copilot usage signals into adoption, engagement, acceptance rate, lines of code, and pull request lifecycle metrics. GitHub's reporting surfaces can help leaders understand active usage, feature breadth, accepted suggestions, PR creation, merge activity, review suggestions, and time to merge.

GitHub's own interpretation guidance makes the distinction explicit. Adoption cohorts and the adoption multiplier can be useful directional signals, but team composition, project complexity, and seniority can influence comparisons. GitHub cautions against treating the multiplier as a standalone productivity measure, and says ROI comparisons should be treated as directional associations rather than causal proof. Adoption measurement and productivity measurement are not the same thing.

That is useful operational telemetry. It is not a complete performance system.

Usage metrics answer questions like:

Are developers actively using the AI tools we bought?
Which surfaces are being used: completions, chat, CLI, code review, or agents?
Is adoption deepening beyond initial trial?
Are AI-assisted workflows appearing in pull requests?
Are enablement efforts changing behavior?

Those are rollout questions. They are not the same as:

Did the team ship more valuable work?
Did quality improve?
Did review load fall or rise?
Did rework decline?
Did the code survive later maintenance?
Did customers, reliability, security, or roadmap delivery improve?

When leaders collapse those two categories into one score, usage becomes compliance. The dashboard stops asking whether AI helped the work. It starts asking whether the team can prove it used AI.

What people optimize when AI usage is the KPI

Metric optimization often starts small. These are hypothetical incentive-design patterns, not claims that every company or every team behaves this way.

Developers keep tools open during work that does not need them. Active-user metrics rise, but the work is unchanged.
Teams route easy tasks through AI to show adoption. The usage score improves, while high-risk or ambiguous work still depends on human judgment.
People accept suggestions earlier. Acceptance metrics improve, but some accepted code is immediately edited, rewritten, or corrected during review.
Managers label more work as AI-assisted. Reporting looks modern, but the label may say little about the contribution's quality or durability.
Agents generate more first drafts. Output volume rises, but review queues, PR size, and verification effort may rise with it.
Teams avoid negative evidence. If the culture treats low AI usage as resistance, developers become less likely to report where AI slowed them down.

None of this requires bad intent. It is what happens when the organization rewards the visible proxy more clearly than the underlying outcome.

The hidden cost appears in review and rework

One important warning sign is high adoption paired with rising verification cost.

Stack Overflow's 2025 Developer Survey found that more developers actively distrusted AI tool accuracy than trusted it, and that the most common AI frustration was dealing with answers that were almost right but not quite. That is exactly the kind of failure mode usage dashboards can miss. The tool was used. The suggestion may even have been accepted. The cost appears later, when someone has to notice, debug, rewrite, or explain the flaw.

Sonar's 2026 State of Code Developer Survey points in the same direction. Sonar reported that AI-generated or AI-assisted code already represented a large share of committed code in its respondent base, while 96% of developers did not fully trust AI-generated code. It also reported that 38% of developers said reviewing AI code requires more effort than reviewing human-written code.

Those findings do not mean AI is bad for engineering. They mean usage is not enough. AI can move work from authoring into verification. If the measurement system sees authoring speed but not verification cost, leaders may think productivity improved while senior engineering attention is being consumed somewhere else.

The better question is whether AI-assisted work survives

DORA's 2025 State of AI-assisted Software Development report frames AI as an amplifier of an organization's existing strengths and weaknesses. That is the right lens for AI metrics. AI does not automatically fix a confused delivery system. It can make the confusion move faster.

The healthier measurement question is not "How much AI did people use?"

It is: "Which AI-assisted work became durable engineering value?"

That question changes the scorecard. It pushes leaders toward signals that are harder to fake:

AI Effort Share: where AI meaningfully influenced engineering work across repositories, teams, and work types.
Real Effort Value: whether the contribution represented meaningful engineering work after complexity, context, and quality are considered.
Review and verification cost: how much human attention was needed before the work was safe to merge or ship.
Rework ratio: whether AI-assisted changes created more downstream correction after review, merge, or production release.
Contribution Retention: whether the code remained useful after later maintenance, refactoring, and product change.
Delivery quality: whether reliability, defect rates, cycle time, incident load, or customer outcomes improved.
Qualitative judgment: whether reviewers and maintainers believe the work made the system easier or harder to own.

A metric is harder to game when improving it requires doing the thing the organization actually wants.

Not all of these signals come from a single engineering analytics platform. Some require repository data, delivery and operational data, review evidence, customer context, or qualitative organizational judgment. The point is to build a measurement system that connects usage to outcomes, not to pretend one dashboard can answer every question.

Do not punish honest non-use

One of the quickest ways to break AI measurement is to punish honest non-use.

There are tasks where AI is useful: explaining unfamiliar code, drafting tests, generating boilerplate, exploring alternatives, summarizing logs, or producing a first version of a low-risk change.

There are also tasks where a senior engineer may deliberately use AI less: architecture decisions, incident response, security-sensitive changes, ambiguous product trade-offs, performance regressions, data migrations, and work in poorly documented legacy systems.

If every low-AI day looks suspicious, developers will protect themselves by manufacturing usage. That makes the data worse. Leaders lose the ability to distinguish valuable adoption from defensive adoption.

Better cultures treat non-use as a signal to inspect, not a failure to punish. Maybe the developer missed an opportunity. Maybe the tool was not good enough. Maybe the task required judgment the tool could not provide. All three answers are useful. Only the first suggests there may be an adoption or enablement gap worth investigating.

How leaders should set AI expectations

The right expectation is not "use AI more."

The right expectation is "use AI where it improves the work, and make the outcome auditable."

That can become a practical operating model:

Define where AI is encouraged, optional, restricted, or inappropriate.
Measure usage as rollout telemetry, not as a personal performance grade.
Pair every usage metric with a quality or durability counter-metric.
Review examples of AI-assisted work, not only aggregate charts.
Track where AI creates review load, not only where it creates output.
Reward teams for reducing rework and improving maintainability, not for producing more AI-labeled activity.
Keep space for developers to report when AI made a task slower, riskier, or noisier.

This gives leaders visibility without turning adoption into theater.

Where GitMe fits

GitMe is built for the layer after raw usage.

AI Effort Share helps leaders see where AI is influencing engineering work. Real Effort Value helps separate meaningful contribution from generated volume. Rework and historical comparison help reveal whether AI-assisted work is associated with more or less downstream correction over time. Contribution Retention shows whether the work continues to matter after later development.

That matters when a company wants AI adoption without metric gaming. GitMe can help leaders compare AI-assisted activity with durable contribution, rework, and meaningful engineering effort instead of treating AI activity as proof of productivity by itself.

This connects with GitMe's views on why AI usage metrics still do not measure AI ROI, AI moving the bottleneck from coding to review, AI-generated code durability, and what developer productivity means when agents write code.

AI usage should be visible. It should be understood. It should inform training, tooling, governance, and investment. AI adoption should be measured. It should not automatically be rewarded. And it should never become the work itself.

The goal is not to maximize AI usage. The goal is to maximize durable engineering value with the right amount of AI leverage.