The models got good at writing SQL before most analysts got good at reading it.
That's not a knock on analysts. It's a sequencing problem. The conventional path to SQL was always about production: learn to write queries, run them, get output. The benchmark was a result set, not comprehension. Reading other people's SQL — tracing logic you didn't write, catching an assumption buried in a subquery — was never really a tested skill. You were the one writing it. When would you need to read it?
Then the models arrived, and they could produce working SQL in seconds. Fluent, formatted, multi-join queries with CTEs and window functions and everything. Analysts who barely knew a SELECT from a GROUP BY were suddenly shipping queries. Everyone looked more capable. The output ran. The dashboards loaded.
Running isn't the same as right.
A generated query that executes without errors has passed exactly one test. It hasn't been checked for correctness on your data — because the model doesn't know your data. It doesn't know that your revenue column double-counts refunds. It doesn't know that the join you asked for is one-to-many and will silently inflate every number downstream. It produced something syntactically valid. Whether it's analytically valid is a separate question, and it's yours to answer.
That's the gap that actually matters right now. Not whether you can prompt a model into producing a query. Whether you can read that query cold and know what it's doing.
SQL literacy in this sense means tracing logic you didn't write. Start from the innermost subquery. Follow what each CTE produces. Ask what the grain of the result set is before you look at the numbers. Check whether the filter conditions make sense for your specific data. Ask yourself what happens to the NULLs, because the model almost certainly didn't.
Most people skip this step. The query ran, the number looks plausible, time to move on. That's how you ship a metric that's wrong by 30% and don't notice for six months.
The analysts who are hard to replace right now aren't the ones who can generate the most SQL. They're the ones who can audit it. That's the skill that compounds — the ability to take any query, yours or a model's or a colleague's, read it clean, and tell you exactly what it's doing and where it might be wrong.
You don't have to write faster than the model. You have to think better than it.
The model got good at writing. The job is knowing how to read.