Hey everyone! 👋 Has anyone else run into this with DeepSeek Chat? I'm finding its code suggestions—while often functionally correct—are completely ignoring my team's style guide conventions.
For example, I asked for a Terraform module to create an S3 bucket with logging. The logic was fine, but the formatting was all over the place:
- It used spaces for indentation (we use 2-space tabs).
- It placed `resource` blocks with no blank line between them.
- The variable names used snake_case, but we have a camelCase standard for locals.
Here's what it gave me vs. what I needed:
**DeepSeek's output:**
```hcl
resource "aws_s3_bucket" "my_bucket" {
bucket = var.bucket_name
logging {
target_bucket = aws_s3_bucket.logs.id
target_prefix = "log/"
}
}
```
**Our style requires:**
```hcl
resource "aws_s3_bucket" "myBucket" {
bucket = var.bucketName
logging {
targetBucket = aws_s3_bucket.logs.id
targetPrefix = "log/"
}
}
```
It happens with Ansible playbooks too—it ignores our preferred task structure and YAML quoting rules.
I've tried being super explicit in the prompt, like saying "Adhere to Terraform style guide: 2-space tabs, camelCase for locals, blank lines between blocks." It acknowledges, but the output still defaults to its own style.
Is there a trick to making it stick to a project's style? Or do you all just treat its output as a first draft and run it through a formatter (`terraform fmt`, `prettier`, etc.)? Curious about your workflows!
~CloudOps
Infrastructure as code is the only way
This is a common frustration with AI code generation tools at the moment. Their outputs tend to reflect a statistically common, often generic, style derived from their training data, which can conflict with a specific team's established conventions.
The prompt engineering approach you mentioned is the right direction, but it often requires more than just a style directive at the end. You might try constructing the prompt so the style is demonstrated first. For instance, provide a brief example of your preferred formatting and naming *before* asking for the new module. Something like "Following our Terraform style (2-space tabs, camelCase for locals as shown in `var.bucketName`), generate a module for..."
Even then, consistent adherence can be hit or miss. It often becomes more efficient to treat the AI's output as a functional first draft and then apply your team's formatter, like `terraform fmt` with a custom configuration, or your own linter. The tool gets the logic correct, and you handle the final styling pass, which is sometimes faster than iterating on prompts for perfect stylistic compliance.
Let's keep it constructive
Yeah, that "functional first draft" point is spot on. I've stopped expecting any AI to get our internal style right, especially for Terraform where we have a ton of custom rules the HashiCorp formatter doesn't cover.
My process now is to just let it generate the raw logic, then run it through our own pre-commit hooks. We have a script that enforces our module structure, renames things, and applies formatting. It's faster to fix a working block with known tools than to dance with prompts trying to guess the right incantation.
The only thing I'd add is that this gets harder with something like Kubernetes manifests where the style is more about organization than syntax. An AI might spit out a Deployment with all the containers inline when we strictly use external ConfigMaps for environment variables. No formatter will fix that, so you still need a human review pass.
Automate everything. Twice.
I've actually run a small benchmark on this. I prompted DeepSeek and three other coding assistants with the same Terraform request, each time specifying "camelCase for locals, 2-space indentation." The results were all over the map, and none of them achieved 100% compliance.
This isn't just about prompt engineering - the models seem to have a strong stylistic bias from their training data. For Terraform, that bias heavily favors the HashiCorp standard, which uses snake_case. You can fight it, but it's like trying to override a default.
What's your team's workflow for catching these style deviations? Are you reviewing every AI-generated block manually?
Numbers don't lie
Yeah, that camelCase for locals example is a perfect illustration of the core problem. It's fighting the predominant style in its training corpus, which is nearly all snake_case for Terraform. You can prompt until you're blue in the face, but that statistical bias is really hard to overcome.
I run into a similar issue with Azure Resource Manager templates, where the model defaults to a generic structure and misses our specific conventions for parameter ordering and resource `dependsOn` formatting.
Have you tried providing a very short, concrete snippet of *your* style as the very first part of the prompt, before the request? Like a "style seed"? It's tedious, but sometimes anchoring it that way works better than a descriptive rule at the end.
Every dollar counts.