Data analysis
Also called analytics, data science, statistics in practice
A model will write the query and explain the result. Neither tells you whether the number means what you think — and that was always the job.
The claim Analysis is the one skill where a confident wrong answer is invisible by construction, so the whole of learning it is building the checks that make wrongness visible.
In most of the skills on this page you can eventually see the failure: the interface confuses someone, the program crashes, the essay bores. An analysis that is wrong looks exactly like an analysis that is right. It has a number, a chart and a sentence, and the only way to tell is to have checked something you were not asked to check.
That is why the assistance question here is sharper than elsewhere. Gu and colleagues watched 22 analysts verify AI-generated analyses at CHI 2024 and put the problem precisely: the response can be misaligned with your intent, or seemingly correct and lead to a wrong conclusion. Verification behaviour varied enormously with the analyst's own background — which is another way of saying that the tool is safest for the people who least needed it.
The productivity evidence is genuinely good and it is about the mechanical layer. Writing the SQL, reshaping the frame, plotting the thing, remembering the syntax of a window function — that work compresses hugely, and Brynjolfsson's support-agent study is the general shape of what happens next: a 14% average gain, 34% for novices, near zero for experts, because the model is transmitting known practice rather than creating new judgement.
The judgement it cannot transmit is domain-shaped. Where did this data come from, who was excluded from it, what does this column actually record as opposed to what it is named, which comparison is confounded, what would this look like if my hypothesis were false. Nothing in the output tells you which of those questions was skipped, and a fluent explanation of a wrong query reads exactly like a fluent explanation of a right one.
So the practice below is built around one habit that predates all of this and is now the whole game: predict before you look. Write down what you expect the number to be and why. An analysis you predicted correctly taught you nothing you did not know; an analysis that surprises you is either a finding or a bug, and going to find out which is the entire skill.
What actually changed
-
WasLearning the tool — SQL, pandas, ggplot — was a real fraction of learning the craft.
NowThe syntax layer is nearly free, which is a genuine gift, and it removes the slow apprenticeship during which people used to absorb what the data meant.
-
WasA wrong query usually errored, or returned something visibly absurd.
NowIt returns a plausible number attached to a fluent explanation of why that number makes sense — the two failure signals you used to rely on, both muted at once.
-
WasYou knew your data because you had spent three days cleaning it by hand.
NowCleaning is generated in a minute, so provenance has to be learned deliberately: read the source, count the nulls, ask who is missing.
-
WasCharts took long enough that you made few of them and thought about each.
NowYou can make forty, which makes the discipline of deciding what you were asking BEFORE plotting it more valuable, not less.
The path
In order. Each stage names what the model may and may not do while you are in it — that rule is the difference between the two arms of every study at the bottom of this page.
-
1 Ask a question that could be answered wrongly
Learn to state an analysis as a claim with a shape, before touching data.
- Write the question, the number that would answer it, and what you expect that number to be, in advance.
- Say what would change if you were wrong. An analysis nobody would act on differently either way is a chart, not an answer.
- Define the metric in one sentence a stranger could implement. Most disputes about numbers are disputes about definitions.
What AI may do here It may sharpen the wording. It may not choose the question — the question encodes what you care about, and the model has no stake in your decision.
You are done when Someone else can read your question and metric definition and produce the same number independently.
-
2 Meet the data before you model it
Build the habit that catches most real errors: knowing what the rows are and who is missing.
- Count rows, nulls, duplicates and date ranges before anything else. Every time.
- Find out how each column is produced. A field named active means whatever the system that writes it means, and it usually means something surprising.
- Plot the raw distribution before any aggregate. Means hide bimodality, outliers and dead sensors with equal enthusiasm.
- Ask who is not in this dataset — the churned, the unlogged, the bots, the people whose consent banner blocked the beacon.
What AI may do here Let it write the profiling code; read the output yourself, line by line. The summary of the summary is where the surprise gets smoothed away, and the surprise was the point.
You are done when You can describe your dataset's shape, gaps and biases from memory, and name one group it systematically misses.
-
3 Learn the statistics that change decisions
Acquire the small set of ideas that separate a real finding from a confident coincidence.
- Variation and uncertainty first: what an interval means, what it does not, and why a difference between two noisy numbers is usually nothing.
- Confounding and selection: the reason your best-converting channel looks best and the reason that may be an artefact.
- Base rates, and what a small percentage of a large denominator does to your intuition.
- Run one real experiment end to end — hypothesis, sample size decided in advance, analysis written before the data arrives.
What AI may do here Excellent at explaining a concept and at doing the arithmetic once you have specified the design. Do not let it choose the test: the model will produce a defensible-sounding choice, and the assumptions it silently made are the analysis.
You are done when You have killed one of your own findings by checking it — a difference that turned out to be noise, or a comparison that was confounded.
-
4 Communicate it so it survives contact with a decision
Turn a correct analysis into something someone acts on without misreading it.
- One chart, one claim. Label the window the number covers, not just the metric.
- Say the uncertainty out loud, in the sentence, not in a footnote.
- Write the version for the person who will only read the first line.
- Keep the analysis reproducible — a script and a query someone else can rerun in six months.
What AI may do here It can draft the summary and critique your chart. Read every sentence it writes about your data against your own numbers: it will confidently round, generalise and smooth in ways that are wrong in exactly the direction that sounds better.
You are done when A decision was made from your analysis, and the person who made it could state the caveat correctly afterwards.
-
5 Automate, with the checks in the pipeline
Get the speed of generated analysis without inheriting its silence.
- Turn your manual checks into assertions that run every time — row counts, ranges, null rates, totals that must reconcile.
- Version the metric definitions where the queries can see them, so two dashboards cannot disagree.
- Ask the model for the analysis and for the check separately, and write the check first.
- Re-derive one important number by a different method occasionally. Two roads to the same number is the cheapest audit there is.
What AI may do here Generate freely at this stage, because you now have something that fails loudly. The rule is simply that no generated analysis reaches a decision without passing a check you wrote.
You are done when A pipeline of yours has caught a real data error before a human did.
Keep these unaided
The gap between what you can do with the tool and what you can do without it is the only honest measure of whether you learned anything. Check it occasionally, on purpose.
- Sanity-check a number's order of magnitude against something you already know.
- Spot a selection or survivorship problem in how a dataset was collected.
- Write the SQL for a metric you defined, without help, at least well enough to check someone else's.
- Say what an interval or a p-value does and does not claim.
- Explain why a chart is misleading — axis, denominator, window, or missing group.
Where the model genuinely helps you learn
- Writing the query, the reshape and the plot once you have decided what you are asking — the compression here is large and costs you nothing you needed.
- Explaining an unfamiliar statistical method with your own data in front of you, which is far better than a textbook example.
- Generating the checks: ask what would have to be true for this result to be an artefact, then go and test each one yourself.
- Producing the alternative explanation you are too invested to see.
- Turning your finished analysis into the three versions different audiences need, which you then verify against your own numbers.
Traps
- Answering the question you were given rather than the question behind it. The model will not notice, because it cannot see the decision.
- Fluent explanations of wrong numbers. Gu's participants found this the hard case: output that is seemingly correct and leads to an incorrect conclusion.
- Skipping data provenance because cleaning was instant. The three days of cleaning were also three days of learning what the data was.
- Verification theatre — rerunning the code and getting the same answer, which tests reproducibility and not correctness.
- Automating a metric before its definition is stable, which produces two dashboards that disagree and a meeting about which is lying.
- Believing your own confidence. Assisted work feels more finished than unassisted work at the same level of correctness, which is the general finding across every study on this page.
What counts as proof now
The artefact stopped being evidence — anyone can generate one. These are the things that still say something about you.
- An analysis where you predicted the answer in advance, were wrong, and found out why.
- A finding of your own that you killed by checking it.
- A reproducible pipeline with assertions that have actually fired.
- A decision someone made from your work, with the caveat they repeated back correctly.
Where to learn it
Courses
- Kaggle Learn Free
Short free hands-on modules in Python, SQL, pandas and visualisation. Good for mechanics; competition-shaped, so it teaches modelling on clean data rather than deciding what is worth measuring.
- Statistical Rethinking Free tier
Lectures and materials free, book paid. The best available course on thinking causally rather than pushing tests — it will change how you read every study you see. Demanding, and worth it.
- Calling Bullshit Free
A free university course on spotting misleading data claims — selection effects, misleading axes, dubious causality. The fastest way to build the reflex that catches your own errors as well as other people's.
Books
-
Free online, and the best structured introduction to the actual workflow — import, tidy, transform, visualise, communicate. R-specific; the habits transfer to Python unchanged.
-
Free PDF with R and Python labs. The standard bridge from statistics into modelling for people who are not going to do a PhD in it.
-
What actually goes wrong in A/B testing at scale, from the people who ran it at Microsoft, Google and Airbnb. Read it before you trust your first experiment result, not after.
Papers
-
A study of how 22 analysts actually check AI-generated analysis. Read it as a catalogue of verification moves to steal, and of the ones people skip.
The evidence
What each source measured, and what kind of source it is. A practitioner study and a randomised trial are both worth reading and are not the same claim.
- Gu et al. (2024), CHI Peer-reviewed
Qualitative study of 22 analysts verifying AI-assisted analyses: responses can be misaligned with intent or seemingly correct while leading to incorrect conclusions, and verification behaviour depended heavily on the analyst's own programming and analysis background.
-
5,179 support agents: 14% average productivity gain, 34% for novices, near zero for experts — the model spreads existing best practice rather than creating new judgement, which is exactly the part of analysis that is scarce.
- Dell'Acqua et al. (2023/2025), Organization Science Peer-reviewed
758 consultants: better and faster work inside the model's capability, and 19 percentage points worse than unaided colleagues on a task just outside it — a business-analysis task, which is the closest thing in the literature to this job.
- Noy and Zhang (2023), Science Peer-reviewed
Professional writing tasks, with data analysts among the 453 participants: 40% less time and 18% higher graded quality, concentrated among the weaker performers.
The learning science underneath
None of the advice above is original to this skill. It is the general findings on how humans learn, applied to one job — and each of these pages sets out the evidence for the principle itself.