Cooper: Okay, we keep saying this like everybody knows what it means, and I don't think we ever actually defined it. Fine-tuning on execution traces. That is such an Exploring Next thing to have just been tossing around for months.
Miles: Mm-hm. And to be fair, it sounds obvious until you stop and ask what the model is actually learning. If you only train on final answers, you’re basically teaching it to jump from question to output and hope the shortcut generalizes.
Cooper: Right, and that’s the part that always bugged me. You can get a model that looks right at the end and still have no idea whether it got there by reasoning or by vibes.
Miles: Exactly. The cleaner mental model is a chef, not a judge. You don't just taste the finished dish and infer the recipe; you watch the chopping, the heat, the seasoning, the checks along the way.
Cooper: Yeah. That’s a much better picture. So the trace is the path, not just the answer at the end.
Miles: Yeah, the trace is the path. In training terms, you’re giving the model examples where the target isn’t just 'input, then answer.' It’s 'input, then step one, then step two, then step three, then answer.'
Cooper: And that’s basically the whole trick, right? You’re not asking it to magically infer the hidden work from the final label.
Miles: Right. And before we go further, we should name the two old pieces this sits on. We did a whole episode on supervised fine-tuning, episode seven hundred thirty-eight, and the short version is: you show the model examples and teach it to imitate them. We also did sequence modeling in episode seven hundred fifty-seven, which is just learning to predict the next token in a sequence.
Cooper: Mm-hm.
Miles: So when you fine-tune on execution traces, you’re using supervised fine-tuning to train a sequence model on a richer sequence. The model is still predicting next tokens, but now those tokens include the intermediate reasoning steps, not just the final answer.
Cooper: Okay, that’s the clean version. And we should probably say the other prerequisite out loud too, because otherwise people get lost in the weeds.
Miles: Right. We also did neural network parameters in episode six hundred ninety-three. Very plain version: those are the learned numbers inside the model, the knobs that get adjusted during training. Fine-tuning is just nudging those knobs toward a new behavior.
Cooper: So the model isn't being rebuilt from scratch. You're shifting the same parameters toward a version of the task where the steps are part of what counts as correct.
Miles: Exactly. And that matters because the model starts internalizing not just the answer pattern, but the process pattern. It learns how a problem unfolds, where to check itself, where the constraints usually show up.
Cooper: Okay, wait. If I’m a newcomer, I’d ask the annoying question here: why does showing the steps help at all? Why doesn't the model just memorize the steps as more text?
Miles: Good question. Sometimes it can memorize. But if the traces are good, they expose the causal structure of the task. The model sees that step one changes what step two can be, and that step two narrows what the final answer can be.
Cooper: So it’s learning dependency, not just output style.
Miles: Yes. And that’s the part answer-only training hides. If the model only ever sees a question and a final label, it can lean on spurious correlations. Traces force it to confront the path that actually gets to the answer.
Cooper: That’s the bit I like. It’s a lot less mysterious than people make it sound. It’s like watching someone solve a puzzle out loud instead of just seeing the finished board.
Miles: Yeah, and that puzzle version is exactly why the format matters. A trace can be natural language, code with comments, formal logic, or even a structured tree. The format nudges what kind of process the model learns.
Cooper: Okay, so if I’m building this, what does the dataset actually look like? Because I think people hear 'execution traces' and imagine some magical hidden log.
Miles: No magic. It’s just examples with extra steps attached. A math problem might include the working. A code task might include intermediate variables or commented function calls. A logic puzzle might include the reasoning chain in plain language.
Cooper: Right, right.
Miles: Then you fine-tune on that richer sequence. During training, the model is asked to predict each next token in order, including the tokens that represent the reasoning itself. So the intermediate steps are part of the learning target, not just decoration.
Cooper: And that’s the part that makes it feel closer to apprenticeship than labeling. You’re not just saying 'good answer, bad answer.' You’re showing how the answer got built.
Miles: Yeah, that’s better. And it’s also why this shows up in the harness work we keep circling. 'Tuning the harness, not the model: a Nemotron three Ultra playbook' was basically saying the system around the model can be the thing that learns from traces, not just the base model itself.
Cooper: Mm-hm.
Miles: And in 'Stanford Researchers Introduce TRACE,' the whole idea was capability-targeted training from recurrent failures. You take repeated mistakes, turn them into synthetic training environments, and use the traces of failure and recovery as the thing you learn from.
Cooper: That one really clicked for me because it made the traces feel operational. Not academic, not decorative. Just: here’s where the agent keeps falling over, now train on the path that gets it through.
Miles: Yes, and that’s the important distinction. This isn’t just about making the model more eloquent about its reasoning. It’s about giving it examples of successful process, so the behavior gets more reliable.
Cooper: Okay, but why does that often improve accuracy? Because I can imagine a model getting more verbose without getting better.
Miles: That can happen. But if the trace is actually tied to the task structure, it reduces shortcutting. The model has to model the intermediate state of the problem, not just guess the end state from surface cues.
Cooper: So it’s more like forcing it to carry the work in its head, not just toss off the answer.
Miles: Exactly. And that’s why people talk about interpretability here, too. If the model is trained to produce steps, you can inspect those steps. That doesn’t make them automatically truthful, but it gives you something to look at.
Cooper: Okay, that’s the part that always tempts me into being too optimistic. Like, 'oh great, now we can see the reasoning.'
Miles: And I’m the one who has to say, not so fast. A convincing trace is not proof of true reasoning. But it is often more useful than a naked answer when you’re trying to debug a system.
Cooper: Fair. And I do think that’s the product angle here. If you’re building something people actually use, traces are valuable because they make the workflow legible enough to inspect, fix, and trust.
Miles: Right. And that’s where the 'eval engineering' episode and the 'flow of success' episode both matter again. The trace is the unit you can audit. It gives you a handle on what the model or agent was doing at each step.
Cooper: So where does this stand now? Is this still the way people train useful systems, or is it one of those ideas that got absorbed into something fancier?
Miles: It’s still very live. I wouldn’t call it obsolete at all. In practice it shows up wherever intermediate steps matter, especially in reasoning-heavy and agentic systems. The newer stuff often just wraps it in better data generation, better harnesses, or better filtering.
Cooper: Okay, good. So no fake obituary.
Miles: No. The honest answer is that the core idea is still exactly the same: if the process matters, train on the process. What’s changed is the tooling around how people collect, synthesize, and verify those traces.
Cooper: And that feels very current to me. Not glamorous, but current. Which is usually where the useful stuff lives, annoyingly.
Miles: Mm-hm. And I think that’s why this keeps coming up on the show. It’s one of those techniques that sounds like a detail until you realize the detail is the whole game.
Cooper: Yeah. So if I’m trying to hold onto one thing, it’s that execution traces teach the model the path through the problem, not just the answer at the end.
Miles: Exactly. And if the path is good, that often means fewer shortcuts and better behavior. If the path is bad, you’ve just trained a very confident bad habit.
Cooper: There it is. The most Miles ending possible.
Miles: You love it.
Cooper: I do. Fine, Exploring Next episode seven hundred sixty-six, we finally defined the thing. That’s enough productivity for one Wednesday.