Forem: Alex Rebula

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

Alex Rebula — Sun, 03 May 2026 06:33:41 +0000

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.

Portfolio website

Coming soon.

The Ethics of AI-Assisted Work: What the Professional Codes Actually Say

Alex Rebula — Fri, 24 Apr 2026 04:53:46 +0000

This is Part 2 of my series on AI in professional work.
Read Part 1 → I Used AI for 90% of my Portfolio Website — Am I Cheating?

As you read this article, you'll notice the em dash ( — ) appearing. I'm aware of it, and we'll address that later. But ask yourself: What does a punctuation mark once known only to real writers tell you today versus what it meant in the past?

I'm back on the job market, updating my portfolio, writing posts, networking, and staying on top of industry developments. This time I'm approaching it more deliberately, treating the process like a researcher. I want to examine things properly, write about it, and cite sources, examples, not just assert facts and give advice that anyone can copy from an AI model conversation and paste on LinkedIn.

Every conversation loops back to AI. Articles everywhere tell you that "AI will replace you", "AI is a cheat code", "AI users are lazy", "AI users are the future". Everyone has a strong opinion.

I've seen developers and writers get frustrated with people who use AI heavily but don't make it their own. I get that frustration. I've seen the kind of output they're complaining about — generic, polished, completely interchangeable, with almost no real human voice left in it.

The problem isn't AI. The stone in the shoe for many of us is the misuse of a powerful tool. Any tool can be used well, even the worst one. The same way any screwdriver can open a bottle of beer, the same way any pair of scissors can cut a finger. AI is no different. Here's another example. Try asking AI to print a Slovenian famous "jota" (pronounced roughly "YOTA") cabbage and beans soup. I can assure you with 100% accuracy that other than getting a perfect recipe, you will stay hungry. Unless you put your apron on and really start cooking.

It Worked For Centuries, So Why Fix It Now?

It is not that the em dash should not be used, it should! It is beautiful! It served a purpose for centuries and it still does in books, but in today's AI world it is a visual tell, and sometimes even a first impression, as sad as this may sound.

In case you want to know, the em dash is named after the width of a capital M in a typeface and has been used in English writing for centuries to show interruptions or asides. The only thing is, no one, except professional copywriters, ever used it. And now, suddenly everyone is Shakespeare. The issue is that LLMs are trained mostly on formal writing – essays, journalism, books – so they love throwing in em dashes.

I personally find them very useful and feel they SHOULD be a standard in any text. I am curious what the writers have to say about this.

But, I'm Not A Writer

A colleague once asked if I'd used AI on a document I prepared for a client.

I said

"Yes, of course! Why?".

He said,

"I could tell straight away. Not because of the em dashes, but because you used American English instead Australian."

Let's just say felt like the Homer Simpson meme. The client was a big Australian company.

What happened? The model just defaulted to American English because most of its training data is American. I'm a Slovenian living in Australia, writing for Australian clients and readers.

What Do IEEE and ACM Actually Require?

The IEEE Software Engineering Code of Ethics and the ACM Code of Ethics are comprised of obligations.

Obligation #1: Do you understand what you're producing? If you can't explain it, that's a problem, regardless of how you built it. You shouldn't claim expertise or authorship if you don't actually have it, and you own your output, full stop. Whatever ends up in production with your name on it is yours.

Obligation #2: You have to disclose AI use in published work and name the tool you used.

Obligation #3: AI can't be listed as an author; you have to disclose when you used it, and the humans involved are fully responsible for what gets published.

None of these policies prohibit AI use but both require disclosure and accountability.

Disclosure: Tools Used for This Article

Because I just spent the last few paragraphs talking about professional obligations around disclosure, I’m going to practise what I preach.

I wrote every single idea, opinion, story, and personal reflection in this article myself. The core content — the em dash observation, the jota soup analogy above, the stories below - the "šlepar" story from university, , the CodeProject funeral, the Andy Serkis analogy, and all the feelings around being accused of cheating — are 100% mine. They came from my own experience and thinking.

I did, however, use AI assistance (Grok) for two very specific things:

