Build the engine
Machine learning → deep learning → NLP → generative AI → RAG → agents → deployment. Build and train from the ground up. Assumes you'll code your way there.
the deep-technical routeAI is the teacher. You point.
Three tracks · one tutor.
The only job left is pointing you at the paths worth chasing. The AI does the teaching — you bring the taste for which paths, and in what order.
Two kinds of school teach this today — one to build it, one to lead it — and both still sit you in front of a lecturer with a fixed syllabus. Swap both: an AI tutor you can point at anything, and a map of the paths worth chasing.
- ✕Make you watch. From the very first step you're building or deciding something real, with the AI working next to you.
- ✕Skip the hard part. The hard part is the point — the tutor's job is to make you sit in it, not route around it.
- ✕Sell a certificate. The proof is what you built or the call you made — not a name on a PDF.
- ✕Freeze a syllabus. The paths shift as fast as the field does; keeping the map sharp is the actual work.
Two kinds of school, one shared habit
Almost every AI program lands in one of two camps — and both teach the same way they always have.
both put a lecturer at the front
Lead the rollout
Strategy, picking tools, governing adoption, the shift from AI-as-feature to AI-as-operating-model. Assumes you won't touch the tools yourself.
the leadership routeThey differ on what you learn — the engine, or the rollout. They agree on how: a lecturer and a frozen syllabus. This changes the how. An AI tutor you aim at anything, a set of paths worth chasing, and three tracks for what you actually want to walk out holding.
How to use this. Every step comes with a starting prompt — a ready-made message you paste into any AI chatbot (ChatGPT, Claude, Gemini, or one you run yourself). Copy it, paste it in, and follow where it leads. On the build tracks, don't let the AI gloss over the hard part — that's where the learning is. On the management track, keep pushing until you have something you can actually use. The page points. The AI teaches.
Brand new to all this? Do Start here first — it shows you how to take code out of the chat and actually run it, which every build path below quietly assumes you can do.
Which track is yours? Explorer and Builder are hands-on — you'll be making little tools, so you'll want to be okay taking code out of a chat and running it. Operator needs no code at all: you point an AI advisor at a real work problem and use what it hands back. Not a builder and not running a team? Operator's first two paths are the gentlest place to start.
Explorer
the way inFor the curious who like to tinker. Six short paths you chase with an AI beside you, easing from your first tiny build into the steeper, under-the-hood ones — plus a deeper seventh, and an optional Sunday-night stitch-up.
These are rough tries, not finished products. You chase a path, get the idea, leave something scrappy behind, and move on. They're meant to be thrown away — that's what makes a whole weekend honest.
→ walk out with: a real feel for building things, six scrappy builds that prove it, and a first taste of the deep end.
01 Why not a server chasing the core idea
What you chaseFind out where your data in a SaaS tool actually lives — then rebuild a useful slice of it as one offline file you own.
Be my tutor for the next hour, not a summarizer — and assume I've never written a line of code. Pick one cloud tool I use every day and grill me on where my data inside it physically lives: whose servers, who can read it, what happens to it if the company is acquired or shuts down. Then walk me through rebuilding the smallest genuinely useful slice of that tool as a single HTML file that runs offline and keeps my data on my own disk — and when you hand me the file, tell me exactly how to save it and open it on my own computer. Whenever I reach something I can't explain, stop and make me work it out — don't smooth it over.
What you getA working zero-dependency tool, and the thesis in your gut — felt, not argued.
02 Pull the AI out chasing the one big rule · the whole idea in an afternoon
What you chaseBolt AI onto the tool you just built, then rip it out and see if it still stands. Build a second one where it can't.
Take the little tool I built in the first path — or any small tool I've already got — and help me bolt an AI feature onto it that drafts something I'd otherwise type by hand. Assume I'm not a coder, and keep every explanation plain. Then make me rip the AI back out and check whether the tool still stands on its own. Next, walk me through building a second tool where ripping the AI out makes the whole thing collapse — so I can feel, in my hands, the line between a tool with an assistant and a wrapper with a UI. Finish by feeding a deliberately wrong AI answer through the part of the tool that doesn't use AI, and show me why it fails loudly and obviously instead of quietly producing something wrong.
What you getA gut feel for whether a tool can stand without its AI — and why failing loudly makes it safe to let a model write your code.
03 A model in your tab chasing running AI yourself · the fun one
What you chaseRun a real model on your own GPU, in the browser, nothing leaving the machine. When it's slow, find out why.
Walk me through running a real language model entirely in my browser, on my own computer's graphics chip — no API call, nothing leaving my machine. Assume I've never coded: set it all up for me using WebGPU and Transformers.js (which runs the model in a browser-friendly format called ONNX under the hood), and load a model small enough for a browser but good enough to do real work — Gemma 4 E2B (the browser-sized "E2B" instruction-tuned version) is the current default; if you don't recognise it, use the latest small browser-ready Gemma in ONNX form. Tell me exactly what to click and run at each step. The moment the first reply comes back slowly, stop and teach me, in plain language, what my hardware is actually doing right now — what "attention" is computing. Then have me load an even more compressed version of the same model and watch the quality drop as the precision drops, so I've seen quantization happen instead of just reading about it. Keep checking that I can explain each step back to you.
What you getYou've run inference on your own silicon and roughly know what happened. Quantization, felt.
04 What actually leaves the machine chasing what really leaves your machine
What you chaseWire your own API key, then trace every byte that leaves on each call. Learn why "key never leaves" ≠ "data never leaves." Then drive the tool by script and by click.
Help me connect my own API key so a small tool can call a cloud AI model with it — assume I'm not technical, show me each step, and point me to where I'd get a free, no-credit-card key if I don't have one (something like Google AI Studio or Groq). Then trace through with me, in plain terms, where that key is stored and everything that actually leaves my device on each call. Make me find the exact text being sent to the provider, and have me explain back to you why "my key never leaves my machine" and "my data never leaves my machine" are two completely different claims. Then add a tiny way to drive the same tool with a short script as well as by clicking, and have me run it both ways until it's obvious they're the same machine underneath.
What you getYou can reason honestly about what escapes a "local" tool — and you've built the start of the two-door pattern: one door a person clicks, one a script drives, both opening onto the same machine.
05 The core and the disk chasing how it's built · the steep one
Steeper going. The most jargon-heavy path here — so it comes as two short pastes instead of one. Bring patience, or come back to it after the lighter ones.
What you chaseFirst, build with all three browser storage layers and feel what survives when you pull the folder permission. Then move a slow job into a background worker and watch the page stop freezing.
Two pastes, one after the other. Get the first working in your AI chat, then paste the second to continue from where it left off.
I'm not a developer, so go slow, explain each new word in plain language, and show me how to run things at every step. Teach me how the browser actually stores data by helping me build one small tool that saves to all three of its storage layers — File System Access, OPFS, and IndexedDB. Have me save some real data in it. Then have me deliberately revoke the folder permission mid-session, so I feel exactly what survives and what disappears. Before you explain why, make me try to reason out for myself why the tool should save to those three in the order folder → OPFS → IndexedDB.
Carry on with the little storage tool we just built, and keep assuming I'm not a developer — explain each new word plainly and show me how to run it. Now teach me what a "background worker" is by having me move one slow piece of work — something that visibly freezes the page — off the main page and into a worker, so the page stays responsive while it runs. Then have me break it on purpose, by sending the worker something it can't handle, so the line between the page and the worker stops being abstract and I can see exactly where one ends and the other begins.
What you getYou hold the storage stack in your hands, know what each layer is for, and have felt the line between the page and a background worker.
06 The wall in the browser chasing why local AI is tricky · the steep one
Steeper going. You'll install a small model on your machine and run into the browser's security rules head-on — so it comes as two short pastes. Easiest once you've done a couple of the earlier paths.
What you chaseFirst, install and run an AI model on your own machine. Then call it from an ordinary tab, hit the wall on purpose, and understand it before you build the smallest honest bridge across.
Two pastes, one after the other. Get the model running with the first, then paste the second to hit the wall and cross it.
Help me install and run an AI model on my own machine using a simple model runner like Ollama — with a small, capable model such as Gemma 4 at its on-device size — assume I've never used a terminal, so give me the exact commands one at a time and say what each one does, and tell me how to check it's actually working before we go further. Keep every explanation plain, and don't move on until I confirm the model is running and answering me.
Now help me call the model I just got running from an ordinary browser tab — and keep assuming I'm not technical. I'm going to hit a wall almost immediately. Do not route around it for me: make me hit it, then teach me in plain language why the browser refuses, what same-origin, CORS, and mixed-content each protect me from, and what would go wrong if they didn't exist. Only once I can explain the wall back to you in my own words, help me build the smallest honest bridge through it — and tell me what that bridge is now responsible for keeping safe.
What you getThe browser's security model — and why a bridge has to exist — in your bones.
07 Make it faster — and a little bit yours chasing where every path leads · the deep one
The deep end. Two short pastes — and the second one leaves the browser for a free hosted notebook. Treat it as a taste of where the deep paths go, not a box to tick.
What you chaseThe two things every deep path eventually leads to: making a model smaller so it runs faster (you feel this in the browser), and teaching it something new (this pulls you out to a free hosted notebook).
Two pastes, one after the other. Do the first in your browser, then the second in a free notebook like Google Colab.
Be my tutor for an hour, and assume I'm not a developer. Right here in the browser, take the small model I'm already running (say the Gemma 4 E2B from the earlier path) and shrink it to use fewer bits (quantize it), then measure its speed — tokens per second — before and after. I want to feel the speed go up, watch the quality change, and understand the trade I'm making. Explain every step in plain words, and show me how to run each one.
Now take me out of the browser into a free hosted notebook (like Google Colab) — assume I've never opened one, so show me how to get in and run a cell. Walk me through teaching a tiny model something new with a small fine-tune (a LoRA) on a handful of my own examples — the smallest real fine-tune there is. Show me the model's behaviour actually change because of what I gave it. Explain every step in plain words, and be honest about which parts a plain browser can't do, and why.
What you getYou've made a model faster with your own hands and taught one something with a dozen examples — the first real taste of training and serving, which is where the deep end actually is.
✦ Bonus — Sunday night, optional stitch two throwaways into one
What you chaseCombine two of the weekend's throwaway tries into one thing that runs a model on your own machine and keeps its data on your disk and keeps working when you pull the AI out.
Help me stitch two of the throwaway tools I built this weekend into one that runs a model on my own machine, keeps its data on my disk, and keeps working fully when I unplug the AI. I'm not a coder, so explain how the pieces join in plain words. Keep it scrappy — this is a quick experiment, not a product, so optimize for me understanding how it fits together, not for polish.
Builder
the technical pathFor the people a technical college is aimed at — but who'd rather build than sit a course. The same paths, but you finish each one with a real, working tool instead of a rough try.
You don't train models from scratch here — you wire existing ones into tools that are yours and keep working when the AI's gone. The model rides as a passenger — a sidecar, an optional helper bolted alongside that suggests, never the engine that drives — and the tool is the thing you own. Adopt what's mature, build only the genuinely new shape.
→ walk out with: a set of small, self-contained tools — yours to keep, deploy, or sell. The tools you built are your proof.
01 One file, nothing of theirs in the loop your first build
You buildA zero-dependency single-file tool that does one useful deterministic thing offline — no account, no server, no telemetry.
Done whenOpens on double-click · visible version string · a help affordance on the welcome screen.
Be my build partner for a single-file tool: one HTML file, no build step, no server, no account, no telemetry. Help me pick one genuinely useful deterministic job and ship it end to end. Make me add a visible version string and a help affordance on the welcome screen from the start. As we go, explain each constraint as a deliberate position rather than a limitation — I want to understand what this shape buys me before I'm tempted to give it up.
02 Roles, invariants, then the core the backbone
You buildA real tool with a deterministic core, a storage façade (one wrapper over all three storage layers) that mirrors folder → OPFS → IndexedDB, and a Web Worker for the heavy work. No AI yet.
Done whenActors enumerated & invariants written before features · replaying the event log reconstructs the state.
Before we write a single feature, make me enumerate every actor this tool has — including the ones I'll forget, like the automation that calls it and the person who only ever reads from it — and then write the invariants list: the schema validator, the state shape, the storage façade, the event bus, the keyboard guard. Then help me build the deterministic core with one validated entry point that fails loud, the mirrored storage façade, and a Web Worker for the heavy work. Keep pushing me to name the actor I've missed before you let me move on.
03 Run it locally, fall back honestly running the AI
You buildA tool that does real work with a local model — summarize, search the user's own files, read an image — and falls back to a cloud call only when the local model can't clear the bar.
Done whenRuns with the network off · asks before downloading a model · an optional one-tap upgrade to a detected local runtime · honest about what ran where.
Help me build a tiered inference path into my tool: a new user lands on in-browser WebGPU automatically — Transformers.js running an ONNX model like Gemma 4 E2B (or the latest small browser-ready Gemma) — with an optional one-tap upgrade to a faster local runtime if I detect one — never forced, never a settings maze. Never silently download a model; always ask first. Where the local model genuinely isn't good enough for the job, fall back to a cloud call and tell the user plainly what ran where. I want this driven by detection, not by a configuration screen — walk me through detecting capability instead of exposing knobs.
04 Attach the AI as a passenger AI as a helper
You buildAn AI sidecar — an AI that rides alongside the tool as an optional helper, suggesting rather than running things — on the tool from station 02: it proposes an editable artifact (a query, a transform, parameters) and the deterministic core runs it. Must still stand with the AI off.
Done whenWorks fully with AI disabled · output lands editable and overridable · a wrong generation fails loud, not silently.
Help me attach an AI "sidecar" to my tool — by sidecar I mean an AI that rides alongside as an optional helper: it suggests, the tool's own non-AI core decides and runs, and the whole thing still works with the AI switched off. Have the sidecar propose an editable artifact in the tool's own language — a query, a transform, a set of parameters — never an opaque finished result, which the deterministic (non-AI) core then runs. Keep the no-AI path fully working, and make it degrade cleanly when the key or model is gone instead of throwing up an error wall. Wire bring-your-own-key so the key stays on the user's machine. Make both firing the AI and accepting its output explicit, opt-in steps — nothing ambient. Then make me prove the tool still stands with the AI switched off, and route a deliberately wrong suggestion through the core so I can see it fail loudly.
05 A human face and an agent face works by hand and by script
You buildA tool with both faces — a human screen and a script-callable interface over the same core — driving a multi-step task with retrieval over the user's own data.
Done whenSame operation by click and by script · an importable request collection for the interface · the agent face off by default behind a developer setting.
Help me build an agent loop on top of my tool's own core — not a chat box bolted to the side — and expose a small, opt-in scripting interface plus a cross-tab channel, off by default behind a developer setting. The path a person drives and the path a script drives should be one mechanism, not two codepaths. Add retrieval over the user's own data so only the slice a given step needs ever leaves the device. Then help me package that interface as an importable request collection rather than a page of curl commands, and make me drive the same task once by hand and once by script to prove they're identical underneath.
06 When the browser can't hold it when the browser isn't enough
You buildOne escalation, done right — a background daemon, a thin desktop shell, or a small personal relay with pass-through billing and no logging.
Done whenA written reason the browser genuinely couldn't hold it · proof the invariants survive the new rung (or an explicit note of where they're relaxed, and why).
My tool has outgrown a single browser tab. First, pressure-test me hard on whether it genuinely can't run in the browser, or whether another stack would just be more familiar — I only want to escalate if the browser truly can't do the job. Then help me escalate exactly one rung and no further: a background daemon, a thin desktop shell, or a small personal relay with pass-through billing and no logging. Carry the invariants — the user's data on their disk, no telemetry, no account — as far down as the new rung allows, and tell me the precise point where this stops being something the user fully owns.
★ Capstone — ship it end to end everything, at once
What you buildOne real tool that works fully with the AI off, runs on-device by default and escalates only when it must, keeps the user's data on their disk with an export that opens without your tool and without any model, and offers both a human screen and a script-callable interface.
Help me ship one real tool end to end that ties the whole track together: it works fully with the AI switched off, runs on-device by default and only reaches for a key or relay when it has to, keeps the user's data on their own disk with an export that opens without my tool and without any model, and offers both a human screen and a script-callable interface. Then walk every kind of user through the finished thing with me — clicking the real interface the way each of them would — and help me fix whatever that walk turns up, in place, as we go.
→ The deep end — make the model itself yours where Builder crosses over · needs a GPU, not a tab
Where it goesEverything so far wired existing models into tools. The deepest version is to make the model itself yours: fine-tune a small open model on your own data, then serve it properly — batching many requests together, reusing the KV cache, running it quantized, juggling several fine-tuned adapters behind one endpoint. This is the layer the sufficiently motivated always end up in. It also leaves the single-file, in-browser shape behind — it needs a real GPU box, not a tab. (Really its own track; threaded here as the doorway.)
I've built tools that wire in existing models. Now I want to make the model itself mine. Be my guide: help me fine-tune a small open model on my own data with a LoRA, then serve it properly on a GPU — explain batching, the KV cache, quantized serving, and running several fine-tuned adapters behind one endpoint. Start me on the smallest real version, end to end, and tell me honestly where the single-file, in-browser approach stops and a GPU box has to take over.
Operator
the management pathFor the people a management college is aimed at — leaders who need outcomes, not a framework lecture. You learn the same way: feed your real situation to an AI advisor and walk out with something you can use.
Outcomes first, no purism. Call whatever model or API gets the job done — cloud, local, no-code, whatever's fastest. Keeping data close is a lever you reach for when it has to stay close, not a creed. You're here to ship results, not to prove a point.
→ walk out with: analyses and live presentations you can use this week, and a deployment plan with a running pilot for your team.
The everyday — point AI at a task, read the result
01 Data analysis — without writing the code you direct, AI does the work
What you doHand the AI your data and a question. It writes and runs the code; you read the charts and the answer, and push back. You never touch the code.
What you getReal analysis from a spreadsheet you didn't have to wrangle — and an honest read of what it does and doesn't show.
Act as my data analyst. I'm going to give you a spreadsheet [or describe my data] and a business question. You write and run the code to analyze it — I don't want to see or touch the code unless I ask. I want the answer, the charts that show it, and a plain-language read of what's going on. Be honest about what the data can and can't tell me: flag anything that looks like a coincidence, a gap, or a number I shouldn't trust, and never dress up a weak finding as a strong one. Then let me push back and ask follow-ups, and re-run the analysis as my questions sharpen.
02 Interactive presentations animate it by asking, not by hand
What you doBuild presentations that move and respond — a chart that builds and morphs, a process that plays out step by step, a diagram that assembles itself — the kind of motion that's hours of hand-animation, conjured by describing it. Still bound to your real numbers.
What you getA single-file interactive presentation with motion that makes the point — built in minutes by asking, not hours by hand.
Help me build an interactive, animated presentation for this — a single self-contained page, not static slides. I want the kind of motion that would take hours to animate by hand: a chart that builds and morphs as the story moves, a process that plays out step by step, a diagram that assembles itself, key numbers that climb on cue. I'll describe the concept, the data behind it, and the motion I'm picturing; you build it so it animates and so I can click into it live — drill into a part, change an assumption, watch it respond. Make it run from one file with the data baked in, so it opens anywhere with a double-click — no install, no account. Then let me direct it like a film: tell you what to retime, emphasize, or cut, section by section, until it lands.
The project — set up something that lasts
03 Find the work worth doing what's real, what's hype
What you doSeparate where AI genuinely pays off in your function from where it's hype. Pick the two best starting bets.
What you getTwo use cases worth piloting — and a list of ideas not worth doing.
Act as a hard-nosed AI advisor for my function — [marketing / finance / HR / ops / support / sales]. Don't sell me on AI; separate where it genuinely creates value from where it's just hype. Ask me about my actual day-to-day workflows, then help me pick the two use cases with the best payoff-to-effort ratio and the lowest risk to start with. Be blunt about which of my own ideas aren't worth doing and tell me why.
04 Prototype it this week fastest path to a yes/no
What you doStand up a rough proof with whatever's quickest — call an API, wire a no-code tool. Test whether it holds.
What you getA working rough proof and a clear go / no-go read within days.
Help me stand up a rough working proof of this use case as fast as humanly possible — calling whatever AI API or no-code tool gets there quickest. We're testing whether the idea holds, not building the final thing, so optimize purely for speed. Walk me through the fastest path: what to wire to what, in what order, and design a sharp test that tells me within a few days whether this is worth pursuing or whether I should drop it.
05 Build, buy, or adopt the real cost
What you doNow that it held, decide honestly how to do it for real — and price in what vendors hide.
What you getA build-vs-buy decision you can defend, with a real total-cost comparison.
This use case held up in a rough test. Now help me decide honestly how to do it for real: buy a SaaS product, adopt and extend a mature open-source one, or build it ourselves. Lay out the trade-offs of each for my situation, and build me a total-cost comparison that includes the things vendors keep quiet — switching cost, lock-in, what happens to my data, and what it would cost me to leave in two years.
06 Where your data can and can't go the one place this matters
What you doClassify your data: most of it is fine in a cloud API; some is regulated or residency-bound and isn't. Know which is which.
What you getA data-handling rationale that holds up — and tells you where a plain API is fine.
Help me classify the data this use case touches: which of it is perfectly fine to send to a third-party AI API, and which is regulated, sensitive, or residency-bound and can't cross certain boundaries — in my case [describe the data and where I operate]. Be concrete about DPDP and any data-residency rules that actually apply to me, and translate each constraint into a deployment choice: tell me where a plain cloud API is genuinely fine, and the narrow places where I need to keep something closer. Don't make this more restrictive than the rules require.
07 When to own the model, not rent it the deeper build-vs-buy
What you doRenting an AI API is the right default — until it isn't. Three things flip the answer toward owning a small model you fine-tune and serve yourself: data that legally can't leave, the API bill at real scale, and quality that plateaus on a narrow or vernacular domain a general model never nails. Learn to spot those thresholds — and to scope and commission the switch. You make the call; you don't run the servers.
What you getA clear read on whether and when to own a fine-tuned model — and a scoped brief you could hand to someone to build.
Act as my advisor. We currently rent an AI API for [use case]. Help me work out whether we'd ever be better off owning a small model we fine-tune and serve ourselves. Walk me through the three triggers — data that can't leave, cost at our real volume, and quality that plateaus on our specific domain or language — and pressure-test each against our actual numbers and constraints. If owning makes sense, help me turn it into a brief I could hand to an engineer or vendor: what to fine-tune, on what data, served how, at roughly what cost. If it doesn't, tell me to keep renting, and why.
08 Govern it once it's live what actually makes it good
What you doWhat matters is how well it's calibrated against real outcomes, not which model it uses. Keep an audit trail; watch for gamed metrics.
What you getA governance bar you can hold a vendor and your own team to.
Teach me how to actually govern this use case once it's live. Make the case for why the thing that matters is how well the system is calibrated against real-world outcomes, not which model is under the hood. Walk me through keeping a usable audit trail, measuring output quality honestly over time, and spotting when a metric is being gamed rather than genuinely improved — all at a level concrete enough that I can hold both a vendor and my own team to it. Give me the specific questions to ask.
09 Roll it out grow without getting stuck
What you doBring the team along, measure ROI honestly, and scale without locking into one vendor or one architecture you can't walk back.
What you getA rollout plan you can take to leadership.
Help me write a rollout plan for this pilot that I can put in front of leadership: how to bring the team along instead of imposing it, how to measure ROI honestly rather than with vanity numbers, and how to scale it without locking myself into one vendor or one architecture I can't walk back later. Flag the specific failure modes that tend to kill rollouts like this, and how to design around each one.
★ Capstone — plan + pilot your team, for real
What you'll haveA deployment plan and a working pilot for your function — a clear use case, a build-vs-buy decision you can defend, a data-handling rationale that survives scrutiny, and an ROI model leadership will accept.
Help me pull everything together into a deployment plan and a working pilot for my function: a clearly-scoped use case, a build-vs-buy decision I can defend, a data-handling rationale that holds up to scrutiny, and an ROI model I can put in front of leadership. Pressure-test the whole thing with me before I take it forward — find the weakest part of the argument and make me fix it.
One way of learning, three goals. The build tracks (Explorer, Builder) lean toward tools you own and run yourself; the management track (Operator) leans toward whatever gets the result. Both are right for who they're for — and the AI tutor is the constant underneath all three.
Your proof is the work: a tool you built, or a decision you can defend. This is about how you learn, not a brand name — it's for anyone who'd rather point an AI at a real problem than sit through a syllabus.
Anyone can build.
Point well, and let the machine teach.