1 min lesson
Good rules vs. bloated rules
Match each case in "Good rules vs. bloated rules" to the signal and response that fit it.
Step 1 of 2
Good rules vs. bloated rules
Concise and specific: "use the repository layer for DB access" beats a paragraph of philosophy.
Testable: you could check whether the model followed it.
Scoped to what actually causes inconsistency, not every preference imaginable.
A 600-line file restating the whole style guide; the signal drowns and output degrades.
Vague aspirations like "write clean, maintainable code" that give the model nothing to act on.
Contradictory rules accreted over a year that nobody pruned.
More rules is not better. Every rule spends context budget and competes with the actual task; a bloated file makes output worse, not safer.
Treat the rules file like code you maintain: prune dead rules, keep each one earning its place.
Learn more
Full explanation
Why this drives expansion
Why this drives expansion
Standardized Rules are how you go from one happy team to a happy org. A pilot team builds a strong rules set, it gets battle-tested and you template it for the next team's stack. New teams inherit a known-good baseline instead of rediscovering the same lessons. That repeatable pattern is exactly the land-and-expand motion an SA owns.
In the demo, edit a rules file live and rerun the same Agent prompt. The output visibly changes to honor the new convention.
That one moment makes the abstract concrete and shows the panel you can teach the most important enablement concept in the product.