Most active commenters
  • rectang(4)

←back to thread

Getting AI to write good SQL

(cloud.google.com)
478 points richards | 18 comments | | HN request time: 1.281s | source | bottom
1. rectang ◴[] No.44010899[source]
> We will cover state-of-the-art [...] how we approach techniques that allows the system to offer virtually certified correct answers.

I don't need AI to generate perfect SQL, because I am never going to trust the output enough to copy/paste it — the risk of subtle semantic errors is too high, even if the code validates.

Instead, I find it helpful for AI to suggest approaches — after which I will manually craft the SQL, starting from scratch.

replies(4): >>44011204 #>>44011349 #>>44011379 #>>44011432 #
2. hosel ◴[] No.44011204[source]
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.
replies(3): >>44011259 #>>44011340 #>>44013480 #
3. rectang ◴[] No.44011259[source]
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.

4. ◴[] No.44011340[source]
5. ◴[] No.44011349[source]
6. hsbauauvhabzb ◴[] No.44011379[source]
Explain that to the average manager or junior engineer, both who don’t care about your desire to build well but not fast.
replies(2): >>44011448 #>>44011772 #
7. paulddraper ◴[] No.44011432[source]
Hopefully your trust in yourself is warranted
replies(2): >>44011729 #>>44012314 #
8. noosphr ◴[] No.44011448[source]
> 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.
replies(1): >>44011475 #
9. Closi ◴[] No.44011475{3}[source]
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.
replies(3): >>44011595 #>>44011821 #>>44014227 #
10. noosphr ◴[] No.44011595{4}[source]
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.

replies(1): >>44020014 #
11. rectang ◴[] No.44011729[source]
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.

12. rectang ◴[] No.44011772[source]
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.
13. fkyimeanit ◴[] No.44011821{4}[source]
Because the testing pipeline was generated by AI, and code-reviewed by AI, reading a PR description generated by AI.
14. auggierose ◴[] No.44012314[source]
You'd rather trust in AI than yourself?
replies(1): >>44012366 #
15. malthaus ◴[] No.44012366{3}[source]
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.

16. yahoozoo ◴[] No.44013480[source]
What is the relevance of Pydantic with SQL?
17. dns_snek ◴[] No.44014227{4}[source]
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.
18. Closi ◴[] No.44020014{5}[source]
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.