[projektfu]

The article buries the lede by waiting until the very end to talk about solutions like having the LLM write DSL code. Presumably if you feed an LLM your orders table and a question about it, you'll get an answer that you can't trust. But if you ask it to write some SQL or similar thing based on your database to get the answer and run it, you can have more confidence.

[IsTom]

Until it mishandles a NULL somewhere in a condition on does JOIN instead of a LEFT JOIN and outputs something plausibly-looking that is just plain wrong. To verify it you'll need to do the work that it would take to write it anyway.

[projektfu]

I disagree, both because LLMs can be less likely to make those errors than a lot of humans, and because it's easier for me to review and critique its code than to review my own. I can also have a basis for testing, and I can tell it to fix problems in the code rather than having it make up a new answer.

If what I am doing is summarizing data and it will likely have uncertainty as a result, I can include statistics in the specification of what I want.

I have also been impressed from time to time where Claude Code catches a mistake I would have written. For example, I asked it to create a configuration file with some names of my staff to use for a query. It then ran the query and noticed that one name I gave was not in the database, but that there was a similar name, and it recommended changing the config.

I am pessimistic about whether these tools are intelligent or will ever achieve intelligence, but where they are useful, we should use them.