AI vs ML vs Deep Learning

Welcome to Day 3, post 4 — the code post. We've talked about rule-based AI, classic ML, and deep learning in the abstract. Now we'll solve one concrete task three ways so the differences stop being definitions and become things you can see and run.

The task is churn prediction: will this customer leave? We'll write a hand-coded rule, a classic ML model, and a tiny neural network for the same problem. Watching the same goal expressed three ways is the fastest way to feel, in your hands, exactly what each approach asks of you and what it gives back.

Holding the task fixed is the whole point of this exercise. Churn prediction — flagging customers likely to leave — is a clean, realistic problem with structured inputs like days inactive and support tickets. By solving the one task three different ways, every difference you see is about the approach, not the problem.

This is also exactly how you should think on the job: define the task first, then ask which rung of the ladder fits it. Too many projects start from 'let's use a neural network' and go looking for a problem. We're doing it the right way round — task first, tool second — and letting the three implementations reveal their own strengths and costs.

The rule-based version is just a function a human wrote: if the customer has been inactive more than 30 days and has opened more than two support tickets, predict churn. That's it — no training, no data, no model file. You can read it, reason about it, and predict its output exactly.

Its strength is that transparency and the fact that it works instantly with zero data. Its weakness is hiding in the thresholds: why 30 days and not 25? Why two tickets? A human guessed, and the rule will miss any pattern the human didn't think to encode. It's a perfectly reasonable starting point — and often a baseline the fancier models have to beat.

The classic ML version barely looks like more code — create a GradientBoostingClassifier, call fit on your training data, call predict — but conceptually it's a different world. You're no longer writing the rule; the algorithm learns it from examples, discovering the thresholds and interactions a human would have guessed at.

What's doing the heavy lifting isn't visible in these four lines: it's the features in X_train that you chose and engineered. The gradient-boosted tree learns how to weigh days-inactive, ticket counts, usage trends and so on, finding combinations no hand-written rule would capture. On eight tidy columns, this is almost always the sweet spot — more accurate than the rule, far cheaper than a neural net.

The deep learning version defines a small neural network: an input layer taking eight features, a hidden layer of 32 units with a ReLU activation, and an output neuron with a sigmoid for the churn probability. Then — implied by the comment — it's trained with backpropagation over many epochs.

Notice how much more apparatus this needs: a network architecture, activation functions, an optimiser, epochs, and a training loop. For eight tabular columns, all that machinery is overkill — there simply aren't enough features or examples for the network to discover anything the gradient-boosted tree didn't. This same code shape, scaled up and fed raw text or images, is what powers the impressive models. The architecture isn't wrong; it's just mismatched to a small tabular problem.

Tallying the three: the rule is instant and free but misses subtle patterns because a human had to guess every threshold. Classic ML — the gradient-boosted tree — is the winner here: it's fast, accurate, and perfectly suited to eight tabular features with labels. The deep net is overkill; it needs far more data to show its strengths and brings cost and complexity that buy nothing on this problem.

The headline result is one worth tattooing on your decision-making: on tabular data, classic ML usually wins. Not sometimes — usually. The flashiest tool lost to the practical one, because the data played to the practical tool's strengths. That outcome is the rule, not the exception.

Reading the three implementations top to bottom, a clear pattern emerges: the human does less and the machine does more at each step — but the data and compute bill climbs to match. The rule needed a human's full attention and no data; the neural net needs little human design but lots of data and a training budget.

For eight columns, the gradient-boosted model sits in the sweet spot — enough learning to beat the rule, little enough overhead to stay cheap. But flip the data type and the calculus inverts: for raw images or free text, only the deep net would work at all, because the others can't operate on unstructured input. The lesson isn't 'classic ML wins' — it's 'let the data decide which trade-off you want'.

This tiny snippet is the most underrated tool in applied ML: a DummyClassifier that just predicts the most frequent class. If 80% of customers don't churn, it scores 80% accuracy by always guessing 'won't churn' — while learning absolutely nothing.

The point is brutal and clarifying: if your sophisticated model can't beat this, it isn't helping. Baselines like this catch the embarrassing failures — a 'great' 80% model that's actually worse than a one-line guess. Running a dummy baseline first reframes every later number. Suddenly '85% accuracy' isn't impressive on its own; it's five points over a do-nothing baseline, which is a real, honest measure of what your model added.

Four practical rules distil the whole post. Few structured features? Reach for classic ML first — it'll usually win and it'll win fast. Unstructured data like text, images, or audio? That's where deep learning earns its complexity, and often the only thing that works.

Always benchmark against a simple baseline, so your accuracy numbers mean something. And the closing reminder ties the day together: 'newer' is not 'better'. The job is to match the tool to the data, not to chase the most advanced-sounding option. Internalise these four and you'll make calmer, cheaper, more defensible modelling decisions than a lot of people who reach for the biggest model by reflex.

The benchmark people skip is the cheap one: jumping straight to the neural network without first trying a three-line rule or a gradient-boosted baseline. It feels like progress — you're building the impressive thing — but you've skipped the step that tells you whether the impressive thing is even helping.

Without baselines, you literally cannot prove your complex model earns its cost. Maybe it beats a rule by twenty points (great, ship it) or maybe it ties a GBDT that trains in three minutes (then why are you paying for GPUs?). And on tabular data, it's usually the latter. Baselines aren't busywork; they're the evidence that turns 'we used deep learning' from a boast into a justified decision.

Seeing the same task in three flavours of code is the fastest cure for tool-by-prestige thinking. The takeaways: define the task first, start with a baseline, and let the data — not the trend — pick your rung on the ladder. Save the snippets; they're a handy template next time you're scoping a model.

Tomorrow closes out Day 3 with the five most common AI/ML/DL mistakes — the muddles that cost real projects time and money — and exactly how to avoid each one.