DEV Community: Mykola Mizhigurskiy

Microsoft GH-300: GitHub Copilot | Tips & Tricks

Mykola Mizhigurskiy — Mon, 10 Aug 2026 19:10:40 +0000

Today I passed the GitHub Copilot GH-300 exam and decided to write down my impressions right away while they are still fresh. First of all, this article is not so much a “how to pass” guide as a place where people who are currently preparing for the exam can ask questions to someone who literally took it today. If anything from my experience helps you prepare better, or at least understand what to expect, then this article has already served its purpose.

The gap between preparation materials and the actual exam questions

The first thing that genuinely surprised me was how different the information in the recommended preparation materials can be from what you actually see on the exam. A few times, my completely honest reaction was: “Where did this even come from?” Subjectively, I managed to answer some of those questions not because I had memorized the materials well, but because by the time I took the exam I had already been using Copilot quite intensively in real-world development. Sometimes practical experience helped, sometimes it was a general understanding of engineering processes, and sometimes it was simply common sense.

So I would not recommend treating the official materials as a complete map of the exam. They are useful and they provide the basic structure of the topics, but they are not enough to make you confident about every question. If you already use Copilot at work, that is a serious advantage, because part of the exam tests not only whether you know the wording from the documentation, but also whether you understand how the product behaves in common scenarios.

Copilot = Microsoft

Another thing worth keeping in mind: Copilot is GitHub, GitHub is Microsoft, and Microsoft also means Windows and PowerShell. If, like many developers, you have spent years working on macOS and barely touching the Windows ecosystem, some questions may come as an unpleasant surprise. For example, you may need at least a basic understanding of how something is installed or configured through PowerShell. I barely looked at things like that during my preparation because I relied too heavily on the recommended resources and hardly read any additional documentation. If I were preparing again, I would definitely close that gap.

Do questions from the preparation materials appear on the exam?

A separate story is my attempt to “outsmart the system.” During preparation, I collected all the questions I came across in the learning modules and the practice exam, put them into Anki, and simply memorized them. I thought it would be a decent safety net: even if the questions were not repeated word for word, at least I would have the relevant facts firmly memorized. In practice, my subjective impression is that I did not see a single question repeated exactly on the real exam, and only one or two vaguely resembled something I had learned this way. So I would not recommend memorizing the correct answers; it is much more useful to use those questions as a way to check whether you actually understand the topic.

Question formats

Another mistake in my expectations about the GH-300 was assuming that the exam would mostly follow the classic format: one question, four answers, one correct choice. In reality, there are more formats. Some questions require you to choose two correct answers out of four or three out of five, some ask you to match items between two columns, and some require you to arrange several steps in the correct order. Personally, I found the last type to be one of the trickiest because it is no longer enough to “roughly remember the correct answer” — you need to understand the process itself.

Statistically, you can feel the difference too. In a standard multiple-choice question with four options, you at least have a 25% chance of guessing correctly if you know absolutely nothing. But when you need to choose several items from a set and then put them in the correct order, the number of possible combinations grows very quickly. That is why I would pay particular attention to how GitHub Copilot handles basic workflows: authentication, starting a new session, resuming a previous one, working with context, and common interaction scenarios. It is important not only to know that a feature exists, but to understand what happens step by step.

A final gift :)

And finally, here is a small semi-joking life hack that I came up with for myself while preparing. Use this entirely at your own risk.

If you are looking at a question where you have absolutely no idea which answer is correct and you are going to guess anyway, take a closer look at the longest option. In the practice materials, I repeatedly noticed a pattern: the correct answer is often written in a complete, careful way with all the necessary qualifications, while the incorrect options sometimes look as if, after writing the correct one, the author got a little tired of coming up with alternatives.

If you don’t know which answer to choose, choose the longest one.

I do not know how consistently this works on the real exam, and I definitely would not recommend using it as a substitute for knowledge. But if you are already in a situation where you have to guess anyway, at least you will have some kind of heuristic. I saw this pattern often enough in the practice questions to notice it.

