The mental models first, the tools second. A systems-thinking way into artificial intelligence — for builders, founders and the curious, not just engineers.
Most AI teaching starts with tools and buzzwords. I start with systems. Once you can see what a model actually is, how data moves through it, and how to wire it to everything else, the tools stop being magic and start being parts you can combine. That's the whole game — and it's learnable.
These lessons grow out of real systems I've built — Enki, the base-60 collapse, agents and local models — distilled into plain explanations. The written lessons are here now so you can start today; each grows a companion video as it's recorded.
Seven lessons, in order — open any one to read it. Videos publish here as they're recorded.
Strip away the chat window and the branding, and a large language model does exactly one thing: it looks at the text so far and predicts the next word. Then it adds that word and predicts the next. That's the whole engine. Everything else — answering questions, writing code, holding a conversation — is that one prediction loop, run over and over, very fast.
It learned that skill by reading an enormous amount of text and being scored, trillions of times, on how well it guessed the next word. What it kept isn't the text — it's the shape of language: which ideas tend to follow which, how a well-formed argument flows, what a Python function looks like. A model isn't a database you look things up in. It's a pattern engine that reconstructs a plausible answer from the shape it absorbed.
This tells you exactly where it's strong and where it's dangerous. It's brilliant at anything that is really a pattern — rewriting, summarizing, translating, drafting, explaining. It's unreliable at anything that needs a specific true fact it never clearly saw, or that happened after it was trained, or that lives in your private files. Asked for those, it doesn't stop — it generates the most likely-sounding answer, which is where "confidently wrong" comes from.
Think of a brilliant improviser who has read nearly everything but remembers no single source. Ask them anything and they'll give you a fluent, well-shaped answer in the right voice — but whether it's true is a separate question the improviser can't answer for you. Fluency is not the same as fact.
A model gives you a very well-read guess, not a lookup. That's not a flaw to fix — it's the nature of the tool. Trust doesn't come from the model being right; it comes from the system you build around it. That idea runs through every lesson here.
I got this word from building, not software: an architect draws a master plan before a single stone is laid — the whole thing, at once, on purpose. Software is no different. You've just seen what the raw material is; before we pick up a single tool, this is the frame the rest of the course hangs on. Before I build anything, I draw one.
A master plan begins as a flow, not a feature list: the complete path through the thing you're building, start to finish, before any single screen or function exists. Most people start with features and discover the flow by accident, halfway through — and it's backwards. You have to see the whole journey first — where a person enters, what moves through the system, where it ends up — and only then break it into parts. Get the flow wrong and every feature gets built in the wrong place.
Here's the part almost everyone misses: an app is dualistic. There are always two of them living inside one. There's the customer app — the experience the user actually came for — and the admin app — the control plane behind it, where the system is run, watched, and corrected. Different users, different purposes, different screens. A real master plan designs both from the start. Build the customer side and bolt admin on later, and you've built half an app twice.
So the plan answers two questions, not one. What is the user trying to accomplish? — their goal, and the shortest path to it. And what does the admin need to see and control? — the levers, the corrections, the human eye on the system. The two purposes shape each other; you can't finish one without the other. Hold onto that admin side — it's where the later lessons land: it's exactly where determinism, the gates, and the human eye live, the place a person validates what the machine produced.
And here's the sequence that matters: a master plan is only finishable once you understand the system architecture available to you. The flow and the dual purpose come first — but a plan floating free of what you can actually build with is just a daydream. You take the flow, then bind it to the real palette of systems you have — databases, models, agents, the pieces the rest of this course will hand you — and composing those into the flow is what turns a plan into an architecture. Flow first, then purpose, then the systems that make it real.
Enki is exactly this dual shape. The customer app is the agent in your hand — a sensor node out in the field, feeding the system. The Command Center is the admin app — where everything is ingested, mapped, queried, and where a human validates what the models found. One system, two faces, planned as a pair. CheatCodes is the same: a public museum for players out front, and behind it the place my son hand-checked every record.
The master plan is the full flow of a dual system, drawn before you build — the user's purpose and the admin's purpose together, then bound to the architecture you actually have. Get that on paper and the build becomes almost bookkeeping. Skip it, and you'll rebuild the same app until you do.
People treat prompting like casting a spell — find the magic words and the model obeys. That's the wrong model. A prompt is an interface: you're specifying the inputs, the constraints, and the shape of the output you want. Prompting well is just clear system design applied to language.
Reliable prompts almost always make four things explicit: the role (who the model is being — "a careful copy editor"), the context (what it's working from), the task (the exact job), and the output shape (format, length, what to include and exclude). Vague in, vague out. The more of the answer's shape you specify, the less the model has to guess.
The single biggest upgrade is giving an example of a good answer. One or two worked examples teach the model the pattern you want far better than a paragraph of instructions — because, as Lesson 1 showed, patterns are its native language.
Lucky: "Summarize this article." You get something — length, tone and focus are a roll of the dice. Designed: "Summarize this article in exactly 3 bullets, each under 15 words, plain language, focused on what changed and why it matters." Now the result is repeatable, because you gave it a spec instead of a wish.
Stop hunting for magic words. You're writing an input/output contract. And treat it like engineering: when a prompt underperforms, change one thing, run it again, and watch what moves — the same way you'd debug any system.
So far the model just answers once and stops. An agent is what you get when you put that answer inside a loop and give the model a way to act on the world. The word sounds futuristic; the idea is old and simple — it's a control loop where the model makes the decisions.
Every agent, underneath, runs the same cycle: look at the goal and what's happened so far → decide the next step → take an action → read the result → repeat, until the job is done. The model is only the "decide" step. The power comes from wrapping it in the loop.
Tools are the hands — a web search, a calculator, the ability to read a file or run code. A model with no tools can only talk; a model with tools can do. Memory is what it carries from one step to the next so it doesn't start over each time. And a stop condition tells it when it's finished — without one, a loop just runs forever.
A little research agent, given "find out what changed in this field this month": it searches, reads a few results, notes what's useful, decides whether it has enough, searches again if not — and once its stop condition is met, writes the summary. No single prompt could do that; the loop can.
An agent isn't a smarter model — it's a model placed inside a loop with tools, memory, and a clear stopping point. Design the loop and the guardrails first; the model is just the decision it makes each time around.
You don't have to rent intelligence from someone else's servers. Capable open models now run on hardware you own, in your own room, with no data ever leaving it. For a lot of real work, that isn't a compromise — it's the better call.
Three reasons. Privacy: your documents, your signals, your life never touch a third party. Control: no rate limits, no price changes, no model swapped out from under you, no terms of service. Cost: once the machine is paid for, running it is close to free. When the material is sensitive — which, for the things I build, it usually is — local isn't optional.
The industry sells one message: bigger is better. But for finding everything in a body of text, a federation of diverse small models can beat a single frontier model — because different models notice different things, and you take the union of what they find. More independent eyes means higher recall. This is the architecture behind Enki: not one oracle, but a team of small, offline readers.
On the same document, my local two-pass setup surfaced 108 grounded findings where a single frontier pass found 52 — and only four overlapped. The small federation didn't just tie the big model; it saw roughly twice as much, precisely because its members disagreed about what mattered.
Capability isn't only a function of size. For trust-critical work, architecture — many diverse models, run privately, combined deliberately — can outperform raw scale. Own the machine, and you own the intelligence.
A pile of documents is text a human has to read one at a time. A knowledge graph is the same information turned into something you can query — a web of entities (people, places, claims) connected by relationships. Getting from one to the other is the core move behind Enki, and it's more approachable than it sounds.
Four steps: ingest the raw documents, extract the entities and the claims made about them, resolve all the different names for the same thing into one, and connect what's left into a graph. Step three is the hard, interesting one — and it's where the base-60 idea lives.
The same person shows up across a corpus as "Dr. Fauci," "Anthony Fauci," "the NIAID director," "Fauci, A." A human sees one person; naïve software sees four. Collapse folds every alias down to one canonical entity with one fixed address. Crucially, it's done by a deterministic rule, not a model's guess — so the same documents always produce the same graph. The addresses are laid out in base-60, the Sumerian number base, because 60 divides so many ways that its address space subdivides cleanly again and again — ideal for splitting a huge graph across many machines with nothing landing in the cracks.
Once every mention of a thing resolves to one address, you can pull every statement ever made about it across thousands of pages in one query — then cluster those statements by meaning and see, at a glance, where the record agrees and where it flatly contradicts itself. That's the setup for the final lesson.
Structure is what makes text trustworthy and searchable. The graph is the real product; the model is just the worker that helps fill it in. Build the structure, and the knowledge stops being a pile and becomes a system you can ask questions of.
Here's the problem that everything else has been building toward. Models paraphrase, they drift, and they can't prove what they told you. For anything that matters, "the AI said so" is not good enough. The fix isn't a better model — it's a change in who does the judging.
Instead of asking the model to be right, ask it only to transcribe — to point at what a source actually says. Then a set of fixed, deterministic rules does the judging. The model proposes; the structure proves. Because the rules are mechanical, the result is repeatable and auditable — the opposite of vibes.
Every claim has to pass gates before it counts: the quote must appear word-for-word in the source, the speaker must sit right beside it, and boilerplate or OCR garble gets thrown out. A claim isn't "probably true because it sounds right" — it's backed by a verbatim quote and an attribution, or it doesn't exist. That's proof-by-quote.
On the COVID-origins record, this surfaced a genuine, provable contradiction: one official saying lab notebooks "would have been a requirement," another saying they were "not required" — two verbatim quotes, two sources, pointing opposite ways. No opinion in the middle. The geometry and the source text made the call, not a model.
Don't ask AI to be an oracle you have to trust. Build a system that can't lie — where every output traces back to a verbatim source through rules anyone can check. A smarter guess is still a guess; a library that can't lie is something you can build on.