In fact auto-complete in VS code with copilot works surprisingly well. Let’s say there are patterns in how classes in a framework are constructed, and I already added changes to the schema, it will often emit the correct implementation code when going there. That is really speeding me up even if I know the code base very well.
The harder part is understanding the nature of the data you're working with. There's always some catch ("oh that field `foo` was never backfilled, so for queries before 2020 you have to recompute it by joining with legacyBar instead")
> SQL is not hard enough to require an LLM to think about for you
As someone who's seen queries that are hundreds of lines long, involve a bunch of CTEs, nested SELECTs as well, upwards of a dozen joined tables with OTLT and EAV patterns all over the place (especially the kind of polymorphic links where you get "type" not "table_name" so you also need to look at the app code to understand it), I'd say that SQL can be too hard for people to reason about well.
Bonus points for having to manually keep like 5 Oracle package contents in your working memory cause that's where the other devs on the 10 year old project stored some of the logic, while the remainder is sort-of-dynamic codegen in the app.
Same as with most app code, it shouldn't be like that, but you sometimes get stuff that is really badly developed and the cognitive load (both to inherent and accidental complexity) will increase until people will just miss things and not have the full picture.
I can write that script faster than I can write the text asking the AI to write the script as SQL is concise and my IDE has auto-complete.