Skill reuse: the metric that predicts AI winners

The teams pulling ahead with AI aren't writing the most code — they're reusing the most skills. New Codiedev research shows how fast a team creates and reuses skills is a leading indicator its output dashboards can't see.

Los Angeles, July 9, 2026— Codiedev, the platform that measures how engineering skills compound, today published research showing that the fastest-improving engineering teams are set apart not by how much code they write with AI, but by how many of their skills get captured and reused across the team.

The finding runs against the instinct that AI productivity is mostly about the tools. Access to a capable model is table stakes now; most engineering teams have it. What separates them is what happens to the knowledge those tools help create — the prompts, patterns, specs, and fixes that make the second use of a tool far faster than the first. On the teams that pull ahead, that knowledge is captured and shared. On the teams that stall, it evaporates at the end of each session.

“Every velocity dashboard can tell you output went up. None of them can tell you whether it will keep going up. Skill leverage is the leading indicator underneath the graph — the skill written once and applied a thousand times. The teams compounding those skills are quietly pulling ahead, and until now nobody could measure it.”

— Eric Lam, co-founder and CTO of Codiedev

The research is built on Codiedev telemetry — every skill authored, surfaced, and reused across a nine-week study of a 75-engineer platform team. It is also why Codiedev treats skill reuse as a leading indicator: reuse is the input a team can grow directly, and shipped output is the result that follows from it. Measuring the input — not just the output — turns a lagging scoreboard into an early signal.

Output tells you where you've been

Pull-request counts, cycle time, deployment frequency — all real, and all sharing one property: they report the past. By the time a chart moves, the work is already done and the habits that produced it are already set. That makes output a scorecard: useful for keeping score, useless for changing the result of the quarter you are still in.

Skill reuse behaves differently. When an engineer captures a pattern — a prompt that reliably works, a spec that encodes a hard-won convention, a fix for a whole class of bug — and a teammate applies it, the team gets faster at that kind of work immediately, and again every time the skill is reused. The reuse shows up in the data the moment it happens, weeks before its full effect accumulates into shipped output. Watch the input and you can still act; watch only the output and you can only report.

This is the difference between a lagging metric and a leading one, and it is why two teams with identical AI tooling can diverge so sharply. The tools are the same. What differs is whether the knowledge those tools produce stays in one person's head or compounds across the team.

Key findings

• 1
  Skills compound.As the team's shared skill library grew, weekly reuse climbed from a handful to 567 per week, and reuse per authored skill reached 36×. A skill captured once is applied more times every week it exists.
• 2
  A little authoring, a lot of leverage. 37 skills, written once, were reused 1,337 times over the study window — a 36× return on the effort of writing them down.
• 3
  Deeper reuse, not just more people. Across a steady group of active contributors, weekly reuse nearly quadrupled— the gains came from richer reuse of what the team already knew, not from adding headcount.

The story is in the back half. Merged output ran at its usual baseline while reuse was still near zero; then, as the team's reuse of its own captured skills took off, the work it merged accelerated with it — the two climbing together and cresting in the same week. It is the pattern you would expect if reuse is what turns individual AI speed into shipped output.

Why skills compound when code doesn't

A line of code is written once and, most of the time, used once. A skill is written once and used indefinitely. That asymmetry is the whole engine behind the curve above. The library grew only modestly over the study, but every skill already in it stayed available — so the pool of reusable knowledge got deeper each week even when few new skills were added, and the odds that any given task matched something the team already knew kept rising.

Compounding also means the return on a single act of authoring is not fixed. A skill reused ten times in its first month is not finished paying out; it keeps returning value for as long as the work it addresses recurs. Thirty-seven skills producing 1,337 reuses is not a one-time transfer of thirty-seven lessons — it is thirty-seven assets still on the balance sheet, still accruing. Output metrics have no line for this, because the asset never appears as output. Only its effects do.

How captured skills got put to work

The mix matters as much as the volume. The largest share of reuse happened automatically — a captured skill matched to the work in front of an engineer without anyone stopping to search for it. That is the difference between a wiki nobody opens and knowledge that arrives at the moment of use. Documentation that has to be hunted for decays; knowledge that surfaces itself compounds, because the cost of reusing it drops to almost nothing.

The compounding total

What this means if you run an engineering org

The takeaway is not “write more skills.” It is that skill reuse is a number worth watching in its own right, next to velocity and delivery — because it moves first, and it tells you something the others cannot: whether the productivity you are seeing is durable or borrowed. A team whose output is climbing while its reuse stays flat is getting faster on individual effort, and that advantage walks out the door when the individuals do. A team whose reuse is climbing is building something that stays.

It also reframes where attention pays off. When reuse concentrates in a few people, the highest-leverage move is rarely hiring — it is making sure what those people already know becomes something the rest of the team can pull. The knowledge exists; the gap is distribution, and distribution is a far cheaper problem to solve than raw capacity. It just stays invisible until you measure the layer where it lives.

None of this replaces output metrics. It sits in front of them. Delivery tells you what shipped; skill reuse tells you whether next quarter's delivery is being quietly built or quietly bottlenecked in a handful of heads.

Reading the signal on your own team

The mechanism is general: any team that captures and reuses its engineering knowledge produces this data, and the shape of the curve says how healthy the compounding is. A steepening reuse line means the library is paying off faster than it is growing — a team gaining leverage. A flat line beside rising headcount or rising output means the knowledge is not spreading, and the gains rest on people rather than on anything the organization owns.

Measuring that is the point of Codiedev. The same instrumentation behind this report runs on a team's real work, turning the skills engineers already create into a metric leaders can watch — so the question “is our AI advantage compounding or borrowed?” has an answer before the output charts catch up.

Research methodology

About Codiedev

Codiedev is the platform that measures how engineering skills compound. By instrumenting the skills, specs, and context engineers capture and reuse as they work, Codiedev turns scattered tribal knowledge into a measurable, compounding asset — so engineering leaders can see not just that AI made their teams faster, but why, and whether it will last.