I was inside a fast-growing Series A AI company where headcount had crossed the point at which any one person could remember who shipped what. Engineering moved across many repos, in many time zones, on a release cadence that nobody outside the team could narrate.

The consequence was predictable. Performance conversations and recognition decisions kept landing on the wrong axes — visible PR counts, who spoke up in meetings, who happened to sit next to whom. The actual shape of contribution was not on the table, because the table did not have it.

I wanted one artifact that turned the company's real GitHub activity into something a leadership team could read in five minutes — and that a contributor could read about themselves and recognize as fair.

GitHub will hand you 16 repos and tens of thousands of commits across a few dozen contributors. What it will not hand you is shape. Raw PR counts are a misleading proxy — one small bugfix can outweigh a month of careful refactor work. Reviews and issues matter, often more than authored code, and live in entirely different APIs. Reading commit diffs by hand does not scale past a single repo, let alone sixteen.

The hard problem was never "look at GitHub." The hard problem was turning diffs into substantively-described work in a way that survives audit — where every label on a person traces back to the line of code that produced it, and where the methodology itself can be argued with on its own page.

The system had to do four things at once: read code carefully, attribute it to the right person, aggregate it into a profile, and show its work. Skip any of them and the output is just another dashboard nobody trusts.

Phase 0 — Identity resolution.

Reconcile GitHub handles against the internal roster so every contribution lands on the right person. Engineers use multiple handles, bot accounts show up, and squash merges erase co-authors. Without this layer every downstream phase is noise dressed up as signal, so I treated it as the foundation, not an afterthought.

Phase 1 — PR collection.

Pull merged PRs from each tracked repo via the GitHub API, walk every commit inside them, and attribute work PR-centric: one PR fans out to many commits and resolves to one author chain. This is the shape that actually matches how the team ships, which matters more than raw commit volume.

Phase 1.5 — Reviews and issues.

Supplement PRs with review counts and issue activity through the Search API, sidecar to the main pipeline. Some of the most central engineers on a team review heavily and author lightly — they are invisible to PR-count metrics and conspicuous the moment reviews enter the frame.

Phase 2 — Diff analysis with Claude Haiku.

Run each commit diff through Claude Haiku to extract structured signal per commit: substantiveness, work type (feature / bug / chore / refactor), and auto-generated-code ratio. This is where the actual reading happens. Diffs are cached to Postgres and truncated at 30K characters so a re-run does not re-fetch from GitHub and does not blow up on a single oversized commit.

Phase 3 — Profile generation with Claude Sonnet.

Aggregate Phase 2 per contributor and synthesize: a title-like descriptor, a centrality estimate, a role read, and a short list of key deliverables. Sonnet does not see raw diffs — it sees already-summarized commits. That ordering is the whole point.

Why both models.

Haiku is cheap and runs across many diffs; Sonnet is the synthesis pass over already-summarized work. The split materially controls cost — the cheap model does the wide read, the expensive one does the narrow write. Collapsing them into a single model either inflates spend by an order of magnitude or sacrifices the substance of the per-commit read.

• Four-phase pipeline (identity → PRs → reviews → Haiku diff read → Sonnet profile)
• PR-centric attribution model handling multi-author commit chains and squash merges
• Diff cache in Postgres — Phase 2 re-runs never re-fetch from the GitHub API
• 30K-character diff truncation to control Phase 2 token cost
• groupBy aggregation queries — the employee list does not load the full contribution table
• Public methodology page so the synthesis is auditable, not opaque
• Web portal (Next.js 15) + analyzer CLI (TypeScript)

The interesting outcome was not in the dashboard. It was upstream of the dashboard, in how leadership conversations actually moved. Discussions stopped routing through "how many PRs did X merge this quarter" and started routing through Phase 3 profile reads — the title-like descriptor, the centrality estimate, the role read, the short list of key deliverables. The shape of the contribution finally fit on the page.

The methodology page did the second piece of work. It became the trust contract: any contributor could read why the profile said what it said, trace the label back to the commits it summarized, and disagree on specifics rather than reject the whole thing. That is a different shape of conversation than the one a closed dashboard produces.

I started this build thinking the hard part was the pipeline — model selection, identity resolution, the diff cache, the truncation math, the cost shape. Those were the parts I could plan on a whiteboard and ship in evenings. The hard part turned out to be the methodology page: writing it precisely enough that the first contributor who disagreed with their own profile could read it, find the exact step they wanted to argue with, and argue with that step rather than with me. Every word on that page was load-bearing — softening it killed the audit trail, hardening it killed the willingness to read it. The lesson:

The hard part of measuring engineering isn't building the pipeline — it's writing the methodology page that survives the first person who disagrees with their own profile.