Ask your AI to add a delete button, and it will add a delete button. It works. It is even styled nicely. What it almost certainly will not do — unless you spell it out — is make sure that only the person who owns the thing can actually delete it. The AI does not know your rule. It gave you a generic solution to a generic request.
This is one of the most dangerous patterns in vibe-coded software, because the gap is invisible right up until someone finds it.
Why your AI gives generic answers
A language model is trained on an enormous amount of generic code, so when you ask for a feature it produces the common-case version — the one that appears most often in its training. The common-case delete button just deletes. The common-case form just submits. The common-case list just shows rows. But your application is not generic. It has rules that live in your head and nowhere else:
- Only the owner can delete this project.
- An email address must be unique across the whole workspace.
- A member can see their own drafts; an admin can see everyone's.
- You cannot move a card to Done unless its checklist is complete.
- Refunds over 500 dollars need a second approval.
The AI cannot infer these. They are not in the code yet, not in the request, and specific to your business. So unless you state each one explicitly, every single time, you get the generic version — which silently has no rule at all.
And here is the part that bites hardest: even when you do mention the rule, the AI frequently enforces it in the wrong place. You say "only the owner should be able to delete this," and it hides the delete button from everyone else. The screen looks correct. The owner sees the button; nobody else does. Demo passes. But hiding a button is not a security control. The delete endpoint is still sitting there, and anyone who can send an HTTP request — a curious user with dev tools open, a script, an attacker — can call it directly and delete data they should never touch. The rule exists in the UI and is completely absent from the server, which is the only place it actually matters. That is the gap afterclick is built to catch.
How afterclick makes the rule real
An independent second eye on the risky calls. afterclick runs a review engine — separate from the model that wrote the change — over the calls touching authorization, ownership, user data, money, and production. When the agent ships a change that should carry a rule and does not, the engine reads the diff and reasons about intent: a delete handler with no ownership comparison, a unique field with no constraint, an endpoint that trusts the client to have hidden the button. These get surfaced in plain language, not shipped silently.
It pushes the check to the server. The whole point is that a UI guard is not a guard. afterclick's concern is whether the rule is enforced where requests actually land, so its advice points at server-side authorization and validation — the ownership check inside the delete endpoint, the unique constraint in the database — not the cosmetic version that only hides a button. It names the exact gap between looks enforced and is enforced.
You state the rule once, and it is remembered. afterclick keeps a cross-session memory board of your decisions. So when you establish "only the owner can delete this," you do not have to repeat it on every related change — the rule is recorded, and the second eye holds the line on the risky calls so a fresh session cannot quietly undo a deliberate decision you already made. Your business logic stops being something only you remember.
A keys vault so secrets never become the next leak. Business rules are not the only thing the generic path gets wrong — generic code also tends to hardcode the API key or the database URL right into the source. afterclick gives you a keys vault that keeps secrets out of code, so the credentials behind your protected endpoints are not sitting in a file waiting to be committed to a public repo.
A record you can stand behind. Every flag, override, and decision lands in an audit trail and a read-only human dashboard. When you need to answer "is this endpoint actually protected, and who checked?", the answer is recorded — advisory by default with owner override, and an opt-in enforce mode for the rules you refuse to ship without.
In practice it looks like this: the agent adds a teammate-removal feature and hides the Remove button from non-admins. afterclick's engine reads the endpoint, sees it checks nothing server-side, and surfaces one flag: any logged-in user could remove any teammate by calling this directly. You add the admin check in the handler, the vault keeps the service key out of the code, and the whole exchange is on your dashboard. The rule went from looks enforced to is enforced — before anyone tested it the hard way.
| Rule | The generic AI default | What afterclick pushes for |
|---|---|---|
| Only the owner can delete | Hide the button in the UI | Ownership check in the delete endpoint |
| Email must be unique | Validate in the form | Unique constraint and a server check |
| Members see only their own data | Filter the visible list | Authorization scoped on every query |
| Action needs approval | Disable the button | Server enforces the approval state |
| Secrets for protected calls | Hardcoded in the source | Pulled from the keys vault, out of code |
State the rule, trust the enforcement
The hard truth of vibe coding is that the AI is a brilliant generic developer and a poor mind reader. It will not know that only the owner can delete this, and even when told, it may guard the wrong layer. afterclick closes both gaps: it surfaces the missing authorization and validation on the calls that matter, insists the check lives on the server, and remembers the rule so it stays enforced.
It is free to start, one paste into your project. Claude is the developer. afterclick is everyone else — including the reviewer who asks "wait, can anyone else call this?" before your users do. Turn it on and let your rules be real where it counts.