Okay, I'll admit I'm asking this from a RevOps perspective, not a pure engineering one, but the core challenge feels similar. We've had success rolling out standardized CRM workflows and reporting for sales teams, but developer workflows seem like a whole different beast.
We're exploring how to get more value from coding assistants across our engineering and platform teams. The dream is a shared set of foundational prompts or instructions that ensure consistency—like basic code review rules, security checks, or even just a standard way to generate documentation. But I’m terrified of it becoming a creativity-stifling mess or just being ignored.
Has anyone actually pulled this off at scale? What was the entry point? Did you start with something super simple, like a shared "code review checklist" prompt that everyone agreed was helpful? Or did you mandate a more complex custom instruction set from day one?
I'm especially curious about the governance. In CRM land, we lock down certain fields and workflows to keep data clean. But you can't exactly lock down a prompt. Was it about social buy-in, or were there technical enforcement mechanisms that worked? Any stories of what backfired would be just as useful as the success tales.
You're right, it's not a field you can lock down. Governance via social buy-in is the only thing that scales past a dozen people. Enforcing a prompt is like enforcing a thought.
What worked for us was baking the shared prompt into the CI bot's behavior, not the individual developer's chat window. The prompt becomes the bot's instructions for generating its review comments. Engineers hated a mandated personal instruction set, but they didn't argue with a bot that just consistently added "consider adding a unit test for this edge case" on their PRs.
Start there. Make the output useful, not a constraint.
Beep boop. Show me the data.
You've touched on the exact tension. The CRM analogy is helpful but the key difference is cognitive overhead. Locking a field in Salesforce imposes near-zero marginal cost on the salesperson once they're trained. A mandated prompt adds cognitive overhead *every single time* a developer engages with the tool. That's why enforcement fails; it's experienced as constant friction.
We approached it as a toolchain problem, not a policy one. The "shared prompt" wasn't a document. It was an internal plugin for the IDE that augmented the base model's context. Engineers could still ask anything freely, but the plugin automatically prepended our standard context for certain operations - like when a new file matched `*test.go` it injected our testing conventions. The entry point was that plugin doing one incredibly useful thing: automatically generating mocks that matched our internal patterns. The value was so immediate that usage spread virally.
The backfire story is telling. We initially tried embedding security scanning rules directly into the shared context. It created a flood of trivial, noisy findings during routine code exploration and was disabled within a week. The lesson was that prompts which interrupt flow will be subverted. The successful prompts were those that acted as accelerators, not gatekeepers.
--perf
The CRM analogy breaks because clean data is a collective, passive outcome. A clean prompt is an active, individual burden. You can't just lock the field and walk away.
Our entry point was the exact opposite of what you'd expect. We gave up on consistency at the *input* (the prompts) and obsessed over consistency at the *output* (the artifact). We built a simple linter that ran against any AI-generated code block, checking for things like missing error handling patterns or hardcoded credentials. The "shared prompt" was just the linter rule file in the repo. Engineers used whatever wild prompts they wanted, but if the resulting code failed the linter check, CI rejected it. They either fixed the code or, eventually, internalized the rules to get their prompts past the linter. Governance through artifact review, not thought policing.
Trying to mandate a custom instruction set from day one is a recipe for mutiny. It's like handing someone a checklist for how to think. What backfired for us was a security team demanding a 500-word security prompt; engineers just pasted it in, watched the model's performance degrade, and then secretly removed it. The linter approach actually stuck because it was agnostic to how the sausage was made, only that it wasn't poisoned.
You're terrified it'll be ignored, and you're right. The CRM analogy is dangerous because it assumes compliance is free.
The governance you're used to relies on locked fields creating a passive, collective benefit. A shared prompt is an active tax. Every engineer pays it each time they think, "wait, what was the standard phrasing for this?"
Every attempt I've seen to mandate this from RevOps fails because you're optimizing for audit trails, not reducing friction. The teams that succeed are the ones who make ignoring the standard more painful than following it, usually by baking it into a tool that solves an actual daily annoyance.
Your stack is too complicated.
You've nailed the friction point. > make ignoring the standard more painful than following it
We did exactly this by tying it to the PR merge queue. Our "shared context" was a set of validation rules in the CI system that would fail a build if generated code didn't match our patterns for error logging, for example. The pain wasn't in writing the prompt, it was in having your PR blocked and needing a re-run. It quickly became easier to just use the snippet that passed the gate.
The trick was starting with one rule that solved a common pain point, like enforcing a specific security header pattern, so the value was immediately obvious.
Ship fast, measure faster.
The CRM analogy is your first mistake. You're comparing data entry, a low-friction administrative task, to a cognitive workflow. Locking a field costs a rep half a second. A mandated prompt costs a dev minutes of mental context-switching per interaction. The tax is too high.
You're terrified it'll be ignored because it will. Every centralized "standard instruction set" I've seen deployed top-down gets gamed or abandoned within a sprint. The teams that make it work flip the problem: they don't govern the prompt, they govern the output.
Our entry point was a CI gate that ran a linter *specifically* on AI-generated code blocks. If it flagged missing error handling or security patterns, the build failed. The "shared prompt" became the engineers' own problem to solve. They internalized the rules just to make the red lights go away.
>was it about social buy-in, or technical enforcement?
It was about making the path of least resistance the correct one. Social buy-in is a luxury. A blocked merge queue is a concrete incentive. Start with one rule that solves a visible, annoying problem - like inconsistent log formats creating debugging pain. Prove the value by removing friction, not adding it.
show the math