Machine learning for web developers: the only mental model you need
You do not need calculus to work with models. You need one idea — that a model is a function you fit instead of write — and the rest follows from things you already know.
Contents
Every few weeks somebody on a client call asks whether we should “add AI” to something, and every few weeks I watch a room of good web developers go quiet. Not because the question is hard. Because nobody wants to be the person who admits they never did the maths course.
Here is the thing: you do not need it. Not to make sensible decisions about models, not to ship a feature that uses one, not even to debug it when it goes wrong. You need one mental model, and you already have most of the pieces.
A model is a function you fit instead of write
You write functions all day:
function shippingCost(weightKg, country) {
if (country === 'AE') return weightKg * 4;
if (country === 'PK') return weightKg * 6 + 10;
return weightKg * 12 + 25;
}You know the rules, so you type the rules. Input goes in, output comes out, and if it is wrong you open the file and fix the branch.
Now imagine the rules are not knowable. “Is this support ticket angry?” There is no if statement for angry. You could try — look for swear words, exclamation marks, the phrase “unacceptable” — and you would be wrong about half the time, because the angriest ticket I ever received was four words long and perfectly polite.
A model is what you use when you cannot type the rules. You supply a few thousand examples of tickets labelled angry or not, and a training process searches for a function that gets most of them right. The function it finds is a big pile of numbers. Nobody wrote those numbers. Nobody can read them.
That is the whole idea. Traditional code: you know the rule, you write the rule. Machine learning: you know the examples, the machine finds a rule.
Everything else — neural networks, transformers, gradient descent, the lot — is detail about how the search happens. You can ship real features without ever opening that box, in exactly the way you ship real features without knowing how V8 optimises a hot loop.
What changes when you cannot read the function
This is where the intuitions you have from normal code start to mislead you, so it is worth going slowly.
The function is probabilistic, not exact. shippingCost(2, 'AE') is 8. Always 8. A sentiment model does not return “angry” — it returns something like { angry: 0.82, calm: 0.18 }, and it is your job to decide what to do with 0.82. This is the single biggest adjustment for developers. You are no longer writing code that is right or wrong. You are writing code that is right often enough, and handling the rest.
It fails in ways you cannot reproduce by reading it. A bug in shippingCost is a line you can point at. A bug in a model is usually a gap in the examples it learned from. If nobody in your training data wrote a polite complaint, the model has no idea polite complaints exist. You fix it with data, not with a patch.
It has no idea what it does not know. A model asked something outside its experience will not throw. It will answer, confidently, in exactly the same tone as when it is right. Every production problem I have seen with models traces back to somebody forgetting this.
The three shapes of everything
Almost every model you will touch as a web developer is one of three shapes.
Classification picks one of a fixed set of labels. Spam or not spam. Which of these twelve support categories. Which language is this. Output is a set of labels with confidence scores that add up to 1.
Regression predicts a number. How long will this delivery take. What will this property rent for. Output is a number, usually with no honest sense of how sure it is.
Generation produces a sequence — text, code, an image, audio. Output is whatever you asked for, one piece at a time, each piece chosen partly at random. This is what every large language model does, and the randomness is not a bug: it is why the same prompt gives you a different answer twice, and why “temperature” is a setting you can turn down.
If you can name which of the three you need, you can usually find a model for it in an afternoon. If you cannot, the problem is probably not a machine learning problem yet.
Where this leaves a web developer in 2026
You are not going to train anything. Let me be blunt about that, because a lot of tutorials pretend otherwise. Training a useful model from scratch costs more than your car and requires data you do not have. What you will actually do is one of these, in rising order of effort:
| What you do | When it fits | Roughly what it costs |
|---|---|---|
| Call a hosted model’s API | Generation, and most classification | Per request, cents |
| Run a small model yourself | Privacy, offline, high volume | A GPU, or a beefy CPU box |
| Fine-tune an existing model | You have a house style or jargon | Hundreds, and a dataset |
| Train from scratch | Essentially never | Don’t |
The skill that matters is not modelling. It is the same skill that has always mattered: knowing where the boundary of your system is, what happens when something on the other side of it misbehaves, and what you show the user while you wait.
What to read next
The posts in this category go one layer down on each piece. What an embedding actually is covers the one idea that unlocks search, recommendations and retrieval. Tokens, context windows and why your bill is what it is covers the economics, which you will need long before you need the maths.
And if you remember nothing else: a model is a function somebody fitted to examples instead of writing by hand, it answers with a probability rather than a fact, and it will never tell you when it is out of its depth. Build accordingly.