Just started using the Amazon Q Developer trial for my project. Was getting annoyed because its code suggestions didn't match my team's style (like bracket placement, naming conventions). Felt like I was reformatting everything.
Then I found this obscure mention in the docs about custom guidelines. You can literally feed it a markdown file with your own rules. I pasted in our simple style guide, and the next suggestions were way more on point. It's not perfect, but it cut my editing time in half. Has anyone else tried this? Curious if it works for other things, like API design patterns.
Free tier is my favorite tier.
Feeding it a style guide is a decent start, but you're trusting it with your codebase patterns. What's your threat model for that markdown file? Does your guide get uploaded to AWS? Is it stored, processed, or used to train other models? Check the data handling terms.
I'd prioritize using it for security linting rules, not just brackets.
Least privilege is not a suggestion.
That's actually super useful, I'd never have thought to look for that feature. I was just accepting the suggestions and then reformatting, which defeats the point. Where did you find it in the docs?
> It's not perfect, but it cut my editing time in half.
That's still a huge win. Have you tried feeding it rules for something like test fixture patterns or specific logging formats yet? Wondering how far you can push it.
PipelinePadawan
I've used this for Terraform module conventions and API Gateway OpenAPI patterns. It works, but you're fighting the model's default training data, so you need extremely explicit rules. Vague guidelines like "use descriptive names" are useless.
For example, I fed it our service mesh ingress rules: "All external traffic must route through the istio-ingressgateway; internal service-to-service calls use mTLS." It then correctly suggested VirtualService configurations with the right gateways and port mappings, which was a noticeable improvement over its generic Istio outputs.
The real limitation is that it doesn't understand the "why" behind your style. If your guide says "never use public S3 buckets," it might avoid `PublicRead` ACLs but miss the equivalent `BucketPolicy` statement that does the same thing. You're still the final reviewer.
Boring is beautiful
You've hit on the crucial limitation with the S3 bucket example. It's optimizing for pattern matching, not intent. This is why I only feed it highly mechanical, syntactic rules.
For cloud cost, I've had some success with rules like "Always specify `gp3` not `gp2` for new EBS volumes" or "For Lambda suggestions, include a `MemorySize` of 1024 as a starting point." It prevents the initial suggestion from using a more expensive default.
But for something like "prefer Spot Instances," it's useless unless I'm writing the specific ASG definition and can constrain the rule to that exact context. It can't reason about the cost/availability trade-off.
CloudCostHawk
Good luck finding a straight answer in the data handling terms. They're designed to obscure.
Even if it's not used for training, it's stored somewhere. That means it's a potential leak vector for your entire internal style and security rules. Feeding it security linting rules just gives an attacker a better map.
If it ain't broke, don't 'upgrade' it.