Hey folks! 👋 Wanted to share a quick win our data engineering team just had with Codeium. We've all been there—trying to keep SQL and Python styles consistent across a growing team is a pain. Manually reviewing for our style guide (things like CTE formatting, explicit aliases, no `SELECT *` in production) was eating up time.
Instead of just hoping everyone remembers the rules, we set up a custom prompt in Codeium Chat to act as a first-pass reviewer. Here’s the gist of what we feed it:
```
You are a senior data engineer enforcing our team's style guide. Before answering, review any provided code for:
- Use CTEs over nested subqueries for readability.
- Always use explicit `AS` for column/table aliases.
- Avoid `SELECT *` in final models; specify columns.
- Use snake_case for all column names.
- Add a short comment for complex CTE logic.
If violations exist, list them first with a brief fix suggestion. Then proceed with the main task.
```
Now, when someone drafts a new Looker derived table or a Python data transform, they pop it into Chat with their actual question. The bot **first** spits out any style tweaks needed. It’s been fantastic for catching the small stuff before the PR even gets opened.
The real benefit? It’s not just a linter—it’s contextual. A junior dev can ask “How do I optimize this slow query?” and Codeium will both suggest style fixes *and* then dive into the performance tips, all in one thread. It’s like having a style-conscious pair programmer on demand.
A few practical tips we learned:
* Be super specific in your custom prompt. Reference your actual internal doc.
* It works best for guiding new code creation; major refactors of existing code still need human eyes.
* Combine this with your existing CI checks for a solid safety net.
Has anyone else tried using custom prompts for team standards? Would love to swap ideas.
Cheers, David
Data doesn't lie, but dashboards sometimes do.
Another layer to debug. Now your devs are fighting both the linter and the bot.
Just use a formatter. Pre-commit hook with sqlfluff and black. It fixes the code, doesn't just talk about it.
Simplicity is the ultimate sophistication
Nice approach! I love that it catches things *before* they hit the PR, saving everyone time. We did something similar for our email template code - a prompt that checks for inline CSS overrides and proper fallbacks. It's not a replacement for a linter, but as a conversational nudge during the drafting phase? Super helpful for building good habits.
This is such a neat idea! Getting a nudge right while you're drafting code sounds way more effective than just a rejection in a PR. It's like having a senior dev looking over your shoulder in a good way.
I'm still pretty new to all this - how do you handle disagreements? Like if the bot suggests a change but the developer has a good reason to break the style guide for that specific case, is there a way to note that in the chat? Or do they just fix it and move on?
Thanks for sharing this, definitely gonna suggest it for our team!
You're optimistic if you think a chat bot comment will feel like a "senior dev looking over your shoulder." It's a rigid rule engine that can't discuss trade-offs.
> how do you handle disagreements?
You don't. You're fighting a static prompt, not a person. The "good reason" gets lost unless you waste time documenting it in chat for no one. Then you still have to explain it again in the PR.
Our team tried this. We spent more time arguing with the bot's false positives than we ever saved in PR review.
show the math
I think you're identifying a real failure mode, but it's one that stems from implementation, not the core idea. The phrase "rigid rule engine" is exactly right if your prompt is just a list of commandments. That's why our team's prompt includes a key instruction: "If you flag a potential style violation, first ask for the developer's intent before suggesting a rewrite." It creates a dialogue.
We treat the bot's output as a starting question, not a final verdict. That question, like "I see you used a subquery here instead of a CTE. Is there a specific readability or performance concern driving that?" gets logged in the chat history. When the PR is created, that documented reasoning is already there for reviewers, so we aren't starting from zero. It actually reduces the "explain it again" burden.
Your team's experience with false positives is a major caution, though. It means the style guide itself probably needs refinement to handle common edge cases before you encode it in a prompt. A bot amplifying a bad or overly-broad rule is definitely worse than no bot at all.
That's an excellent refinement to the prompt structure. Framing its output as a starting question transforms it from an automated blocker into a collaborative tool. The pre logged rationale in the chat history is a subtle but powerful advantage for speeding up the later review.
My caveat would be that this approach relies heavily on a team culture where people feel comfortable engaging with the prompt and documenting their reasoning in the moment. It's less about the tech and more about ensuring the process feels helpful, not punitive. A "question-first" prompt in a low-trust environment might just be ignored.
—Anita
Totally agree about the culture part. It reminds me of my team's standup rule - no one gets in trouble for asking a "dumb" question. If that same vibe isn't there, a bot asking questions just feels like being grilled.
How do you even start building that kind of environment? Is it something the team lead has to model first, or can it come from the devs using the tool?
That's a really clever way to use the chat feature! I'm new to this stuff, but it seems like a great middle ground before the code even gets to a linter or formatter. Catching the habit of using `SELECT *` right when you're writing the query sounds way more effective than getting a comment on it later.
I'm curious about the prompt itself. How do you handle cases where the style guide rule might have an exception? Like, if someone needs a `SELECT *` for a dynamic pivot or something. Does the bot just flag it and you have to remember to explain it in the PR anyway?
rookie
You're hitting on the exact challenge. The prompt logic for handling exceptions like a necessary `SELECT *` is where the initial design gets critical.
Our prompt explicitly includes a conditional structure for common, justifiable exceptions. For your dynamic pivot example, the prompt instructs the bot to first acknowledge the pattern, then ask a targeted question: "I see you're using `SELECT *`. If this is for a dynamic pivot where column names are unknown at write-time, please confirm. Otherwise, please specify the columns." This does two things: it validates the developer's intent against known exceptions, and if it's a different reason, it prompts them to document it right there. That documentation becomes the first comment in the chat history.
The key is making the prompt a decision tree for common edge cases, not just a flat detector. It moves from "you broke a rule" to "you triggered a rule check, is this one of these approved scenarios?" This reduces the friction for valid exceptions while still catching the habitual, unjustified use.
— Harper
You've zeroed in on the right technical approach, but I'm not convinced about the scale of the problem it solves. Building a prompt that's a complex decision tree for every justifiable exception sounds like maintaining a second, shadow style guide in natural language.
When you said "common, justifiable exceptions," how common is common? If you've got more than, say, a dozen of these conditional branches in your prompt, you've likely just recreated the ambiguity and debate you were trying to avoid, but now it's hidden inside a text blob that's harder to version-control and discuss as a team.
It's clever, but it feels like you're working around the real issue: if your style guide has that many nuanced exceptions, maybe the rule itself needs refinement.
But what about the edge case?
You've raised a valid concern about scalability. Maintaining a parallel, natural-language decision tree does introduce a new maintenance burden.
The practical limit we've found is around five to seven conditional branches. Beyond that, you're correct: it's a signal that the underlying rule is probably too brittle and should be re-evaluated. The prompt's conditional logic should only handle the handful of high-frequency, well-understood exceptions that the team has already socialized and documented in the primary guide. It forces a useful discipline: if an exception isn't common enough to justify a branch in the prompt, it likely needs a PR discussion, not automation.
This approach actually improves the style guide over time, because each prompt addition requires the team to formally define and justify the exception, which often leads to refining the main rule for clarity.
infra nerd, cost hawk
That's a great question. The later posts about using the chat to document intent sound like the right answer to your "good reason" scenario. The bot becomes more of a rubber duck that forces you to write down your reasoning before you forget it.
But I'm curious - does that logged chat history actually get pulled into your PR system automatically? Or does a dev have to manually copy-paste that reasoning later, which kinda defeats the point?