I remember walking to the bus from high school, staring at a Motorola 6800 instruction set manual. I didn’t really understand what I was looking at—boolean expressions, instruction encodings, timing tables—but I was obsessively fascinated by the mechanism of it all. Here was this complicated machine where if I understood it I would have power & control.

I feel the same way about AI models right now. I don’t claim to understand the details, not yet, but I’m fascinated by the mechanism of it all. I’m interested in both:

• How models work but also,

• The machinery that makes a model.

It’s this latter topic, how a model gets constructed, that I will begin to explore in this post (& possible followups).

I love baking. You take ingredients in one form & transform them to a totally different form. The ingredients aren’t palatable in themselves but what you create from them is delicious. Oh and also baking is sensitive to initial conditions—you can make a small change early in the process & it will have a large consequence later.

I’ve been experimenting with cold proofing, where you let the yeast do its work overnight in a refrigerator. As I was working to understand models it struck me that there’s an analogy there to creating models, at least as I understand the process so far (please correct me in the comments if I’ve gotten something wrong).

First, though, a progressively revealed story about what we mean by a model. I’ll over-simplify but then reveal more complexity a little at a time.

By “model”, we mean a computer system that can converse with a human (see, told you I’d over-simplify—hope you stay with me, this won’t take long).

Actually it’s a little more complicated than that. The model is split into 2 parts:

• A user interface that takes care of formatting inputs & outputs & sequencing & authentication & all that stuff.

• The model proper where the magic happens.

The user interface is built using conventional programming techniques (even though “convention” has changed radically in the last 2 years). The model proper, though (our topic of exploration) is built using radically different techniques.

A model is a bag of numbers. For today’s purposes that’s enough (maybe some day we’ll get to how those numbers are used when the model is producing useful words, but I’d have to understand it a little first).

How did we come up with these numbers? Unlike in programming, where you lay out a sequence of statements the result of which is a program, AI models result from training.

Training bears some resemblance to programming—you change an artifact to modify its future behavior—but also some huge differences.

You wouldn’t just magically guess a bunch of correct numbers in one go. Oh no, oh no. First we get some approximately correct numbers & then we tweak them to get even better numbers. The two processes are wildly different.

(Near as I can tell, there’s pre-training, post-training, & mid-training (about which I know nothing), but there’s not “training” except as the composition of pre-, mid-, & post-. Here’s hoping the vocabulary evolves.)

Pre-training is a big batch. The whole team sets up the initial conditions—the data & the blank model. They run the data backwards & forwards through the model a gajillion times. They take snapshots along the way in case of crashes. They check for signs that the pre-training has driven off into the weeds & needs to be tweaked & restarted. Pre-training is a big bet—hundreds of millions of dollars & (more expensively) months of delay.

(I need to learn more about how pre-training folks collaborate.)

Pre-training is the cold proofing of model training.

• You mix some stuff together.

• You put it away somewhere where you can’t mess with it.

• You just have to let it play out.

• The result isn’t usable but it’s the precursor to the process that follows.

Post-training is lots of little batches. Folks (called “researchers” but in my naive bluntness I’d call “model engineers”) look at particular problems the raw model addresses poorly & explore possible tweaks that might improve performance. The result is lots of little chunks of code & data (the surviving experiments) that apply to the model as it currently exists.

Post-training supplements the original model. Apply enough supplements & you have a model that, when paired with a UI & a user & compute can respond to, “Give me 5 unusual focaccia toppings.”

Post-training is the shaping & cooking of model training. You take something with potential & make it delicious for humans. (The analogy doesn’t cover the collaborative, iterative, & reversible nature of post-training—le sigh.)

In a followup I’m going to explore the different teams & roles involved in this whole process. They have some interesting divergences of incentives, tools, rhythm, short-term vs long-term, feature vs future, backgrounds, & culture.

First, though, I wanted to double check my understanding of the process. Let me know if I got something wrong above.

Most teams don’t have a strategy problem. They have an adaptation problem.

Your plan was never going to survive contact with reality. The question is whether your organization bends or breaks when it doesn’t.

I help teams bend. Adapt to Thrive.

Booking a handful of custom talks and advisory engagements now. I interview your people, measure your real software flows, and hand you the truth plus what to do about it.

Curious whether it fits? Tell me about your team.