Imagine you are a climber preparing to trek to Everest Base Camp.

There is more than one way to get there. You could take the Classic Everest Base Camp route, follow the Gokyo Lakes and Cho La Pass variant, tackle the Three Passes Trek, or take the historic route from Jiri.

Each can lead you toward the same destination, but the journeys are very different. They vary in time, difficulty, altitude exposure, scenery, logistics, and risk.

Suppose the climber chooses the Classic route.

Months later, someone looking only at the route they took might ask:

“Why didn’t they take the Three Passes route? It’s better.”

But better according to what?

Perhaps the climber had limited time. Perhaps they wanted a more established route, simpler logistics, or less altitude exposure. The decision only makes sense when you understand the circumstances in which it was made.

Architecture decisions have the same problem.

Months or years after a system has been built, someone might ask:

“Why did we choose a relational database over a NoSQL database?”

"Why did we build this capability rather than buy a SaaS product?"

"Why did we choose Azure App Service instead of deploying the application to AKS?"

Looking at the finished system may tell you what was chosen. It rarely tells you why that choice made sense at the time.

That is the problem an Architecture Decision Record (ADR) is designed to solve.

An ADR preserves the context behind a significant architecture decision so that someone looking at it later can understand not only what was decided, but why that path was chosen.

That leads to the more difficult question:

Which decisions are significant enough to deserve an ADR?

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.