You do not need the maths

An engineer tells me he has decided to get serious about AI. He has a plan, and the plan has an order to it. Linear algebra first, then calculus, then probability, and building things only once the foundations are properly in place.

I have never once talked anybody out of this plan. It sounds like discipline. It sounds like the opposite of the people chasing prompt tips, and the person proposing it is usually the most conscientious person in the conversation.

Four months later there are two endings. Either he gave up somewhere in the middle and quietly concluded the field was not for him, or he finished, opened a terminal, and found that nothing he had learned told him how to split a document into chunks.

I do two jobs that sound like one. I help organisations get their engineers building with this technology, and I work on the machine learning end of it. So I have the maths. I did the four months and a good deal more, and I use it in one half of my working life and almost never in the other. That is the only reason this post is worth writing. It is easy to tell somebody they do not need the hard thing when you have not done the hard thing.

What the four months actually buys

Take the syllabus seriously, because the books are serious. The standard route is Mathematics for Machine Learning by Deisenroth, Faisal and Ong. Part I is linear algebra, analytic geometry, matrix decompositions, vector calculus, probability and distribution, and continuous optimisation. The Goodfellow, Bengio and Courville Deep Learning book opens with linear algebra, probability and information theory, and numerical computation.

Both are excellent and neither is misleading you. Deisenroth and his co-authors say plainly what the book is for: they are not covering advanced machine learning techniques, they aim "to provide the necessary mathematical skills to read those other books". That is an honest description of a prerequisite, and what it is a prerequisite for is reading research papers.

Now hold that against a week of Layer 2 work. How should this document be split so that retrieval finds the right piece. When the answer is wrong, was it retrieval that missed or the model that invented. What is this agent allowed to do on its own, and what should it stop and ask a human about first. What happens when the third tool call times out and the first two already changed something. Did last night's prompt change make the answers worse, and how would anybody know.

Not one of those questions is addressed by any chapter in Part I of either book. They are questions about information design, failure handling, permissions and measurement. Vector calculus has nothing to say about them, and that is not a failing of vector calculus.

The maths is not too hard. It is about a different object. It describes what happens inside the model during training. The work at Layer 2 happens outside the model, at runtime, in the space between a user and an API call. Those two worlds touch at exactly one point, which is that one produces the thing the other consumes.

So four months buys a genuine, permanent, transferable education, and a correct answer to a question the engineer was not asking. What it costs is worse than the time. It filters. It does not filter out people who were never going to be any good at this. It filters out the people who believed the prerequisites were real prerequisites, which is the same instinct that makes somebody good at building software carefully.

What the adverts actually ask for

I did not want to assert this, so I counted.

I took the two most recent Ask HN: Who is hiring? threads I had to hand, June and July 2026, and pulled every top-level posting: 575 of them with enough text to read. Of those, 231 mention large language models, agents, retrieval, fine-tuning, embeddings or machine learning in some form. Call that the AI hiring market as it appears in one busy place.

Three of those 231 contain any mathematical word at all, and mentioning is all any of them does. One wants "mathematical maturity in formal systems" and names type theory and proof assistants, which is a different discipline entirely. Another mentions productionising statistical workflows alongside data pipelines. The third is a candidate advertising himself rather than a job.

Across 231 postings for work with these models, essentially nobody asked for linear algebra or calculus.

What they asked for instead was TypeScript, JavaScript, React or Next in 94 of them, and Python in 75. Postgres or SQL turned up in 60, a cloud platform in 49, evals in 32 and retrieval-augmented generation in 15. That is a web engineering job market with a model in it.

One posting, from a small Dublin company hiring its first engineer to build a WhatsApp agent, put the whole argument in five words: "ML hobbyist > ML PhD for this role."

Be careful with my numbers, because I would be careful with somebody else's. This is a single forum that skews heavily towards startups and small companies, the postings are short prose blurbs and not formal requirement documents, and I classified them with a regular expression instead of reading all 575. Frontier labs mostly do not recruit there. Absence of a word in a blurb is weaker evidence than absence from a specification. What I would defend is the direction and the size of the gap, not the third decimal place.

There is a second piece of evidence that needs no statistics. Anthropic publish a guide called Building Effective Agents, written by the people whose model you would be building on. Its section headings run through prompt chaining, routing, parallelisation, orchestrator-workers, evaluator-optimiser, tool documentation, and when not to use an agent at all. It contains no equations, because there is nothing in the job it describes that requires one.

