Prisma and Cursor without schema chaos

I have seen agents invent a second User table because the prompt said “add profiles.” That kind of quiet mistake shows up later as broken admin login. Not fun.

Rule one: agents may propose schema changes; I approve migrations. I paste the relevant chunk of schema.prisma into the prompt so the model is not guessing from vibes.

Separate tasks. Updating the Prisma model is not the same job as building the UI form. Sequence them. Schema first, generate, migrate, then UI. Mixing them is how half-applied fields land in production.

I mention seed and env assumptions every time. SUPER_ADMIN_*, CONTENT_SOURCE, SMTP fallbacks — agents forget runtime shape. On this portfolio CMS, public pages read JSON even when the admin uses the database. That detail belongs in the brief or you get “fixes” that only work in one mode.

After schema edits I run migrate, generate, and a smoke path: login, publish a section, submit contact. Typing speed is meaningless if auth cookies break on HTTPS.

Cursor is great at writing the boring Prisma client calls once the model is settled. It is a poor solo architect. Keep the human on the entity design.

If the agent suggests “just use a JSON column for everything,” I push back. Flexible sounds nice until you need to query contacts by unread status at 2am.