Helping me condense the original 2000+ word messy draft into a tighter, more readable version while keeping every idea and every one of my own words.
Light structural feedback and suggestions on flow and order.

I did not ask the AI to generate any new ideas, rewrite my stories, or polish my voice. I reviewed every change and kept full ownership of the final text.

I believe this is the right balance — using the tool for what it’s good at (speed and structure) while staying the one who owns the thinking, the stories, and the final decisions.

But my story is absolutely NOTHING compared to this guy's story.

There's a Gollum Hiding in My Article

I recently saw Andy Serkis doing the audition for the Lord of the Rings. Seriously? Andy Serkis needs an audition for a job? This analogy can be translated into engineering – every good and experienced engineer will eventually be humbled on a tough interview, no matter his portfolio and experience.

I always try to stay grounded with the knowledge that no matter what, I never know everything, and there is always someone above me that will easily destroy me on an interview with more knowledge, experience, and intelligence.

Therefore, I would be terrified going on an interview, not knowing what my code does when questioned. This would destroy my self-worth, my ego, and my reputation. I'm okay not knowing things, but I'm not okay going on an interview and not knowing what my code does and why.

The "Cheat" at The University & Serena Williams

In Slovenian, we use the word "šlepar" (pronounced roughly "SHLEH-par"), which describes a person who fakes competence – someone who pretends they know the material and have prepared properly while secretly relying on cheat sheets or hidden notes to pass the exam. In short, it describes a cheat.

Even when I was still at the university, a professor once accused me to my face of being a cheat during an exam. With no evidence. Just on a hunch. I was upset and justifiably so. Not because I failed that test, but because I am not a cheat, let alone there was no proof or real indication of that. I don't have issues with authority and I always loved my mat teacher from high school, despite the fact that I struggled with math at that time.

I can still hear Serena Williams' voice clearly:

"I have never cheated in my life. I have a daughter, and I stand for what's right for her. I have never cheated."

That's exactly the same how I felt at that exam "incident", and I still feel like that if I think about it - the shame, the frustration, the loss of reputation in front of a professor.

The differences between Serena and me are just immense -> Serena is a wonderful athlete and I am not. Also, she has a daughter and I have a son.

For all these reasons, I stand by the principle that whether you can explain it now, without documentation, under direct questioning or not, makes the difference between an honest person and a cheat.

Vibe Coding - Brrrrr... :)

I do allow myself to "vibe code" for things I don't know much about (YET) - example - devops. This allows me a great, effective, fast learning opportunity for things it would take me forever to learn back in the days when there was no AI other than in The Terminator movies - but I always and always want to know what the code does and I want it to be documented - Not just pressing the accept button and then no review. At least press that button, but review it after. I know, I know, in a perfect world, you should never push your code before it is perfect, but at least, while you're learning and working on professional code, you are allowed to make mistakes that will make you a better professional at work, when it really conunts.

For things I know, making the code with AI is a breeze – I can review quickly and ask AI to review specific things because I know them.

Ask yourself:

"Can you explain your codebase to a junior developer without documentation in front of you?"

Can you defend the decision in your codebase in an interview?

Personal Voice Is a Professional Signal

Recruiters can usually tell when a portfolio is AI-drafted. The rhythm and structure are the same, nothing that could only have come from one person.

The ones I remember are the ones where something clearly happened to a real person.

AI is good at structure, at mocking, at explaining, at finding needles in a haystack. But it doesn't have your experience, it doesn't see the full context of the app architecture without your expert explanation and putting everything in proper perspective.

Only when this is done, AI will help you. I've learned this the hard way - I lost my job because of AI, and I'm going to get a new one with AI.

The Real Emerging Problem: Article Fatigue

Everyone writes now. Publishing used to require effort, time, and skill. That barrier is basically gone. The volume has exploded, and the average quality has dropped. Readers are fatigued. Nobody believes the text is yours.

Do you remember CodeProject? Here's a reminder.

If you do, you're probably around my age, in your 40s and 50s. It launched in 1999 and was THE blogging place. At its peak, it had 15 million registered members. The articles on the site were long and properly structured. Source code was included. Design decisions were explained. It went offline in March 2026. Not because the content was bad. The financial model just collapsed. There wasn't enough attention to go around, and there was too much free content everywhere. It died right as the flood of low-effort AI content peaked. I find that depressing.