If I had to start preparing again today, I would spend less time memorizing ready-made answers and more time on three things:

actually working with Copilot
reading additional documentation
understanding the product workflow.

The learning path and the demo exam are useful, but I would treat them as a map of the topics rather than a simulation of the actual exam.

So,

if you are preparing for the GH-300 right now, leave your questions in the comments.

While my impressions are still as fresh as possible, I will try to answer everything I can.

Chasing Tokens: I Renamed My Entire Repository — Here’s What Happened

Mykola Mizhigurskiy — Mon, 10 Aug 2026 15:11:14 +0000

After optimizing my CI logs for AI agents, I found myself looking for tokens everywhere.

Then I had another idea.

Many of my files and directories used kebab-case.

My assumption was simple: if - increases token count, then switching everything to camelCase might reduce the amount of context an AI agent has to process.

So instead of guessing, I measured it.

I wrote a script to tokenize my entire repository before and after renaming every kebab-case path to camelCase.

Repository before: 376,553 tokens
Repository after: 376,204 tokens

Total reduction: 349 tokens.

Honestly? That was much smaller than I expected.

At first glance, this looks like a classic micro-optimization. But I don't think the story ends there.

Why File Paths Matter More Than You Think

Unlike source code, file and directory names have a very different lifecycle during an AI coding session.

An agent doesn't read them just once. They appear repeatedly in:

imports and exports
directory listings
search results
git diffs
stack traces
test output
formatter and linter logs
tool responses from the IDE

In other words, file paths are part of the agent's working context over and over again.

So while the repository itself became only 349 tokens smaller, the cumulative savings across a long coding session could be noticeably larger because those same paths are processed repeatedly.

I haven't measured that part yet, so I won't claim any specific numbers.

Conclusion

This experiment reminded me of something more important:

Measure first. Optimize second.

Some optimizations that sound brilliant turn out to be negligible. Others—like reducing unnecessary tool output—have a much larger impact than you'd expect.

AI-assisted development is creating a whole new class of performance optimizations. The only way to know which ones matter is to measure them.

What micro-optimizations have you tested for your AI coding agents? Did they actually move the needle, or did the data surprise you? Let me know in the comments!

💥 Easy way to save your AI coding agent a surprising amount of context.

Mykola Mizhigurskiy — Mon, 10 Aug 2026 15:07:28 +0000

One thing clicked for me only after working with AI agents for a while.

Like many teams, I have a set of mandatory checks that must pass before code is committed:

Prettier
ESLint
Type checking
Unit tests

I also have a rule for my coding agent: whenever it makes executable code changes, it automatically runs all of these checks before moving on.

Sounds obvious, right?

The problem was that all of these tools were configured for humans, not for AI.
For example:

Prettier printed every file it checked - even when nothing changed.
The type checker produced verbose success output.
The test runner listed every executed test file.
ESLint printed a lot of informational output even when everything passed.

Then it hit me:

Every line of that output becomes part of the agent's working context.
Those hundreds of log lines aren't free. They consume context, increase token usage, and make it harder for the model to focus on information that actually matters.

Fixing the Noise

So I changed the defaults:

Prettier runs silently unless there's a formatting issue.
ESLint only reports warnings and errors.
Tests use a dot reporter and print detailed output only for failures.
Successful checks produce only a short summary.

The result?

Exactly the same safety guarantees, but with dramatically less noise.

For humans, verbose logs are mostly harmless. For AI agents, they're context pollution.

And context isn't free. Every unnecessary token is one that could have been spent reasoning about your code instead.

Sometimes the best optimization isn't a faster model—it's simply giving the model less irrelevant information to read.

Appendix: For those who prefer numbers over opinions

I rolled the repository back and measured the raw output with a tokenizer:

Prettier output: ~15,000 tokens
Test runner output: ~35,000 tokens

