When ChatGPT Writes Your Stored Procedures: A DBA's Conflicted Field Notes

I've been using AI tools for SQL work.

Not because I'm a true believer. More because ignoring them feels like ignoring a slow-moving train headed directly for my platform. The hype is everywhere, and as someone who's spent years understanding why SQL Server does what it does, I have questions. Lots of them.

This post isn't a cheerful tutorial. It's field notes from someone who remains deeply skeptical -- not Luddite-skeptical, but more like I've-seen-too-many-silver-bullets-rust skeptical.

The Experiment

I've been feeding real-world SQL problems to various AI tools -- Claude, Copilot, ChatGPT, Gemini, DeepSeek -- to see what comes back. The results are interesting, at the very least, but most notable is that they are not consistent across the AIs.

Example 1: The Query That 'Works'

I asked for a stored procedure to return recent orders for a given customer, with date filtering. What I got back compiled just fine:

CREATE PROCEDURE dbo.usp_GetCustomerOrders
    @CustomerID int,
    @StartDate datetime,
    @EndDate datetime
AS
BEGIN
    SELECT OrderID, OrderDate, TotalAmount, Status
    FROM dbo.Orders
    WHERE CustomerID = @CustomerID
    AND OrderDate BETWEEN @StartDate AND @EndDate
    ORDER BY OrderDate DESC;
END;

Looks clean. Runs without errors. Ship it, right?

Except: no SET NOCOUNT ON. No consideration for parameter sniffing on a table where one customer has 50 orders and another has 50,000. No thought about whether that BETWEEN is going to play nicely with the existing indexes. No handling for NULL parameters.

This is the kind of code that works great in dev and melts your production server at 9:01AM on a Monday.

Example 2: The Index Suggestion That Made No Sense

I described a performance problem -- slow reads on a reporting query hitting a fact table. All AIs I gave this to suggested:

CREATE NONCLUSTERED INDEX IX_Orders_CustomerID_OrderDate
ON dbo.Orders (CustomerID, OrderDate)
INCLUDE (TotalAmount, Status);

Reasonable on the surface. But the actual workload filters primarily by OrderDate range first, then aggregates across all customers. The suggested index would be nearly useless for the dominant query pattern. Any human who spent five minutes with the actual execution plan would never have suggested this.

Example 3: The Legitimate Win

I asked for a quick script to identify tables with identity columns approaching their max values. In about 30 seconds, I had working code that would have taken me 15-20 minutes to write and test:

SELECT 
    SCHEMA_NAME(t.schema_id) AS SchemaName,
    t.name AS TableName,
    c.name AS ColumnName,
    ty.name AS DataType,
    IDENT_CURRENT(SCHEMA_NAME(t.schema_id) + '.' + t.name) AS CurrentIdentity,
    CASE ty.name
        WHEN 'int' THEN 2147483647
        WHEN 'bigint' THEN 9223372036854775807
        WHEN 'smallint' THEN 32767
        WHEN 'tinyint' THEN 255
    END AS MaxValue,
    CAST(IDENT_CURRENT(SCHEMA_NAME(t.schema_id) + '.' + t.name) * 100.0 / 
        CASE ty.name
            WHEN 'int' THEN 2147483647
            WHEN 'bigint' THEN 9223372036854775807
            WHEN 'smallint' THEN 32767
            WHEN 'tinyint' THEN 255
        END AS DECIMAL(5,2)) AS PercentUsed
FROM sys.tables t INNER JOIN sys.columns c 
  ON t.object_id = c.object_id INNER JOIN sys.types ty 
    ON c.user_type_id = ty.user_type_id
WHERE c.is_identity = 1
ORDER BY PercentUsed DESC;

Did I validate it? Yes. Did it save me time? Also yes.

What This Tells Us

AI-generated SQL is a first draft from a very fast, very confident intern who has read a lot of Stack Overflow, but has never been paged at 2AM when a query plan went sideways.

AI knows syntax. It knows patterns. It does not know your data distribution, your workload, or the way your application actually behaves under load.

Which brings me to the bigger concern.

The Part That Keeps Me Awake at Night

