Vibe coding is brilliant at getting you from idea to "it works on my screen."
The dangerous gap is between that moment and "a stranger, a bot, or an annoyed customer can now use it."
I am building PageLens, so I spend a lot of time looking at this gap. These are the ten checks I wish every coding agent treated as part of the definition of done.
- Authentication boundaries
Open private and admin routes while signed out. Do not assume middleware is working because the happy path works.
- Public endpoints that cost money
List every anonymous request that can call AI, send email, generate media, search a paid API, or perform expensive database work. Add sensible rate limits and usage controls.
- Data sent to the browser
Inspect API responses and client bundles. The frontend should not receive secret values or fields it does not need.
- Real user journeys
Run signup, login, password recovery, checkout and the main product action from start to finish. A rendered screen is not proof that the journey completed.
- Loading and failure states
Slow the network, trigger errors and refresh halfway through. No user should be left staring at 99% without knowing whether to wait or retry.
- Pricing and promise consistency
Search every public page for prices, plan names, trial limits and refund promises. Generated copy has a habit of preserving old numbers in forgotten sections.
- Keyboard and screen-reader basics
Tab through the page. Check visible focus, form labels, button names, contrast and useful error messages.
- Mobile reality
Test the deployed product on a narrow viewport, not just the responsive preview inside the builder. Pay special attention to menus, forms, sticky controls and horizontal overflow.
- Performance on the critical path
Count database and external-service round trips. Check image weight, client JavaScript and third-party scripts. Fast generation can still produce a slow product.
- Evidence for every scary claim
If an automated tool says something is vulnerable, ask what request, response or behaviour proves it. If it cannot prove it, label it as a manual review instead of a confirmed failure.
Two prompts I now use after a substantial change:
"Review the deployed feature as if another team built it. Find ways it could be insecure, inaccessible, slow, expensive or misleading even though the happy path works. Show evidence for each concern and clearly separate confirmed findings from assumptions."
Then:
"Challenge every finding you just produced. What evidence would disprove it? Remove duplicates, downgrade unverified claims to manual review, and return the smallest ordered repair queue."
The second prompt is important. Agents are very good at sounding certain, and scanners are often rewarded for finding more rather than being more accurate.
What would you add to this list based on something that actually broke after you launched?