After enabling silent output and compact reporting:

Prettier: ~500 tokens
Test runner: ~1,500 tokens

That is roughly 48,000 tokens removed from a single validation cycle—without removing a single check or weakening the pipeline.

Same guarantees. Far less context pollution.

What configuration tweaks have you made to keep your AI coding agents focused? Let me know in the comments!

AI Melting Your Brain? Here’s the Fix.

Mykola Mizhigurskiy — Mon, 10 Aug 2026 15:03:18 +0000

A few weeks ago, I came across a post from a developer who had spent six months working with five or six Claude Code terminals open at once. His description of the experience was funny, but also uncomfortably familiar: most of the time, he was simply waiting for agents to finish and pressing Enter.

His conclusion was blunt: “Claude Code is melting my brain.”

I’ve been seeing variations of this concern more and more often. Developers who use AI heavily start wondering whether they are becoming less sharp because the machine is doing too much of the actual coding. At the same time, another term has started appearing in discussions around AI-assisted development: comprehension debt.

I think that term captures the problem remarkably well.

Technical debt appears when a codebase accumulates decisions that will have to be dealt with later. Comprehension debt appears when the codebase evolves faster than the people responsible for it can maintain a mental model of what is happening inside it. The software keeps moving forward, but your understanding of it falls further and further behind.

Eventually, you can end up in a strange position: you are responsible for a system that you technically own, but no longer fully understand.

These look like two different problems:

AI making developers “dumber”
AI creating comprehension debt

... but I suspect they are mostly the same problem viewed from two angles. And, more importantly, I think they have the same solution.

The problem is not AI. The problem is you going full auto.

There is a peculiar productivity competition happening in software engineering right now. Every week I see another impressive number: hundreds of thousands of lines generated, thousands of commits, dozens of agents running in parallel, or thousands of pull requests produced by AI-assisted development pipelines.

Uber, for example, has publicly discussed an internal AI coding system producing roughly 1,800 pull requests per week (1 PR each 80 seconds).

That is certainly an impressive throughput number. But whenever I see metrics like this, I find myself asking a slightly uncomfortable question:

What exactly are we optimizing?

A pull request is a unit of software delivery. It is not a unit of product value.

A software product is, at some level, encoded business logic. Its purpose is to solve problems: make something easier for a user, automate a process, reduce costs, create revenue, satisfy a regulatory requirement, improve reliability, or enable some new capability.

So the interesting question is not how quickly an organization can manufacture changes to a repository. The interesting question is how quickly it can discover, validate and deliver meaningful changes to the product.

Imagine someone tells you that their AI workflow can generate a thousand PRs in a relatively short period of time. Fine. Now ask them a different question: can you name the next important feature your product needs—right now?

And I don’t mean something sitting in the backlog already. I mean a genuinely new requirement. Something that has been validated rather than hallucinated by AI. Something supported by customer feedback, user behavior, business analysis, stakeholder needs, market research or other evidence that suggests building it will actually create value.

That is much harder. And definitely not possible at the rate of 1 feature per 80 seconds.

The reason is simple: once implementation becomes extremely fast, implementation stops being the primary bottleneck. Product discovery does not suddenly become a hundred times faster because your coding agent did. Neither do requirements analysis, UX research, architectural reasoning, stakeholder alignment or understanding what customers actually need.

At some point, enough is enough.

There is a finite amount of meaningful change that a product can discover, validate, absorb and maintain. Once AI gives us effectively abundant implementation capacity, maximizing the amount of code produced becomes a strange goal in itself.

And this is where I think full-auto development becomes dangerous. Not necessarily because AI writes bad code, but because execution can begin moving faster than understanding.

That is where comprehension debt starts accumulating.

My approach: Semi-Automatic AI-Native Development

The workflow I use has a deliberately cumbersome name: Semi-Automatic AI-Native Development with Human in the Loop.

I described the broader workflow in another article, so I won’t repeat the whole thing here. The important part for this discussion is the human in the loop.

