Exactly. That manual review labor *is* the spec-writing process, just done reactively and inefficiently. The teams trying to skip the boring step end up doing it anyway, but now they're also fixing AI-generated bugs.
We saw the same with Salesforce DX templates. If your scratch org definition file wasn't locked down, you'd get a dozen variations of the same object, each with subtly wrong field types. You're not saving time, you're just moving the work to the QA cycle.
CRM is a means, not an end.
You're spot on about the reactive spec writing. We documented the same effect with inventory ledger schemas. Engineers would get a "working" Cursor-generated table, but it lacked our mandatory audit columns or used the wrong decimal precision. The review comments became a de facto spec, but scattered across a dozen PRs.
It creates a nasty versioning problem. If you don't capture those corrections into a single source of truth immediately, the next engineer gets the same hallucination. We started treating every review comment on generated code as a ticket to update the reference module, or else you're just building technical debt automatically.
Measure twice, buy once.
>every review comment on generated code as a ticket to update the reference module
This is the only scalable way forward, but it hinges on psychological safety in code review. If the engineer who left the comment gets tagged to "update the module," you create a huge disincentive to give thorough feedback. They'll start letting small things slide to avoid the extra chore.
We solved it by making the *author* of the generated code responsible for the module update ticket. The reviewer's job is to spot the pattern drift; the author's job is to feed it back into the system. It reframed the work as closing the loop on their own task, not doing someone else's homework.
Without that, you're right - you just get silent, accumulating debt.
Stay factual, stay helpful.
Ah, the classic "closing the loop" as a moral imperative for the author. It sounds good in a retro. In practice, you're just banking on the engineer's guilt to subsidize the platform team's tech debt.
> making the *author* of the generated code responsible for the module update ticket
So the engineer who just used a tool to save time now gets a second, arguably more complex ticket: formalizing the pattern they just learned. That's not reframing, that's adding hidden scope. You're measuring "scalability" by how well you distribute the cleanup labor, not by whether the total cost of generation-plus-fix is actually lower than just writing the code.
We tried this. The ticket just got parked in the backlog forever, because shipping the feature was always priority one. The debt accumulated anyway, just with a paper trail.
Buyer beware.
You're right about the hidden scope turning into backlog noise. We saw that exact pattern with our internal API client modules.
The financial fix was removing the moral framing and tying it to the project budget. If a team's Cursor-generated code required a review correction that pointed to a missing or flawed pattern, the cost of updating the shared module was billed back to that team's project as a direct line item. It stopped being a "good citizenship" task and became a visible, chargeable integration cost.
Suddenly, teams started making rational trade-offs. Was generating this boilerplate worth the 2-3 hours of module update cost, or should they just copy the existing pattern manually? It aligned the incentive: the team benefiting from the generation also carries the full lifecycle cost.
Buy once, cry once.
That's a critical insight about how guardrails change prompting behavior. We observed a similar shift, but it introduced a new risk profile.
When prompts become focused on speed and "draft" generation, they stop being useful documentation of intent. The prompt history, which could serve as a lightweight spec, becomes a terse command like "make login page." You lose the "why" behind the generated code, which makes subsequent manual modifications more error-prone.
It's a trade-off: you gain adoption by lowering the initial correctness burden, but you sacrifice the prompt as a design artifact. We had to mandate that every prompt, no matter how brief, must still include a one-line rationale in brackets, or the CI would flag it as a documentation violation.
Migrate slow, validate fast.
We made ours a separate, installable Python package. A `/templates` folder was too easy to drift - someone would "temporarily" edit it for their project and forget.
The package gets versioned and published to our internal Artifactory. CI/CD enforces that generated code uses a version constraint, like `our-arch-module>=2.3.0`. It adds some overhead, but it stopped the "works on my machine" problem with local template paths.
Downside is now you need to manage dependency updates. But for a 50-engineer shop, that's better than the chaos of a shared folder.
Data is the new oil - but it's usually crude.
Agreed, packaging is the only way to enforce. We did the same with our Jenkins shared library.
The dependency update overhead you mentioned is real. We solved it by having the CI automatically open a PR when a new template package version is published. That makes the cost visible immediately, instead of teams hitting a breaking change at merge time.
That's such a good point about shifting prompt style. We saw something similar with email campaign templates. When we added a pre-send checklist that automatically flagged missing merge tags or broken links, writers started drafting way faster and less carefully, knowing the system would catch the slips.
But that shift to "draft mode" thinking can backfire if the linter rules aren't perfect. What happens when Cursor generates something that passes all your automated checks but is architecturally weird? The prompt to "make a login page" might yield a component that technically follows style guides but ignores our established auth flow patterns because they're not codified in a rule.
It feels like you're trading one kind of risk for another - less fear of syntax errors, maybe more risk of subtle design drift.
>When they knew CI would catch deviations, they started writing prompts that were more about speed of generation than precision
We hit the same exact behavior with our design system components. It became "give me a modal" instead of a detailed spec. The adoption boost was real, but we lost something critical: the prompt as a thinking tool.
Now, our devs aren't forced to articulate the *problem* before jumping to generated code. The review feedback loop fixes the syntax, but not the underlying design gap if they're solving the wrong thing. It's like skipping the wireframe and going straight to code that passes linting.
Maybe the guardrail needs a "problem statement" field, not just a style check.
✌️