You're not learning "AI". You're learning a hot path.

Lesson 0 · the orientation the webinar slides would have given you · for a fullstack dev who last touched AI 12 years ago

You walked away from the webinar with a book reference and one screenshot (the CUDA execution-model diagram in Lesson 1). This lesson rebuilds the missing frame around that screenshot — so Lesson 1 lands as "obvious next step", not "deep end".

The one split that dissolves your fear

The word "AI" hides two almost-unrelated jobs. The thing you're rusty on is the left column. Your mission lives entirely in the right column.

TRAINING — what you studied in college

Goal: compute the model's weights from data.
Backprop, gradients, loss functions, optimizers.
The math-heavy, research-y part.
Done once, by someone else, on a big cluster.
You can ignore this for a long time.

INFERENCE — your turf

Goal: run the finished model fast and correct.
Memory layout, kernels, bandwidth, latency, cost.
The systems / performance part.
Done billions of times, in production, on your watch.
This is where a fullstack dev has an edge.

"Inference runtime engineering" — the phrase in your mission — is the right column. None of it requires you to remember how a model learns. It only requires you to make a fixed pile of arithmetic go fast on a GPU. That's an engineering problem, and you already do engineering problems.

What a model is, at inference time

Strip away the mystique and a model running inference is something you already understand: a pure function over a giant constant.

The whole shape of inference: output equals the model applied to an input.

Listen first: the one line is output = model(input) — read it as "output is what you get when you call the model on the input." The model is a fixed blob of numbers, the weights, loaded once and never changed, plus a fixed sequence of array operations. Nothing learns here; it only computes.

output = model(input)        # that's the whole shape of it
#         ^^^^^ a fixed blob of numbers (the "weights"), loaded once
#               + a fixed sequence of array operations

Four facts are all the "AI" you need to start. Each has a web-dev analogy:

Inference fact	What it means	The analogy you already have
Weights	A huge, read-only blob of numbers produced by training.	A giant config / constants file you load at boot and never mutate.
Tensors	Multi-dimensional arrays. A vector, a matrix, a stack of matrices.	Typed arrays / nested arrays. Nothing more exotic.
The forward pass	Push the input through a fixed sequence of array ops to get output.	A deterministic pipeline: same input → same output, no side effects.
A few hot ops	Elementwise (add/mul), matmul, softmax/normalization, attention. These eat ~all the time.	The hot loop in a backend service — the 5% of code that's 95% of the cost.

Your whole job, reduced to one sentence: make those hot ops run fast and correctly on the hardware. That is what a Triton kernel is. That is what Netra-style puzzles test. That is the mission.

Why your fullstack instincts are the right toolkit

The skills that make inference fast are skills you've been building for years — they just wear GPU clothes here:

You already reason about…	…which in inference becomes
Cache hits vs misses, hot/cold data	GPU memory hierarchy, coalesced access, shared memory
"Is this CPU-bound or I/O-bound?"	"Is this kernel compute-bound or memory-bandwidth-bound?"
Batching DB queries to amortize round-trips	Batching tokens/requests to amortize weight loads
Concurrency, parallel workers, race conditions	Threads, blocks, grids, synchronization (Lesson 1)
Profiling before optimizing	Benchmarking a kernel before claiming it's faster

The ML researcher who trained the model is often weaker at this table than you are. That's the opening you're walking through.

So the honest risk isn't "too advanced." It's over-preparing on training-era theory you don't need yet, and stalling. The cure is to start, and pull each ML concept in only when a lesson needs it.

What you do not need yet

Permission to skip, in writing: backpropagation, gradient descent, loss functions, optimizers, how transformers were invented, training dynamics, most of your college AI notes. When a concept like attention or quantization becomes load-bearing for a kernel, that lesson will hand you exactly the slice you need — just-in-time, not up-front.

Cold-recall defense (one breath):
"AI" = training (compute the weights — not my job yet) + inference (run the finished weights fast — my job). At inference, a model is a pure function: a fixed blob of weights + a fixed sequence of array ops over tensors. A handful of hot ops (matmul, attention, softmax) eat all the time, and my job is making them fast and correct on the GPU. My fullstack instincts about caches, bottlenecks, and profiling transfer directly.

Where this hands off to Lesson 1

You now know what you're making fast (those hot ops over tensors). Lesson 1 starts on the how: the GPU's execution model — the exact diagram from your screenshot — and how Triton lets you write one program over a whole tile instead of fiddling with individual threads. Go there next.

Primary source

Read Baseten — Inference Engineering (the overview/map, ~10 min). Treat it as the table of contents for the right-hand column above: models, hardware, software, optimization, production. Don't summarize it — just let it confirm the shape of the field. It's the same "map, not main output" role noted in your RESOURCES.md.

💬 I'm your teacher for this — ask me followups any time. If any analogy in the tables above feels too loose, or you want the one-screenshot webinar context reconstructed further, ask and I'll tighten it before you move to Lesson 1.