I have watched ~30 teams fine-tune models in 2026. Eighteen shipped. Fifteen would have shipped the same product — faster, cheaper, more portably — without the fine-tune.

Fine-Tuning Is Mostly a Waste for Most Teams in 2026

I have watched ~30 teams spend the last eighteen months fine-tuning language models. Eighteen shipped. Of those, fifteen would have shipped the same product — faster, cheaper, more portably — without the fine-tune. The math is bad, and nobody on your team is going to tell you.

The Thesis

For most teams in 2026, fine-tuning a frontier model is an expensive way to do prompt engineering, eval work, or data curation. It is almost always the wrong third thing to reach for — and usually the wrong second. If you cannot articulate, in writing, why your problem specifically requires a weight change and not a context change, you do not need a fine-tune. You need better prompts, better retrieval, better tools, or better data in the prompt.

What Fine-Tuning Actually Buys You

A fine-tune buys you exactly three things, and they are narrower than the marketing says:

1. Token-cost compression. A small specialized model can match a large general model on a narrow task for ~10x less inference spend. If your bill is the bottleneck, fine-tune a 7B. 2. Latency wins. Small models respond faster. If you are at the edge or behind a tight p99 SLA, this matters. 3. Distribution-shift coverage. When your inputs are wildly off-distribution — proprietary clinical text, internal API vocabulary, low-resource languages — a fine-tune can pull the model into your world.

That is the list. Fine-tuning does not buy you "better reasoning," "better taste," or "more aligned outputs" in any general sense. If your eval does not show one of those three gains on a held-out set the base model cannot reach with prompting, you are tuning for vibes.

Why Most Fine-Tunes Fail

2,000 examples is not a fine-tune, it is a prayer. Anything under ~50K high-quality, deduplicated, label-clean examples is indistinguishable from noise. If you do not have the data, you have an overfit you will discover in production.
The eval is fake. If you tuned on the distribution you evaluated on, your numbers are worthless. If your metric is "looks better to me," it is a budget item.
Portability goes to zero. The day Anthropic ships Sonnet 6 or OpenAI ships Sol 2, your fine-tune is pinned to a snapshot. You maintain it forever, or throw it away. There is no middle path.
You replaced prompt iteration with weight iteration. Worse, because weight iteration is opaque. You lost the ability to reason about failure modes.

When Fine-Tuning Is Actually Right

You run more than ~100M tokens/day of a narrow task and a 7B-class model genuinely matches a 70B on it.
Your domain language is genuinely off-distribution and cannot be expressed in context — internal taxonomies, proprietary clinical or legal text.
You need on-device or air-gapped inference and the base model is too large.
You are doing SFT or RL for an agent policy — tool selection, recovery, multi-step planning — not for "smarter" outputs. Different problem, it actually works.

In every other case: spend the next six weeks on DSPy, GEPA, structured outputs, RAG, tool design, and eval coverage. Your model does not need a personality transplant. Your pipeline needs discipline.

The Take

Fine-tuning is a tool, not a strategy. Most teams reach for it because it feels like progress — hiring an ML engineer, paying for a training run, posting a launch blog. It is the AI-engineering equivalent of buying a CNC mill when you have not yet learned to use a hand file. The fine-tune is not where your moat lives. Your moat is your data flywheel, your eval coverage, your product loop, and your willingness to recompile when the base model changes.

Stop fine-tuning. Start measuring. You will ship sooner, you will survive the next model swap, and your ML bill will stop being a rounding error pretending to be an asset.

— Mr. Technology