How do you measure developer productivity? Every classic answer — lines of code, commit counts, story points, hours — measures something other than what you actually care about, and some of them destroy team trust along the way. This article presents the unit we use at DeployIt: the dev-day, an estimate of production that everyone understands — executives, developers, and now AI agents.
Why the classic metrics lie
Lines of code reward verbosity. The best commit of the week is sometimes the one that deletes two thousand lines: a refactoring that halves your codebase would count… negatively. No serious developer takes this metric seriously, and they're right not to.
Commit counts measure a splitting habit, not production. One developer commits fifteen times a day out of good hygiene; another commits once, when the feature is done. Same actual production, wildly different numbers.
Story points are relative to the team that assigns them: incomparable across teams, prone to inflation the moment they're watched, and unreadable from outside. Ask a CEO what 34 points are worth; the silence that follows is the answer.
Hours confuse presence with production. And in the age of AI agents, time spent has lost its last link to value produced: an agent "works" for ten minutes and delivers the equivalent of two human days.
What these four metrics have in common: they count gestures. None of them estimates what was produced.
The dev-day: a unit everyone already understands
The definition we use: 1 dev-day ≈ 5 hours of focused production — a genuinely good developer day, thinking, tests, and review included. Not 8 hours: nobody produces eight hours of focused code in an office day, and an honest unit has to acknowledge that.
Why this unit works where the others fail:
- It's self-calibrated for a business reader. Everyone knows what a developer's day is worth — it's often a line in your P&L. "This week: 14 dev-days of production" reads without any training, where "47 commits" or "34 points" require an interpreter.
- It estimates production, not clocked time. The question isn't "how long did it take" but "what does it represent." A fix shipped in two hours that's worth a day of work counts for what it's worth.
- It survives AI agents. It's the only scale on which humans and agents can be read together — more on that below, because it has become the decisive use case.
Where the number comes from (and why we say "estimate")
DeployIt reads your GitHub in read-only mode and estimates production from actual activity: the scope of the changes, their nature (feature, fix, refactoring), their context in the project. The result is aggregated per developer, per AI agent, and per project, week after week.
And we label it for what it is: an estimate. The goal isn't penny-level truth — it's a stable order of magnitude, computed the same way every week, that makes periods comparable. Which is exactly what a leader needs to steer: the trend and the outliers, not the third decimal. What we measure is described on the product page.
Ready to see what your team shipped?
What it changes in the age of AI agents
Here's the use case that accelerated everything. If your team uses Copilot, Cursor, or Claude Code, one question keeps coming back, from the board to the coffee machine: "concretely, what is AI changing for us?" Without a common unit, the answer stays a feeling.
With dev-days, it becomes a number — illustrative example, not a customer case: a team of five developers plus two AI agents reads in its monthly report "62 dev-days produced, 17 of them attributed to agents, about 27%." Next month, 31%. It's an estimate, but it's computed the same way every month: the trend is solid, and the trend is what a board cares about. An agent that produces two dev-days within a single day — you see it. And that gap between machine time and estimated production is precisely the return on your AI tooling, made visible.
One important precision: agent code is graded with the same quality methodology as human code, with zero leniency. Producing a lot isn't enough; the report also shows whether it holds up.
What we do NOT do with dev-days
A production unit can turn into a surveillance instrument. Our red line is explicit: we measure AI agents thoroughly; we never track individual humans.
Concretely: no developer rankings, no individual "X dev-days per sprint" targets, no ammunition for performance reviews. The human-side reading is aggregated and trend-based — the team, the project, the period. AI agents, on the other hand, are individually accountable: share of the work, quality, human review required on their code. That asymmetry is deliberate, and DeployIt is read-only: it alerts you when something deserves attention; it blocks nothing and scores nobody publicly.
If a measurement tool offers you a developer leaderboard, run: you'd be paying for visibility with your team's trust.
How to introduce dev-days to your team
A unit shouldn't sneak in — it should be announced. Three steps that prevent the misunderstandings:
- Present it to the team, definition included. "We're going to read production in dev-days: 1 dev-day ≈ 5 hours of focused production, it's an estimate computed from Git, read-only." The word "estimate" has to be said out loud — it's what defuses the precision debates before they start.
- State the anti-surveillance rule on day one. No individual reading of humans, no personal targets, never in a performance review. If that rule isn't explicit, the most honest unit in the world will still feel suspicious.
- Install the reading ritual. The week's number gets read in the Monday report, as a team or in the leadership meeting — same place, same time, every week. Regularity is what turns a number into a steering instrument: after a month you're reading trends; after a quarter you're answering the board with data.
Dev-days in practice: the reading cadence
A unit is only as good as the ritual that carries it. At DeployIt, it arrives through the weekly report on Monday morning (the week in dev-days, humans and agents, plus the points needing attention), the monthly and quarterly reports built for a board or a client, and the real-time dashboard in between. We published a weekly engineering digest template if you want to see the shape, and the Swarmia alternative for non-technical leaders if you're comparing approaches.
DeployIt is free during early access; paid plans arrive in January 2027 — details on the pricing page.
You don't need a better gesture metric. You need an honest estimate of what got produced, in a unit everyone already understands. That's the dev-day.
Continue reading
Know What Your Developers Shipped — Without Standups
Reporting standups are expensive and still tell you neither what shipped nor what is stuck. Replace them with a Monday weekly report and a real-time dashboard, read-only.
Swarmia Alternative for Non-Technical Leaders
Swarmia speaks to VP Engineering: DORA, sprints, benchmarks. Here is the alternative for non-technical leaders who want to read what shipped — humans and AI agents — without the jargon.
Weekly Engineering Digest Template: Ship in 10 Minutes
Use this weekly engineering digest template to build a ship rhythm in 10 minutes — sections, examples, and how DeployIt emails it automatically every Monday.