Hey, I’m Lars and I’m late to the party. Like, really late.
While everyone else has been talking about AI coding assistants, building entire apps with prompts, and sharing screenshots of their productivity gains, I’ve been… well, I’ve been in meetings. And reading architecture docs. Maybe doing some budget planning. And trying to remember when I last wrote production code for more than an hour straight.
If you’re reading this and thinking “finally, someone who gets it” – welcome. This series is for us. The engineering managers, the directors, the VPs, the tech leads who still love to code but don’t get to do it every day anymore. The ones who heard about GitHub Copilot and other tools months (or years) ago and thought “yeah, I’ll check that out later” – right before getting pulled into another planning session. The ones who installed it during a rare coding session, got some autocomplete suggestions, and didn’t really get what all the fuss was about. The ones who are now wondering if we’ve missed the boat entirely while we were busy, you know, working.
Spoiler: We haven’t.
The thing about being late
Here’s what I’ve learned: being late to the AI party doesn’t mean you’re doing it wrong. It just means you’re arriving with a clearer head. While the early adopters were figuring out what works and what doesn’t, we get to walk in and learn from their experience. We’re not pioneers – we’re pragmatists.
And honestly? When you’re spending half your day in 1:1s, reviewing your budget, and trying to keep three projects unblocked, you don’t have time to chase every new tool. You need to know what actually matters.
And you might be asking “Why GitHub Copilot? Why not Claude Code? Why not Cursor? Why Windsurf?”. The answer is simple. Because I started with Copilot. 🤷 Most people in tech already have a GitHub account. So it’s a simple thing to click that “purchase Copilot” button. But the stuff I’m writing about is not some GitHub Copilot special sauce. I’m sure the same concepts apply to most other AI coding tools.
GitHub Copilot: The basics (in case you’re even later than me)
If you’re completely new to Copilot, here’s the 30-second version: it’s an AI coding assistant that lives in your editor (VS Code, Visual Studio, JetBrains, even Xcode). As you type, it suggests code completions. Sometimes it’s a single line, sometimes it’s an entire function.
Think of it as autocomplete on steroids. You start typing a function name, and Copilot might suggest the entire implementation. You write a comment describing what you want to do, and it might generate the code for you.
Out of the box, Copilot is pretty smart. It reads your current file, understands your context, and makes reasonable suggestions. For a some people, this is enough. You get helpful completions, you accept the good ones, you ignore the bad ones, and you move on with your day.
But here’s where it gets interesting – and here’s where I felt genuinely silly for not knowing this sooner.
Copilot can read custom instructions from your project. You can literally tell it how your team works, what frameworks you’re using, what coding conventions you follow, and it will use that context when making suggestions.
You can create a simple markdown file in your repository that acts like a guidebook for Copilot. It’s been a feature for a while now. Everyone else seemed to know about it. And I… well… am late to the party.
What are custom instructions, actually?
Custom instructions are just a markdown file that you put in a special folder in your repository. Copilot reads this file and uses it as additional context when generating suggestions.
The main file most people use is .github/copilot-instructions.md – just create a .github folder in your repository root and add the file there. That’s it. No complex setup, no configuration. Copilot in VS Code and other editors will automatically pick it up.
What goes in this file? Whatever you want Copilot to know about your project:
- Project overview: What you’re building, what problem it solves
- Tech stack: The frameworks and libraries you’re using
- Coding conventions: How your team likes to structure code and unit tests
- Patterns to follow: Specific architectural patterns or approaches
- Things to avoid: Common pitfalls or deprecated approaches
It’s like giving Copilot a README for how you work, not just what your code does.
Getting started (seriously, it’s easy)
If you’re thinking “okay, this sounds useful but I bet it’s complicated” – it’s not. Here’s the simplest way to start:
- Create a
.githubfolder in your repository root (if you don’t have one already) - Create a file called
copilot-instructions.mdinside it - Write a few sentences about your project
That’s it. Really.
Here’s a simple example to get you started:
# Project Overview
This is a .NET application for collecting engineering metrics from different sources.
# Tech Stack
- C#
- MVC for the Dashboard project
- Plain JavaScript and CSS, no frameworks
# Coding Conventions
- Every business logic should have meaningful unit tests
- Keep components small and focused
# Testing
- Use xUnit instead of NUnit
- Use "given-when-then" pattern for test names
You don’t need to document everything on day one. Start small. Add a few lines about your tech stack. Mention a coding convention or two. You can always expand it later as you discover what helps Copilot give you better suggestions.
And why not go one step further and let Copilot create the copilot-instructions.md for you 😉 (see https://docs.github.com/de/copilot/how-tos/configure-custom-instructions/add-repository-instructions#asking-copilot-coding-agent-to-generate-a-copilot-instructionsmd-file)
You’re at the party now
Look, I’m not going to pretend I’m some AI coding wizard. I’m still learning. I still ignore half of the suggestions. I still write plenty of code the old-fashioned way – by thinking hard and typing it out myself. And some weeks, I don’t open my IDE at all because, well… Excel, PowerPoint, Outlook and Teams dominate my screen these days.
But Copilot and it’s custom instructions actually made a difference. It’s a small change that makes those rare coding sessions more productive. When you’ve only got an hour or two to work on something, you don’t want to spend it fighting with your tools or remembering conventions.
And if you’re just discovering this now? You’re not behind. You’re right on time. We’re all just figuring this out as we go, somewhere between the sprint planning and the 1:1s.
Next up in this series (yes, I’m actually planning to do a series again. Fingers crossed, that it will not be just another single post series 😄): I’ll dive into more autonomous coding using agents.
Until then – happy coding (whenever you get the chance)! And remember: the best time to arrive at the party is whenever you actually get there.