I almost never use AI in full-auto mode for meaningful development work. I use it aggressively, but I try to be very deliberate about which part of engineering I delegate.

For me, AI is an extremely fast electronic typewriter, an implementation engine, a research assistant, a second opinion and a tool for validating assumptions. What I do not want it to become is a replacement for engineering judgment.

Before I ask an agent to implement something, I try to define the system it is going to operate inside as precisely as the task justifies. Depending on the feature, that means thinking through types, validation rules, business requirements, functional behavior, file structure, data flow, relationships between modules, API contracts, architectural boundaries and test expectations.

And one thing I care about particularly strongly is semantics.

What does this entity actually represent? Who owns this state? Where does this transformation belong? What responsibility does this module have? What does this abstraction mean in terms of the domain? Which concepts are genuinely different, and which are merely different names for the same thing?

Those questions are not formatting preferences. They are architecture.

Once those constraints are clear, AI can do what it is extraordinarily good at: execute quickly inside them.

Recently I came across a post from Robert "Uncle Bob" Martin that described a surprisingly similar philosophy.

His approach is more extreme than mine. He says he does not read the code generated by his agents; instead, he surrounds those agents with extensive constraints: unit tests, Gherkin tests, QA procedures, quality metrics, mutation testing, coverage and many other forms of automated verification.

I do still read AI-generated code. But the underlying idea resonates with me: the engineer’s job increasingly becomes designing the environment in which automated implementation is allowed to happen.

You create the constraints. You define the architecture. You specify the semantics. Then you let the machine move quickly inside that system.

Why I still review the code

When people argue that developers should review AI-generated code, the usual explanation is safety: AI can hallucinate, misunderstand a requirement, introduce a security problem or simply produce incorrect code.

All of that is true. But for me, there is another reason that is at least as important.

The generated code is feedback on the architecture I designed.

Before implementation begins, an architecture is partly a hypothesis. I believe these responsibilities belong in these modules. I believe this abstraction is sufficiently general. I believe this data flow is clean. I believe this type model represents the domain correctly. I believe these boundaries will continue to make sense when the next requirement arrives.

Then the AI implements the feature at high speed, and that hypothesis collides with reality.

Perhaps the abstraction turns out to be awkward. Perhaps data starts leaking across boundaries that were supposed to be clean. Perhaps a type requires exceptions everywhere. Perhaps two concepts that looked independent are much more tightly coupled than expected. Perhaps the agent repeatedly struggles with one particular part of the design.

Those are not merely implementation problems. They are signals.

When I review the result, I am not only checking whether the agent wrote acceptable code. I am checking whether my model of the system survived implementation.

That creates an extraordinarily powerful learning loop.

AI can make you learn faster, not slower

This is the part of AI-assisted development that I think gets far less attention than it deserves.

Without AI, much of a developer’s working day is consumed by execution. You design something, then spend hours or days typing it into existence. You write boilerplate. You perform repetitive refactorings. You search through documentation. You implement the twentieth variation of a pattern you already understand.

AI can compress a huge percentage of that execution time.

If you keep yourself inside the reasoning loop, the time you save does not have to disappear. It can be reinvested into the parts of software engineering where the real intellectual work happens: architecture, modeling, semantics, constraints, trade-offs and validation.

My workflow increasingly looks like this:

Design → constrain → let AI execute → inspect the result → learn → adjust the design.

Then another requirement arrives and the loop starts again.

The interesting part is the speed. Suppose I design an architectural approach and implementing enough of it to discover its weaknesses would traditionally take several weeks. With an agent, I may get that feedback in hours. Sometimes much faster.

That means AI does not merely accelerate implementation. Used this way, it accelerates the architecture-feedback loop.

You make a design decision. Reality tests it almost immediately. You learn. Then you make another design decision.

Do that repeatedly and something interesting happens: instead of spending most of your time exercising your ability to type code, you spend much more of it exercising your ability to design systems.