The only thing that actually cuts through now is specificity. A post that could only have come from one person, about one specific situation, from a perspective nobody else has.

Conclusion

Know what you're shipping, own the output, and don't claim things that aren't true. AI just makes all three easier to get lazy about.

The engineers I've seen use it well are the ones who stay close enough to the work that they're still making the calls.

If you're reading something and trying to figure out if it's worth your time, stop worrying about AI involvement. Check if there's a real person behind it. Is there something specific? Is there a specific opinion, something that could only have come from one person's situation?

That's what matters. The tool used is irrelevant, your ethics are not.

References

[1] CodeProject — Wikipedia... (accessed 23 April 2026)
[2] IEEE Author Center. Guidelines for Artificial Intelligence (AI)-Generated Text...
[3] ACM. ACM Policy on Authorship...
[4] IEEE Computer Society. Software Engineering Code of Ethics...
[7] Rebula, A. I Used AI for 90% of My Portfolio Website — Am I Cheating? DEV Community, 23 April 2026.

I Used AI for 90% of my Portfolio Website — Am I Cheating?

Alex Rebula — Sun, 19 Apr 2026 06:36:49 +0000

I am currently building my new portfolio site with extremely heavy use of AI (Claude + Copilot). Probably around 90% of the code, documentation, tests, and even some of the architectural thinking have been accelerated or directly generated by AI tools.

And I’m completely fine with that — the same way I am completely fine pasting my own ideas, sweat and experience into a prompt in bullet points and thoroughly revising the result before publishing the article like in this case. As times change, tools change, and people should move with them and add human value to the ever-improving toolset.

But the question still comes up (both from others and occasionally from myself): "Am I cheating?"

My Honest Answer

No, I’m not cheating.

I use AI aggressively for speed, but I follow a deliberate, systematic process to stay in full control and maintain ownership of the code.

Every generated piece goes through structured review:

I maintain detailed TODO lists in Markdown files for every major section and component.
I write tests (Vitest) for critical data factories and components.
I force myself to understand and be able to explain every function and major decision.
I regularly push back on AI suggestions that feel off, overly clever, or not aligned with existing codebase patterns.
I treat AI output as a strong first draft — never the final product.

This review discipline is something I’m actually proud of. It’s how I make sure the massive speed AI gives me doesn’t come at the cost of depth or long-term maintainability.

Where Does AI Really Help

Boilerplate → It removes boring boilerplate and lets me move extremely fast.
New learning discoveries → It surfaces patterns and solutions I might not have considered immediately.
Consistency → It helps me maintain consistency across a large number of components and even documentation.

A quick note about code documentation though — I personally do not care if a documentation is written with AI or not, as long as it helps and as long as it is well written. I really don't. An article may not belong in this same category, depending on the premise, but as far as documentation concerns, I am totally fine with using AI. In other words, if you produce great documentation and you used AI for that, I can only say thank you!

A Concrete Example From My Own Project

When I asked the AI to silence Iconify’s “icon loaded online” warnings, it suggested importing large JSON packages (@iconify-json/solar, @iconify-json/logos, @iconify-json/simple-icons) and writing a pickIcons() helper. It compiled and the warnings disappeared — technically “correct.”

Before — what AI suggested:

// icon-sets.extra.ts (AI version)
import { icons as logosIcons } from '@iconify-json/logos';
import { icons as solarIcons } from '@iconify-json/solar';
function pickIcons(collection: IconifyJSON, names: string[]): IconifyJSON {
  return { ...collection, icons: Object.fromEntries(names.map((n) => [n, collection.icons[n]])) };
}
addCollection(pickIcons(logosIcons, ['angular-icon', 'vue', 'react', ...]));
addCollection(pickIcons(solarIcons, ['code-bold', 'settings-bold', ...]));

This however, was the wrong solution.

The codebase I used already had a clean and established pattern in icon-sets.minimals.ts: inline SVG strings, no extra package imports, explicit width/height control. Copilot / Claude didn’t see or follow that pattern — it reached for the general Iconify documentation approach instead of reading the existing code first.

