- Published on
- ·6 min read
You Might Be Closer to AI Engineering Than You Think
If you've spent a few years writing software, you've probably felt it: the sense that AI moved without you. Every week there's a new model, a new framework, a new acronym. It's easy to conclude that AI engineering is a separate world, one you'd have to re-enter as a beginner.
I don't think that's true. Most of what makes AI systems work in production is not new. It's the same set of concerns you already reason about every day, just pointed at a component that happens to be statistical instead of deterministic. The distance between where you are and "AI engineer" is smaller than it looks. This post is a map of that distance.
You can only connect the dots looking backwards. Only now, having made the move myself, does the line from one world to the other look clear. I could not see it while I was in the middle of the work.
One honest note before we start. A lot of what we cover early on is really applied AI and applied ML: taking models that already exist, treating them as components, and wiring them into systems that hold up in production. That is a different job from training models or doing original ML research, and I will try to be clear about which one we are in at any given moment. I am starting with the applied side on purpose. It is the natural on-ramp for a working software engineer, and it happens to be the part that leans hardest on the computer science you already know.
Why it feels further than it is
Most AI content pushes you toward one of two extremes.
On one side is the academic path: linear algebra, calculus, backpropagation, the mathematics of transformers. It's genuinely important work, and if you want to train models it's unavoidable. But for an engineer who wants to build with models, starting there is like being told to study semiconductor physics before you're allowed to write a web server. It's not wrong. It's just the wrong first step.
On the other side is the hype path: "build an agent in ten minutes," reaction threads to the latest release, lists of prompts to copy. This gets you moving, but it rarely leaves you with a mental model. When something breaks, and it will, you're left without the understanding to reason about why.
Neither of these matches how experienced engineers actually learn. We learn by mapping something unfamiliar onto something we already trust. So let's do that.
The reframe
Here's the shift that made everything click for me.
An LLM is just another component in your system.
It's a dependency you call, one that returns useful output most of the time and occasionally does something surprising. You already know how to build reliable systems around unreliable components. You've been doing it with flaky networks, slow databases, and third-party APIs for years.
Seen that way, a lot of AI engineering stops being foreign and starts feeling like a variation on problems you've already solved:
A couple of those rows deserve a note, because this is where the mapping earns its keep. The word for testing here is evals, and it splits in two. Offline evals check behavior against a fixed set of examples before you ship, the way a test suite does. Online evals and tracing watch that behavior once real traffic hits it, the way monitoring does. Same instincts you already have, pointed at output that varies from one run to the next.
I want to be careful here. These pairings are bridges, not equalities. RAG is not simply a database query, and an agent is not literally a distributed system. There's real depth in each of these topics, and pretending otherwise would be its own kind of disservice. The point is gentler than that: if you've felt the intuition behind the thing on the left, you already have a foothold on the thing on the right. You're not starting from zero. You're starting from familiar ground and extending it.
The one thing that's genuinely new
If there's a single mental shift worth naming, it's this.
You're moving from a world of determinism to a world of non-determinism.
Most of our instincts as engineers assume that the same input produces the same output. Tests rely on it. Debugging relies on it. A lot of AI engineering is learning to design systems where that assumption no longer holds, where "correct" becomes "correct often enough," where you validate distributions of behavior rather than single results, and where evaluation looks more like monitoring a live system than asserting an exact value.
That shift is real, and it takes some getting used to. But notice that even here, the tools are ones you already own. Handling uncertainty, setting tolerances, observing behavior over time, degrading gracefully when a dependency misbehaves. This is engineering you've done before, in a new setting.
Where to start
You don't need to master the mathematics of transformers to start building things that matter. You need to connect what you already know to what's in front of you, and fill in the genuinely new parts as you go.
That's what this section of the site is for. It takes AI engineering one concept at a time and reasons about each from first principles and core computer science, the discipline underneath all of it.
We'll start where the applied work usually starts, with retrieval. Earlier I said RAG is not simply a database query, and I meant it. That caveat is the whole reason it deserves a post of its own. So the next one walks across that first bridge slowly: why retrieval feels familiar if you've ever built an index, where the database intuition genuinely helps you, and where it quietly falls apart once you are searching by meaning instead of exact keys and handing the results to a model that can still get things wrong. That last part is where applied AI starts to feel like its own discipline. See you there.