Rule-based vs Machine Learning

Not all AI learns from data. Some AI follows hard-coded rules written by programmers — explicit if-then logic that handles situations one by one. This kind of AI has been around since the 1950s and still powers enormous amounts of software, from tax calculators to form validation to much of the logic inside every app on your phone. It’s reliable, fast, transparent, and boring — which is why it rarely makes the news.

The other kind of AI, the kind that does make the news, is machine learning. Instead of writing rules, you show the model examples, and it learns the patterns. That’s what powers ChatGPT, Midjourney, face unlock, Google Translate, and most of the AI you hear about today.

Understanding when to use rules vs ML is one of the most important design decisions in AI — and it’s often made badly, because teams pick whichever approach feels newer or more impressive. The honest truth is that neither is universally better. They solve different problems, they fail in different ways, and the real skill is knowing which fits the one in front of you.

For the first 30 years of AI research, there was essentially one approach: rules. From the 1950s through the 1980s, AI meant writing explicit logic — giant trees of if this, then that — to capture human expertise. Doctors would dictate their diagnostic reasoning; programmers would encode it as hundreds of rules; the resulting system was called an expert system. In the 1980s, expert systems were the peak of AI. Companies spent millions on them. They worked, in narrow domains, as long as the world didn’t change.

Then the world changed. Expert systems turned out to be extremely brittle. Rules that made sense in one hospital didn’t transfer to another. Updating a system meant rewriting rules by hand. The systems couldn’t learn from new cases. By the late 1990s, most had been quietly retired — and the AI field had entered a long period called the AI winter, where funding dried up and people stopped talking about AI.

The shift came from a different direction. Researchers had been developing machine learning since the 1950s, but it needed three things that weren’t available: huge datasets, cheap computing, and better algorithms. Around 2010, those arrived — data from the internet, GPUs for training, and the deep-learning breakthrough. Suddenly, models could learn the patterns that used to be hand-coded as rules — and they learned patterns humans had never even articulated.

Over the last 15 years, ML has dominated the headlines. But the pendulum hasn’t swung all the way: rule-based systems never went away. They’re still running the safety-critical, legal, and compliance-heavy parts of modern software. Tax software is rules. Form validation is rules. Much of what keeps planes in the air is rules. AI today is a hybrid world, not a pure-ML one — and the design skill is knowing which problem belongs to which paradigm.

When a designer picks between rule-based and machine learning, the decision usually comes down to five questions. Most of them are about the problem, not the technology.

1. Can you write the rules down? Some problems have clear, finite, well-understood logic. Calculating tax owed given income and deductions. Checking whether a password meets complexity requirements. Deciding if a shipping address is in a delivery zone. These are rule problems. If an expert can articulate the decision process in under an hour, rules are almost always the right choice. If the expert struggles to explain how they decide — “I just know when an email is spam” — you probably have an ML problem.

2. Do you have enough labeled data? ML needs examples, often thousands to millions of them. If you don’t have the data and can’t afford to collect it, ML isn’t an option regardless of how well it would theoretically fit. A startup with 100 customer support tickets doesn’t have enough data to train a useful classifier — but 100 tickets is enough to write some solid rules.

3. How much does explainability matter? For regulated domains — medical decisions, loan approvals, legal compliance, hiring — you often need to explain why the system made a choice. Rule-based systems are inherently explainable: you can point to the exact rule that fired. ML models are harder. There are explainability techniques, but they’re often approximations. If “we can’t fully explain this decision” isn’t acceptable, rules have an edge.

4. How fast does the problem change? Fraud patterns, spam tactics, user slang, product catalogs — these shift constantly. Rule-based systems require a human to write new rules every time something changes. ML systems can be retrained on new data. For fast-moving problems, the maintenance cost of rules is crushing; for stable problems, rules last years with minimal upkeep.

5. How bad is it when the system is wrong? ML output is probabilistic — it will sometimes be confidently wrong in ways you can’t predict ahead of time. Rules fail in predictable ways: they miss cases they weren’t written for. For safety-critical systems (medication dosing, avionics, legal contracts), predictable failures are often preferable to surprising ones, even at the cost of some accuracy.

Most real-world AI systems don’t pick one. They’re hybrid. Gmail’s spam filter uses ML to score each email, then rules to enforce hard constraints (never auto-delete an email from someone in your contacts, always quarantine messages with known malware signatures, respect your filter preferences). Fraud detection systems use ML to flag suspicious transactions and rules to escalate anything above a threshold. The question isn’t “rules or ML?” — it’s “which parts of this problem are rule-shaped, and which parts are learning-shaped?”

The last two missions have been about the how: how data shapes AI (D1), and how to choose between rule-based and ML paradigms (D2). These are the practical skills of AI design.

But every design question starts further back. Before you ask “should this be rules or ML?”, you have to ask: what problem am I solving, and for whom? The most technically elegant AI solves no problem at all if no one needed it. The most sophisticated ML model does harm if it’s aimed at the wrong thing. A huge amount of wasted AI effort comes from teams who built a clever solution looking for a problem — rather than starting with a real human need and working backward to the tool.

This is especially visible when AI gets pointed at community problems. Some community needs fit AI well: translation for minority languages, early crop disease detection, accessibility tools for people with disabilities, wildfire risk forecasting. Other community needs fit AI badly: situations where the real bottleneck is trust, human connection, legal representation, or political will — where inserting a model can actually make things worse.

In the final mission, “AI for Community,” we’ll work on the judgment of when AI actually helps, when it doesn’t, and how to design responsibly when the stakes involve real people outside the tech industry.