Prompting Based On Data Shape

Before you prompt an agent to do anything with data, you have to know:

WHAT TABLES EXIST and what's in them. WHAT COLUMNS EXIST and what types they are. HOW THE TABLES RELATE (foreign keys, joins). WHAT THE TYPICAL ROW LOOKS LIKE. WHAT'S MISSING (nulls, unknowns, bad data). WHAT THE EDGE CASES ARE (the row that's three years old, the row with the customer's name in the wrong column, the row that breaks every query you run).

This is data shape. It's not a fancy concept. It's literally just "what does my data look like."

The mistake people make: they describe what they want done as if the data is clean. The data is never clean. The agent writes code for the clean data. The code breaks on the dirty data.

The fix: include a sample of the actual data in your prompt. Three to five rows is usually enough. The agent sees the shape and writes code that handles it.

-- Example: my orders table
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    customer_id INTEGER REFERENCES customers(id),
    total_cents INTEGER NOT NULL,
    status TEXT,  -- 'pending', 'paid', 'shipped', 'cancelled', sometimes NULL
    placed_at TIMESTAMP NOT NULL,
    notes TEXT  -- often empty, occasionally has comma-separated tags
);

-- Sample rows:
-- (1, 42, 4999, 'paid', '2026-01-15 10:23:00', NULL)
-- (2, 17, 12000, NULL, '2026-01-16 14:11:00', 'rush, gift-wrap')
-- (3, 42, 850, 'cancelled', '2026-01-17 09:00:00', '')

Now when you ask "write me a query that shows total revenue per customer this month," the agent knows that status is sometimes NULL (and probably shouldn't be counted), that total_cents is in cents (not dollars), and that notes can be empty string or NULL.

By industry, the data shapes you'll encounter:

E-COMMERCE. Orders, customers, products, line items. Lots of foreign keys. Money is usually in cents (integers), not dollars (decimals), to avoid rounding errors. Status fields are usually strings with a small set of allowed values. Refunds, cancellations, and partial shipments make "total revenue" trickier than you'd expect.

EDUCATION. Students, courses, enrollments, grades. Many-to-many relationships everywhere (a student takes many courses, a course has many students). Time is multidimensional: term, semester, academic year. Grades are stored as both numbers and letters, sometimes inconsistently.

HEALTHCARE. Patients, encounters, providers, claims. PHI everywhere (privacy is non-negotiable, see section 6.5). Codes for diagnoses (ICD) and procedures (CPT) that are not human-readable. Dates that are intentionally fuzzed for de-identification.

HOME SERVICES. Customers, jobs, technicians, invoices. Time-windowed (this customer's roof was replaced in 2019 and needs a 5-year follow-up in 2024). Geography matters (jobs are clustered by zip code or route). Notes fields are often where the actual important information lives.

RESTAURANTS. Menu items, orders, modifiers, inventory. Modifiers and combos make "what was actually sold" surprisingly hard to query. Inventory depletes per ingredient, not per dish, so you need a recipe table to map "one burger" to "one bun, one patty, one slice of cheese, three pickle chips."

If you can describe the shape of your data this way before prompting, the agent will produce code that works on your data, not on hypothetical clean data that doesn't exist.