My AI dev team shipped its first real project this week, and the most important line of code in it is a test that makes sure something never happens. Treating compliance as a test — not a note, not a comment, not a paragraph in a doc — turned out to be the whole design.
Here's what we built, and why the rule lives where it does.
The Product: A Review Tool That Can't Gate Reviews
The project is a review-collection tool. A business gives a past customer a link, the customer taps a star rating, and the paths diverge: happy customers get pointed to the company's Google page, unhappy ones get a private feedback form first.
Simple enough — except the obvious version of that idea is against the rules.
Why Is Review Gating a Problem?
The tempting design is called review gating: send five-star customers to Google, and quietly keep one-star customers away from it. It's an easy feature to build and it reliably inflates a rating.
It's also prohibited. Google prohibits it, and the FTC has guidance against it. Worse, the risk doesn't land on me — it lands on my clients' Google profiles, which are among the most valuable assets a local business owns.
So we killed that version on day one and built the compliant one instead: unhappy customers see the private feedback path first, but the public Google option is never hidden or disabled based on their rating. They're offered a gentler road, not denied the main one.
A Promise Is Not a Feature. Promises Rot.
Here's the part I keep thinking about.
"Never hide the Google link" isn't a feature. It's a promise. And promises rot.
Six months from now, someone tidies up the unhappy-customer screen. They remove a button that looks redundant. The whole product silently becomes non-compliant, and nobody notices until a client's profile gets flagged. No one did anything wrong. No one even made a decision. The rule just quietly stopped being true.
Documentation doesn't prevent this. A comment doesn't prevent this. Both are addressed to a reader who, in the moment that matters, isn't reading.
How We Locked the Rule Into a Test
So we didn't write it as a comment or a note in the docs. We wrote it as a test: the visible, enabled Google link on the low-rating screen. Then we locked the test file so the build agent literally cannot edit it.
That inverts who has to act. To break the rule now, you'd have to delete a passing test on purpose — a decision someone has to make out loud, in a diff, with their name on it. Not an accident someone stumbles into while cleaning up a screen.
The rule stopped depending on anyone remembering it.
What 53 Passing Tests Actually Bought
The build finished with 53 of 53 tests green. Both customer paths and the owner dashboard were driven in a real browser. A reviewer approved it. My own involvement was two approvals: the plan at the start, and the finished product at the end. The tests held the line in between.
But the count isn't the achievement. Fifty-three tests passed, and only one of them really mattered — the one guarding the thing we promised never to do. The other 52 tell me the software works. That one tells me the software is still honest.
Put Your Rules Where They Fail Loudly
The lesson I'm taking into every build from here: the rules you care about most shouldn't live in your head, your README, or your onboarding doc. They should live somewhere that fails loudly and blocks the work.
Compliance as a test isn't a constraint bolted onto the product. It's the product's spine.
What's the rule in your system that everyone knows and nothing enforces?