When to use it
When you need to fill a database, tests or a demo with realistic data and doing it by hand takes too long: a seed for development, fixtures for tests, data for a demo. The role is a data engineer. The key is that you supply the schema and types, and the model generates ONLY against it, including edge cases and "dirty" rows. The output: valid synthetic data in the format you need plus a set of deliberately broken cases.
The prompt (grab it and paste)
You are a data engineer. Generate REALISTIC synthetic test data strictly according to the schema below. No real personal data — invented only.
SCHEMA / FIELDS AND TYPES: "<PASTE: tables and columns, or a TS interface, or a description of the fields with their constraints>".
OUTPUT FORMAT: <JSON array / SQL INSERT / CSV>. HOW MANY ROWS: <N>. LOCALE/LANGUAGE OF THE DATA: <e.g. Russian names and addresses>.
SPECIAL RULES: "<relationships between fields, ranges, uniqueness, business logic — e.g. end date > start date>".
Requirements:
1. Respect the types, constraints and relationships from the schema (foreign keys, unique fields, email/phone/date formats).
2. The data must be PLAUSIBLE and varied (different names, cities, values), not "test1/test2".
3. Include EDGE cases: empty and maximum-length strings, boundary numbers (0, minimum, maximum), dates on the boundaries, special characters and unicode, NULL where a field is optional.
4. Add several DELIBERATELY "dirty"/invalid rows as a SEPARATE block (for negative tests) — and label what is wrong with each.
5. If the schema has relationships (for example orders referencing users) — keep referential integrity.
Give me: 1) the valid data in the specified format; 2) a separate "invalid/edge cases for negative tests" block with the problem noted on each; 3) one line on how to use it (import/seed).
Filled-in example
Schema: users(id, email UNIQUE, name, age INT, city, created_at) and orders(id, user_id FK, amount NUMERIC, status, created_at). Format: SQL INSERT. Rows: 10 users and 20 orders. Locale: Russian names/cities. Rule: amount > 0, status from ('new','paid','cancelled').
Expected AI response: INSERTs with plausible data (varied full names, cities — Moscow, Kazan, Novosibirsk; valid emails; ages in a sensible range), orders referencing existing user_id values, status only from the list, amount positive, order dates ≥ signup dates; a separate "invalid, for negative tests" block — a row with age=−1, an empty name, a duplicate email, amount=0, a status not in the list, each labelled with what is wrong; and at the end "to import: psql -f seed.sql".
Variations
- For your framework. "Give me not the data but a factory (Faker/factory_boy/Prisma seed) that generates it" — for repeatability.
- Large volumes. "Generate a script that creates 100,000 rows" (bulk generation is better done in code than row by row in the response).
- A connected graph. "Build a consistent dataset across several tables with a realistic distribution (80% of orders belonging to 20% of users)."
Pro tips
- The schema is mandatory and must be exact: without types and constraints the AI will invent fields and the import will fail. Paste your
CREATE TABLE, your interface or a clear description with the constraints. - The real value is in the edge cases and the "dirty" rows: those are what production falls over on. Always ask for a separate block of invalid data for negative tests, not just the "pretty" rows.
- NEVER generate "test" data based on real people and never mix in real personal data — this is synthetic by definition (otherwise you are into Federal Law 152-FZ territory). For very large volumes use a code factory with a fixed seed so the data is reproducible between runs.