We built a compiler, so you no longer have to rely on AI getting it right. It’s not that AI models aren’t accurate enough; it’s that the industry has been asking them to do things they shouldn’t be doing.

Have you ever run into this? AI-generated SQL executes successfully and passes validation, only for you to discover after going live that the boundary is off by one row – with no error reported.

Why we built a compiler

We’ve been used to throw a requirement at AI and get back a beautiful CTE in seconds – window functions nested inside window functions, and nothing for review to flag. It wasn’t until reconciliation that we found the grouping was off by one, and the fallback row had been dropped.

That’s when we realized that while the entire industry was racing to make models more accurate, we needed to take a different path: stop asking models to generate complex, production-ready SQL.

AI is good at breaking plain-language requests down into steps. A compiler is good at translating those steps into SQL. Let each do what it does best, and there’s no need to gamble on AI getting it right.

An example of SQL that runs but gets the right result only by luck

The request was simple, yet it was enough to make us hold our noses and push it live.

Sort the events table by time. Consecutive rows with the same value column value belong to the same group. For each group, output its start time as effective_from and the start time of the next group as effective_to. By convention, set effective_to for the last group to 9999-12-31.

The value column in the source table contains the sequence 1, 2, 2, 1, 1, 1, 2, 2, 1. Consecutive identical values are grouped together:

id	value	timestamp
1	1	2023-11-10 13:00:00
2	2	2023-11-11 13:00:00
3	2	2023-11-12 13:00:00
4	1	2023-11-13 13:00:00
5	1	2023-11-14 13:00:00
6	1	2023-11-15 13:00:00
7	2	2023-11-16 13:00:00
8	2	2023-11-17 13:00:00
9	1	2023-11-18 13:00:00

The expected result only has five rows:

id	value	effective_from	effective_to
1	1	2023-11-10 13:00:00	2023-11-11 13:00:00
2	2	2023-11-11 13:00:00	2023-11-13 13:00:00
4	1	2023-11-13 13:00:00	2023-11-16 13:00:00
7	2	2023-11-16 13:00:00	2023-11-18 13:00:00
9	1	2023-11-18 13:00:00	9999-12-31 00:00:00

We gave the AI a one-sentence requirement and got SQL that looked like this: six CTEs, nested subqueries, the full lineup of LAG, SUM, and LEAD, plus an extra layer of filtering that served no obvious purpose. It looks perfectly correct on the surface. But would you dare deploy it straight to production?

WITH Value AS (
    SELECT id, value, timestamp FROM events
),
Value1 AS (
    SELECT Value.*, LAG(value) OVER (ORDER BY timestamp ASC) AS prev_value
    FROM Value
),
Value2 AS (
    SELECT id, value, timestamp,
        SUM(CASE WHEN value <> prev_value THEN 1 ELSE 0 END) OVER (ORDER BY timestamp ASC) AS gid
    FROM Value1
),
Grouped AS (
    SELECT gid, MIN(id) AS id, MIN(value) AS value, MIN(timestamp) AS effective_from
    FROM Value2
    GROUP BY gid
),
t_1 AS (
    SELECT gid, id, value, effective_from,
        LEAD(effective_from, 1) OVER (ORDER BY gid) AS effective_to
    FROM (
        SELECT * FROM Grouped WHERE id IN (SELECT id FROM Grouped WHERE effective_from IS NOT NULL)
    ) inner_q
),
cte_final_v2 AS (
    SELECT gid, id, value, effective_from, effective_to FROM t_1 WHERE 1 = 1
)
SELECT * FROM cte_final_v2 ORDER BY gid;

Could you spot the errors without running through the groups one by one? The most dangerous thing about this kind of SQL isn’t its syntax, but three subtle logic errors hidden inside it. The ORDER BY clause omits the branch for handling NULL values. The SUM calculation is missing a + 1, causing gid to start from 0. The LEAD function is missing a default value. The LEAD issue directly causes the fallback value for the last group to become NULL: one row is wrong, no error is reported, and all you can do is hope for the best. The other two issues can also cause failures when boundary cases arise.

