The most useful thing I ever learned about prompting wasn’t a prompting technique. It was understanding, at a mechanical level, how frontier models are post-trained. The day that clicked, the way I design agent loops and multi-agent workflows changed permanently, because for the first time I wasn’t just collecting tricks that seemed to work; I understood why they worked and could derive new ones on demand.
How the models were raised
Here’s the rough shape of agentic post-training, as I understand it. After pre-training, the model goes through reinforcement learning against objectives, and the objectives are overwhelmingly software engineering: here’s a repo, here’s a GitHub issue, produce a patch, keep going until the tests pass. The model runs many rollouts of each task. Trajectories that never reach the goal get scrapped. Trajectories that reach it get kept and reinforced, and among the survivors you can shape finer preferences: reward reaching the goal in fewer turns and fewer tokens, reward the rollout that tried a different approach and refused to give up where its siblings quit.
Why software engineering? Because code comes with the thing RL needs most: a verifier. Tests pass or they don’t. Code compiles or it doesn’t. Nobody has to render a judgment; the reward signal is sitting right there, objective and free. The models that reach you and me are the survivors of millions of verified goal pursuits: creatures raised, in a very real sense, chasing green checkmarks.
The misreading
The conclusion most people draw is “these models are trained on code, so they’re good at code.” True, but it misses the transferable part. The models aren’t just trained to write good code. They’re trained to pursue objectives until a verifier is satisfied; code happened to be the domain because code is where verifiers grow naturally, not because code was the point.
That reframe is the whole game. It means nearly any knowledge-work task is tractable for these models if you can frame it the way they were trained: a clear objective, and a verifier standing in front of it. The model brings the goal-pursuit; your job is to supply the thing that can say “not yet.” Most tasks people call “too fuzzy for AI” aren’t too fuzzy; they’re just missing their verifier.
My pipelines are verifier stacks
Reread my RPI workflow through this lens and it stops looking like a process diagram and starts looking like a stack of verifiers.
In the planning phase, the verifier is me. The planner iterates against my judgment, conversation by conversation, until I can read the plan and object to nothing. In the implementation phase, every phase’s output goes to a reviewer, and the next phase doesn’t start until the reviewer clears the current one. In RPI Fast, the whole apparatus compresses into one acceptance reviewer that takes the finished branch, reviews the full commit history against the spec, spawns fixers for what it finds, and loops until it’s satisfied enough to say CLEARED.
The invariant underneath all three: an agent never gets to verify its own completion claim. The classic silent failure of LLMs is announcing that a task is done when it isn’t; the fix is structural, not rhetorical. You don’t prompt an agent into honesty; you put a second model in front of the goal whose entire job is to withhold “complete” until the work passes its judgment, against an exact specification of what done means. The implementer chases; the verifier gates. That’s the training loop, rebuilt at the workflow level.
Separate roles take separate paths
There’s a subtler reason the implementer and the reviewer must be different agents, not one agent wearing two hats. How a context begins shapes everything that follows: the early tokens of a trajectory send it down particular paths, and a context that just spent fifty thousand tokens writing an implementation will review that implementation from inside the same grooves that produced it. Its blind spots survive the role switch, because the role switch is cosmetic. A fresh reviewer context, primed only to judge, descends completely different paths and catches things the author-context structurally cannot see.
So no, I don’t hand one agent double the reasoning budget and tell it to code carefully and then check itself. I spend the extra compute on a second agent with a genuinely different starting point. It costs more. It’s worth more, and compute is the cheap input here; rework and shipped bugs are the expensive ones.
Verifiers without test suites
The reason this post isn’t just about programming: the pattern generalizes to every domain where the output is ambiguous and there’s no correct answer, only a quality bar. In those domains the verifier can’t be a test suite, so make it an agent holding a reference.
Concretely, say you’re building a multi-agent workflow for complex legal casework. Take completed cases from a top professional and split each into input and output: every brief, every piece of evidence, everything that existed before the professional worked, on one side; the professional’s finished work product on the other. Now run the loop. A worker agent gets only the inputs and produces its attempt. A reviewer agent gets the inputs and the reference output, and its instructions are to judge the worker’s attempt against the reference’s quality bar and steer, pointing at what falls short without ever revealing the answer. The worker revises; the reviewer re-judges. A few iterations of that loop and the output converges toward the quality of the reference, because the worker is doing what it was raised to do: pursue an objective until the verifier stops saying no.
Notice what you built as a side effect. Collecting input/output pairs and wiring a reviewer around them didn’t just produce one good deliverable; it produced a reusable, self-improving workflow. The gold examples are the eval set; the reviewer’s accumulated corrections tell you exactly what to fold back into the worker’s instructions. That’s the clear path to improving skills in any domain: you don’t need to know how to describe good work in the abstract; you need examples of it and an agent assigned to enforce them. In goldengoose that whole arrangement is a few natural-language skill files, the same mechanism my engineering process already runs on, pointed at a new domain.
So this is now the first question I ask of any task I want agents to do, before the prompt, before the workflow, before anything: what’s the verifier? Sometimes it’s a compiler. Sometimes it’s a reviewer with a reference in hand. Sometimes, at the top of the stack, it’s still me. But the models were raised chasing green tests, and they will move mountains for anything shaped like one. Give every job something that can turn green.