Is commits per developer a useful productivity metric?

On its own, no. A raw commit count has no honest good number — commit size and habits vary enormously between people doing equally valuable work. The widget deliberately carries no benchmark tier for that reason.

What should I look at instead of the commit count?

The other three columns: lines added and removed, AI-assist percentage, and the weekly trend. Those describe the shape of someone's work rather than just its frequency.

Does the same person appear multiple times across providers?

No. Identities are unified across GitHub, GitLab and Azure DevOps so one engineer is a single row rather than three partial ones.

Commits per developer: why the count alone tells you almost nothing

Commits per Developer puts one row per person — commit count, lines added and removed, AI-assist %, and a weekly trend — unified across GitHub, GitLab, and Azure DevOps so the same person isn't split into three rows. There's no benchmark tier here on purpose: a raw commit count has no honest "good" number, and this page exists to explain why the other three columns matter more than the first one.

deckgauge · Board · Commits per Developer

Developer	Commits	+ Lines	- Lines	AI-assist
D. Kowalski	142	380	210	12%
S. Iwasaki	58	6,400	1,900	41%
A. Petrosyan	89	2,240	890	68%
L. Fontaine	33	2,100	700	9%

Synthetic table, one row per person, sources merged.

What it measures, and where the data comes from

Commits — raw commit count in the window, attributed per person and unified across sources so one developer working across two repos on two different platforms shows up as one row, not two.
+ / - Lines — lines added and removed across those commits. This is the column that turns a commit count into something meaningful: it's the difference between "shipped a lot" and "committed a lot."
AI-assist % — the share of that person's commits flagged as AI-assisted by the connected source. It's a tool-adoption signal, not a quality signal — assisted and unassisted commits are graded the same everywhere else on this page.
Weekly trend — a sparkline of commit counts, so a person going quiet shows up before their total for the window looks low.

Sourced from GitHub, GitLab, and Azure DevOps commit history — whichever platforms are connected to the board. There's no benchmark tier because there's no honest universal target for commit count; some people commit in small increments, some batch a day's work into one commit, and both are fine engineering habits.

Activity, not valueEvery column here measures how someone worked, not what the work was worth. A commit fixing a typo and a commit shipping a new billing engine both count as one row in this table. Treat it as a conversation-starter, never a stack-rank — the moment this table becomes "who committed the most," people will start optimizing for commits instead of for the thing the commits were supposed to produce.

How to read it

Never read the Commits column by itself. Read it against + / - Lines first — a high commit count with a small line-change footprint usually means someone commits in tiny increments, which can be a good habit (small, reviewable diffs) or a sign of busywork, and you can't tell which from this table alone. Read it against AI-assist % second — a big jump there tells you a tool is genuinely sticking with someone, not that they're suddenly more productive.

The weekly trend is the column to watch for people, not the total. A flattening sparkline on someone whose total for the window still looks respectable is the earliest version of "this person's checked out," well before a 1:1 would surface it on its own.

What it tells you over time

Commit habits are personal and pretty stable — someone who commits in tiny increments in week one will still be doing it in week twelve, and that's not a trend, it's just how they work. What is worth tracking over a quarter: AI-assist % creeping up across the whole table (adoption is spreading) versus staying flat for everyone but one or two rows (adoption stalled outside a small group), and a weekly trend that keeps drifting down for a specific person across several weeks in a row.

Example situations

1. High commit count, barely any lines changed

deckgauge · Commits per Developer

Developer	Commits	+ Lines	- Lines
D. Kowalski	168	410	260
S. Iwasaki	44	7,100	2,300

Commit count and lines changed pulling in different directions.

What you're seeing: D. Kowalski has almost four times the commits of S. Iwasaki, but a fraction of the lines changed. On a commit-count-only view, Kowalski looks like the more prolific engineer. The lines-changed columns say the opposite is closer to true.

How to react: don't reward the commit count on its own. It's entirely possible this is a good habit — small, atomic commits that make review and rollback easier — so look at what those commits actually touched before assuming it's padding. Check the Merge Frequency and PR Size widgets to see whether the commits are landing in substantial PRs or just churning the same small area.

Managerial playStop using commit count as a proxy for output in any conversation, formal or casual — it's too easy to game and too easy to misread in either direction. If you want to praise someone's pace, point at what shipped (a feature, a fixed incident, a closed ticket), not at how many times they pressed commit to get there.

2. AI-assist % swinging wildly across the table

deckgauge · Commits per Developer

Developer	Commits	AI-assist
A. Petrosyan	89	68%
S. Iwasaki	58	41%
D. Kowalski	142	12%
L. Fontaine	33	9%

AI-assist adoption uneven across the team.

What you're seeing: AI-assist ranges from 9% to 68% across four people doing comparable work. That's not noise — it's a real gap in how much the team has actually adopted whatever AI tooling is available to them.

How to react: this isn't a "some people are lazy" story or a "some people are cheating" story — it's an enablement gap. Find out what A. Petrosyan is doing differently before assuming D. Kowalski and L. Fontaine just haven't tried.

Managerial playAsk your highest-adoption rows to demo their actual workflow in a team session — the specific prompts, the specific tool, the specific moment they reach for it versus write it by hand. Adoption spreads through seeing a concrete example, not through a Slack link to a tool nobody's opened. Revisit this table in a month; if the spread hasn't narrowed, the blocker is tooling access or trust, not awareness.

Frequently asked

Is commits per developer a useful productivity metric?: On its own, no. A raw commit count has no honest good number — commit size and habits vary enormously between people doing equally valuable work. The widget deliberately carries no benchmark tier for that reason.
What should I look at instead of the commit count?: The other three columns: lines added and removed, AI-assist percentage, and the weekly trend. Those describe the shape of someone's work rather than just its frequency.
Does the same person appear multiple times across providers?: No. Identities are unified across GitHub, GitLab and Azure DevOps so one engineer is a single row rather than three partial ones.

Related widgets

Merge Frequency per Developer — the outcome-shaped counterpart; PRs merged, not just commits made.
Bot vs Human Commits — makes sure the commit counts here aren't quietly inflated by automation.
AI Adoption — the team-level rollup of the AI-assist % column.
Back to the widget reference.

Last updated 17 August 2026