Directing AI to Build Your Data Layer
AI is excellent at schema design and query writing — if you give it the constraints to design against. Don't say "make a ." Describe the , the relationships, and your non-negotiables.
A strong looks like this:
Design a PostgreSQL schema for a task-management app.
Entities and relationships:
- A user can own many projects.
- A project has many tasks.
- A task belongs to one project, has a status
(todo / doing / done), and an optional due date.
Requirements:
- Use UUID primary keys and created_at timestamps.
- Enforce relationships with foreign keys.
- Add indexes for the columns we'll filter on.
- Give me the schema as SQL, plus a forward migration file.
- Explain any trade-offs you made.
Then review the output with the checklist from this chapter: honest types, foreign keys and constraints present, sensible indexes, no duplicated data. When you ask for queries, explicitly require parameterized queries so user input is never concatenated into . And for any migration that drops or renames something, ask AI to call it out so you can back up first.
The database is the part of your app where mistakes are hardest to undo — data, once corrupted or lost, doesn't always come back. That's exactly why these fundamentals are worth knowing: not so you can write every line yourself, but so you can direct AI confidently and catch the dangerous moves before they ship.