Every tool vendor has a percentage. None of them measured your project. Here is how we count it on ours, and what we have found.
What we count
Cycle time from ticket to merged, review time per change, defect escape rate, and rework — the share of shipped work that comes back within a month. Four numbers, collected from the tools we already use, before and after a change in tooling.
Why we do not count lines of code
Because assistance produces more of them, and more code is a cost. A measure that rewards volume will reward the wrong behaviour within a sprint.
Where the gain is real
Test coverage, migrations, repetitive refactors and documentation. Work with a known shape, where the bottleneck was typing and recall. Junior engineers get unblocked faster, which shows up as fewer stalled tickets rather than as faster individual output.
Where it costs more than it saves
Reviews get longer, because plausible-looking code takes more attention than obviously wrong code. Unfamiliar domains get worse, not better. And any task where verifying the answer costs as much as producing it is a net loss, every time.
The honest summary
On our own delivery the reliable gain sits in review throughput and in the boring half of a sprint. It does not compress a discovery phase, it does not reduce the number of engineers a hard problem needs, and it has never once made a deadline that was wrong to begin with.
How this reaches your invoice
It does not, directly. We do not bill by keystroke. It shows up as more shipped in the same sprint, and as fewer weeks spent on the parts of a build nobody wanted to pay for anyway.
The tooling behind these numbers is the AI engineering kit. Everything else we build with models is on the AI map.