Skip to content
Notifications
Clear all

Rolled out Copilot to 100 devs - what broke and what stuck

4 Posts
4 Users
0 Reactions
1 Views
(@devops_rookie_22)
Reputable Member
Joined: 5 months ago
Posts: 167
Topic starter   [#22126]

Hey everyone, my org just finished rolling out GitHub Copilot to all our devs (around 100 people). I'm coming from a Linux sysadmin background, so watching this rollout was fascinating from an infra and process angle.

We saw some immediate friction. Our internal, older APIs aren't well-documented in the codebase, so Copilot kept suggesting wrong or outdated methods. It also really struggled with our custom Helm chart structures. On the plus side, it stuck perfectly for boilerplate stuff—Dockerfile stages, basic Kubernetes manifests, and even some Terraform modules for AWS. My team loved it for writing Ansible playbooks.

For those who've been through this, what were the biggest pain points in your stack? And more importantly, how did you adapt your onboarding or documentation to make the AI suggestions more useful? Trying to help our platform team smooth this out.



   
Quote
(@charlotte4)
Trusted Member
Joined: 2 weeks ago
Posts: 37
 

Interesting to hear about your experience with undocumented APIs. We had a similar issue with our internal Python packages. Copilot kept suggesting deprecated functions.

What helped us was adding small, targeted docstrings to the most used internal functions. Just a one-line description of what it does now. The platform team also created a short "common pitfalls" guide for our stack.

Did you track how often devs accepted the suggestions for boilerplate versus custom code? I'd be curious if acceptance rates were a good signal for where documentation was needed.



   
ReplyQuote
(@henryf)
Estimable Member
Joined: 2 weeks ago
Posts: 92
 

Our rollout had the exact same friction with custom Helm charts. It kept hallucinating non-existent values.

We found two things that worked:
- Created snippet libraries for the problematic patterns (like our ingress template) and pointed Copilot to those files first.
- For the older APIs, we didn't have time for full docstrings. Instead, we added a simple // DEPRECATED: use package/v2/whatever comment above the old function declarations. That stopped most of the bad suggestions cold.

Your point about boilerplate is spot on. That's where it's actually reliable. We now explicitly tell new hires: use it for Docker, K8s, and Terraform boilerplate. Ignore it for our internal service layer until you know the ropes.



   
ReplyQuote
(@ci_cd_mechanic_7)
Estimable Member
Joined: 3 months ago
Posts: 137
 

The snippet library approach is solid. We did that with our custom Jenkins pipelines. Copilot kept suggesting wrong agent labels until we seeded it with a few real examples from our repo.

But that DEPRECATED comment trick is dangerous. If your IDE's linter doesn't flag it, a human might still copy the old function by accident. Better to actually remove export or add a runtime warning.

Our rule is stricter: boilerplate only, full stop. No suggestions for internal business logic at all. Cuts down the noise.



   
ReplyQuote