It’s not that the model isn’t accurate enough – it’s that the delivery format is wrong: it outputs the final SQL in one shot, and if something goes wrong, the only option is to rewrite the prompt and regenerate the whole thing, so logical deviations naturally can’t be undone.

It is the last row where the error occurs:

The expected last row: 9 | 1 | 2023-11-18 13:00:00 | 9999-12-31 00:00:00

The actual last row: 9 | 1 | 2023-11-18 13:00:00 | NULL

We asked AI to do the one thing it should never do

AI is good at planning steps, but not at guaranteeing that the final SQL is correct.

The old paradigm was “prompt → AI → nondeterministic final SQL”: a black-box deliverable that leaves you with no choice but to ask the AI to regenerate the entire query whenever something goes wrong.

The new paradigm should be “prompt → AI → structured steps → compiler → deterministic SQL,” with every step open to validation.

AI writes the logic. A compiler writes the SQL.

With SQLazy, it takes just 5 steps

The same validity-period logic – the logic of getting each group’s start and end times, as described above – takes just five steps in SQLazy. You can inspect the intermediate table at every step.

Name	Anchor	Statement
t1	events	sort timestamp
t2		segment value; change; as gid
t3		summarize first timestamp as effective_from, first id as id; group gid, value
t4		compute ifn(effective_from[1],datetime("9999-12-31 00:00:00")) as effective_to
result		derive delete gid

Here’s what the five steps do at a glance: sort the data chronologically, automatically create a new segment whenever value changes, retrieve the first record in each segment along with the start time of the next segment, and finally remove the helper columns. You don’t need to know how to write a LAG function.
Remember the three subtle logic errors we saw earlier? In SQLazy, they have nowhere to hide. Just click on any step to inspect its intermediate result. To check whether the segmentation is correct, all you need to do is look at the gid column.

If the error is in step 2, just fix step 2. There’s no need to start over from the beginning. You can make changes with confidence because every step is visible and inspectable.
The compiler generates the SQL according to predefined rules, making the output traceable and auditable:

WITH Value AS (
    SELECT id, value, timestamp FROM events
),
Value2 AS (
    SELECT gid, id AS id, value AS value, timestamp AS effective_from
    FROM (
        SELECT id, value, timestamp,
            SUM(CASE WHEN value <> col__5 THEN 1 ELSE 0 END)
                OVER (ORDER BY CASE WHEN timestamp IS NULL THEN 1 ELSE 0 END, timestamp ASC) + 1 AS gid
        FROM (
            SELECT Value.*, LAG(value) OVER (ORDER BY CASE WHEN timestamp IS NULL THEN 1 ELSE 0 END, timestamp ASC) AS col__5
            FROM Value
        ) sub__6
    ) Value1
    GROUP BY gid
)
SELECT gid, id, value, effective_from,
    LEAD(effective_from, 1, TO_DATE('9999-12-31 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) OVER (ORDER BY gid) AS effective_to
FROM Value2
ORDER BY gid;

There’s no guesswork in this SQL. The compiler translates the five steps according to predefined rules. The same workflow always produces the same SQL, and no column names are ever made up.

For simple CRUD operations, just let AI write the SQL. Use SQLazy for more complex logic like segmentation and retrieving the first and last records in each group.

Post your suspicious-looking piece of AI-generated SQL here

What’s the most suspicious piece of AI-generated SQL you’ve ever put into production? Did it invent a nonexistent column, omit a segmentation key, or quietly get the aggregation logic wrong?

You no longer have to get stuck in the “rewrite the prompt → rerun the code → hope for the best” loop. Paste the AI-generated SQL you trust the least into the Playground, follow the same step-by-step, verifiable workflow shown above, and share your experience.

Try it online and run this example:

Link	Description
github.com/SPLWare/SQLazy/examples	Open-source example library
www.sqlazy.com/?3IT	Playground – click the link to run the example illustrated in this article

AI plans, compiler guarantees - zero hallucinations.