Why Post-Training Is Becoming as Important as Pretraining for Modern LLMs

Suppose your team is building an internal pull-request assistant for a TypeScript service. A developer asks it to review a change, run the relevant tests, explain any failure, and propose a minimal patch. The assistant needs more than the ability to produce plausible TypeScript. It must interpret the request, inspect the right files, use tools in a sensible order, avoid inventing test results, and stop before turning a two-line fix into a refactor. That gap—between knowing a lot and behaving usefully—is why post-training now matters almost as much as pretraining.

Pretraining builds broad capability

Pretraining is the long, expensive stage where a model learns to predict the next token across a huge collection of text, code, and other training material. A token is a chunk of text that may be a word, punctuation mark, or fragment of a word. By repeatedly predicting missing continuations, the model picks up grammar, programming patterns, facts, APIs, styles of reasoning, and correlations between a request and a likely answer.

For the pull-request assistant, pretraining is why the model may recognize a Jest failure, understand that a TypeScript type is too broad, and write a likely correction. But the pretraining objective has an important limitation: it rewards predicting text that resembles its training distribution. It does not directly reward asking a clarifying question, calling a test runner, returning a valid structured tool call, or admitting that the repository does not contain enough evidence to support a claim.

That is not a minor product-polish problem. Next-token prediction produces a capable generalist, but software engineers evaluate the assistant as an operator in a workflow. Did it touch only the intended files? Did it run the command it said it ran? Did it preserve the project’s conventions? Was its patch correct? Those are behavioral requirements, and they need a training signal closer to the work itself.

Post-training teaches a model what to do with its capability

Post-training is the collection of training stages applied after pretraining to shape a base model into a useful assistant. It usually begins with supervised fine-tuning, or SFT: training on examples of an input paired with a desired output. For our pull-request assistant, an example might include a developer request, repository context, a sequence of tool calls, a concise diagnosis, and a patch that fixes the bug without unrelated changes.

SFT is valuable because it makes desired behavior concrete. Rather than hoping the model infers that it should run a narrow test before suggesting code, you show it many well-formed examples. You can teach response format, code-review tone, tool syntax, refusal behavior, and repository-specific policies. If your organization wants the assistant to cite the file and line range supporting each review comment, SFT is one direct way to make that pattern common.

But examples alone do not cover every ambiguous case. A model can imitate a good tool-use trace while choosing the wrong trace when the codebase differs from anything it saw. This is where preference training and reinforcement learning enter. Preference training uses comparisons: given two candidate responses, a rater or automated judge indicates which one is better. Reinforcement learning, or RL, then adjusts the model to increase the likelihood of choices that receive higher reward.

For the running example, imagine two reviews of a failing pull request. One confidently proposes a null check without running a test. The other first runs the focused test, traces the failure to an unexpected undefined value, changes a single guard, and reports both the command and result. A preference dataset can label the second trajectory as better. An RL setup can go further and reward outcomes such as “the patch applies,” “the targeted test passes,” “no forbidden file changed,” and “the final explanation matches the observed output.”

The important shift is from answer quality to trajectory quality

A trajectory is the sequence of decisions an agent makes: reading files, searching symbols, calling tools, interpreting results, editing code, and reporting back. For a chat-only assistant, the visible answer may be most of the product. For a coding agent, the path matters because an attractive final paragraph can conceal a bad edit, a fabricated command result, or unnecessary work.

This gives post-training a powerful advantage: many engineering tasks have verifiable intermediate signals. A compiler either accepts the patch or does not. A test either passes or fails. A linter reports a count. A sandbox can check whether the agent obeyed an allowlist of commands. These checks are not perfect measures of software quality, but they are much less subjective than asking whether a paragraph “feels helpful.”

Modern reasoning-oriented training increasingly combines these signals. Models may be trained to spend more tokens working through a problem when there is a reliable way to check the result, then to present a cleaner answer to the user. DeepSeek’s R1 report is a visible example: it describes large-scale RL producing reasoning behaviors, while also noting that additional stages and initial supervised data helped address readability and language consistency. The lesson is not that every team needs to run giant RL jobs. It is that the behavior of the finished model is increasingly determined by the feedback loop after the base model exists.

Why pretraining alone is no longer the whole competitive story

Pretraining still determines the ceiling. If the base model cannot parse a complicated generic type, recognize an unfamiliar framework, or retain enough context to inspect a large diff, post-training cannot reliably create that capability from nothing. It can overfit a narrow format, but it cannot cheaply substitute for broad knowledge and representation learned at scale.

Still, as more labs can obtain strong base models, the differences users feel often move downstream. Two models with similar coding knowledge can behave very differently in the pull-request workflow. One may eagerly modify ten files. Another may formulate a plan, run the smallest useful test, make one edit, and surface uncertainty. The latter is not necessarily “smarter” in a general sense; it has been optimized more effectively for the job.

This is also why a model release described only by parameter count or pretraining data tells engineers too little. Ask what its post-training included: instruction data, coding traces, tool use, preference data, synthetic problems with executable checkers, safety policies, and agent evaluations. Ask whether the released artifact is a base model or an instruct model. A base model may be excellent raw material but frustrating in an editor. An instruct model may be immediately useful but carry choices about style, refusals, verbosity, and tools that do not match your environment.

Post-training is an engineering loop, not a final coat of paint

For a team building the pull-request assistant, the practical implication is to treat post-training like product engineering. First, define the behaviors that matter: make minimal edits, run tests before claiming success, never invent tool output, and escalate ambiguous security changes. Then collect realistic tasks and build evaluators. Some evaluators can be deterministic, such as whether a patch compiles. Others need review, such as whether the diagnosis was proportionate to the evidence.

1. Start with a capable base or instruct model and a small set of real repository tasks.
2. Log failures as concrete examples: wrong file selection, invalid tool calls, noisy patches, unsupported claims, or missed tests.
3. Turn what can be checked into automated rewards or regression tests.
4. Use curated demonstrations and preference comparisons for qualities that are harder to score automatically.
5. Re-evaluate after every training or prompt change, because optimizing one behavior can degrade another.

There are real risks. A reward that values passing tests can encourage an agent to weaken tests. A preference dataset can accidentally teach reviewers to prefer confident, long explanations over correct short ones. Narrow fine-tuning can make a model worse outside the target repository. This is why evaluation must include adversarial cases and why human review remains necessary for the criteria that matter but resist clean measurement.

Pretraining gives the pull-request assistant the latent ability to read and write code. Post-training teaches it how your team wants that ability exercised under constraints. As LLMs move from answering questions to taking actions, that second problem becomes central. The winners will not merely be the models that have seen the most text. They will be the models—and the teams around them—with the best feedback loops for turning broad capability into dependable work.