tomydiaz
All posts

AI Foundations · Part 1 of 8

8 min read

What AI Actually Is: Pattern Matching All the Way Down

A working definition of AI that survives contact with production, and why the shift from deterministic to probabilistic changes how you build.

I just finished the first learning path in my AI studies, five courses covering everything from core concepts to production operations. Rather than let the notes rot in a folder, I’m writing the whole thing up as a series. This is part one.

Let me start where the courses started, because it turns out the hardest problem isn’t technical. It’s that nobody agrees on what the word means.

The board says “AI” and pictures agents replacing half the company. A data scientist says “AI” and thinks about the prediction model they’ve been tuning for six months. Someone’s grandmother says “AI” and pictures robots taking over. Everyone is using the same word for different things.

This confusion isn’t anyone’s fault. The term has drifted. What we called AI in the 1980s, expert systems following decision trees, we wouldn’t call AI today. That was cutting edge then. Now it’s just code.

A definition that actually holds up

Here’s the one I’ve adopted:

AI is software that uses statistical patterns, learned from data, to perform tasks that traditionally required human judgment.

Every clause is load-bearing.

Statistical patterns, not logical rules. Traditional code says if X, then Y, because you said so. AI says when I see X, it’s probably Y, because that’s what the patterns suggest. This is why a fraud model is 94% accurate rather than 100% correct.

Learned from data, not programmed. You don’t write the rules. You show it thousands or millions of examples and it derives the patterns. Think about how you learned to spot spam: after enough Nigerian prince emails you developed an intuition. AI does something similar, except it has no concept of royalty or geography, just tokens that correlate with things people marked as junk.

Tasks that traditionally required human judgment. Recognizing faces, understanding language, detecting fraud. These aren’t calculations with a single right answer. They require pattern recognition under ambiguity, and that’s exactly where modern AI is strong.

The shift that matters most for developers

Traditional code is deterministic. Call a sort function on the same array and you get the same result every time, forever.

AI is probabilistic. Same input, potentially different output. A sentiment classifier might be 89% confident a review is positive on one call and 91% on the next.

That isn’t a bug. It’s the fundamental nature of the system, and internalizing it changes how you build, test, deploy, and monitor. You can’t write an assertion that a model returns exactly one string. You can’t reproduce a bug by replaying the input and expecting identical behavior. Your test suite has to reason about distributions, not equality.

Traditional codeAI
Rules come fromDevelopersData
Same input, same outputAlwaysNot guaranteed
Failure modeThrows an errorReturns a confident wrong answer
DebuggingRead the logicInspect the data and the patterns
Fixing itChange the codeRetrain, or redesign around it

That third row is the one that catches people. When a database fails, you get an exception. When AI fails, you often get a well-formed, plausible, completely incorrect response. There is no exception thrown for a hallucination.

Narrow AI is all we’re actually dealing with

Everything running in production today is narrow AI, systems that are very good at one specific thing. A fraud model can’t start recognizing faces. A language model can’t spontaneously learn chess.

Artificial general intelligence, a system that reasons across domains the way a person does, is not what you’re integrating. The terms keep sliding, too: some of what we’d have called AGI five years ago is just last Tuesday’s release. The target moves because the field moves, which is part of why everyone is confused.

The family tree

“AI” is an umbrella. You’ll hear machine learning, deep learning, neural networks, transformers. These aren’t competitors to AI, they’re techniques inside it.

  • Artificial intelligence: the broad category: machines doing tasks that normally need human intelligence.
  • Machine learning: a subset. Instead of hard-coding rules, you feed data to algorithms that learn patterns. Often works on structured data: spreadsheets, labeled text.
  • Deep learning: a subset of ML using layered neural networks. Handles unstructured data, images, audio, video, but needs far more data and compute.

A neural network processes information in layers, each extracting more abstract features. In image recognition, the first layer might detect edges, the next combines them into shapes, later layers identify “wheel” or “door,” and the output says 98% confident this is a car.

Here’s the thing worth holding onto: whether it’s linear regression or a massive transformer, they all do the same fundamental thing, learn patterns from examples. Don’t get lost in the taxonomy.

“The algorithm” usually isn’t AI

Culturally we say “the algorithm showed me this” or “the algorithm rejected my loan.” Most of that isn’t AI.

A credit rule that says if income > X and credit_history > Y then approve is traditional code following rules a person wrote. A credit model that learned from millions of applications and found subtle correlations nobody would think to program is a fundamentally different thing.

The distinction matters because it changes everything downstream about how the system is built, tested, deployed, and monitored. It’s also the single best filter for marketing claims, ask whether the system actually learns from data and adapts over time. If it doesn’t, it might not be AI at all. The courses called this AI washing: labeling something “AI-powered” to sound current. It creates unrealistic expectations and makes people cynical about the genuine work.

Training and inference are different worlds

Of everything in the first course, this is the distinction I most wish I’d had straight in my head earlier.

Training is when the model learns the patterns. The system takes an example, makes a prediction, checks it against the known answer, and if it was wrong, nudges its parameters. Then it does that again, millions of times. It’s slow, expensive, and happens once per model version. This is why training a frontier model costs millions and takes weeks on large GPU clusters.

Inference is what you do in production, using already-learned patterns on new data. Every API call is inference. It’s fast and comparatively cheap.

Most developers only ever touch inference, and that’s fine. But the distinction explains a lot of otherwise confusing behavior:

  • Why models don’t improve on their own. The model is not learning from your production traffic. It learns when you retrain it. Never.
  • Why you can’t teach it your use case on the fly. That’s a training operation.
  • Why retraining is a big deal. It’s a fresh expensive process producing a new artifact you have to evaluate and roll out.

Fine-tuning and transfer learning are variations on training. Fine-tuning takes a model that already learned general patterns and teaches it more specific ones. Transfer learning uses patterns learned on one task as a starting point for another. Both are dramatically cheaper than training from scratch, but you’re still bound by the same limits, still dependent on data quality, and still going to see the characteristic failures when production stops matching training.

Why now, if the ideas are from the 1950s?

Neural networks aren’t new. Three things had to converge:

  1. Massive, diverse data became available.
  2. Compute got cheap enough to process it.
  3. Algorithms got good enough to find something useful in it.

All three were required. Remove any one and you’re back in an AI winter. The fundamental approach hasn’t changed that much, we’re still doing pattern matching, still doing training and inference. We just got dramatically better at the details. We didn’t invent a new way to learn; we got very good at this one way.

Why this framing is worth keeping

Once it clicks that there’s no understanding in there, just patterns, a lot of behavior stops being surprising:

  • It writes competent prose but can’t reliably count the letters in a word.
  • It works brilliantly on stable patterns and fails badly on genuinely novel situations.
  • It states wrong facts confidently, not because it’s lying, but because those word sequences were statistically likely.

It also changes the questions you ask. Instead of “Can AI solve this?” you ask “Are there stable patterns here?” Instead of “How accurate is the model?” you ask “How well does production match training?”

And it gives you a hype filter. When a vendor says their system understands something, you know they mean it found patterns. When they say it continuously learns, you ask about the retraining pipeline. When they promise 100% accuracy, you know to walk away, a probabilistic system cannot guarantee a deterministic outcome. That’s not pessimism, it’s arithmetic.

Next up: how these models actually take in information, tokens, context windows, embeddings, and the preprocessing work that eats half your development time.