AI isn't just coming for stored procedures. It's coming for the apprenticeship model. For the slow accumulation of hard-won knowledge that separates a senior DBA from someone who can write syntactically correct SQL.

I learned parameter sniffing by debugging a production outage that ruined my weekend. I learned about tempdb contention by watching a server grind to a halt and not understanding why until I dug into wait stats for hours. I learned to read execution plans because nothing else would explain why the same query ran in 200ms on Tuesday and 45 seconds on Wednesday.

What happens when junior DBAs skip that pain? When they trust the AI output because it compiled and simply looked right?

I wrote recently about Intelligent Query Processing guard rails -- how SQL Server's own 'smart' features will silently disable themselves when they detect that they're making performance worse. The optimizer has regression guards. It monitors its own decisions and backs off when they fail.

Can AI coding tools do the same? When ChatGPT suggests a query that causes blocking chains or tempdb spills, does it learn? Does it warn you? Does it even know?

No. It generates. You validate. Or you don't, and you find out later that you should have.

The Societal Layer

I try to keep this blog focused on SQL Server, but it's impossible to talk about AI in our field without acknowledging the broader wave.

AI is being embedded into everything -- hiring decisions, medical diagnoses, financial analysis, content moderation, legal research and so much more. The same confidence that produces plausible-but-wrong tSQL is producing plausible-but-wrong conclusions in domains where the stakes are MUCH higher than a slow report.

And most people using these tools have even less ability to validate the output than we do.

At least when AI suggests a bad index, I can look at the execution plan and prove that it is wrong. When an AI summarizes a legal contract or flags a medical scan, who's checking? The patient who never saw the contract? The radiologist who now bills for twice as many scans because it lets AI do the easy ones? Or the doctor that never even opened the folder sent by radiology to view the scans because the AI didn't stamp it with 'REVIEW'.

I don't have answers. I just notice that the same pattern I see in AI-generated SQL -- confident, plausible, frequently wrong in ways that require expertise to detect -- is showing up everywhere. And the pressure to adopt these tools is immense, regardless of whether we're ready.

Reluctant Advice for Data Professionals

Here's how I'm approaching AI tools in my own work, for whatever it's worth:

1. Use them as a first draft, never a final answer.
AI is good at boilerplate and scaffolding. It's not good at understanding your specific constraints. Generate, then validate. Every time. That is my approach.

2. Never deploy AI-generated code without running it against real data.
Never. Not sample data. Not 'representative' data. Your actual production data distribution. The thing that makes queries slow is usually the thing that makes your data different from the textbook examples.

3. Keep learning the fundamentals.
Execution plans. Wait stats. Index internals. Parameter sniffing. Lock escalation. AI can't debug what it doesn't understand, and neither can you if you outsource your learning of these critical points to AI.

4. Be especially skeptical of 'optimization' suggestions.
Anyone can write a query that returns correct results. But what about writing a query that returns correct results efficiently, at scale, under concurrency -- that's the hard part, and this is exactly where AI tools are weakest, because they can't see what you're actually running against.

5. Document what the AI gave you and what you changed.
Future you (or the next person who manages your code) will want to know which parts were human-validated and which parts were machine-generated hopium. Code comments = good tactic.

Where I Land

I'm not swearing off AI tools. That would be like swearing off power tools because I cut myself with a table saw. The AI tools can be useful. They could save substantial time. Sometimes they may even surface an approach that I wouldn't have thought of.

But I'm also not going to pretend that 'AI wrote my stored procedure' is anything other than a liability statement. The tool doesn't understand your system. It doesn't feel the weight of 3AM pages. It doesn't learn from the outages it causes. Very simply, it does not have common sense.

You do. That's still your job.

There is much speculation, but I don't believe that any of us can really know exactly where this is going yet. The technology is improving fast, and the pressure to adopt is only increasing. But I know that understanding why the query runs the way it does still matters -- maybe more than ever, because when the AI is wrong, someone has to catch it.

And right now, that someone is still us.

More to read

• sqlfingers: Regression Guards — When SQL Server Silently DISABLES Features
• Brent Ozar: Using ChatGPT for T-SQL Code Reviews
• The Risks and Realities of LLM-Generated SQL Content
• Microsoft: Intelligent Query Processing