How I Use GitHub Copilot as a Senior .NET Engineer (Without Letting My Skills Rot)

I was a skeptic. I'd been writing C# for years without autocomplete-on-steroids, and the first time Copilot suggested a whole method, my instinct was distrust — justified, it turned out, because the method had an off-by-one bug. But I've now used AI assistants daily for long enough to have a settled workflow, and the honest summary is: they've made me meaningfully faster in some areas, no faster in others, and they will absolutely erode your skills if you use them passively.

Here's my actual workflow — what I delegate, what I don't, and the discipline that keeps the tool from using me.

The mental model: an eager junior with encyclopedic recall

Copilot is like pair-programming with a junior developer who has memorized all of GitHub: instant recall of syntax and idiom, boundless confidence, zero understanding of your business domain, and no sense of when it's wrong. That framing tells you exactly how to use it — delegate the things you'd delegate to that junior, review everything like it came from that junior, and never let it make architectural decisions.

Where it genuinely earns its keep

Boilerplate with a known shape. DTOs, mapping methods, builder classes for tests, EF Core configurations, controller scaffolding. When I write public record CreateOrderRequest( the completion is nearly always what I'd have typed. This is real time saved on the least interesting 20% of the job.

Test authoring. My highest-value use. Write one good test establishing the pattern — naming convention, builders, AAA structure — and Copilot extrapolates the variations: the null case, the boundary case, the empty-collection case. I routinely get double the edge-case coverage for the same effort, because the marginal cost of the next test dropped. (Review still applies: it will happily generate a test that asserts the bug.)

Unfamiliar API surface. Writing against a library I don't know well — a new Azure SDK, a charting package — the assistant knows idioms I'd otherwise be digging out of docs. Direction-finding, not gospel: APIs drift, and hallucinated methods that should exist are a classic failure.

The "translate this" chores. SQL to LINQ, JSON sample to C# records, a regex explained or authored, converting a snippet between languages. Mechanical transformations with verifiable output — ideal delegation.

Where I've learned to decline

Anything with business rules. The domain knowledge isn't in the training data. Suggested code that touches pricing, permissions, or workflow looks plausible and is wrong in the specific ways that cause incidents. I write domain logic myself and use the assistant for its scaffolding.

Concurrency and security-sensitive code. Plausible-looking async code with subtle races, hand-rolled auth checks, anything cryptographic — the failure modes here are silent and expensive, and pattern-matching from public code is exactly the wrong tool. These deserve full human attention.

Architecture. "How should I structure this service?" is a conversation for humans (or at minimum, a deliberate design session), not an autocomplete. The assistant optimizes for locally-plausible next tokens, not for your system's five-year maintainability.

The review discipline that makes it safe

The core risk of AI-generated code isn't that it's often wrong — it's that it's wrong while looking right, and arrives faster than your skepticism engages. Rules I hold myself to:

  1. Read every accepted suggestion as if reviewing a PR. If I wouldn't approve it from a colleague without understanding it, I don't accept it from the machine. Accepting code you don't understand is taking on debt in a currency you can't see.
  2. Never accept beyond my own comprehension speed. If a 30-line suggestion would take me longer to verify than to write, I write it. Typing was never the bottleneck of software engineering; understanding is — and understanding is not delegable.
  3. Tests for AI-written code are non-negotiable — written or at least fully vetted by me. AI code with AI tests, unreviewed, is a rubber stamp stamping itself.
  4. Watch for the subtle staleness. Suggestions skew toward the average of public code, which is often years behind: WebClient instead of HttpClient, Newtonsoft where System.Text.Json is standard, pre-nullable patterns. Your job is to hold the codebase's standards against the gravitational pull of the average.

Keeping the skills sharp

The uncomfortable question juniors ask me: "will this make me worse?" It can. Skills you don't exercise atrophy — that's not an AI property, it's a brain property. What I actually do about it:

  • Struggle first on new concepts. When learning something (a new language feature, an unfamiliar algorithm), I turn suggestions off or ignore them until I've fought through it once. The struggle is the learning; the assistant is for after you've earned the shortcut.
  • Keep writing the hard parts. Domain modeling, tricky refactors, performance work — I do these by hand not just for quality, but as deliberate practice.
  • Use the assistant as a rubber duck with recall. "Why might this EF query be slow?" produces genuinely useful hypothesis lists. Interrogating it teaches; passively accepting from it doesn't.

The developers who get worse aren't the ones using AI — they're the ones who stopped thinking while using it. The ones who get better use the recovered time on the things that were always scarce: understanding the domain, reviewing deeply, designing well.

The bottom line

Copilot hasn't changed what makes a senior engineer senior: judgment about what to build, how to structure it, and what "correct" means in your domain. It has changed the price of typing, tests, and boilerplate — roughly to zero. Take the discount, keep the judgment, and review like everything came from that brilliant, overconfident junior. Because it did.

Where to go next