The maths you do need, which is not nothing

I part company here with the more comfortable version of this argument. Plenty of people say you need no maths. That is not true either, and saying it sets people up to be wrong in a different direction.

Three things matter, and all three are ordinary.

The first is probability held as an instinct, not performed as a calculation. The model does not return an answer. It returns a distribution over what could come next, and something samples from it. Run the same input twice and you can get two different outputs, and neither is a malfunction. Once that lands, a lot of behaviour stops being mysterious and a lot of testing practice stops being defensible. A test you ran once told you what happened once.

Attached to that is a piece of arithmetic almost nobody does. Suppose a step in your pipeline is right ninety-five per cent of the time, which sounds respectable. Chain ten of them and you are at roughly sixty per cent. Multiplication, not mathematics, and it is most of the reason agent demos are astonishing and agent products are disappointing. Nobody multiplied.

The second is being able to read a benchmark table without being taken in by it. Evan Miller's paper for Anthropic, Adding Error Bars to Evals, makes the case that evaluations are experiments and the field has largely been reporting them as if they were scores. His recommendations are the standard toolkit: report the standard error alongside the number, cluster it when your questions come in groups, compare models on paired differences rather than separate averages, and do a power calculation so you know how many questions you needed. One finding is worth carrying around on its own. Clustered standard errors on popular evals can be over three times as large as the naive ones, which means a great many published gaps between models are smaller than the uncertainty in measuring them.

You do not need to be able to derive any of that. You need to look at two models a point and a half apart and ask how many questions were in the set and whether anyone reported a spread. That question is worth more to you than a term of linear algebra.

The third is cost, which is multiplication done in advance instead of at the end of the month. Tokens in, tokens out, times requests, times users. I have written separately about why that arithmetic is an architecture decision rather than a finance one.

All three are secondary school mathematics applied with care, which is a different thing from advanced mathematics applied at all. The skill is noticing when the arithmetic is load-bearing, and most people miss that not because the sums are hard but because nobody told them a sum was involved.

What Layer 3 genuinely requires

Now the other half, and I want to be specific instead of gesturing at difficulty, because vagueness here is what makes the whole field look like a priesthood.

Open Attention Is All You Need, the 2017 paper the entire current generation of models descends from. In the middle of it there is a decision to divide the attention scores by the square root of the key dimension. The authors explain why in a footnote: if you assume the components of the two vectors are independent random variables with mean zero and variance one, their dot product has mean zero and variance equal to the dimension. So as the dimension grows the scores grow, and large scores push the softmax into a region where its gradients are almost nothing, and the thing stops learning.

Read that again as a job description. To have made that decision you need to know how variance behaves when you sum products of independent variables, and what a softmax does to gradients when its inputs get large. That is not background reading for the work. That is the work, and there is no version of the job where somebody hands you the intuition and you skip the derivation.

The second example is money. In 2022 a DeepMind team trained over 400 language models, from 70 million to 16 billion parameters, on 5 to 500 billion tokens, to answer one question: given a fixed compute budget, how big should the model be and how much data should it see. The answer was that model size and training tokens should scale equally, and the demonstration was a 70 billion parameter model outperforming a 280 billion parameter one trained with the same compute. Getting that relationship wrong does not produce a bug you fix on Thursday. It produces a run that was doomed before it started, discovered weeks and a large amount of money later.

At Layer 2 the maths is a tool you occasionally reach for. At Layer 3 it is the surface you work on. The feedback loop is a loss curve rather than a failing test, the choice in front of you is often between two things that differ only in an equation, and the equation is how you tell them apart before you spend the compute.

One advert I read makes the split concrete better than any diagram. A small European company building foundation models for tabular data, hiring in the same post for a Full Stack Engineer on the ML Platform, wanting "TS + Python, React/FastAPI/Postgres", and for a Research Scientist on the foundation model itself, wanting "PhD + top-venue publications or equivalent". Same company, same product, same advert. Two professions, and the gap between them is not seniority.

Which one do you actually want

The useful question is not whether you are good at maths. It is which question you want to spend your working life answering.

If the question that pulls at you is why the thing behaves the way it does, and what would be different if it had been trained differently, that is Layer 3 and you should go and get the maths properly. Not in four months from a video course, either. It is the Deisenroth Part I list, with exercises, and then papers.

If the question that pulls at you is how to make this useful for somebody who is not you, that is Layer 2, and the curriculum is a detour with a reasonable-sounding excuse attached.

