Explain that to the average manager or junior engineer, both who don’t care about your desire to build well but not fast.

It’s not true that I want to build “well but not fast” — I’m trying to add value, and both speed and reliability matter. My productivity is high and I don’t have trouble articulating why; my approach has generally (though not universally) been well received by management and colleagues.

> So now that we brought down prod for a day the new rule is no AI sql without three humans signing off on any queries.

If that’s the scenario, I would be asking why the testing pipeline didn’t catch this rather than why was the AI SQL wrong.

Because the testing pipeline was generated by AI, and code-reviewed by AI, reading a PR description generated by AI.

Because the testing pipeline isn't the real database.

Anyone that knows a database well can bring it down with a innocent looking statement that no one else will blink at.

Sure, but everyone knows humans end up bringing down the database too by writing an innocent looking test query nobody else blinks at, which is why you end up needing a testing strategy for ANY SQL before YOLO'ing into prod.

To offer a 3rd option - what testing pipeline? Incompetent managers aren't going to approve of developers "wasting their time" on writing high quality tests.

Really? In my experience it’s been pretty good (using Pydantic)! I read over before I execute it, but it’s never done anything malicious.

I don't trust myself to craft a prompt in natural language which completely specifies my intent as codified with the precision of a programming language.

I also tend to turn to AI for advising me on difficult use cases, and most of the time it's for production code rather than one-offs. The easy cases, I just write myself because it's more mental effort to review code for subtle errors than it is to write it.

What is the relevance of Pydantic with SQL?

Hopefully your trust in yourself is warranted

I embrace my fallibility, and enthusiastically pursue testing, code reviews, staging environments, and so on to minimize the mistakes that make it through to production.

It seems to me that this skeptical mindset is consonant with handling AI output with care.

You'd rather trust in AI than yourself?

in writing good sql code? i definitely would

ai is not going to replace the senior sql expert with 20 years of battle experience in the short-term but support me who last dug into sql 15 years ago and needs to get a working sql query in a project. and ai usually does a better job than me copy pasting googled code in between quickly browsing through tutorials.