Training
How a model gets made. Pre-training installs knowledge, post-training shapes behavior, and evals tell you whether either worked.
Why it interests me: I build on models rather than train them, so the question is which lever matters to a consumer and which is someone else's problem.
Training › Pre
Predict the next token over a huge pile of text. This is where the compute and money go, and where facts and skills come from. The output is a base model that autocompletes rather than answers.
Why it interests me: If a model never saw something here, later steps can't really add it. That sets the ceiling for everything downstream.
Training › Post
Turn a base model into an assistant. SFT copies examples, RLHF and RLAIF use graded preferences, RLVR uses answer keys, and agent training grades whole multi-step runs.
Why it interests me: Most of what makes a chat model feel like one happens here, for a rounding error of pre-training's cost. Who grades the answer turns out to explain most methods.
Training › Evals
Tests for systems whose output isn't one right answer. A dataset, a way to run the system on it, and a scorer.
Why it interests me: You get what you measure, in training and in my own tools. Without an eval, "it seems better" is a vibe.
Training › Evals › coding
Code can be checked by running it. Did the tests pass, did the diff touch only what it should. That makes coding the easiest place to grade an agent.
Why it interests me: Checkable answers are why coding agents improved so fast. The open question is how far the same trick reaches past code.
Training › Evals › judges
When nothing is checkable, have a model grade the output against a rubric or pick the better of two.
Why it interests me: Judges are cheap and scale, and they can be gamed or drift. When to trust one, and how to check the checker, is the interesting part.
Usage
Who the agent is working with, which changes what good looks like. Another agent, a person, or a codebase.
Why it interests me: The same model is a different tool in each of these. Splitting them keeps me from judging one by the standards of another.
Usage › A2A
Agents handing work to other agents. An orchestrator picks the agent, gives it a place to work, tracks the job and checks the result.
Why it interests me: Once more than one agent runs, the hard parts are coordination and trust between them, not any single prompt.
Usage › A2H
An agent whose output is for a person. The measure is whether the person ends up better off, not whether the task finished.
Why it interests me: Larry, my AI life coach, lives on this branch. It's the one that touches life outside of code.
Usage › A2H › help me think
AI as a thinking partner. Pull in context, ask good questions, and catch what I'd miss, rather than hand over a finished answer.
Why it interests me: The question is whether it makes my thinking sharper or just does it for me.
Usage › A2H › enabling environment
Andy Matuschak's idea of a place that expands what you can do. With AI, the key is less how I prompt it and more how it prompts me.
Why it interests me: Building these is fun, and that is also the trap. My AI policy pushes back on building one more.
Usage › A2C
Agents writing code. Chat-oriented programming, where I direct and review and the agent types.
Why it interests me: It's the branch I've written about most, and where the tools change fastest.
Inference
Running a trained model. Prefill reads the prompt, decode writes the answer one token at a time.
Why it interests me: As a model consumer, this is the part I pay for on every call.
Inference › Efficiency
Getting more answer per GPU. The KV cache, quantization, smaller and mixture-of-experts models, speculative decoding, batching.
Why it interests me: Faster isn't always better. Fast tokens can still be wrong answers, so speed has to be weighed against thinking.
Inference › Efficiency › costs
What a token costs, and how that shapes which model gets which job.
Why it interests me: I can't afford all the expensive tokens I want, so routing work to the right model is a daily choice.
Multimodal
Models that take in and give back more than text. Pictures, diagrams, speech and video, on the way in and on the way out.
Why it interests me: Text is the narrowest pipe between me and a model. Each extra channel changes what I can ask for and what it feels like to work together.
Multimodal › explainers
Turning something I want to understand into a page I can play with. A model drafts the interactive part, I check it against the source.
Why it interests me: An explainer is the test of whether I understood the thing, and AI made building one cheap enough to do for a single lecture.
Multimodal › voice
Talking to the model instead of typing. Dictation for commands at the desk, and a model that talks back on a walk.
Why it interests me: I say things out loud that I would never type, and it works where a keyboard doesn't. That changes where I think with it, not just how fast.
Multimodal › video
A camera or a recording as the input. The model watches a card trick, a kettlebell swing or a lecture and tells me what it saw.
Why it interests me: Most of what I do away from the keyboard is visible but never written down. Video is how a model gets to see it.