That is almost the opposite of “AI melting your brain.”

It is closer to deliberate practice for software architecture, with an implementation engine attached.

Of course, this only works if you actually stay in the loop. If you delegate the decisions, delegate the implementation, accept the output and move directly to the next prompt, the mechanism reverses. AI keeps learning about your codebase while you gradually stop doing so.

That is comprehension debt.

I probably won’t generate 1,800 PRs a week. That’s fine.

A semi-automatic workflow with deliberate human involvement is obviously slower than telling a swarm of agents to modify a repository as quickly as possible.

That does not bother me.

I want to produce exactly as much code as meaningful product development requires. If AI makes me capable of implementing useful changes faster than a product organization can discover and validate those changes, I have already won. More implementation throughput beyond that point has rapidly diminishing value.

The objective of software engineering is not to maximize the amount of software produced. It is to solve useful problems with software.

AI gives us an extraordinary opportunity to remove a large amount of mechanical work from that process. I think the mistake would be to remove ourselves from the intellectual work at the same time.

So yes, review the code. It may contain bugs. It may contain security issues. It may misunderstand your requirements. Those are all perfectly good reasons.

But review it for another reason too.

Review it because it tells you whether your architecture was right.
Review it because it forces you to maintain a mental model of the system you are responsible for.
Review it because every implementation is an experiment, and every experiment gives you feedback.

And if AI can run those experiments dramatically faster than before, perhaps the technology that supposedly makes developers stop thinking can—used correctly—make us learn faster than we ever could before.

There is one line from Uncle Bob’s recent posts that summarizes the responsibility better than anything I could add:

That is the point.

You are not the engineer because you typed every line of code. You are not the engineer because you can explain every keystroke that created the repository. And you are certainly not the engineer because your AI generated more pull requests than somebody else’s.

You are the engineer because you are accountable for the system that comes out the other side.

What do you think?

How are you managing the balance between AI speed and system comprehension in your codebase? Do you use a human-in-the-loop workflow, or have you experimented with full-auto agents? Let me know in the comments below!

Stop asking AI to do a linter’s job.

Mykola Mizhigurskiy — Mon, 10 Aug 2026 14:56:28 +0000

I have developed a workflow that I call:

A semi-automated, AI-native development flow with a human in the loop.

It may sound like a collection of AI buzzwords, but each part represents a very practical principle.

1. Semi-automated

If a task can be performed reliably by a simple script, it should not be delegated to AI.

Want consistently formatted code? Configure Prettier.
Want custom naming conventions, import restrictions, or architectural constraints? Configure ESLint or write a custom rule.
Want consistent formatting across different editors? Add an EditorConfig file.

Do not make AI spend context and reasoning capacity checking indentation, semicolons, or naming conventions. Deterministic problems should have deterministic solutions.

Here is a less obvious example.

I have written several thousand unit tests for my current project. As a perfectionist and former QA engineer, I care about how elements are selected in tests.

Whenever possible, tests should use accessible selectors first, such as roles and accessible names. A test ID should only be used as a fallback.

Initially, I treated this as something AI should remember, while I would catch mistakes during code review.

But I noticed that I was correcting the same issue far too often.

So I asked myself:

Why am I repeatedly reviewing something that can be checked automatically?
I wrote a custom lint rule.

A few lines of code solved the problem permanently.

Now the linter knows the required selector priority and reports violations automatically.

The best part is that AI fixes these issues in virtually every case.

Why?

Because running the project’s validation procedures is mandatory in my workflow. Even when AI makes a mistake, it runs the linter, receives a precise error message, and corrects the code.

That is what “semi-automated” means to me:

AI handles tasks that require reasoning.
Scripts handle tasks that require consistency.

2. AI-native

A repository can be structured primarily for human convenience, or it can be structured so that both humans and AI can navigate it efficiently.

An AI-native repository treats context as a limited engineering resource.

