I should be honest about where I started: skeptical. Not dismissively skeptical, but the kind of skeptical that comes from watching a lot of tools get adopted as productivity multipliers and then quietly fade into the background of everyone's workflow without changing much.
I had used Copilot in passing. Accepted a completion here and there, ignored it most of the time. That is not a fair evaluation of anything. So I decided to give it a proper run: six weeks, every day, across the actual infrastructure work I do. Terraform, Python scripts, Helm charts, Bash, the occasional bit of Go.
This is what I found.
The first week is misleading in both directions
The first few days felt impressive in a way that is hard to separate from novelty. Copilot was completing things before I finished typing them. It knew common Terraform patterns. It suggested the boto3 call I was about to write before I had typed the function name.
But I also caught myself accepting completions that were subtly wrong. Not catastrophically wrong. The kind of wrong that would have passed a cursory review and caused a confusing bug later. A Terraform resource block that used a deprecated argument. A Python function that handled the happy path correctly but silently swallowed exceptions in a way I would never have written myself.
The lesson from week one: Copilot is not a replacement for knowing what correct looks like. It is a tool that generates plausible code fast, and plausible is not the same as correct. Once I internalised that distinction and started reading completions the way I would read a junior engineer's PR, the tool became significantly more useful.
Where it genuinely saves time
After six weeks, the honest answer is: boilerplate and pattern repetition.
Writing the fifteenth Kubernetes deployment YAML in a project follows a pattern. Writing an argument parser for a Python script follows a pattern. Writing health check endpoints follows a pattern. For all of these, Copilot is fast and usually right. It knows the shape of what I am trying to do and produces something structurally correct that I then verify and adjust.
The specific things where I noticed meaningful time savings:
Config file generation. Fluent Bit configs, Prometheus alerting rules, nginx configs. These have well-established patterns and the completions are reliable. Not always right, but close enough that editing is faster than writing from scratch.
Writing tests for existing functions. This surprised me. Copilot is quite good at generating a reasonable test structure for a function it can see. The tests are not always comprehensive, but they are a solid starting point that I expand from. Previously I would procrastinate on tests. Now I generate a skeleton and fill it in.
Documentation comments. I started letting Copilot write the first draft of docstrings and README sections. I edit them, but it gets the structure right and I do not have to start from a blank page.
Regex and string manipulation. I am not a person who enjoys writing regex. Copilot is considerably better at it than I am at first attempt, and I can verify the result without writing it.
What it does not help with
The work that requires understanding context Copilot cannot see.
Architecture decisions. When I am deciding whether a piece of infrastructure should be a separate service or a shared library, or whether a particular Kubernetes operator is the right choice for a use case, Copilot has nothing useful to offer. These decisions require understanding the organisation, the team's operational capacity, the existing systems, the compliance requirements. That context does not fit in a context window.
Security-sensitive code. I am more cautious with Copilot on anything touching authentication, secrets handling, or network policy. Not because Copilot is uniquely bad at these, but because the cost of a subtle error is higher and I want to be deliberate rather than fast.
Novel problems. When I am doing something genuinely new, something without a clear pattern Copilot could have learned from, it is not helpful and sometimes actively misleading. It generates something that looks like the thing I want but is not, and I waste time understanding why it does not work before discarding it.
The PR review integration
This is where my opinion got more complicated.
GitHub has rolled out Copilot review suggestions in pull requests. The model reads your diff and leaves comments. I had it enabled for about four weeks across pull requests I was either authoring or reviewing.
The comments fall into a few categories.
Useful catches: Copilot flagged a missing null check in a Python function that I had genuinely missed. It caught a Terraform resource that was not tagging a resource it should have been. These are legitimate finds. Not things a careful human reviewer would miss, but things that get through in a fast review.
Correct but obvious: A significant fraction of the comments were things like noting that an error is not being handled in a place where the calling code handles it perfectly adequately a level up. Technically accurate observations that demonstrate the model does not have enough context to know they are not actionable.
Wrong: Some comments were simply incorrect. Suggestions based on a misreading of what the code was doing. These required a response to explain why the suggestion did not apply, which costs time.
The overall effect on my PRs: slightly useful as a first-pass check before human review. Not useful as a replacement for human review. The signal-to-noise ratio on the automated comments was around 60/40 useful to not useful, which is not high enough to trust without reading everything.
One thing I did find valuable: using Copilot Chat to ask questions about my own diff before submitting. "What edge cases does this function not handle?" produces a useful checklist I can quickly verify. That is a better use of the tool than reading its automated comments after the fact.
Six weeks later
I still use it. That is probably the most honest summary.
My workflow has adapted. I use completions freely for boilerplate and read them carefully for anything with real logic. I use Copilot Chat for a handful of specific tasks: explaining unfamiliar code, generating test skeletons, writing documentation. I do not use the PR review automation as a gating step.
The productivity question is genuinely hard to answer. I write certain things faster. I also spend time reading completions I do not accept. Net, I think it is positive, but modestly so. The people who claim it doubles their productivity are either doing different work than I am or measuring differently than I would.
What has changed more than my speed is my approach to certain tedious tasks. Tests, documentation, boilerplate. I no longer avoid these in the way I used to because the activation energy is lower. Whether that is the tool or just a mindset shift from committing to the experiment, I genuinely cannot separate.
If you work in infrastructure and have been on the fence: try it properly for a month. Not the occasional accepted completion. Actually use it, read its output critically, and form your own view. The honest answer is probably that it is more useful than you expect and less transformative than the marketing suggests.
That is usually where good tools land.
