Skip to content
My team's experienc...
 
Notifications
Clear all

My team's experience with Copilot for coding - the good and bad

6 Posts
6 Users
0 Reactions
3 Views
(@cloud_ops_learner)
Reputable Member
Joined: 2 months ago
Posts: 143
Topic starter   [#7503]

Hey everyone, new here! My team has been using GitHub Copilot for a few months now, mostly for Terraform and some AWS CLI stuff. I'm still getting the hang of cloud ops myself.

The good part: it's really fast for writing boilerplate Terraform, like a security group rule. Saves a lot of typing. The bad: it sometimes suggests outdated AWS resource names or weird configurations that could be a security risk if we didn't catch them. Also, no idea how it impacts our cloud bill if the code isn't efficient 😅

Has anyone else run into this? Curious about cost or security pitfalls with these AI coding tools.


Still learning


   
Quote
(@charlieg)
Estimable Member
Joined: 1 week ago
Posts: 93
 

Ah, the security risk angle is the one that gets less airtime than the "it writes my loops for me" hype. You've nailed it.

The outdated resource names are annoying but fixable. The subtly insecure configs, like an overly permissive IAM policy it might generate because that pattern exists in some public repo, are the real problem. It's automating the copy-paste of bad practices.

On cost, it's a black box. It doesn't know your billing alarms. It'll happily suggest you provision a db.m7g.24xlarge because the documentation it trained on mentions it, with zero concept of your dev budget. You're still the one on the hook for the bill.


cg


   
ReplyQuote
(@katherineh)
Eminent Member
Joined: 1 week ago
Posts: 30
 

Your point about boilerplate speed versus configuration risk is exactly the dilemma we've seen. It's fantastic for generating the repetitive structure of a security group, but the moment it starts populating `cidr_blocks` with `0.0.0.0/0` or suggesting `ingress` rules from `::/0` on IPv6 without explicit prompting, you've got a problem.

The efficiency question ties directly to the training data. Copilot doesn't know your cost optimization tags or reserved instance commitments. It'll pull examples that use `m5.xlarge` as a generic instance type because that's common in tutorials, even if a `t3.medium` is functionally sufficient for your dev workload. You still need a secondary review layer, like a pre-commit hook that runs `infracost` or similar, to catch those suggestions before they hit your pipeline.

Have you looked into tuning its suggestions with a more curated context window? Feeding it your own internal module definitions can sometimes steer it toward safer, more company-specific patterns.


—KH


   
ReplyQuote
(@kittycat)
Trusted Member
Joined: 1 week ago
Posts: 31
 

Hey, your experience is spot on. The boilerplate speed is real, but the outdated/insecure suggestions are the hidden tax on that efficiency.

I'd add one more nuance on cost: it's not just about suggesting oversized instances. Copilot can also generate patterns that lead to sprawl, like suggesting you create a new standalone Lambda for every minor task instead of reusing a shared function, because that's how a lot of example code is structured. That indirect cost multiplier is harder to catch than a single instance type.

Have you noticed if the insecure suggestions (like the overly open CIDR blocks) come more often when you're writing from a vague comment, versus when you're already typing a more specific line of code? I'm curious if prompting style changes the risk level.


Sample size matters.


   
ReplyQuote
(@darrenk)
Estimable Member
Joined: 1 week ago
Posts: 103
 

Great point about the sprawl, that's a subtle cost that's easy to miss.

On your question, I find it absolutely does change with the prompt. Vague comments like "add a rule to allow access" are a magnet for those `0.0.0.0/0` suggestions. If I start typing something more constrained, like `cidr_blocks = ["10.0.`, it tends to follow that pattern.

It's a good reminder that how you start the line guides the outcome more than you'd think.


dk


   
ReplyQuote
(@chrisg)
Estimable Member
Joined: 1 week ago
Posts: 75
 

Exactly. It's amplifying the bad patterns we've been trying to get rid of for years.

We had it suggest an S3 bucket policy with `"Principal": "*"` because that's still in half the old AWS blog posts. The automation just makes it faster to repeat the mistake.

Your billing point is key. It can't read your company's cost center tags. You need a guardrail like `terraform-compliance` or OPA policies to block those suggestions before they even get to a PR.


YAML all the things.


   
ReplyQuote