The honest case is not that AI cannot do the work. It is that AI produces confident output nobody has checked, and the ability to check it is precisely what people mean by fundamentals. The job that disappears is running the report. The job that remains is owning whether the number is right.
The argument on this page is about skills, and skills travel. The labour-market caveats we quote are specific to British Columbia, and if you are reading from outside Canada you should treat the market observations as illustrative rather than as evidence about your own market — we have not studied yours and will not imply otherwise.
The strongest version of the argument against us
Let us start where a course marketing page normally will not. A large part of what junior analysts have historically been paid to do is produce routine reports on a schedule. That work is genuinely, materially exposed to automation — and it is exposed to the same class of tooling we teach people to use.
We publish that on our own roles page, attached to the role it most affects, rather than tucking it into a footnote:
Routine report production is the work most exposed to automation, including by the same AI tooling we teach. We think that argues for learning to build the pipeline rather than to run the report — but you should weigh it.
Source: Roles & market dataIf you were looking for a reason to be sceptical of anyone selling analytics training right now, that is the reason, and we would rather hand it to you than have you find it later and wonder what else we left out.
And "prompt engineer" is not the escape hatch
The usual response to that threat is to pivot: if the tool is doing the work, become the person who operates the tool. That has produced an enormous amount of content encouraging people to train for a specific job title. Here is our position on it, published as one of our five role families:
Directing, prompting and auditing AI tooling as part of an ordinary analyst or developer job — the thesis the Foundation track is built around.
The counter-case: We are NOT going to tell you "Prompt Engineer" is a job you can apply for. Our research found it is not a meaningful standalone hiring title in this market — prompt and retrieval literacy shows up as a SKILL inside ordinary engineering and analyst postings. We also could not establish how often it is a stated requirement, so we cannot tell you whether this is a differentiator or merely table stakes.
Source: Roles & market dataNotice the second half of that, because it is the part we like least. We could not establish how often this literacy is a stated requirement, which means we cannot tell you whether it is a real differentiator or simply table stakes. Here is the fuller version of that gap:
Whether AI, prompt or RAG literacy appears as a stated requirement in ordinary analyst and developer postings, and how often. We found it absorbed into other roles rather than posted as its own, but we could not establish a rate.
Source: Roles & market dataWe are not going to describe a job title as an emerging career when we could not verify that employers are hiring for it under that name. Treating a skill as a destination is how people end up with training that does not map onto any requisition anyone is writing.
What the tool cannot do without you
So if routine reporting is exposed, and the tool-operator title is not a job, what is left? The answer is unglamorous and, we think, correct: the tool produces output, and someone has to be accountable for whether that output is true.
That is not an abstraction. It is a specific, teachable set of claims a person can defend under questioning. These are the ones our students are expected to be able to make after the first week of writing Python — verbatim from our own syllabus, not written for this article:
- I can explain what a virtual environment is and why professionals use one — I set mine up from scratch this week.
- I understand Python data types and how functions return values, and I can trace through a short script mentally without running it.
- I read the traceback before Googling or asking AI — I can diagnose a TypeError or FileNotFoundError from its last line in under a minute.
- I process CSVs with the standard-library csv module into a list of dicts, and I reconcile a total two independent ways before I report it.
- The first thing I do with a new export is audit it. On a 312-row order file I found 12 duplicated orders inflating revenue by about 3.9%, four amounts that would not parse, and eight delivered orders with no ship date — I can tell you the number I reported and what I excluded to get it.
Read the last one again. Using AI to move faster is not the thing under examination. Testing every line before committing is. And here is the same discipline applied to SQL, where the failure mode is subtler because a wrong query returns a confident, well-formatted, entirely incorrect number:
- I can read a schema diagram and tell you, from the keys alone, how customers, orders, and products relate before writing a single query.
- I build queries in layers — SELECT, then WHERE, then GROUP BY — and I run each layer so I know exactly which clause produced the number I am reporting.
- I know the difference between INNER and LEFT JOIN and can show you a case where choosing the wrong one silently drops or duplicates rows.
- I can find customers with no orders using a LEFT JOIN anti-join, and I can explain why the status filter has to live in the ON clause, not WHERE.
- I use AI to draft and explain queries, but I verify every column against the real schema and can defend each clause aloud before I trust the result.
And in a debugging context, where the temptation to accept a plausible-looking patch is strongest:
- I approach a broken repo with an inspect-first loop: reproduce the failure, capture the error signature, and identify the affected files before I change a line.
- I can state the difference between an environment problem and a logic problem, and I check the runtime and dependencies before rewriting code when failures look broad or non-deterministic.
- I keep my fixes as small, targeted patches and re-run the smallest meaningful test after each one, then the full suite, to confirm I have not introduced a regression.
- I direct Claude Code with real context — the failing test, the stack trace, and file snippets — and I reject any patch I cannot explain aloud, because I own the diff, not the model.
The fundamentals that actually hold
What those claims have in common is that none of them is about producing output. Every one is about being able to reject a confident wrong answer. That is the reframe we would offer:
They are not what let you write the query. The model writes the query. They are what let you look at the query and know it is wrong — that the join will silently duplicate rows, that the filter is in the wrong clause, that the answer is in a different SQL dialect than the database you are pointed at, that the total does not reconcile against a second method.
Which is why the specific things worth learning are the ones that look unfashionably basic:
- Reading a traceback to its last line before you paste it anywhere.
- Knowing what an inner join does to rows that do not match, and what a left join does instead — and being able to demonstrate it rather than recite it.
- Knowing why a filter belongs in the join condition rather than the where clause, and what breaks when it does not.
- Reconciling a total two independent ways before you report it to anyone.
- Recognising when the answer you were handed belongs to a different database engine than the one you are querying.
None of that is exotic. All of it is what separates someone who can be trusted with a number from someone who is forwarding a model's guess with their own name on it.
What we could not verify
Two limits on the above, published for the same reason we published the argument against ourselves. First, the one our own business rests on:
Whether employers accept a portfolio of shipped projects in place of a degree. We found no evidence in either direction. This is the claim our own programs rest on, and we are not going to assert it without support.
Source: Roles & market dataWe believe proof of work matters more than paper. We have not proven it, we could not find anyone who has proven it either way, and we would rather say so than let you assume the question is settled because a school with an interest in the answer told you it was.
Which tools Metro Vancouver employers actually ask for in entry-level postings, and at what frequency. Answering this needs a coded sample of posting bodies, which occupational statistics cannot substitute for. We have not done that study, so we publish no tooling-frequency figures.
Source: Roles & market dataSo what do you actually do
- Use the tools. Refusing them is not a principled stand, it is just slower.
- Learn the layer that lets you audit what they produce — that is the durable part.
- Build at least one artifact where you can name, specifically, something the model got wrong and how you caught it.
- Practise saying it out loud, because in an interview you will be asked, and "I used AI" is not an answer.
That last point is increasingly literal: how you work with these tools is now its own line of questioning. We covered what a good answer sounds like in how data-analyst interviews have changed. And if you are still deciding which roles to aim at in the first place, start with how to become a data analyst.
We could not establish how often AI literacy is actually a stated requirement in ordinary postings, so nothing here quantifies its value in a hiring process.
This is an argument, not a measurement. We are telling you how we read the situation and showing our reasoning; we are not claiming to have proven it.
We publish no pay figures in these guides. The sourced wage bands live on the roles and market data page.
Common questions
Will AI replace data analysts?
Should I become a prompt engineer?
Do employers actually ask how I use AI?
Is using AI on a take-home assignment cheating?
If the model writes the SQL, why learn SQL?
Try the free course — no card, no cohort
AI at Work is our free short course on directing, prompting and verifying AI on real business tasks. It is the discipline this guide argues for, and you can start it right now.
Start AI at Work — free Or see the programs