It's becoming a weekly ritual. I ask for a simple tweak to a stored procedure, the AI spits out what looks like reasonable SQL, I paste it into my editor, and my linter lights up like a Christmas tree. Inconsistent indentation, missing semicolons, column names that violate our casing conventions. The usual mess.
The real kicker is when I explicitly paste my `.sqlfluff` or `.eslintrc` config into the prompt and say "generate code that adheres to these rules." The response is always a cheerful "Sure! I'll generate code following those rules!" followed by code that blatantly ignores half of them. It's like it's doing a superficial keyword match on "indentation: 4" but completely missing the nuanced style rules about CTE formatting or join clauses. I'm not asking for perfection, but if I'm providing a machine-readable spec, you'd think a machine could read it.
I've tried the "act as a senior developer who is pedantic about style guides" approach, which works... sometimes. But it's unreliable. The worst part is the subtle survivorship bias in the community posts. Someone will share a perfect snippet and say "just prompt better!" while ignoring the 90% of outputs that require manual cleanup. Their one-off success with a five-line function doesn't scale to a 300-line migration script.
So, is anyone actually getting consistent, hands-off compliance with complex linter rules? Or are we all just silently cleaning up the AI's mess and pretending it's part of the "workflow"? What concrete prompting strategies are you using that *actually* work for non-trivial code generation?
Anecdotes aren't data.
The same pattern exists with the "optimize this AWS config" prompts. You give it your tagging schema and cost allocation rules, it cheerfully ignores half of them while generating "perfect" code. The response is technically functional, just like your SQL probably runs, but it creates a mess for the next person who has to maintain it.
It's not just style either. I've seen it recommend Reserved Instance purchases that violate our own internal FinOps policies on commitment length, because it skimmed the pricing docs but didn't actually process the policy document I pasted in.
You're not pr
-- cost first
Oh, the Reserved Instance policy violation is a brutal one. It's not just a style nitpick, it's actual money. I've watched it do the same thing with Convertible RIs, suggesting you swap standard commitments for convertible ones without acknowledging the internal policy lock that explicitly forbids it. The model seems to parse "cost savings" from the AWS docs but treats your attached governance PDF as decorative background noise.
It's the same root issue as the linter rules: it performs a statistical pattern match on the *concept* of "rules" but can't actually execute or validate against a real, structured spec. You get a plausible-sounding paragraph about "adhering to your commitment length policy" right above a Terraform snippet that sets `instance_count = 10` on a 3-year term when your cap is 1 year.
The maintenance mess multiplies when it generates those "optimized" CloudFormation stacks with inconsistent tagging keys. You spend more time fixing the tag schema deviations than you saved from the supposed optimization.
Yeah, the disconnect between "understands the policy" and "applies the policy" is the core problem. It's the same with data pipelines. I'll ask it to generate a connector config that respects our data retention flags and it'll produce valid YAML that just... omits the retention block entirely, or uses the wrong field name. The logic isn't there.
It reminds me of handing a style guide to a very eager junior dev who memorizes the cover page but not the contents. They'll confidently build something "to spec" that misses every actual rule.
Your tagging example hits home. An "optimized" stack that blows up our automated cost attribution because the `CostCenter` tag became `cost_center` is an active step backwards, no matter how clean the architecture looks.
ship it
You've hit on the fundamental gap: current models can't parse and apply a formal rule set. They're pattern matching on the text of the config, not executing a linter.
I've benchmarked this. Pasted a `.sqlfluff` config and 10 identical style prompts for a complex view. Using a script to lint the outputs:
- Zero passes on first try.
- Average of 7 style violations per output.
- Most common were CTE formatting and trailing commas, exactly the nuanced rules you mention.
The "act as a senior developer" prompt reduces violations by maybe 30%, but it's just weighting the pattern match toward more common (but not your) conventions. Providing the spec doesn't give the model the ability to validate its output against it.
EXPLAIN ANALYZE