GitHub Copilot Six Months In: An Honest Review

It's been about six months since we got access to GitHub Copilot in the technical preview. Long enough to form real opinions instead of initial reactions. Long enough to see patterns in how people use it, where it genuinely helps, and where it just sits there generating code nobody wants.

I want to give you my actual take, not the hype version and not the cynical "AI is all garbage" version.

What Actually Works

Boilerplate. That's the thing Copilot is genuinely good at. TypeScript interfaces based on a JSON example. Express route handlers. Redux action creators. Database migrations. All the stuff that follows a pattern. You start writing it, Copilot suggests the rest, you accept it or tweak it, and you move on.

I watched a junior developer write four Redux slices in two hours yesterday. Without Copilot, that's probably a full day's work. It's not just fast—it's mind-numbing work made slightly less mind-numbing. That matters for developer happiness even if the net time saved is just two to three hours per week per person.

The acceptance rate on suggestions varies wildly by context. For API endpoints, I'd guess we accept maybe 60-70% of suggestions with minimal changes. For business logic, it drops to maybe 20-30%. For tests, it's higher than logic but lower than boilerplate, maybe 40-50%.

The quality when it works is legitimately good. It generates code that matches the style of the codebase. It makes reasonable assumptions about what you probably want next. It gets variable naming right more often than I would have expected.

Where It Falls Apart

The version of Copilot we've been using will generate plausible-looking code that is completely wrong in subtle ways. Not obviously wrong—plausible wrong. A function that looks like it does the right thing but misses an edge case. Logic that's almost correct but has an off-by-one error. The kind of subtle bugs that are easy to introduce and hard to catch in review if you're not being careful.

This isn't a dealbreaker—that's what code review is for. But it does mean you can't just accept suggestions blindly. You have to actually read what it's suggesting. That overhead is real. Sometimes it's faster than writing it yourself. Sometimes it just creates more work for review.

The second failure mode is hallucination. Copilot will suggest code that calls methods or APIs that don't exist. It'll suggest library imports for libraries you're not even using. It'll reference variables that aren't in scope. None of this breaks anything on the fly—the code won't run until you try to run it. But it's weird. It makes the developer doubt what they're looking at.

After a few months, you get calibrated to this. You skim suggestions for hallucinations before accepting them. But that takes experience with the tool.

The Honest Productivity Impact

I think the net effect for us has been about 10-15% faster feature delivery. Not for all features. For feature classes that are heavy on boilerplate and light on novel logic. If you're building something completely new and complex, Copilot doesn't help much. If you're building something that's mostly pattern-following, it helps a lot.

That's not nothing. 10-15% is worth paying for. But it's also not the 40-50% productivity increase some people are claiming. Those claims are either based on toy examples or measuring the wrong thing.

What I think is actually happening is that Copilot is giving you fast feedback. Instead of wondering "how do I structure this component class," Copilot shows you an option immediately. You accept it or reject it or modify it. That fast iteration loop might feel like acceleration even if the net time isn't that different.

What Changes If This Goes Mainstream

I think the most interesting effect is going to be on code consistency. Right now, across a codebase, you have lots of individual stylistic choices. If everyone's using Copilot trained on your codebase, all new code will be in that style. That's not bad. In fact, it's probably good for readability. But it also might lead to a lot of code that looks the same even when it should be different.

I've also noticed that having code suggested to you changes your thinking about what's possible. You see a Copilot suggestion that does something clever with a library you use regularly, and you think "oh, I could use that feature in three other places." It's like the tool makes certain capabilities visible that were technically available but not salient before.

The scary version of this is teams stop thinking because the suggestions are good enough. The tool enables lazy thinking. I see hints of this already with some developers getting the suggestion and accepting it without understanding what it does. That's not sustainable.

The Real Impact

After six months, here's what I actually think:

One, Copilot is genuinely useful for boilerplate. That's not a small thing but it's not revolutionary either. We were going to generate that boilerplate somehow. This just makes it faster.

Two, it shifts when you think about code. Instead of writing it and thinking about it, you see a suggestion and react to it. That's different and it has effects we don't fully understand yet. Some good, some potentially bad.

Three, it requires discipline. You can't adopt this and abandon code review or stop thinking about what you're shipping. The tool generates plausible code that sometimes has bugs. That's a feature not a limitation, as long as you're treating it as a suggestion generator, not an oracle.

I'm convinced that AI-assisted coding is real and it's going to become standard across the industry. I'm less convinced that it's the productivity revolution everyone's hyping. It's a tool that makes certain workflows faster. The teams that use it well will be more productive. The teams that use it as a substitute for thinking will ship worse code.

The difference, as with most tools, comes down to how disciplined you are about actually using it well.