Quick take
Copilot is genuinely useful for boilerplate and pattern completion. It’s genuinely dangerous for anything involving business logic, security, or correctness. Net effect: I write first drafts faster and spend more time reviewing. Whether that’s a win depends on the task.
I’ve been using GitHub Copilot daily for about six months now, across Go projects, Terraform modules, and some TypeScript. Enough time for the novelty to wear off and an honest assessment to form.
The short version: it’s good at autocomplete on steroids. It’s bad at thinking. And the gap between those two things is where bugs live.
Where It Actually Helps
Copilot shines on boring, repetitive code that follows well-established patterns. The stuff you know how to write but don’t enjoy writing.
Boilerplate. Struct definitions, HTTP handler scaffolding, test table setup in Go. Copilot generates these faster than I can type them, and the output is usually close enough that a quick edit gets it right. For Go specifically, it handles the if err != nil pattern well, which is both useful and slightly depressing.
API recall. I don’t have every AWS SDK method memorized. Copilot often suggests the right function signature, saving me a trip to the docs. Not always correct, but correct enough to jog my memory.
Glue code. Converting between types, building request objects, wiring dependencies. The code that connects the interesting parts together. Copilot handles this well because it’s highly contextual to the current file and follows obvious patterns.
Comments to code. Writing a clear function signature or a descriptive comment and letting Copilot fill in the implementation works surprisingly well for straightforward functions. The key word is “straightforward.”
Where It Quietly Makes Things Worse
The problems aren’t obvious. That’s what makes them dangerous. Copilot doesn’t crash or throw errors. It produces plausible-looking code that passes a casual review. The failure mode is subtle wrongness.
Business logic. Copilot has no idea what your business rules are. It will happily generate a discount calculation that looks reasonable but uses the wrong formula because the actual logic lives in a requirements doc it has never seen. I caught one of these in a PR review – the code looked fine, compiled fine, and would have silently applied the wrong pricing.
Error handling. In Go, Copilot handles the mechanical if err != nil return pattern, but it’s bad at deciding what to do with errors. Should you retry? Log and continue? Wrap with context and propagate? Copilot picks whatever pattern it has seen most often, which is usually “return err” without any context wrapping. For a language that relies on error handling discipline, that’s a real problem.
Security. This is where I draw a hard line. I don’t use Copilot for authentication flows, permission checks, input validation, or anything involving cryptography. The cost of a plausible-but-wrong suggestion in these areas is too high. With my NATO cyber defense background, I’m probably more paranoid about this than most, but I’ve seen what “looks correct” security code can cost an organization.
Naming and consistency. Copilot doesn’t know your codebase’s naming conventions. It will suggest getUserData in a codebase that uses fetchUserInfo. Small inconsistencies compound into a codebase that feels like it was written by a dozen different people. Which, with Copilot, it effectively was.
The Review Problem
Here is what nobody talks about in the productivity benchmarks: Copilot shifts work from writing to reviewing.
I draft faster. But I also spend more time reading and verifying what was generated. For simple boilerplate, the net is positive. For anything with logic, the net is roughly break-even. For complex systems work, it can be negative because I’ve to review generated code that I would have written differently and more carefully from scratch.
Code review at the team level changes too. Reviewers can’t assume the author understands every line, because some lines were generated and accepted quickly. The review burden increases, and the conversations become more about “did you actually verify this?” than “is the style correct?”
That shift is healthy in one way – we should be reviewing logic and risk, not formatting. But it only works if teams explicitly acknowledge the change and adjust expectations.
My Workflow
After six months, I’ve settled into a pattern:
- Write a clear function signature with good names and types. Copilot uses these as context, so better inputs produce better outputs.
- Accept small suggestions, one or two lines at a time. Reject multi-line completions that I would need to audit carefully.
- Edit aggressively for naming, error handling, and edge cases. Copilot gets the shape right and the details wrong.
- Run tests immediately. If there are no tests for the code I just generated, write them before moving on. This is non-negotiable.
I explicitly don’t use Copilot for: auth code, permission checks, crypto, complex algorithms, or any code where I can’t immediately verify correctness by reading it.
For Teams Considering Adoption
Treat Copilot as a new team member who’s fast, eager, and doesn’t understand your domain. You wouldn’t merge their PRs without review. Same rules apply.
Set explicit boundaries about where it should and shouldn’t be used. Security-sensitive code is the obvious no-go. But also consider: do you want AI-generated code in your core domain logic? The answer might be yes for a CRUD API and no for a payment processing engine.
Keep your quality bar unchanged. “Copilot wrote it” isn’t an excuse for a bug. The person who accepted the suggestion owns the code.
Where This Is Going
Copilot is the starting point, not the ceiling. Broader project context, better refactoring support, and multi-file awareness are coming. But the fundamental challenge will remain: these tools generate code that looks right. Knowing whether it is right still requires a human who understands the problem.
The engineers who will benefit most are the ones who already have strong fundamentals – system design, testing discipline, domain knowledge. Copilot amplifies competence. It also amplifies carelessness. Which one you get depends on how you use it.