This is interesting. Funnily enough this is something that we also built in the tool I'm building called nao, which is a data editor for data teams. Because most of the SQL parsers aren't fault tolerant we had to develop our own fault-tolerant parser.

I really think what you showcase in the start of the article is the best thing, being able to statically highlight error in a text form for a user (or for a LLM) to iterate on the fixes is the best thing.

How many AIs do you want in your domain?

Yes

This is really interesting — I’ve been working on something in a similar space called DB Pro (https://dbpro.app), a modern desktop database workbench.

We ran into the same challenge with SQL parsing and validation early on. Most open-source parsers tend to either choke on dialect quirks or fail silently when dealing with incomplete queries, which makes proper linting or fault tolerance a nightmare. For DB Pro, I ended up writing a lightweight validation layer on top of the parser that can recover gracefully and still provide syntax hints or AI-assisted corrections.

The LLM side gets especially tricky when you want to offer reliable query generation but still ensure correctness and safety. That’s why DB Pro lets users optionally download and run a local model for SQL assistance — so everything stays on the machine and we can still iterate safely without sending any data to the cloud.

Curious how you approached error recovery — did you build your parser from scratch or extend an existing one? And do you plan to release it as a standalone library?