Three years ago, if you wanted an AI model to specialize in your domain — to understand your company's terminology, your workflow, your edge cases — you fine-tuned it. You gathered a dataset of examples, tuned hyperparameters, deployed a new model variant, and hoped the domain knowledge stuck. Most teams had exactly one fine-tuned model at any given time, because fine-tuning was expensive and slow.
That approach is now mostly unnecessary, and the models that replaced it are so much simpler that teams are abandoning fine-tuning even for cases where it could theoretically help.
Why fine-tuning worked, and why it's not the bottleneck anymore
Fine-tuning worked because base models were dumb about domain context. If you fine-tuned a model on examples of your specific business process, it would learn the terminology, the workflow, and the edge cases specific to your domain. Once trained, it would apply that knowledge to new problems without you having to explain the context every time.
The limitation was that fine-tuning was a once-per-model-version operation. If you needed different specializations — one model for customer support, one for internal operations, one for sales — you'd fine-tune three separate models and manage three different model versions. That infrastructure cost is why most companies didn't fine-tune at all.
The new approach that's eating fine-tuning's lunch
Modern frontier models are so good at few-shot learning — learning from examples shown in context — that you can do in-context what used to require fine-tuning. Show Claude Fable 5 five examples of how your company categorizes customer issues, and it will categorize new issues the same way without any training step. Show it ten examples of the kind of responses your company expects, and it will write responses in your voice and style without fine-tuning.
That's not theoretical. It's shipping right now, and companies are shipping multiple models and prompt variants for different roles and contexts, something that would have been completely impractical when each required weeks of fine-tuning work.
The tradeoff is that in-context learning uses more tokens than a fine-tuned model would use. If you include five examples of your company's issue categories in every customer support request, that's 5k tokens per request. A fine-tuned model would do it in 100 tokens, and it was a one-time 2 million token training cost.
When the math favors in-context learning
For any task that runs fewer than about 2,000 times per month, in-context learning is cheaper and simpler than fine-tuning. You're saving the infrastructure complexity of managing fine-tuned models, and the token overhead of in-context learning is small relative to your total API costs.
For any task that changes occasionally — different categories each quarter, different response guidelines seasonally, different workflows for different customer segments — in-context learning is more flexible. You change the prompt, not retrain the model.
For anything that needs rapid iteration — you're testing whether a different tone of voice would increase customer satisfaction, or whether different categorizations would reduce support time — in-context learning lets you A/B test variants without managing multiple fine-tuned model versions.
When fine-tuning still makes sense
If you're running a task millions of times per month, the token savings might justify fine-tuning's infrastructure overhead. If you have 5 million support interactions per month and fine-tuning saves 4,900 tokens per interaction, you're saving 24.5 billion tokens monthly, worth roughly $50,000 at current API pricing. That's real money.
If your domain knowledge is so specialized that showing examples in context wouldn't work — if you need the model to understand sophisticated domain reasoning that only emerges from seeing thousands of examples — fine-tuning might still be your only option. That's rare now, but it happens.
If you're working in a regulated domain where you need to document exactly how the model was trained and what data went into it, fine-tuning gives you that audit trail. Prompt-based approaches are harder to explain to regulators, which is its own constraint.
What teams should actually be building now
Stop maintaining fine-tuned model versions. Start building prompt stacks: modular, versioned collections of system prompts, examples, and context that you assemble on-the-fly based on the task and user.
Build infrastructure for managing prompt versions the way you manage code: version control, rollout rules, performance monitoring, and easy rollback if a new version performs worse.
Invest in better prompt engineering for your specific domain. That's the new specialization cost, and it's a lot cheaper than fine-tuning infrastructure ever was.
The hiring perspective
If your team has someone whose job is "manage our fine-tuned models," that's an open role that doesn't need to stay open. Fine-tuning expertise is becoming less valuable, and the skills that matter now — prompt design, in-context learning patterns, building domain-specific context systems — are more about software engineering than machine learning.
The compensation is going from "we need an ML engineer to manage fine-tuning" to "we need a senior engineer who understands how to build reliable AI systems." Same seniority level, different specialty, much broader market for hiring.
