GitHub Contribution Graphs Don’t Mean What They Used To

If you’re a Software Developer and have not been living under a rock for the past 3 years, you have used an AI coding assistant either in a work setting or at home for your personal pet projects or both. If you’re like me, and you tend to pay attention to those GitHub contribution timelines showing how active you have been over the last year, you may have noticed a similar trend. Here’s what my activity looked like a few years ago. I was actively developing a personal project in the second half of the year. I was developing the application before the age of coding assistants. I made 1,262 commits that year, and almost all were for that repository.

Compared to that year, I started using coding assistants heavily the year below and specifically started working on a different personal project on June 12th. For the second project, I decided to do vibe coding using Cursor and then subsequently switched to Claud Code.

Here’s where things get interesting.

According to GitHub’s own contribution counting rules, my activity on this newer project shows 194 commits total. That’s not a typo.

Those 194 commits produced 215,947 files.

By comparison, the earlier project built with traditional workflows resulted in 57,437 files across 1,936 commits.

To put it another way:

• ~1,900 commits → ~57k files (pre-assistants)
• ~200 commits → ~216k files (with assistants)

I know what you think. A high number of files or the number of commits is not necessarily a great indicator of productivity over a period without some measure of the quality of the work. We are not even counting lines of code. But I’m not really debating productivity in relation to quality here. At least not yet 😊 I’m merely pointing out the fact that the GitHub contribution timelines are no longer a reliable proxy for productivity in the age of AI coding assistants. We are at a point where we can make massive changes in many code files in a short period, and therefore the number of files changed per commit has increased dramatically. Every developer who has embraced the technology feels it, and we should be able to measure it.

Now you may be asking, why does this matter? Who even pays attention to this timeline graph?

Well, if you manage a team, or care about your own productivity, you should care about such things. You should care about how you can do more in less time and be able to measure your productivity in ways that represents the output produced. We need to change this timeline to be a combination of commits, lines of code, issues resolved and/or created, tests added, and a lot more. We are at a point where we need to finally answer the question of really “how much more productive is a team when using one coding assistant versus another?”