Some developers are familiar with code golf: solving a problem using the fewest possible characters.

AI-native development is not exactly code golf, but the underlying constraint is similar:

Every token has a cost.

This does not mean compressing the code until it becomes unreadable. It means finding a balance between readability, consistency, and context efficiency.

Project standardization plays a major role here.

One component should not use a completely different structure, style, or paradigm from another component without a good reason.

Reusable abstractions should be clearly defined and used consistently.

This allows AI to find an existing implementation, understand it as the project standard, and use it as a reliable reference.

Another important principle is what I call context segregation.

A feature should be divided into meaningful files so that AI can load only the context required for the current task.

For example, a test implementation may have:

the test file itself
fixtures
mocks
setup utilities

Sometimes the setup is larger than the actual test suite.

When I only need AI to inspect test names or understand what behavior is covered, there is no reason to feed the entire setup into its context.

I use colocated suffix files for this purpose. A larger feature can have several supporting files placed next to it, with clear suffixes describing their roles.

Depending on the task, I can provide AI with exactly the files it needs—and nothing else.

And please, use barrel exports where they make architectural sense.

There is no reason to repeatedly feed AI long absolute import paths when a stable public module API can expose the same components with fewer tokens and less coupling.

3. Human in the loop

The internet currently seems obsessed with fully autonomous pipelines where an agent writes code around the clock without human participation.

Maybe I am old-fashioned, but I am highly skeptical of that approach.

I could list many examples of what AI misunderstands, what must be reviewed, and where autonomous implementations fail.

But there is one issue that matters more than all the others:

If you remove yourself from the process, you stop LEARNING.

You are no longer collecting feedback.
You are no longer examining what AI understands and what it misunderstands.
You do not see which instructions work, which create confusion, where AI is fast, where it struggles, or where an additional tool could eliminate an entire category of mistakes.

Most importantly, you lose the data required to improve your own development framework.

Here is my favorite example.

At one point, I created what I believed was the perfect AI development process.

I reviewed every instruction repeatedly. I refined every detail. I was convinced that the framework was exceptionally well designed.

Then I used it in production.

Within two months, the process went through five generations of fundamental changes—not counting dozens of smaller improvements.

Why?

Because real-world usage generated feedback.

I observed what failed, what created unnecessary work, what AI interpreted incorrectly, and what could be automated more effectively.

No matter how good your prompt, instruction set, agent configuration, or MCP setup appears, you do not have objective evidence that it works until you observe it under real production conditions.

That is why my workflow keeps a human in the loop.

Not merely to approve AI-generated code.

But to learn from every iteration and continuously improve the system producing that code.

A New AI Paradigm: The Billion-Dollar Blind Spot

Mykola Mizhigurskiy — Wed, 21 May 2025 11:55:36 +0000

A New AI Paradigm: The Billion-Dollar Blind Spot

Modern AI systems are excellent at detecting toxicity, abuse, radicalization.

But there's a blind spot — and it's costing us billions:

They can't detect brilliance.

Every day, millions of users interact with AI. Among them,

1 in 10,000 may hold a breakthrough idea.
1 in 100,000 may be modeling the future of society, science, or intelligence.

But all of that signal vanishes.

No system is designed to surface it.

Enter SVITLO

SVITLO (Signal of Visionary Ideas Through Latent Observation) is a protocol that proposes a new direction:

➡️ Not just detecting threats

➡️ But detecting insight

➡️ Surface-level agnostic, cognition-focused

It doesn't require new infrastructure.

It builds on existing analytics pipelines and reorients them from defense to discovery.

What if your model could say:

“This interaction shows signs of exceptional thought. Would you like to be seen?”

Use Cases

Identifying overlooked talent
Spotting founder-level thinkers
Building archives of visionary insight
Enhancing alignment, recruitment, and impact

📖 Full manifesto on GitHub:

🔗 SVITLO manifest

Feedback, forks, and discussion welcome.