The week that looks empty in git
Everyone who has done this job for a while has had the week where they closed a customer-facing incident, unblocked two other engineers, killed a bad architectural decision before it shipped, and pushed four commits totalling maybe sixty lines. Then they opened their own GitHub profile on Friday and felt vaguely fraudulent. The graph was pale. The week was brutal.
Quick Answer
Engineering work that never becomes a commit is most of the job: code review, reading and thinking before any code exists, supervising an AI agent, config and environment plumbing, spikes that proved an approach wrong, and debugging that ends in a one-line fix or no fix at all. Git records file-tree changes at the moment they are written, so none of that work is in the repo, and the contribution graph treats a week of it as an empty week. The traces do exist, but they sit in the forge API, in CI history, and in editor and terminal session activity rather than in commits. Below is a taxonomy of the six types, an honest read on how much of the week they take, and what to do if you need the invisible half of your work to be visible.
That gap is not a measurement bug you can fix with a better git query. A commit is a claim about output. It records that this file tree changed, at this moment, attributed to this author, and it says nothing about what produced the change, how long the change took, or how many changes you correctly decided not to make. Everything upstream of the diff happens somewhere git was never watching. The breakdown of why green squares mislead covers what this does to how people read your profile. This page is about the work itself.
A taxonomy of non-commit engineering work
The six categories below cover almost every hour that vanishes between "I worked all day" and "the repo says otherwise". The last column is the useful one, because none of this work is untraceable. It leaves its traces somewhere other than the place people look.
| Work type | What it looks like in a real week | Does it produce a commit? | Where a trace does exist |
|---|---|---|---|
| Code review | Reading a diff properly, pulling the branch, testing the edge case the author missed, writing comments, re-reviewing after changes | No, and never in your own history | Forge API (PR reviews, comment threads, approvals) |
| Thinking and design | Reading existing code, sketching a schema, comparing two approaches, deciding not to build something | Sometimes, hours later, as one small commit | Editor and terminal session activity; design docs if you wrote them |
| Agent supervision | Prompting Claude Code or Cursor, reading what it produced, rejecting half of it, re-steering, verifying the rest | Yes, but the diff arrives in seconds and hides the hour around it | Agent session telemetry, token and cost logs |
| Config, environment, plumbing | CI that fails only on main, expired secrets, dependency upgrades, local env drift, a deploy that will not deploy | Sometimes, as a two-line YAML change after three hours | CI run history; session activity |
| Spikes and dead ends | A branch that proved the approach wrong, a library evaluated and rejected, a prototype that answered its question and died | Almost never, since deleted branches and stashes leave nothing | Session activity, and nothing else |
| Debugging | Bisecting, adding logging, reproducing on a colleague's machine, reading traces | A one-line fix, or nothing if the cause was config | Session activity; the issue tracker if you filed it |
Three of them behave differently from how people assume.
Agent supervision is the newest and the most badly measured. When Claude Code writes a 900-line scaffold, the commit lands in about forty seconds and looks, in the repo, like the most productive minute of your quarter. The hour you spent specifying the thing, reading the output, catching the two places it silently changed an interface, and re-prompting does not appear anywhere in git. In practice this inverts the old relationship between diff size and effort. The biggest commits in an agent-heavy week are often the ones you thought about least, and the tiny ones are where the judgement went.
Spikes are the only category with no trace at all. Review lives in the forge, config failures live in CI, but a dead-end branch you deleted on Thursday leaves nothing behind except the decision it produced. This is the purest form of engineering work that never becomes a commit, and it is usually the work that saved the most money. Nobody has ever been promoted for a git log entry that says "spent two days proving we should not do this".
Config work is the one people underestimate in their own logs. You will often see a developer write off a day of CI archaeology as "admin", as though it were email. It is engineering, it takes the same context and the same debugging discipline, and it blocks everyone downstream until it is done. The two-line YAML commit at the end is a receipt, not a record.
How much of the week is this, honestly
Nobody has published a clean measurement of this split, and any precise-looking percentage you see quoted for it is almost always self-reported. What we do have are the hands-on-coding studies, and they bracket the problem from the other side.
RescueTime's widely cited developer study put active coding-application use at about 52 minutes a day. Amazon shared internal data landing near an hour a day for many engineers. A multi-company survey of roughly 3,000 developers reported a much wider band of 2 to 6 hours, because self-report and passive measurement are not measuring the same thing. The full comparison of those studies explains why the spread is so wide.
Take the range at face value and the arithmetic is unavoidable. On a 40-hour week, hands-on editor time lands somewhere between roughly 5 and 20 hours depending on whose definition you accept. Meetings and real non-engineering overhead take part of the rest, and what remains is the six categories above. Even inside the editor hours, only a fraction ends up as a commit, because reading code, running tests, and steering an agent all happen in the same window as typing.
My own read is that for a mid-level or senior engineer, non-commit work is somewhere between a third and two thirds of the week, and the share rises with seniority. I will not pretend that is a measured figure. It is a bracket derived from the studies above plus the shape of the calendar, and the only number that matters to you is your own. Which you can get, but not from git.
Why engineering work that never becomes a commit stays invisible
The mechanism is worth being precise about, because "git is incomplete" gets said a lot and rarely gets explained.
A commit stores a snapshot of the file tree, an author, and a timestamp taken when the commit object is created. That timestamp is a moment rather than a duration, so the entire history of a change collapses into a single point, and six hours of investigation produces the same shape of record as forty seconds of agent output. Reviews are not repository objects at all. They live in GitHub's or GitLab's API as a separate object graph, which is why git-only analytics can report your commits but not your review load. Spikes get garbage collected. Config work shows up in CI logs that expire on a retention policy.
This is why inferring hours from commit clustering drifts, and drifts hardest for the people using AI the most. The technique assumes commit density tracks effort density, and agent workflows break that assumption in both directions at once, batching hours of supervised work into one large commit while scattering trivial fixes into many small ones. Git remains a useful baseline for what shipped and when. It is not a clock, and the more of your week goes to the six categories above, the further off it reads.
Making the invisible half visible
Most developers hit this problem when someone else needs to see the work: a client questioning an invoice, a performance review, a manager who reads the dashboard literally. Here is the order I would work through, cheapest first.
- Pull your review activity from the forge API. GitHub's
/search/issues?q=reviewed-by:youand the pull request reviews endpoint give you a month of review load in about ten minutes. For most senior engineers this is the largest invisible category and the easiest to recover. - Write down decisions, including the rejected ones. A three-line entry when you kill an approach turns a spike from a total loss into a durable artefact. It is the only trace that category will ever have, and it costs a minute.
- Count the outcomes, not the activity. Whether a change failed in production, whether last month's code has already been rewritten, and how long work took to reach users all survive the AI era intact. The metrics that hold up under agent-written code go through this, and none of them care who typed the characters.
- Instrument the sessions if the stakes justify it. Editor and terminal telemetry records work as it happens, which is the only way to capture the categories that leave no artefact. It is heavier than the first three steps and worth it mainly when someone is paying for, or judging, the answer.
One thing not to do: fix the pale graph by committing more often. Splitting work into smaller commits changes the record without changing the work, and that reflex is what made contribution density worthless in the first place. Fragmenting your day to feed a metric costs you real time too, which the piece on context switching puts numbers to.
Why this becomes a proof problem
This matters beyond feeling underappreciated on a Friday. Every claim you make about the invisible half is currently unfalsifiable. "I spent two days on review" and "I spent two days on Reddit" produce the same git history, and a skeptical client, manager, or hiring panel has no way to tell them apart. Neither do you, six weeks later, working from memory.
It cuts both ways, too. People trust commits despite everything wrong with them because a commit is hard evidence of something, even if that something is narrow. Recovering the rest of the work means producing evidence of the same quality, recorded while it happened and traceable back to a source rather than reconstructed from a feeling. That is a higher bar than a timesheet, and it is the only version of this argument that survives someone who has no reason to believe you.
Where DevClocked fits
If you are a solo developer with nobody to convince, skip all of this. Your own sense of the week is fine, and the honest answer is that a tool solves a problem you do not have. A team running formal DORA reporting is also better served by an engineering-intelligence suite built for org-level rollups.
DevClocked is built for the case where the invisible half has to be defensible. Full disclosure: I build it. It combines a git baseline (useful, approximate, no per-editor plugin needed) with telemetry from a lightweight editor extension and an editor-agnostic CLI tracker covering terminal and agent sessions, so time spent driving Claude Code, Cursor, or Codex is captured as the engineering work it is rather than as a forty-second commit. The git baseline alone will not give you accurate hours, and I would rather say that plainly than sell the graph as a clock. The telemetry layer is what makes the rest possible: Work Blocks that show review and supervision time alongside authoring, AI-versus-human attribution on what shipped, token and cost tracking on agent sessions, and a Leverage Score that reads output against real effort instead of against diff size. If you would rather build this yourself, the guide to measuring developer productivity covers the approach without recommending any tool.
Common mistakes
Treating a pale graph as a verdict on the week. The graph is a record of one narrow event type. Reading it as a productivity score means grading yourself on the fraction of your job that happens to leave a file-tree diff.
Assuming agent-heavy weeks are lower effort. The diff got bigger and the typing got shorter. The specifying, reviewing, and correcting did not go anywhere.
Logging invisible work as one "other" bucket. Review, config firefighting, and dead-end spikes have different causes and different fixes. Collapsed into one category, they tell you only that your week was busy, which you already knew.
Related Guides
- Why GitHub green squares don't prove you did the work: what the contribution graph measures and what it hides.
- How many hours do developers actually code?: the studies behind the numbers used on this page.
- Code metrics that matter in 2026: the measurements that survive agent-written code.
- How to measure developer productivity: building a picture that includes the non-commit half.
- The hidden cost of context switching: why fragmenting the day to feed a metric backfires.
- DevClocked vs RescueTime: how a general activity tracker compares to a code-aware one.
