Text-to-SQL lets anyone type a question and get a query; AI dashboard tools spin up charts on demand. So the mechanical half of analysis — writing SQL, building basic dashboards, pulling numbers — is getting cheap. What stays, and grows, is the thinking half: asking the right question, judging whether the data can be trusted, interpreting a result in business context, and defining what the metrics even mean so the self-serve answers are correct. This handbook is the practical path — what gets automated, what becomes valuable, and the strongest pivot, analytics engineering, the layer that AI querying makes more important, not less.
~15 min readanalysts & BI5 movespivot to analytics engineering
Written by an engineer, honest about a role under pressure from AI querying — not career-placement advice or a market promise. The aim is where to point your skills, and where they transfer.
01
What gets automated, what becomes valuable
The clean way to read it: AI automates producing a number and leaves you knowing which number to ask for, whether to trust it, and what it means. A confident wrong answer is now cheap to generate — catching it is the job. Move toward the right column.
Getting automated (AI does it)
Getting valuable (own this)
Writing SQL from a question (text-to-SQL)
Framing the right question from a vague business need
Building basic charts and dashboards
Judging data quality — is this number trustworthy?
Pulling standard metrics and routine reports
Statistical judgment — sample validity, correlation vs causation
Formatting and summarizing results
Interpreting results in business context and driving a decision
Looking up how to compute something
Defining what a metric means (the semantic layer)
—
Modeling and testing trustworthy data (analytics engineering)
Text-to-SQL is only as good as the warehouse and the metric definitions underneath it — which is exactly the layer you can own. The role moves from producing queries to governing meaning and supplying judgment.
02
The new analyst stack — and the pivot
Level up by owning meaning and judgment, and set up the analytics-engineering pivot that AI querying makes more valuable.
1 — Own what the numbers mean (the semantic layer)
A text-to-SQL query over an ambiguous schema returns a confident number that may be the wrong metric entirely — “revenue” recognized or booked, net of refunds, in which timezone and fiscal calendar? The high-value work is defining each metric once, correctly, in a governed semantic layer so that self-serve and AI querying stay right. You are best placed to do this, because you know both the data and the questions. Owning the definitions makes every AI answer trustworthy — or exposes when it is not.
2 — Supply the judgment AI can't: trust, stats, interpretation
The analysis was never the SQL. It is knowing whether the data can be trusted, whether a sample generalizes, whether a correlation is causal, and what a result actually means for the business — and communicating that so it changes a decision. Those are exactly what a text-to-SQL tool skips, and they get more valuable as raw numbers get cheap. Invest in statistical literacy, data-quality instincts, and the storytelling that turns a chart into a decision.
3 — Pivot to analytics engineering, the escape hatch
The strongest concrete step up is analytics engineering — the modeling, testing, and transformation layer (dbt-style) that turns raw warehouse data into clean, tested, documented tables and defined metrics. It is the most natural pivot for an analyst because you already know the data and the business, and you add version-controlled transformations, data tests, and metric governance. It is durable, in demand, and it is precisely the layer AI querying makes more important, since a self-serve answer is only as trustworthy as the model beneath it.
03
Five moves you can start this week
Each builds value now and toward the pivot. The verify line is where your judgment lives.
1 · Define one metric properly, once
Turn an ambiguous metric into a governed definition:
Take a metric everyone reports differently (e.g. "active user" or "revenue"). Write the single correct definition — the exact logic, the edge cases (refunds, timezones, filters), and the grain — and document it so self-serve and text-to-SQL compute it the same way every time.
You own: the meaning the AI cannot infer — the semantic-layer work that makes every downstream answer trustworthy, and the core of analytics engineering.
2 · Stress-test a text-to-SQL answer
Verify before you trust the confident number:
Take an AI-generated query and answer and check it: does "revenue" mean what the stakeholder thinks, is the join grain right (does it double-count?), is the date filter and timezone correct, and does the number reconcile with a known-correct figure? Note where it is subtly wrong.
You own: catching the confident-wrong answer — a generated query that runs can still be answering the wrong question, and that judgment is the analysis.
3 · Turn a result into a decision
Practice the interpretation and communication AI can't:
Take a finding and write the one-paragraph "so what": what it means for the business, how confident we should be, what could confound it, and what decision it argues for. Lead with the insight, not the chart.
You own: the judgment and communication that turn a number into an action — the part of the job that is entirely human and drives your value.
Take the first concrete step toward analytics engineering:
Model one messy source into a clean, tested, documented table using a transformation tool (dbt-style): the SQL model, a couple of data tests (uniqueness, not-null, freshness), and a description. This is the analytics-engineering craft on top of the SQL you already know.
You own: the shift from querying to producing trustworthy data — the pivot skill that is in demand and that AI querying depends on.
5 · Sharpen statistical and data-quality judgment
Deepen the reasoning AI reliably gets wrong:
On a real analysis, deliberately ask: is this sample representative, is this difference significant or noise, is this correlation plausibly causal, and what data-quality issue could be faking this result? Write down the caveats you'd stake your name on.
You own: the statistical and quality judgment that separates real insight from a plausible-looking artifact — exactly where confident AI output goes wrong.
04
The judgment exercise: spot the danger
Three moments where the analyst, not the tool, decides.
1. Text-to-SQL answers "what was revenue last month?" with a clean number the exec loves. Report it?
The AI produced syntactically correct SQL over an under-defined concept. “Revenue” could mean several things and “last month” depends on the calendar and timezone, so the number is confident and possibly wrong. Verifying the definition — and ideally governing it in a semantic layer so it can’t be ambiguous — is exactly the analyst judgment that survives, not the query itself.
2. AI finds that users who use Feature X churn less, and suggests pushing everyone to Feature X. Recommend it?
A classic trap AI will happily walk into: a strong correlation presented as an action. Engaged users likely both adopt Feature X and stick around, so the feature may be a symptom of engagement, not a cause of retention. Distinguishing correlation from causation — and calling for an experiment — is human statistical judgment the tool does not supply, and getting it wrong wastes real effort.
3. Worried self-serve BI and text-to-SQL make your role redundant. Best career move?
Racing the AI at SQL is a losing game. The winning move is up the stack: own what the numbers mean, supply the interpretation and judgment AI can’t, and pivot into analytics engineering — the modeling and metric-governance layer that makes self-serve and text-to-SQL trustworthy. That layer gets more valuable as querying is automated, not less.
05
Your role in three years — and a plan
In three years, routine querying and dashboarding are largely self-serve, and strong analysts have moved into owning metrics and interpretation or pivoted into analytics engineering. A concrete start toward either:
Weeks
Do this
Why
1–3
Define one contested metric properly and document it; stress-test a text-to-SQL answer against it
Owning meaning makes AI answers trustworthy — your moat
4–6
Practice turning findings into decisions (the one-paragraph "so what") and stating caveats you'd stake your name on
Interpretation and communication are entirely human value
7–9
Model one messy source into a clean, tested table with a transformation tool
The first real step into analytics engineering
10–12
Sharpen statistical judgment (significance, causation, sampling) on a real analysis
Exactly where confident AI output goes wrong — and you catch it
The through-line: let AI write the SQL, and get deeper in the meaning, the judgment, and the trustworthy-data layer it cannot own. Analytics engineering is the most natural, durable destination — and it builds directly on what you already know. See the AI-Era Data Engineer for the adjacent data-side view.
06
Quick answers
Will AI replace data analysts?
It automates writing SQL and basic dashboards, not asking the right question, judging trust, interpreting results, or defining what metrics mean. Those get more valuable as raw numbers get cheap.
Does text-to-SQL make the job obsolete?
No — it makes querying self-serve while raising the value of the semantic layer and the judgment that make a query trustworthy. A text-to-SQL answer is only as good as the model underneath.
What should I pivot into?
Analytics engineering — the modeling, testing, and metric-governance layer (dbt-style) that produces trustworthy data. It builds on your analyst skills, is in demand, and AI querying makes it more important.
Where should I start?
Move 1 — define one contested metric properly and document it, then check a text-to-SQL answer against it. Immediately useful, and it is the core of the semantic-layer work.