PP

Prompt pack

Five prompts to fix what AI misses when vibe coding

Paste these into your AI coding session. Each one targets a specific thing AI almost always gets wrong the first time.

Timezones

You launch, everything looks fine in testing, then your first real user signs up and every date is wrong. AI almost always builds assuming US timezones.

Audit the entire codebase. Store all dates and timestamps in UTC. Convert to the user's local timezone only at the display layer. Never store local times. Show me every file you change.

Privilege escalation

Got an admin area? AI probably stored that as an is_admin flag on your users table and left the endpoint that updates it wide open. Any logged-in user can flip the flag on themselves. The single biggest security hole in vibe coded apps.

Audit the auth and permissions model. Admin flags and role columns must never be writable by end users through any API route, form submission, server action, or direct database query. The exact fix depends on your stack, so apply whichever matches this project. On Supabase, add RLS policies that only allow service_role to update role or is_admin columns, and confirm no client-side code uses the service key. On Drizzle, Prisma, Kysely, or node-postgres with a direct database connection, move role changes into an admin-only server action or endpoint that first checks the caller is already an admin, and never trust role values sent in the request body. List every endpoint, server action, and query that touches role or admin columns, and show me the protection on each one.

IDOR and ownership checks

AI will happily generate a GET /orders/:id or /documents/:id endpoint that trusts whoever is logged in. It rarely checks the record actually belongs to the caller. Change the id in the URL and you're reading someone else's data. The second biggest hole after admin escalation.

Audit every API route, server action, and database query that looks up a record by id, slug, or foreign key. For each one, confirm the query scopes to the current user or their organisation, not just to the id alone. The fix depends on your stack, so apply whichever matches this project. On Supabase, every user-owned table needs an RLS policy that filters on auth.uid() or the tenant id, for select, insert, update, and delete. On Drizzle, Prisma, Kysely, or node-postgres with a direct database connection, every query needs an explicit where clause that includes the current user id or organisation id, enforced server-side from the session, never from the request body or URL. Never trust ids from the client as proof of ownership. List every query you change and show me the ownership check on each one.

Pagination

Every list view loads fine when it's just you testing. Ten real users start adding data and the whole app crawls. AI will fetch every row and render it all at once, with no caching.

Audit every list view and data query. Add server-side pagination with a sensible default page size, and ensure common queries used across the app are cached but allow for mutations. Never fetch all rows. Add database indexes on any column used for filtering, sorting, or lookups. Show me every query you change and confirm no frontend is loading unbounded data.

Query caching

AI will wire up every screen to refetch on every render, and do the fetching from the client where it's slow and expensive. Fine for a demo. It hammers your database and your hosting bill the moment real users arrive.

Audit every data fetch in the app. Default to server-side fetching wherever possible and only use client-side fetching where interactivity genuinely requires it, so hosting and database costs stay low. For React client components and mobile apps, use TanStack Query (or the platform equivalent) with sensible stale times, cache invalidation on mutations, and optimistic updates where appropriate. Never refetch on every render. List every fetch you change and confirm each one is on the correct side of the client and server boundary.

Need a second pair of eyes

Shipped something with AI? Get it reviewed before it scales.

If you've vibe coded an app and want a second pair of eyes on the architecture, security, and performance before more users arrive, I can help.

Get in touch