The moment engineers suspect that AI contribution figures will appear in a performance review, the measurement stops describing reality. People will paraphrase suggestions, retype accepted code, or simply stop using the tools on monitored repositories. You will have a number, and it will be fiction.
This is not hypothetical; it is the standard failure mode of every developer metric ever introduced.
Say what it is for, in writing
Provenance exists so the organisation can answer questions about its own code: what an agent wrote, from which prompt, and whether a person reviewed it. It is a record, not an assessment.
Write that down and put it in the policy. Then behave consistently with it — the first time a contribution figure appears in a review, the measurement is over.
Report at the repository, not the person
Useful questions are about code: which repositories are heavily AI-authored, which sensitive directories have AI-written code without human revision, how much of the codebase nobody can account for.
None of those need a per-developer breakdown. The technical capability exists — events carry identity, because an audit trail must — but what gets reported and looked at routinely should be the repository. Reserve per-person data for genuine investigations, and say so.
Make a high number boring
If ninety percent of a service was AI-written and it was reviewed properly, that is a fact, not a finding. Saying so out loud, early, removes most of the incentive to distort.
The number that should worry you is not the AI share. It is the unattributable share: code nobody can place at all.
Let people see their own record first
Capture is local by default. Developers can look at their own history before anything is shared, which turns the tool into something that is useful to them — a searchable memory of what they did last month — rather than something done to them.
That order matters. A tool engineers find useful survives; a tool they only experience as surveillance gets worked around, and then you are back to guessing.