Last Tuesday I needed a quick count of active users by signup month for the past year. I opened a chat window, typed something close to “how many users signed up each month last year, only the ones still active, from the users table,” and got back a working query in about four seconds. Ran it. Correct. Closed the window.
It felt weird. Not bad weird, just off. Like I’d asked a colleague to do something, and they’d done it slightly too fast and I couldn’t fully trust it even though it was right. That discomfort is what this piece is about.
How We Got Here
Text-to-SQL has been kicking around for years, and for most of that time it was a party trick. You’d demo it at a meetup, it’d fall apart on anything with a multi-table join and some date arithmetic, and everyone would go back to writing queries by hand. Early approaches were rule-based or seq-to-seq models. It was fine for “show me revenue by region,” broken for anything with real business complexity. The query would look plausible. It would just be wrong.
Then LLMs got good enough at code that the capability shifted. It wasn’t overnight, just steadily until one day it was useful. And then Databricks shipped natural language querying in AI/BI, Snowflake added Copilot, BigQuery got Gemini baked into the console. It stopped being a research demo and started being a thing you’d accidentally click on while doing something else.
What’s strange is how fast adoption has outpaced the profession’s ability to reckon with what changed. People are using these tools daily without any shared vocabulary for what it means for the job. That gap is worth sitting with.
What Actually Changed (and What Didn’t)
The honest version: AI writes simple SQL well. Clean schema, obvious column names, straightforward aggregations, it handles those reliably. A join between two tables where the relationship is clear from the names, a filtered aggregate with a date range, a window function for a running total. Most of the time you get back something you’d have written yourself, maybe with slightly different aliasing.
Where it breaks is anything where the meaning isn’t in the schema. Ambiguous column names are a genuine problem. If your table has a status column that means six different things depending on what pipeline last touched the row, the AI doesn’t know that. It picks an interpretation that sounds reasonable. The query runs, returns something, and if you don’t already know what you’re looking for, you won’t notice.
Business logic embedded in layered CTEs is the other rough edge. It’s not because the AI can’t read CTEs, but because that logic often reflects decisions made in a Confluence page from 2021 that nobody reads. The AI doesn’t know that revenue in the finance reporting table excludes certain enterprise contracts due to a custom billing arrangement. It’ll write the query you asked for. The query will be technically correct and semantically wrong.
So, the skill didn’t disappear. It shifted. You need to know SQL well enough to read what came back and decide if it’s doing what you needed. That’s different from writing it. It’s less mechanical, more evaluative. But it’s not nothing. Reading and verifying requires almost as much understanding as writing from scratch. In some ways more, because you’re not getting the intuition that comes from constructing something step by step.
The Part Nobody Writes About
If the AI handles routine querying, who catches the confidently wrong output? It used to be the person who’d spent two years writing bad SQL, running it, getting weird results, figuring out why, and slowly building instinct for when a number looks off. That feedback loop, write something, it breaks, understand why, is how you develop actual intuition about data.
That loop is now seriously bent for anyone starting out. If a junior analyst mostly asks AI for queries and mostly gets back things that look right and run without errors, they’re not building the same foundation. They might go months without ever having to debug a GROUP BY that grouped on the wrong thing, or a join that silently multiplied rows, or a date filter that was off by a time zone. Those failures are annoying. They’re also how you learn what to watch for.
I don’t think this means we should be banning AI tools that ship sailed, and the tools are genuinely useful. But pretending the tradeoff doesn’t exist is also wrong. Something real gets lost in how a person learns to think about data, and “you can always ask AI” is not the same as “you developed the ability to catch problems yourself.”
This probably gets worse before it gets better. The tooling gets more confident, the outputs look more polished, and the gap between “this looks right” and “this is right” gets harder to notice. The people who will be fine are the ones who spent enough time writing SQL badly before the tools got good. I don’t have a clean answer for what you do if you’re arriving now.
What Actually Matters Now
Data modeling matters more, not less. The AI queries whatever schema you hand it. If the schema is clean, well-named, and the relationships make sense, you get useful queries. If it’s a mess of ambiguous columns, redundant tables, and undocumented business logic, you get plausible-sounding garbage. The people who stay valuable are the ones who can design schemas that communicate intent clearly enough for AI tools to work with reliably.
Understanding what someone means when they say “show me revenue” has always been part of the job, but it used to be partially embedded in writing the query. Now that translation work is explicit. You need to take a vague business question and convert it into something precise enough that the AI doesn’t hallucinate an answer that merely feels right. That requires understanding both the domain and the data. It’s the hard part and it’s entirely human.
Knowing when to distrust the output is a skill you can’t shortcut. It means knowing enough SQL to look at a generated query and notice when a JOIN is doing something unexpected, when a filter is applied in the wrong place, when an aggregate is counting at the wrong grain. You don’t need to be a database expert. You need enough fluency to stay skeptical.
And the role is moving upstream regardless. More of what a data engineer does now is building the infrastructure other people query, so pipelines, data quality, modeling decisions, orchestration. The SELECT statement is increasingly the last step, and maybe not one you write at all.
What Monday Morning Actually Looks Like
Two years ago, exploring an unfamiliar table meant running a handful of queries to understand the shape of the data. What’s in this column. What are the distinct values. What does the distribution look like. Maybe twenty minutes, and by the end I had a reasonably solid mental model of what I was working with.
Now I do some of that through conversation. “What does this table contain, what are the key columns, give me a sample of the status column.” It’s faster, and for a first pass it’s fine. But I’ve noticed I’m less likely to stumble across something unexpected, because I’m asking specific questions instead of poking around. Unfortunately, accidental discovery, so finding something weird in the data that you weren’t looking for happens less now. Most days that’s fine. Occasionally it’s a real miss.
The queries I still write by hand are the ones where I’m not confident the AI knows what I mean, or where the stakes are high enough that I want to understand every line before it runs. Anything going into a production pipeline. Anything touching financial figures. Anything where I need to explain the methodology to someone else. For those I write it myself, then sometimes ask AI to review it.
Where This Lands
Nobody knows what the data engineering skillset looks like in three years. The tooling is moving fast enough that confident predictions are mostly just guesswork in a good suit.
But “I know SQL” has never been really the point. It was a proxy for something else. It’s the ability to translate a question about the world into a precise operation on data, and to know when the answer you got back is trustworthy. That underlying thing hasn’t changed. It’s just less visible now, because the syntax isn’t the bottleneck anymore.
