The promise is simple: ask your AI agent for test data, get test data. The reality, until recently, has been messier.
TL;DR: AI coding agents generate fake values well but fail at relational test data. Once a schema gets deep, the agent loses track of insert order, constraints, and unique keys, and leaves the database half-seeded. A better prompt won't fix that; the agent needs a schema-aware tool it can call. Seedfast reads your live Postgres schema and generates valid, connected rows from one natural-language request.
Key Takeaways
- AI agents are strong at generating plausible column values but weak at coherent multi-table data, because respecting foreign keys, unique constraints, and
NOT NULLcolumns is a constraint-solving problem, not text completion. - The common failure mode is a half-seeded database: the agent's script fails partway through a deep foreign-key chain, then re-runs collide with the rows already inserted.
- The reliable pattern is delegation — the agent describes intent in plain language and calls a schema-aware tool over MCP that handles introspection, relationship validity, and constraint-aware generation.
- Seedfast exposes a single
seedfast_runMCP tool that reads the live schema on every run, so the data stays valid across migrations with no seed script to maintain.
You already have an AI assistant. Claude Code, Cursor, Google Antigravity — one of them sits in your editor and writes most of the code you ship, handling the database while vibe coding right alongside every other part of the app. So when it's time to generate test data with AI, the workflow seems obvious: ask the agent, get data, keep coding. And sometimes it works. But if you've tried to do this against a real schema — one with foreign keys, unique constraints, enum columns, and five tables that all reference each other — you know the reality is less charming than the pitch.
This is a playbook for actually generating test data with AI, written for developers who already live inside an AI coding assistant and want their database populated without context-switching, without writing throwaway seed scripts, and without cleaning up half-inserted data the next morning.
Why Your AI Agent Struggles with Seed Scripts
Ask Claude or Cursor to "seed the orders table with related line_items and payments", and here's what usually happens:
- The agent reads your schema files, then re-reads them, burning context on column types and FK relationships it'll need to recall again on the next prompt anyway.
- It writes a Python or SQL seed script, the same
psql -f seed.sqlstarting point covered in how to seed a PostgreSQL database. The script looks plausible, but it misses aNOT NULLcolumn, or inserts anordersrow pointing at auser_idthat doesn't exist yet. - It runs the script. The first batch of inserts succeeds; somewhere in the middle, a constraint fails. Now your database is in a half-seeded state.
- The agent rewrites the script and re-runs it. But the rows from the first attempt are still there, so the second run hits unique-key collisions, leaves orphaned FK references, or quietly duplicates data — old rows tangled with new ones.
- After several rounds of patching and re-running, the data that did land is semantically incoherent: random strings for product names, mismatched relationships, totals that don't add up. Not the realistic scenario you needed for the feature you were actually building.
This isn't hypothetical. When Neon experimented with letting Claude and GPT generate synthetic data directly, the models consistently struggled once the schema's relationships got deep — the point where constraint complexity exceeds what a model can track in its working context. Kent C. Dodds has a whole tutorial dedicated to the realistic version of this problem, because the naive approach doesn't survive contact with a production-shaped schema.
Cursor users say the quiet part on the tool's own forum, where database threads complain the agent "does not acknowledge tables" it was never shown and ends up "generally not really that useful" for schema-dependent work. That reads less like a Cursor flaw than like the same ceiling wearing a different logo, since an editor agent sees the files you opened rather than the live database behind them, and the deeper the schema, the more of it sits outside the window.
The problem isn't that LLMs are bad at generating fake data. They're great at generating fake data. The problem is that schemas have shape, and generating coherent data that respects that shape is a constraint-solving task, not a text-completion task. Getting referential integrity right — every foreign key pointing at a row that exists, inserted in the right order — is the part that breaks. That's the gap Seedfast was built to fill.
What Actually Works: Give the Agent a Tool
The trick isn't to get your agent to stop writing seed scripts. The trick is to give it a real tool it can delegate to — one that understands the constraint-solving part, so the agent can stay in the part it's good at: describing intent and reasoning about your feature.
That's what MCP (Model Context Protocol) enables, and it's what Seedfast MCP exposes. Instead of the agent writing a Python script, it calls a single tool — seedfast_run — with a natural-language scope: "seed the orders table with related line_items and payments". Seedfast handles schema introspection, relationship validity, and constraint-aware generation. Your agent reads the result and returns to whatever it was actually helping you build.
The framing shift is small but load-bearing: the agent doesn't generate test data. The agent orders test data from Seedfast , which is the tool that specializes in generating it. The whole workflow stays conversational, but the hard part is offloaded.
"I'm building the order history feature. Seed the orders table with a few related line_items and payments, then show me a sample row"
One tool call. Clean data. Context preserved. No half-written scripts to clean up by hand.
Want to try it? Install Seedfast — free plan, no credit card.
Generate Test Data with AI: Real Workflows
Once seeding becomes a single conversational step, a lot of workflows you used to skip become cheap enough to do routinely.
Developer onboarding. New team members spend hours setting up local databases. With Seedfast MCP configured in your project's .mcp.json, onboarding becomes a conversation:
New dev:"Set up my local database with test data for the main features" AI: Creates plan, seeds 15 tables, reports completion in 45 seconds
Combine with Docker Compose and the whole local setup is one command plus one prompt.
Pre-demo environment setup. Before a client demo, prepare the environment in a single sentence:
"Seed the staging database with tables: users, orders, products, payments"
Always use the plan-then-execute pattern here — review what will be seeded before touching a shared environment. See the MCP setup guide for the full pattern.
Migration testing. Before running migrations on production, test them against realistic data. Seed a copy of the schema, run the migration, and check whether the ALTER TABLE takes three seconds or three minutes against a million rows. The migration testing guide covers the full flow.
Reproducing production issues. When debugging production bugs, recreate similar data shapes locally:
"Seed the accounts table with related subscriptions and billing_history tables"
Ephemeral CI databases. Seedfast works well in ephemeral CI databases — spin one up per PR, seed it, run tests, destroy it. Each run gets fresh, isolated data with no shared state between jobs.
Multi-service development. When working across microservices that share a schema:
"I'm working on the orders service. Seed only the tables owned by the orders schema, but include the users table from the shared schema for foreign key references"
That prompt assumes the services still share one database. Once each service owns a fully separate Postgres instance with its own connection string, seeding turns into a coordination problem instead of a scoping one — phased seeding across microservice databases walks through the ID-contract and ordering strategies that case needs.
Get Started
If you want to generate test data with AI the way it was supposed to work — without broken scripts, half-seeded tables, or context bloat — the setup is short:
- Install the CLI:
npm install -g seedfast@latest - Get an API key at seedfa.st (free plan, no card)
- Add Seedfast to your AI assistant's MCP config — see the MCP setup guide for Claude Desktop, Cursor, VS Code, and Claude Code CLI
- Ask your agent to seed something, and keep coding
For the patterns that make seeding reliable at scale — scope writing, plan-then-execute, performance, error handling — see the MCP Setup Guide. For credential hygiene and what crosses the wire to AI providers, see Data Handling & Privacy.
Frequently asked questions
Can AI generate realistic test data for a database?
AI models generate realistic individual values — names, emails, amounts — very well. They struggle with relational test data, where rows have to satisfy foreign keys, unique constraints, and insert order across many tables at once. For coherent multi-table data, pair the agent with a schema-aware tool it can call rather than asking it to write a one-off seed script from scratch.
Why does my AI agent's seed script leave the database half-populated?
A generated seed script usually inserts rows in the wrong order or misses a constraint, so it fails partway through a deep foreign-key chain. Re-running then collides with the rows already inserted, producing unique-key errors and orphaned references. The root cause is that constraint-solving across a live schema exceeds what the model reliably tracks in its working context.
What is MCP and how does it help with seeding?
MCP (Model Context Protocol) lets an AI agent call external tools instead of writing throwaway code. With Seedfast's MCP server, the agent calls one tool — seedfast_run — with a plain-English scope. Seedfast handles schema introspection, relationship validity, and constraint-aware generation, and the agent returns to the feature you were actually building.
Does Seedfast need access to my production data?
No. Seedfast reads only your schema — table, column, and constraint definitions — not the rows in your production tables. It generates fresh data from scratch, so real production PII isn't copied into your test datasets. Your schema metadata does get sent to an AI provider (OpenAI) during generation — see Data Handling & Privacy for exactly what crosses the wire.
How do I set up Seedfast with Claude Code or Cursor?
Install the CLI (npm install -g seedfast@latest), get a free API key at seedfa.st, and add Seedfast to your assistant's MCP config — .mcp.json for Claude Code, or the MCP settings in Cursor and VS Code. Then ask the agent to seed a table in plain language. The MCP setup guide has the config for each client, and there's a start-to-finish Claude Code walkthrough if that's your editor.
Related Reading
-
Seed Postgres from Claude Code — the start-to-finish walkthrough of the
.mcp.jsonconfig and the one-prompt seed -
Seed Postgres from the Codex CLI — registering Seedfast with
codex mcp add, plus theenv_varsroute that keeps API keys out of committed config -
Seed Postgres from Google Antigravity — one
mcp_config.jsonentry that both the IDE and the Antigravity CLI read, next to Google's own AlloyDB tools - Best AI Test Data Generator — shopping for a tool rather than a how-to? The buyer comparison of AI and synthetic generators for application testing
- MCP Setup Guide — connect Seedfast to Claude Desktop, Cursor, VS Code, or Claude Code CLI
- Data Handling & Privacy — what crosses the wire and credential hygiene
- Referential Integrity in Test Data — why foreign-key ordering is the foundation problem for multi-table generation
- Circular Foreign Key Seeding — how to seed tables that reference each other in a cycle
- Test Data Generation Methods — the seven approaches, from handwritten SQL to schema-aware generation
-
Migration Testing — test
ALTER TABLEat scale before deploying - E2E Test Fixtures — replace brittle hand-written fixtures with generated data
Originally published at seedfa.st.
Top comments (0)