Direct answer: You prove AI impact by making three things legible from data you already generate: what you built, how widely other people use it, and what it saved. The strongest evidence is adoption you did not author, showing up in telemetry you do not control, which is far harder to argue with than any account you write yourself.
Most engineers who have built something genuinely useful with a coding agent hit the same wall when they try to get credit for it. The work is real. A migration that used to eat a week now takes an afternoon, or a review loop that catches a class of bug the team kept shipping. And when it comes time to point at it, there is nothing to point at. The impact happened inside a terminal, in a hundred small sessions that left no artifact anyone else can see. So the engineer does the thing everyone advises, which is to write it up, and the write-up reads like a claim rather than a fact, because that is exactly what it is.
Why doesn't a write-up prove your AI impact?
I want to argue that the write-up is the wrong instrument, and that reaching for it first is why good AI work stays uncredited. The trouble with a self-authored account is that it is unverifiable, and everyone reading it knows that, whatever its honesty. You are the source, the beneficiary, and the narrator all at once. A staff engineer reading your paragraph about a three-times speedup has no way to separate the real gain from the rounding, and no reason to fully trust the number, because you had every incentive to round up. The account carries no independent weight, so it does the opposite of what you wanted. It makes the impact feel softer, not harder.
The way out is to stop treating impact as a story you tell and start treating it as a signal other people generate about you. Call it the legibility ladder, three rungs, each one harder to fake than the last, and each one already recorded somewhere if you know where to look. The first rung is what you built. The second is how widely it is used. The third is what it saved. They have to be climbed in that order, because each rung only means something once the one below it is established.
What did you build, and where is it recorded?
Start with what you built, because it is the rung you actually own. Every AI request your workflow makes carries a session, a model, a token count, a cache read, a status, and a consumer. Those fields, gathered across the sessions that make up one pattern, are a factual description of a workflow: this is the thing, it runs this way, it costs this much per run, it finishes at this rate. Value has not entered yet. What you have is a definition, and a definition is the thing you need before any value argument can attach to it. Without it you are describing a vibe. With it you are describing an object other people can point at too.
How widely do other people use what you built?
The second rung is where the evidence stops being yours and starts being real, and it is the rung almost every brag doc skips. How widely is the workflow used, by people who are not you. This is the number you cannot author, because it is other engineers deciding, on their own time, that your pattern is worth adopting. Reuse and adoption counts are the closest thing to an unfakeable proof of value that exists on an engineering team. A workflow that ten other people run every week is doing something real, and no one has to take your word for it, because the ten people are the word. It follows that a workflow that spread quietly is stronger evidence than a workflow you personally used a thousand times. Your own usage proves you like it. Other people's usage proves it works.
What did it actually save, stated honestly?
Only now does the third rung, what it saved, carry any force. Savings stated in isolation are the weakest possible evidence, because they are the easiest to inflate and the hardest to check. Savings stated on top of a defined workflow with real adoption are almost unarguable, because the multiplication is doing the work. One run that avoids a billed call saves a small, honest amount. That same run across every person who adopted the pattern saves that amount times the adoption count, and now the number is large without anyone having exaggerated a single figure. The honesty rail matters here and it protects you, not just the reader. Count cash savings only against events that were actually billed, and count time savings only where a slow path was measurably replaced. A conservative number you can defend line by line beats an impressive one that collapses under a single question.
There is a discipline the ladder forces that is worth naming, because it is what separates evidence from noise. A completed status tells you a session finished. It does not tell you the answer was good. Request volume tells you someone was busy. It does not tell you anything shipped. If you build your case on completion counts or call volume you are building it on the two metrics that look like impact and are not, and the first person who understands the data will say so. The rungs that hold are the ones tied to other people's behavior and to genuinely billed events, because those are the ones you could not have manufactured.
So the move, concretely, is to invert the order most people use. Do not open with the savings number and hope the reader trusts it. Establish the workflow as a defined object, show that people who are not you have adopted it, and let the savings fall out of that adoption as arithmetic. None of this is about a review cycle or a comp conversation. It is about contributing to something larger than your own output, and being able to see that contribution the same way the rest of the org can see it, which is the only version of proof that survives contact with a skeptic.
We built Oberhahn so an engineer sees their own workflows, their own adoption counts, and their own defensible savings before anyone else does, drawn straight from the telemetry the work already emits. A live demo with sample data shows what that individual view looks like.
Frequently Asked Questions
How do I prove my AI impact at work?
Make three things legible from telemetry you already generate: what you built, how widely other people use it, and what it saved. Adoption by people who are not you is the strongest evidence, because it is a signal you did not author and cannot easily inflate.
Why isn't writing up my AI work enough to get credit?
A self-written account has you as the source, the beneficiary, and the narrator at once, so a careful reader discounts it. Evidence generated by other people adopting your workflow carries independent weight that your own description never will.
What AI metrics actually prove impact versus just look busy?
Reuse and adoption counts, and cash savings tied to genuinely billed events, prove impact. Request volume and completed-status counts mostly prove activity, and any case built on them falls apart under one informed question.
How do I show savings without exaggerating?
State savings on top of a defined workflow with real adoption, count cash only against events that were actually billed, and let the adoption count do the multiplication. A conservative number you can defend line by line is worth more than an impressive one you cannot.