GitHub Copilot for C# Developers: Setup, Techniques, Agents, and Honest Tradeoffs

A developer published a detailed walkthrough of GitHub Copilot for C# developers, breaking the tool into its three distinct components: inline ghost-text suggestions, Copilot Chat, and the more autonomous Agent Mode. The post demonstrates context-shaping techniques such as writing descriptive comments before code and keeping related files open, and highlights Chat slash commands like /explain, /fix, and /tests while noting their limitations.

GitHub Copilot gets mentioned constantly and explained properly rarely, most people know "it suggests code as you type" and stop there. This post covers it from the ground up, using the Product CRUD API from earlier posts as the working example, since that domain is already familiar and lets the focus stay entirely on Copilot itself rather than a new codebase. Copilot is an AI pair programmer built into your editor, trained on a large body of public code, that suggests code based on the context of what you're currently writing. It is not one single feature, it's actually three genuinely different tools sharing one name. Inline Suggestions show ghost text as you type, predicting the next line or few lines, press Tab to accept, Esc to dismiss. This is the original, most common form of Copilot. Copilot Chat is a separate side panel where you ask questions, request explanations of existing code, or ask it to generate something specific through conversation. Agent Mode is given a broader task rather than a single suggestion, and can plan, edit multiple files, and iterate somewhat autonomously toward completing that task, covered in depth further down. Think of autocomplete on a phone keyboard, but instead of predicting the next word, it predicts the next several lines of code, based not just on what you just typed, but on the surrounding context of your open files, function names, and comments. Once installed, ghost-text suggestions appear automatically as you type in any supported file type, including .cs files. Visual Studio's integration surfaces suggestions the same way - inline, as you type - with Chat available as a separate panel for conversational requests. Copilot's suggestions are only as good as the context it has to work with, specific techniques noticeably change what it suggests. // Writing a clear comment BEFORE the code - this // genuinely steers the next suggestion // validate that price is greater than zero and // stock quantity is non-negative public bool IsValid CreateProductDto dto { // Copilot's suggestion here is shaped directly // by the comment above - likely something close to: return dto.Price 0 && dto.StockQuantity = 0; } // Descriptive naming as a strong signal of intent // A vague name gives Copilot little to work with: public Task<bool DoThing int x { } // A descriptive name gives it a genuine, specific // signal of what the method should actually do: public Task<bool ReserveProductStockAsync int productId { } // Copilot's suggested implementation for the second // version is noticeably more likely to match intent Keeping related files open matters too. If ProductDto.cs, IProductService.cs, and ProductsController.cs are all open in tabs while writing a new method in ProductService.cs, Copilot's suggestions draw on the actual shape of those related types, property names, method signatures, rather than guessing at a generic, unrelated pattern. Copilot Chat also has slash commands worth knowing: /explain explains what a selected block of code actually does /fix suggests a fix for a selected block with an error /tests generates unit tests for a selected method genuinely useful as a starting point, covered further below under the honest cons section. The terminology here is genuinely confusing right now, worth untangling directly. Inline suggestions and Chat both respond to something you've already written or asked, one piece at a time. Agent mode is given a broader, higher-level task, "implement pagination for the GetAll endpoint," and can plan the necessary steps, edit multiple files, run terminal commands, and iterate somewhat autonomously toward completing that task, checking in with you at key decision points rather than requiring line-by-line approval. Autocomplete's scope is the next few lines, and you approve every single suggestion, constantly. Chat's scope is one specific question or request per message, and you approve by reading the response and deciding whether to use it. Agent mode's scope is a whole task, potentially spanning several files, and you approve at a higher level, reviewing a batch of changes, or specific decision points, rather than every individual line. Why this distinction matters practically: agent mode represents a genuine shift in how much you're reviewing versus how much you're trusting the tool to get right on its own, which directly changes how carefully you need to review the eventual output. Speed on boilerplate is real. DTOs, basic CRUD scaffolding, repetitive patterns, the exact kind of code shown across the CRUD post's good version, Copilot genuinely speeds up writing the first draft of structurally repetitive code. A fast first draft helps when you already know what correct looks like. Writing the general shape of a method you understand well, then reviewing and adjusting it, is often faster than typing every character by hand. It can also be a learning aid, used deliberately. Seeing an alternative approach to something you were about to write anyway can surface a pattern or method you didn't know existed, worth treating as a suggestion to evaluate, not an answer to accept. Copilot suggests code that statistically resembles patterns it has seen, including patterns that are simply wrong, if that's what surrounds it in context. // A REAL kind of situation worth being aware of: // if an older, unrelated file in the same project // still contained the BAD version's pattern from the // CRUD post - var query = "SELECT FROM Products WHERE Id = " + id; // - Copilot may suggest something structurally similar // for a NEW method, simply because that pattern exists // elsewhere in the codebase it has as context. It does // not independently know this is a SQL injection // vulnerability - it's reflecting the surrounding code, // good or bad, without judgment A few other genuine cons, stated plainly. There's a real over-reliance risk, accepting suggestions without reading them carefully is an easy habit to fall into, especially for boilerplate that looks right at a glance. Code can be confidently wrong, a suggestion can be syntactically correct, run without error, and still be logically wrong, Copilot has no way to verify business logic correctness, only pattern plausibility. Generated tests can test the wrong thing, /tests can produce a test that passes while checking a condition that doesn't actually matter, or missing the specific failure case, like the ones covered in the unit testing post, that a human would think to add deliberately. And there are genuine licensing and originality questions, a debated topic, since suggested code is generated from patterns in public code, and questions about attribution and originality are worth being aware of, even without a settled, universal answer. The problem: in a live coding interview, you're asked to implement a new endpoint with Copilot enabled and visible. You want to use it efficiently without appearing to not understand your own code, and without accidentally accepting a subtly incorrect suggestion under time pressure. The strategy, step by step: Write the method signature and a clear, specific comment BEFORE accepting any suggestion - this alone demonstrates you're directing the tool, not being directed by it Read every suggestion before accepting - out loud if the format allows it "this checks for null, then queries by id... looks right, accepting that" - this turns an invisible mental step into an audible, visible one for an interviewer When a suggestion looks reasonable but you're not fully certain, say so directly: "I'd want to verify this handles the not-found case correctly" - genuine, visible skepticism reads as competence, not hesitation Use Copilot for the boilerplate parts specifically the DTO shape, the basic CRUD structure and slow down deliberately for the actual business logic - this shows judgment about WHEN the tool is appropriate, not just that it exists If a suggestion is wrong, say so and correct it visibly, rather than silently accepting and moving on - catching and fixing an incorrect suggestion in real time is a stronger signal than never seeing one at all Copilot is three genuinely different tools under one name, inline suggestions, Chat, and agent mode, each with a different scope of autonomy and a different amount of review it actually needs from you. Clear comments and descriptive naming aren't just good practice for human readers anymore, they're the direct input that shapes what Copilot suggests next. Agent mode represents a real shift from approving every line to reviewing a batch of changes, worth understanding deliberately rather than treating it as just a faster version of autocomplete. Copilot reflects the patterns already present in its context, including bad ones, it has no independent judgment about whether a pattern like string-concatenated SQL is actually safe. The genuine skill isn't generating code quickly, it's reading generated code critically enough to know whether it's actually correct, which is exactly the skill built across the CRUD, Repository Pattern, and Unit Testing posts already on this blog. GitHub Copilot is genuinely useful for exactly the kind of repetitive, structurally predictable code shown throughout the CRUD and Repository Pattern posts, but its suggestions are a reflection of surrounding patterns, not a judgment about correctness. Inline suggestions, Chat, and agent mode represent increasing levels of autonomy, each requiring a correspondingly different level of review. Comments and naming aren't just documentation anymore, they're the actual mechanism for getting better suggestions. And the core skill this whole blog has been building toward, understanding SOLID principles, writing testable code, knowing what a correct fix actually looks like, is precisely what makes Copilot's output genuinely useful instead of a fast way to introduce a bug you didn't write yourself. Originally published on my blog: TechStack Blog https://www.techstackblog.com/post.html?slug=github-copilot-csharp-guide More from TechStack Blog: C / .NET: https://www.techstackblog.com/category.html?cat=csharp https://www.techstackblog.com/category.html?cat=csharp CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals https://www.techstackblog.com/category.html?cat=cs-fundamentals