Your observation about boilerplate sticking is spot on. The pattern we noticed was that Copilot excels where there's a clear, repeatable structure defined outside your code, like Docker's `FROM...RUN...` pattern or Terraform's `resource "aws_..." "name" {}`. It's essentially regurgitating its training data, which is heavy on public conventions.
Where it falls apart is your internal convention, like those custom Helm charts. The fix isn't just documentation for humans, it's creating those repeatable patterns *for the machine*. We mandated that any new service's `Chart.yaml` and a `templates/_common_labels.tpl` must be generated from a specific, commented template in our repo. Once that template file is open in the editor's context, suggestion accuracy skyrockets because Copilot latches onto the immediate context more than your entire messy `charts/` directory.
On the latency question from later in the thread, we saw a few spikes, but the bigger issue was IDE plugin stability with our corporate proxy. The network team had to whitelist a very specific set of CDN endpoints, not just `*.github.com`.
Measure twice, cut once.
Absolutely nailed it with the immediate context point. We saw the same thing with our internal Kubernetes operators. Having a well-documented, living example in a nearby open tab made suggestions way more useful than any general doc.
The proxy issue was a real blocker for us too. We had to get specific about the websocket endpoints. Did your network team find GitHub's documentation on the required endpoints helpful, or was it mostly trial and error? Ours had to open a ticket with Microsoft to get a definitive list, which added a surprising amount of delay to the rollout.
Show me the accuracy numbers.
Right? The proxy/websocket thing was a huge headache. Our network team actually found the official docs were missing a couple of critical CIDR blocks for the service mesh we use. It ended up being a mix of their docs and good old-fashioned packet capture to see what was still getting blocked.
The delay sounds familiar. We lost almost two weeks in that middle ground between "it should work" and actually having all the traffic flow. Did you guys end up putting the definitive list into your internal IT wiki, or is it still floating around in a Slack thread somewhere?
The proxy firewall dance was the real time-sink for us, not the code patterns. You can train a dev to ignore a bad suggestion, but you can't work at all if the plugin can't phone home. Our networking team spent days whack-a-moling blocked endpoints, and it turns out the documented IP ranges weren't enough - we had to allow specific WebSocket upgrade patterns at the proxy level, not just static hosts.
On the custom Helm charts, the template-in-an-open-tab trick works, but only for greenfield services. For our existing 50+ charts, the real fix was boring: we had to bite the bullet and refactor three of the most egregious ones into a proper library chart. Once we had that single source of truth, Copilot's suggestions for the dependent charts got about 80% better because it was pulling from a consistent pattern.
Your Ansible win is telling - it works because Ansible modules have a predictable, documented structure. Your internal APIs don't. No AI tool fixes that; it just exposes the debt faster.
Your Linux background gives you the perfect lens to see this. You're spot on about the split between public conventions and internal ones. That's the core adaptation.
For onboarding, we stopped telling devs "how to use Copilot" and started giving them "how to feed Copilot." The single biggest win was a short guide on context management.
* Keep your team's library chart or example API call open in a second tab.
* For legacy code, create a `_patterns.md` file in the repo root with three correct examples of the tricky thing. Just having that file in the project helps.
The boilerplate success actually became the training tool. We had devs use Copilot to generate a simple Dockerfile first, so they could see it work correctly, and then apply that same context principle to a Helm chart.
Did you face any pushback on that sort of procedural change, or did the immediate utility for things like Ansible playbooks win people over?
You're noticing the pattern everyone hits. Copilot works where public convention exists and fails where your internal one does. That's not a tool problem, it's a documentation problem you've just automated.
The onboarding advice you're getting about keeping example tabs open is treating the symptom. The real fix is that if your internal APIs are so poorly documented that a pattern matcher fails, your new hires were already struggling. Use this as the forcing function to actually deprecate the old methods properly, or at least get a real spec written. Otherwise you're just adding a layer of confusion on top of the existing mess.
And let's be honest about the boilerplate success. If your devs love it for Ansible playbooks, that's because they're typing the same YAML everyone else does. The moment you need a custom module, it falls apart. The trick isn't feeding Copilot, it's deciding what you're willing to standardize versus where you need actual human thought.
Anecdotes aren't data.