2 posts tagged with "GitHub Copilot"

It’s Tuesday morning, 09:00.

You’re fired up, coffee nearby, and ready to build software.

You open GitHub Copilot and ask it to help implement a change.

Before it can really get going, you explain how the application is structured.

You tell it where the business logic belongs, which patterns the team follows, how tests should be written and which architectural boundaries it needs to respect.

Copilot gets to work.

The result is good.

Later that morning, you open another conversation to work on something else.

• Again, you explain the project structure.
• Again, you mention the coding standards.
• Again, you remind it how your team expects tests to be written.
• Again, you remind it which architectural boundaries it needs to respect.

At some point, you realise the problem. You are spending a surprising amount of time teaching Copilot how your engineering environment works before asking it to do any actual engineering.

• Some rules should already be available.
• Some expertise should be reusable.
• Some work should have a clear owner.
• Some behaviour should happen automatically.
• Some workflows need access to systems outside Copilot.

And that is where prompting starts to feel insufficient.

That is where GitHub Copilot customisation starts to become genuinely useful.

I Used GitHub Copilot Every Day — Why I Still Took GH-300​

I had already been using GitHub Copilot regularly before I decided to take the GH-300 certification.

It was part of my normal development workflow. I used it to generate code, explain unfamiliar code, refactor existing solutions, explore implementation approaches, write tests and reduce repetition in everyday engineering work.

So when I first looked at the GitHub Copilot certification, I had a very obvious question:

If I already use Copilot every day, what exactly am I going to learn from an exam about it?

It had been a while since I had completed a formal certification, and I had started to think they were not always necessary. At the same time, I also knew that certifications can be useful when they force you to think more deliberately about a tool you already use well.

That question turned out to be the reason the certification was useful.

Using a tool frequently and understanding how to use it deliberately are not the same thing.

GH-300 pushed me past the "I know how to prompt this tool" stage and into the larger question of how AI fits into real software engineering work: context, instructions, governance, accountability and workflow design.

There were plenty of topics in the exam that went beyond my day-to-day usage, and that was exactly why it was valuable.