None of which means never learn any of it. The failure is not learning maths, it is learning it in the wrong order, with nothing to attach it to. The best practical course in the field takes the opposite route deliberately. fast.ai's Practical Deep Learning for Coders trains a working model in the first lesson and digs downwards from there, and their stated prerequisite is a year of coding and a high school maths course. Their own myths table is blunter than anything I would write: against "lots of math" they put "just high school math is sufficient". Whatever you think of the pedagogy, notice that even the course whose entire purpose is to teach you to train models does not ask you to do the four months first.

There is a final asymmetry worth knowing, and it decides the order by itself. Arriving at Layer 3 from Layer 2 costs you nothing, because everything at Layer 3 still runs on code, data pipelines and infrastructure, and the person who can build those is more useful in a lab than the person who cannot. Arriving at Layer 2 from an attempt at Layer 3 costs four months, and quite often costs the ambition as well.

See it for yourself

This takes twenty minutes and it settles the argument with your own work instead of my opinion.

Write down the five things you are genuinely stuck on right now. Real blockers from this week, in your own words: the retrieval keeps returning the wrong section, the agent hangs when a tool fails, nobody can tell whether yesterday's change helped.

Now open the free PDF of Mathematics for Machine Learning and read the contents page of Part I. Seven chapters. Mark which of your five each chapter would help you answer. Then open Anthropic's Building Effective Agents, read its section headings, and do the same count.

Most people score zero on the first list and three or four on the second, which is a season of evenings nearly spent on the wrong shelf.

Then do the other half, because the result only means something if it can come out the other way. Read the scaling-factor paragraph in Attention Is All You Need, footnote included. Most people skim it. If instead you reach for a pen to check whether the variance claim holds, take that seriously.

Sources

Linked so you can check them, including the count that is mine rather than anybody's peer-reviewed research.

• Deisenroth, Faisal and Ong, Mathematics for Machine Learning, Cambridge University Press, 2020. Part I: linear algebra, analytic geometry, matrix decompositions, vector calculus, probability and distribution, continuous optimisation. The authors state the book aims "to provide the necessary mathematical skills to read those other books". Free PDF on the site. High confidence, verified against the publisher's own page.
• Goodfellow, Bengio and Courville, Deep Learning, MIT Press, 2016. Part I: linear algebra, probability and information theory, numerical computation. High confidence.
• My own count of the June 2026 and July 2026 Ask HN: Who is hiring? threads. 575 top-level postings with substantive text; 231 mentioning AI, LLM or machine learning work; 3 containing any mathematical term, none of them requiring the mathematics of machine learning. This is the weakest evidence in the post and I would rather say so. One self-selected forum, heavily weighted towards startups, short blurbs rather than formal job specifications, and classified by regular expression rather than by reading every posting. The gap is large enough that I trust the direction; do not quote the figures as a survey.
• Anthropic, Building Effective Agents, 2024. Section headings covering prompt chaining, routing, parallelisation, orchestrator-workers, evaluator-optimiser and tool design. No equations anywhere in it. High confidence, checked directly.
• Miller, Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations, Anthropic, 2024, with a summary on Anthropic's site. Standard errors, clustering, paired differences and power analysis; clustered standard errors on popular evals can be over three times as large as naive ones. High confidence.
• Vaswani et al., Attention Is All You Need, 2017. Section 3.2.1 and its footnote: components with mean 0 and variance 1 give a dot product with variance equal to the key dimension, and large dot products push the softmax into regions of extremely small gradients. Verified in the paper text.
• Hoffmann et al., Training Compute-Optimal Large Language Models, DeepMind, 2022. Over 400 models from 70 million to 16 billion parameters on 5 to 500 billion tokens; model size and training tokens should be scaled equally; the 70B Chinchilla outperforms the 280B Gopher at equal compute. High confidence.
• Howard and Gugger, Practical Deep Learning for Coders, fast.ai. Stated prerequisites: "you know how to code (a year of experience is enough), preferably in Python, and that you have at least followed a high school math course", and "You don't need any university math either". The myths table lists "lots of math" against "just high school math is sufficient". Verified in the page source.
• Job postings quoted are from the threads above: the "ML hobbyist > ML PhD for this role" line is BrightCore (Dublin), and the paired Full Stack Engineer and Research Scientist roles are Prior Labs (Berlin, Freiburg, New York). Both quoted verbatim from postings written by the companies themselves. Adverts are marketing as well as specification, so read them as a signal of what employers want to be seen asking for.