I caught it though. I pushed back, and we rewrote it together properly: no heavy imports, only the exact icons we use, explicit dimensions, and clear comments explaining the rules for anyone who adds icons later.

After — the correct pattern already in the codebase:

// icon-sets.extra.ts (correct version)
// Rule: inline SVG body only. For logos: collection, always include explicit width + height
// because register-icons.ts forces the collection default to 24×24, which clips non-square paths.
addCollection({
  prefix: 'logos',
  width: 24,
  height: 24,
  icons: {
    'angular-icon': {
      width: 256,
      height: 271,
      body: '<path fill="#E23237" d="M0 134.5L11.5 ..." />...',
    },
    // ... one entry per icon, exactly the ones we use
  },
});

The AI's version: ~18 MB of JSON. The correct version: ~75 KB of inline strings. 247× smaller — and it follows the pattern that was already there.

This is exactly why the review process exists.

Here’s the actual difference:

Package	Raw size	Icons available	Icons we actually use
@iconify-json/solar	6.3 MB	7,404	105
@iconify-json/logos	7.3 MB	2,091	10
@iconify-json/simple-icons	4.6 MB	3,693	3
Total	18.2 MB	13,188	118

The correct approach used 118 inline SVG strings across two registration files, which only weighs around 75 KB total. And that my friends is an oustanding 247× difference in payload. And that's not a small number.

Another issue Claude pointed out to me after my aditional analysis was a defect hiding in the AI’s "lazy" approach: logos icons had a 256×256 viewBox, but register-icons.ts forced all non-carbon collections to default to 24×24. Basically, what happened was, that the pickIcons() approach copied only body and dropped the metadata, so icons like logos:typescript-icon would have silently rendered with the wrong dimensions at any non-standard render size.

An Audit Proved My Point

When the inline SVG pattern was correct, I still continued with my questions and asked the AI to audit the codebase and re-confirm every icon was registered. Just to be on the safe side.

A second scan revealed the real usage: 105 solar icons (not 4). It had also missed 5 logos icons because they were stored as string values in TypeScript data objects rather than JSX props.

So I went further and asked AI to handle both patterns (JSX attributes + string literals) with a whitelist of known Iconify prefixes. The 5 missing icons were finally added, the tests now pass against the correct 118-icon count, and the site is better for it.

And I like to believe this is exactly the kind of thing a senior developer catches that AI alone misses. Maybe you don’t even need to be a senior developer for that — just one that cares.

My Rules for This Project

AI is allowed to draft, but I must review, understand, and be able to defend every important piece.
Critical parts (like the sections-api data layer) get extra scrutiny and manual refinement.
I will eventually go through the entire codebase and make sure I can explain every function and design decision without referring back to the AI conversation.
When AI produces a wrong pattern and I correct it, I write a regression test so the mistake can never happen again.
This portfolio is my test project: use AI aggressively to ship fast, but then do the deeper work to truly own the result.

Disclosure: Tools Used for This Article

Because I talk a lot in this post about staying in full control and owning the work, I want to be transparent here too.

I wrote every single idea, story, example, and opinion in this article myself. The Iconify story, the audit experience, my rules, and all the feelings around “Am I cheating?” are 100% mine.

I did use AI assistance (Claude + Copilot) while writing and refining this post itself — mainly for light structural suggestions, tightening some paragraphs, and improving flow. I reviewed every change and kept full ownership of the final text.

This is the same approach I use in the actual codebase: AI helps me move faster, but I stay the one who understands, reviews, and takes responsibility for everything that ships.

I believe this is the honest and professional way to do it.
I’m not ashamed of using AI heavily. I’m actually quite proud of the system I built around it to make sure I stay a better engineer, not a worse one.

The goal isn’t to write every line myself. The goal is to ship high-quality work while keeping my skills and understanding sharp.

That’s the balance I’m aiming for.

What about you? Have you found yourself above? Have you built something similar with heavy AI use you can talk about? Is so, please, do drop your experience in the comments, it will make me hapy and I do respond.