The Grey Enemy and the Copilot Friend Who’s Turning My GitHub Green

The grey enemy and the friend to save me from it

If you're a software developer and you are on GitHub, you already know what I'm talking about: the contribution graph. That public heatmap on your profile that tracks your every commit, PR, and review you've ever made. That grid of gray and green squares that tells a story about your coding life, Or rather, a biased version of it. In some cases, it looks like a well maintained patch of grass. Just not on mine.

By the title you can already deduce how mine looks. Imagine my hair (I am 45) but worse. Although, my wife disputes the ratio. For years I couldn't look at it without feeling I had something to answer for.

Anyway, here it is. The current year of it at least:

This article is about why that grey is almost always a lie for enterprise developers, what I've been doing to reclaim a public record since April, and what a single morning of code review (alone, without a team behind you) taught me about how these tools actually work when you most need them to.

The "problem" with Github

GitHub's contribution graph is built for open-source and personal work. Enterprise consulting work leaves almost no public trace, by design. Here's how the graph actually works. I asked Copilot Chat (the VS Code extension, not the GitHub PR reviewer) to explain it:

Public repos stay on your profile forever, even after you leave. Private repos on the other hand show up if you enable "Include private contributions" in your profile settings. Private org repos however show up only while you still have access. In other words, when the org removes you, those green squares disappear from your graph.

I started writing code professionally in 2005. The decade before 2015 was enterprise work in Slovenia: financial systems, energy forecasting platforms, information portals. None of it on GitHub. Then SeamlessCMS in Melbourne, building government intranets and public-facing websites, none of it on GitHub. Then six and a half years at Avanade as a software engineer and senior consultant, working with Australian clients including city councils, Bankfirst, Funlab, Vanguard, CPI, NBN, and Australian Retirement Trust. All of it in Azure DevOps, behind client firewalls, invisible to any public graph.

Even if Avanade had used GitHub, my 6.5 years of commits would have vanished from my profile the day I left. The most productive years of an enterprise career leave the least public trace. My GitHub profile suggests I started writing code in 2025. That gap isn't laziness; it's how enterprise development works.

Could I have done extra open-source work on the side? Maybe. But I was also studying, working full days, and changing a toddler's diapers. I didn't, and I'm roughly at peace with it. The same way I'm at peace with not buying Bitcoin when a friend told me to. That was my Laszlo Hanyecz moment. Laszlo who? Laszlo was the programmer who, in 2010, paid 10,000 Bitcoin for two Papa John's pizzas when Bitcoin was worth fractions of a cent. Those coins are worth hundreds of millions today. I'm not glad for him, but at least I'm not alone in my mistakes. Some decisions only look obvious in hindsight. At the time I was writing C# and JavaScript in Sežana, Slovenia. I've learned one thing for certain: I'll never buy pizza with internet money.

The point is: my graph doesn't show the real systems, real scale, or real deadlines I've dealt with. But try explaining that to a heatmap.

The quiet erosion

I left Avanade in February 2024, made redundant, along with a wave of others during the AI spending hangover. Deep down I knew it was time for a change. What I didn't anticipate was how much I would miss being corrected by someone who knew better.

When you stop having code reviews, the love for the craft stays. The habit stays. But the muscle hasn't been tested, and you know it. There is no one to catch what you miss. You rest the brain, enjoy the break, and then every recruiter sees the grey graph and draws the wrong conclusion. My GitHub profile remained grey until I did something concrete about it. If you're in the same position: in my view, the answer isn't to explain the gap, but it's to DO something about it. Building something public ended to be super fun for me. I just hope I am not too late at my age.

I had a portfolio website in 2015 that got me my first Australian job. I removed it eventually. For some odd reason I wasn't proud of it anymore. Ten years on, I needed a new one. This time I wanted to build something I actually stood behind.

Making it green again

Since start of April, this year I've been changing that - I've been "overseeding" my lawn. If you're a gardener, you'll know what I mean, but if you're not, here's the "with other words" part: square by square, day by day I started to build open-source, in public, with work worth showing. I am not yet out of the grey, but I'll get there.

Three open-source packages, a portfolio site on Next.js 16 + React 19, 267 passing tests, a pre-push quality gate that runs six checks before anything hits the Main branch. Nobody asked me to build it that way, but I did, because I saw it when on an NBN project and because my twenty years of experience taught me what codebases look like without those tools. Tools I could only have dreamed of in 2015, let alone in 1992 when I was still loading games from a cassette on the Commodore 64.

