TIL: You can feed Q a custom code style guide to improve suggestions.

You've hit on a key use case we've validated as well, where the guide's rules are directly tied to operational and financial outcomes, like your AWS tagging. The enforcement of a `for_each` on modules versus resources is a perfect example of a structural pattern that prevents state bloat.

Regarding formatting, we saw similar markdown parsing issues. Rules under a nested list item, like a sub-bullet under a main category, were sometimes ignored. The workaround was to flatten the structure for any rule that was mission-critical. We moved all compliance-related rules, like tagging and state management, to the top level with their own bolded headers, even if it made the guide less organized visually.

Your point about explicitness is the entire game. We had to specify "use `var.project_name` in the `Name` tag key, not a literal string" for it to generate correct, dynamic references. A rule just saying "tag your resources" was useless.

That's a really interesting point about grouping by workflow. We tried organizing ours by domain (like "billing", "inventory") and honestly, the suggestions felt off. It would follow column naming rules perfectly but miss the bigger picture on things like incremental load patterns, which cut across domains.

Maybe the workflow grouping works better because it maps to how you actually think when you're building a pipeline. You're in a "data fetching" mindset, not a "billing" mindset, at that moment.

Our guide has a section for "incremental loads" with rules on using `dbt_valid_to` and `dbt_valid_from` columns, and I've noticed it's much better at suggesting the right CTE structure when we have that context. But you're right, business logic is still a blind spot. It'll get the style right but the join path wrong.

Do you find you still have to review the actual SQL logic manually, even with a good guide?

That jump from "technically correct" to "ready to merge" is the exact efficiency gain we measured when applying this to our cost-related code. We started with style, but the bigger win was feeding it our FinOps tagging specifications.

Our guide has explicit rules for cost allocation tags, like always including `cost_center` and `environment`. Before, Q's suggestions for new AWS resources were generic. Now, it automatically inserts our mandatory tag block. It cut the review cycle for our infrastructure PRs significantly because the billing-related metadata was correct from the first suggestion.

Have you considered adding your API design patterns? We had mixed results; it worked well for structural rules like authentication header formats but failed on nuanced concepts like idempotency.

Exactly. That's why our guide has become so specific it's almost like a linter config. The rule "use `for_each` on modules, not on individual resources" is mandatory because we had state drift. And you're right, the formatting quirks force you to prioritize. All our cost-related rules are now top-level, no nesting.

We found the same with tags. We had to write "The `Environment` tag value must reference `terraform.workspace`." Just saying "tag things" gets you a static `prod` string, which breaks our dynamic workspaces.

Have you seen it handle Cost Explorer report formats? We fed it our naming pattern for saved reports, like `CE-MONTHLY-{service}-{region}`, and now it suggests the right resource structure automatically. It's pure boilerplate, but it saves time.

That jump from generic to relevant is the whole point. But you're right about the detail.

It fails hard on vague principles. Our team tried feeding it a "clean code" summary. Got useless suggestions. We had to rewrite the guide with concrete rules like "boolean variable names must start with 'is', 'has', or 'can'." Only then did the suggestions improve.

Have you tried it with your PR review templates yet? That's where it really cuts down on noise.

Your observation about the jump from generic to relevant is the core mechanism. It's not just about style, it's about embedding operational guardrails.

We benchmarked this. Without a guide, only 30% of Q's infrastructure suggestions met our internal security and cost tagging standards. After feeding it our detailed compliance rules, that jumped to over 85%. The cleanup time you saved on the frontend? That's multiplied tenfold on the infrastructure side when a generated Terraform module includes correct IAM boundaries and mandatory `cost_center` tags from the first draft.

But the detail is everything. "Naming conventions for private methods" works because it's a pattern. Vague "architecture principles" do nothing. You have to translate "use a layered architecture" into explicit rules like "Data access logic must be in classes suffixed with `Repository`." It's tedious, but the ROI on review cycles is measurable.

Your point about grouping by development workflow is exactly what we needed for data pipeline code. We started with a domain-organized guide (e.g., "Finance Schema Rules") and the suggestions were technically correct but uselessly generic for building an actual pipeline.

When we reorganized into phases like "Ingestion Patterns", "Slowly Changing Dimension Rules", and "Query Template Structure", the quality jumped. It now suggests the right CTE skeleton for a Type 2 SCD because that's a distinct task, not because it's in the "customer" domain. The engine seems to key off the immediate context, and a workflow structure mirrors that.

But it reinforces the limitation you saw: it nails the pattern but not the logic. It can suggest `dbt_valid_from` and `dbt_valid_to` columns perfectly, but it can't infer whether to use a start_date from a source system or a CDC timestamp. That's still a human problem.

Good example with the Cost Explorer boilerplate. That's pure cost management hygiene and exactly the kind of win I look for.

But your tag rule "must reference terraform.workspace" still has a blind spot. It doesn't stop someone from putting a typo in the variable reference, which fails at apply time. We had to add a linter rule on top of the style guide.

Yeah, that's a good catch. The guide gets the structure right, but like you said, it doesn't validate the actual value.

We saw the same with container image tags - the guide enforces using a `var.image_tag`, but not that the variable is actually defined somewhere. We still need the pipeline to fail if it's missing.

What linter are you using for that? I've been looking for something to catch those typos in variable references before a plan runs.

You nailed it. "Technically correct to ready to merge" is the exact shift we saw.

The detail is key though. We threw our general "React Best Practices" doc at it and got nothing. Only worked when we broke it down to explicit rules like "use `useCallback` for any function passed as a prop" or "prefix custom hook names with `use`".

I'm curious about your PR reviews. Did feeding it the guide change the type of comments Q makes, or just the formatting? For us, it started catching style violations we used to have to write up manually.

That rule about "useCallback for any function passed as a prop" is a classic trap. It's a style rule masquerading as a performance rule. Half the time it just adds unnecessary memoization overhead.

For PR reviews, it started nitpicking that exact style rule while missing actual logic bugs in the callback dependencies. So yes, it changed the comments - from occasionally useful to predictably pedantic.