A contribution graph is the most widely read piece of evidence about developers that exists. It is also one of the most specific, and the specificity is the part that gets lost. Each square is a claim about repository events on a calendar day, in UTC. It is read as a claim about whether somebody was working. Those are not the same statement, and the gap between them is not a rounding error. Worth being exact, because the exactness is the argument. What the squares actually count GitHub documents this plainly, and it is narrower than the reputation of the graph suggests. Creating a repository and forking one always count. Opening an issue, proposing a pull request, submitting a pull request review, opening a discussion, answering a discussion, and making a commit count only when conditions are met. The conditions on commits are the interesting part. A commit counts only when all of the following hold: the commit email is associated with the account, the repository is standalone rather than a fork, the commit is on the default branch or on gh-pages, and the author has a stated relationship to the repository, as a collaborator or organization member, or by having forked it, or by having opened a pull request or issue there. Read that as a specification rather than as trivia and the shape becomes clear: Work on a branch that never merged to the default branch does not count. Work in a fork does not count. A day spent deleting code does not count unless the deletion lands as a commit on the right branch. A long debugging session that ends in a one-line fix counts exactly as much as a one-line typo correction. A day spent reading the codebase, or deciding not to build something, counts as nothing at all. None of those omissions are bugs. The graph counts what it says it counts, and it does it accurately. The failure is entirely on the reading side, where a precise record of a few repository events is taken as a general record of effort. Agentic work widens the gap Every one of those gaps existed before coding agents. Agents make several of them worse, in ways that push in opposite directions. Volume becomes cheaper. When an agent writes the lines, the count of lines and the count of commits detach further from the effort behind them than they already had. A productive afternoon and a wasteful one can produce the same number of squares, and the wasteful one can produce more. Meanwhile the decisions that matter most produce fewer artifacts, not more. Stopping a run that has gone wrong, discarding what an agent produced, choosing a smaller approach, deciding a problem is not worth solving: these are the judgments that separate developers who work well with agents from developers who do not, and every one of them shows up as less on a graph that counts events. So the metric was already narrow, and the arrival of a tool that inflates the numerator while the real work moves to the denominator does not improve it. A calendar of activity records that something happened. It was never able to record whether it was worth happening, and it is now recording a noisier version of the first thing. The obvious trap on the way out There is a tempting response to all this, and it is wrong. The response is: fine, count better things. Weight the squares by tokens, by session length, by cost, by lines produced, and produce a richer picture of a day. That is the same mistake with more inputs. Weighting a calendar by tokens does not measure effort; it measures how much the agent emitted, which is closer to a measure of the tool than of the person. Weighting by elapsed time rewards the long session that should have been stopped, which is the exact behavior the rest of this journal argues against. Every intensity measure available here is a volume measure under a different name, and volume was the original problem. The warning is not new. The SPACE framework was written partly to correct this habit, and it is blunt about it: productivity cannot be reduced to a single dimension, and counts of activity such as commits and pull requests do not reveal why the count moved, so they should never be used in isolation to reward or penalize a developer. A contribution graph is a single activity dimension read on its own, which is precisely the arrangement that guidance exists to prevent. Adding more volume to it does not move it out of that category. This is why the rules Seorak binds itself to for a public activity record are deliberately dull. A day counts as active when at least one captured coding-agent session had measured activity on it. Where intensity is shown, it may reflect the number of distinct sessions and nothing else: not tokens, not messages, not tool calls, not cost, not elapsed time, not generated output. A streak is a count of consecutive active days over complete coverage, and where coverage is partial or missing the streak is unknown across that boundary rather than broken or filled in. The last one is the one that took the most argument to keep. A missing day is not a zero. A machine that was not capturing is not a day that was not worked, and rendering it as an empty square would state something false in the most legible possible way. What a calendar is honestly for Having spent five sections on limits, the fair thing is to say what remains. Presence over time is real information. It shows sustained engagement with a body of work, which is genuinely hard to fake over months and genuinely relevant when somebody is deciding whether to take a project seriously. A person who has been at something for a year has been at something for a year, and that is worth being able to show. What it does not show is quality, output, productivity, improvement, expertise, or how somebody compares to another developer. Those are not conclusions the underlying measurement can reach, and a calendar that implies them is not being generous, it is being wrong. The rules above inherit every one of those limits and add one more: they see only sessions the collector captured, so work done on a machine without capture is invisible, and invisible is not zero. A square means an event occurred. Everything else people read into it, they brought with them, and a record that is honest about the difference is more useful than one that quietly encourages the confusion.