I'm 45 now and at this age, sleep is the most valuable commodity I own, and I guard it accordingly. And when I do manage to wake up fresh, I don't waste it. So, every morning, I do my routine and walk to my computer with a cup of coffee, open the last PR, read the review comments from the day before, fix what needs fixing, and close the loop. Yes, I ask Copilot to fix it for me, I am not silly. I then review him, his buddy reviews him, I review the buddy with Copilot and this is how we roll. I like planning and I do that a lot. Therefore, before writing a single line of new code, I review, clean, document, and plan. Which might sound like boring maintenance, it is however the most valuable part of my day. It is the thing that keeps the muscle sharp and the codebase honest.

One morning, one pull request

On this particular morning, my ritual led somewhere interesting. The PR number 33 in my private portfolio repo had been done but not yet merged the night before, after a decent amount od first-round reviewing. Then, overnight, the GitHub Copilot PR reviewer (the one on the actual Github website) had left three extra comments I have not acted on yet after the final fix commit. I suppose, because I clicked the "Request review" button again for some reason. These new comments were in fact so good I was happy I purchased the Copilot subscription, even though I may suffer from hangover, when the bill comes. Could it be that it is also the fact that it is not cheap, the reason why I am even more motivated to use the tool in its fullest. To think of it, maybe a little, but to be very honest, I simply love how Good Github is and has become. It does make boring tasks super fun,exiting. It hits all the right dopamine spots of a developer such as I am.

So I acted on them - I took those post PR merge comments seriously. Even though this particular repo is private and I am the only developoer in it, so nobody is watching but me. The way how I am wired, I strongly believe that no time spent on code review is time lost. I also firmly believe code reviews are indeed an investment in my own future, money or no money involved. And they should be yours too.

I even had a good night sleep the previous night, so I had no excuses. I therefore opened a new Copilot chat session in VS Code and asked the question that had been sitting in the back of my mind since the night before:

Me:

"I need you to review your buddy at Github and look at the review comments for PR #33 in my private portfolio repo. Tell me what do you think about them and what would you do if you were the one to act on them. Would you do the fixes as per suggestions or would you do something even better? I'm also interested in knowing why was Copilot on GitHub website able to find things but you missed them while writing the code. I thought you had the same power, capability, and context."

That last statement I wrote ("I thought you had the same power, capability, context") opened the whole conversation up and the answer I got back was one of the most useful explanations I've received about how these tools actually work in practice.

GitHub Copilot:

The 9 comments split into two rounds and all nine were correct. None were nitpicks. Would I have done the same? Better? Honestly, I would have done same or equivalent on the code-level bugs. But here's the real answer to your question about why the GitHub PR reviewer found them and I didn't:
The GitHub Copilot PR reviewer has a fundamentally different activation model. Here's the simplest way to picture it: you open VS Code chat and ask me about one file. I respond to that file. The PR reviewer is invoked once on the full diff and must find every issue across the entire change set, without being prompted. It scans the entire diff in one shot — 89–99 changed files simultaneously — and its job is specifically "find all problems across this entire change set.

The output is as good as the input was

The PR reviewer on Github is a completeness tool. It scans the full diff and finds things you didn't know to look for. The VS Code Copilot however is a depth tool. It goes as deep as you direct it, on exactly what you show it. Both are the same model but they do different jobs, and produce different results. Once you understand the distinction, you then stop expecting one to replace the other and start using both deliberately.

That's the thing nobody told me when I started working with AI coding tools: the output quality is mostly a function of how you activate them. Directed conversation gives you depth and a full-diff review gives you breadth. And you do need both, because neither substitutes for the other.

Or in other words, you can give the instruction (the input) in just a few words, or you can spend a bit more time to think of more detailed instructions and write a paragraph. You can and should be doing both and both will give you different results, but both results are equally important. Simple when you think of it, right?

But it isn't. Because you need time, patience, motivation and devotion to do that. I've been doing this for twenty years, and the fact is I'm still learning how to use the tools. And I'd like to believe that's not a failure but it's the job. Because the day you stop discovering how something works is the day you start declining. Ask any "tradie", they will likely all tell you the same.

About the cost

GitHub Copilot Premium+ isn't cheap and I have just discovered a few days ago that they've just announced a shift to a consumption-based model, which, based on how I use it, I'm not expecting it to get any cheaper.

