Text-to-SQL in Practice: When to Trust AI Output and When to Gate It

AI assistants are now a normal part of SQL work. You describe what you need, get a query back in seconds and move on. The problem is not that these queries fail. Most of the time, they run perfectly. The problem is that a query can run perfectly and still be wrong.

This post covers why that happens, how to sort database tasks by risk and how to build guardrails into a normal workflow.

Adoption is high, trust is not

The Stack Overflow 2025 Developer Survey puts AI adoption at 84% of developers using or planning to use AI tools. The same survey found that 46% of developers distrust the accuracy of AI output, compared with 33% who trust it. And 66% named "almost right, but not quite" answers as their top frustration.

That combination describes text-to-SQL well. The output looks correct, compiles and executes. Whether it answers the right question is a separate matter.

An illustrative example: the silent join

Say you ask an assistant for customers with more than three orders in the last 90 days. Your hypothetical schema has orders and order_items, and the assistant decides it needs item-level data:

SELECT c.customer_id, c.email, COUNT(*) AS order_count
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
JOIN order_items oi ON oi.order_id = o.order_id
WHERE o.order_date >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY c.customer_id, c.email
HAVING COUNT(*) > 3;

This runs without error. But COUNT(*) now counts order lines, not orders. A customer with one order of four items qualifies. The fix is small:

SELECT c.customer_id, c.email, COUNT(DISTINCT o.order_id) AS order_count
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
WHERE o.order_date >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY c.customer_id, c.email
HAVING COUNT(DISTINCT o.order_id) > 3;

Nothing in the first version would trigger an alert. The numbers are simply inflated. Now imagine that query feeding a retention dashboard.

The four failure modes to watch for

Most AI-generated SQL bugs fall into a few categories:

1. Schema misinterpretation. Correct tables but wrong join keys, or a column whose meaning differs from what the model assumed. For example, order_date might mean placed-date in one table and fulfilled-date in another.
2. Silent logic errors. Wrong aggregation grain, fan-out from joins, off-by-one date boundaries. No exceptions, just wrong results.
3. Governance gaps. Queries that touch PII or tables outside the user's intended scope because the model had no reason to avoid them.
4. Context collapse. Logic that holds on a simple schema and breaks on a real one with layered relationships and inconsistent naming.

The root cause is the same in each case: the model knows SQL but does not know your database.

A risk-tiered workflow

Rather than a single rule for AI usage, sort tasks by the cost of an undetected error.

Low risk: use AI freely

• Exploratory queries in dev, where you see the result immediately
• Draft documentation for tables and stored procedures
• Explaining an unfamiliar schema you can inspect yourself
• First-pass troubleshooting on slow queries

High risk: gate the output

• Migration scripts and production deployments
• ALTER statements on objects with downstream dependencies such as views, ETL jobs and application queries
• Queries touching PII, audit logs or regulated data
• Financial and operational reporting

For the high-risk tier, AI output is a proposal. It needs review, testing and sign-off like any other change.

Guardrails that fit an existing pipeline

You do not need a separate process for AI-generated SQL. You need to make sure it goes through the one you already have.

Validate reporting queries against a baseline. Before a new query replaces an existing one, compare row counts and key aggregates on a known dataset.

Run AI changes through CI/CD. If schema changes go through version control, automated tests and review, AI-generated migrations do too. No fast lane.

Enforce the same permissions. AI-generated queries should run under the same role as the user requesting them, with row-level security and column masking still applied.

Tag AI-assisted changes. A commit message convention or a field in your change log is enough. When something breaks, you want to know what ran, who approved it and whether AI produced it.

Review joins and aggregations first. When reviewing generated SQL, these are the lines most likely to hide a silent error. Check join cardinality and GROUP BY grain before anything else.

Context is the biggest lever

Much of the failure surface comes from the model guessing at structure. Pasting a schema description into a chat window helps a little. An assistant that reads the live structure of the connected database helps more, because it has less to guess.

This is why AI is moving into database IDEs. dbForge AI Assistant, for instance, runs inside dbForge Studio and dbForge Edge and works from the connected database's metadata, including tables, column types and relationships, for text-to-SQL, query optimization and error troubleshooting. It sends metadata for context rather than table data. Schema awareness like this reduces misinterpretation, but it does not catch every logic error, so the review steps above still apply.

Wrapping up

AI assistants are good at producing SQL quickly. They are not yet good at knowing whether that SQL matches what your business means by "customer" or "order."

Treat AI output the way you would treat a pull request from a capable new team member: useful, often right and always reviewed when it matters.

What guardrails does your team use for AI-generated SQL? Share them in the comments.

---

Source: This post builds on ideas from Victor Horlenko's HackerNoon article, AI Assistants in Databases: Speed vs. Reliability.