So is it worth the money? Yes! And here's is why in my example.

In my case several real bugs and accuracy issues were caught in a single PR pass. Out these, at least two were production-risk issues. They were the kind of defects that don't show up in unit tests and aren't obvious in a code walkthrough. This specific one - the "process.env dynamic-key" issue would have caused a runtime crash in the browser on certain Next.js builds; the regex portability hole would have silently failed on Windows only, the worst kind of bug to diagnose. I would had absolutely no idea until too late.

So, I am confident each fix saved me hours if not days of production debugging. These hidden mistakes are the kind that survive code review in a team, let alone when you're the only reviewer.

Because as sad as it may sound, I'm a solo developer at the moment and I have no team, no tech lead, no senior to glance over my shoulder and say "that regex won't work on Windows." There's just me, the codebase, and the tools I've assembled to approximate a professional environment, so that when my time comes again, I am ready.

So like in a sci-fi movie, Copilot is indeed for me personally the closest thing I have to a senior code reviewer at the moment. That is someone who reads every PR, never gets tired, and flags when a comment contradicts the implementation. It's not infallible though, it will make mistakes, of course, as it does miss things a human would catch from institutional, maybe architectural knowledge, and it can be wrong about intent. However, for breadth of coverage on a solo projects like the one I am working on now, nothing else comes even close. This great tool saves me days, not just hours, so, yes, that's a reasonable investment and I am not saying this lightly. I say this in a period when I have arguments with my wife regarding how we will spread the costs and ration food for the month. At least this is what I tell my wife about Copilot being a justifiable cost when it's time to pay the bills.

FUN FACT If you are reading this part of the article, then you're an absolute legend! It means there's a chance you might have actually read it in full. For this reason, I want you to at least have some fun with this story and I want to share the following anecdote with you.

I must be AI

Since we're speaking about AI reviewers, here's a funny one about the GPTZero AI reviewer.

I write articles on my own, relying heavily on spell checkers and AI detectors. I do not hide it and I am not afraid to admit it.I also hate being judged as lazy, when I know I'm not. A recent case of a man unjustly losing his degree in shame over this issue still bothers me. I believe I mentioned it in a previous article. In my particular case, I spent days before I was happy with what I wrote. I wanted it to be mine, even if it seemed like a rant or tangent. So I tested my work with GPTZero. Here's the score.

As almost everything was ok and it looked human (green), I ran the GPTZero scan again. And guess what?! The above paragraph (starting with "So like in a movie sci-fi movie") was deemed fully AI! I was in shock and horror! So, I left it. As is. Whatever! Because despite the fact I worked so hard on it, GPT Zero kept highlighting it all yellow and I leave it to you, dear reader, to figure out why in the world would anyone or any tool think the sentences above are AI. I was about to change it as per suggestion, but went: "Yeah, nah!" and just decided to leave it there, just for fun. Because the reason why some text gets flagged as AI makes you want to either laugh or cry and this time I was baffled.

But, since this is indeed a bit of a tangent, let's conclude today's Github topic.

Takeaways

If anything, what should we remember?

The Github contribution graph is biased towards enterprise work, sorry.
Contributions made in private org repos will disappear once you are no longer part of the project - in other words, twenty years of Azure DevOps commits will produce zero green squares.
The way how I decided to fight this is to build open-source. Public packages and repos, discipline, planning and morning rituals that close the loop on review comments. It's like going to the gym every day. The effort compounds, unlike the graph. I wish I went to the gym more often too.
Code review is my daily discipline and GitHub is really great at it. Every morning I try to review first, then build. This keeps my brain muscle sharp and the codebase good.
GitHub Copilot in VS Code IDE and the GitHub PR reviewer are the same model activated differently. Depth versus breadth, so, know which one you need, then use it on purpose.

Now, my fixes in the branch are up and the three files are clean and likely none of what I described was glamorous, but that's what a good morning looks to me - another green square earned today.

Can't wait to get the next one tomorrow. Who knows, maybe one day my green patches will no longer be just patches, but pastures.

If you came this far in the article, maybe I did something good after all and for that I say thank you. Let me know in the comments if that's the case, it would make my day. And if you're in the same position as I am, I'd love to hear from you and how you are dealing with it.

My open source repos (still in beta)

As of time of writing this it may not be much yet, but it will be. I would really love it if you would want to contribute or give me any feedback. No feedback is bad feedback.