Every LLM team hits the same fork eventually, either keep steering the prompt or start training the model. Here's how to read the signals before you burn a sprint finding out the hard way.
Originally published at overmindlab.ai.
A perspective on when to tinker with the prompt, and when to train your own model.
Most teams building LLM applications start the same way. They write a system prompt, test it against a few examples, and ship. Prompt engineering is cheap, fast, and reversible. Fine-tuning used to be something only teams with a training pipeline and a GPU budget could afford. Things have changed but the order of operations hasn't.
Both techniques steer model behaviour. Prompting changes what you say to the model. Fine-tuning changes the model itself.
Prompt engineering vs fine-tuning, side by side
| Prompt engineering | Fine-tuning | |
|---|---|---|
| What changes | The input | The model's weights |
| Where it lives | The context window | The model |
| Cost | Seconds, no infrastructure | GPU time and a training pipeline |
| Data needed | None, or a handful of examples | Thousands of labelled runs |
| Reversibility | Instant | Only by retraining |
| Survives a model swap | Yes | No |
| Ceiling | Plateaus quickly | High, bounded by data quality |
Why prompting is the right first move
Prompt engineering means editing what enters the context window. No adjustment of the model's weights. You're changing the input and reading the output.
For a new agent, that's almost always the correct starting point. You learn what the model can already do before you spend anything on training. Most of the behaviour changes you want, prompting will give you.
How to tell which regime you're in
This isn't a one-time decision so much as a loop. You stay in prompt-engineering mode until the eval curve goes flat, then check whether you actually have what fine-tuning needs, a narrow task and real data.
Ship prompt changes until the eval goes flat, then fine-tune.
| Where you are | What you're seeing | What to do next |
|---|---|---|
| New behaviour needed | A gap between what the agent does and what it should do | Ship a prompt change |
| Eval still moving | Each change shifts the score | Keep prompting |
| Eval flat for 3-4 changes, task is narrow, a few thousand labelled runs in hand | Plateau, and you have the ingredients | Fine-tune |
| Eval flat, but the task is broad or the labelled runs aren't there | Plateau without the ingredients | Build the dataset first |
Where prompting hits its ceiling
Prompting always runs out of road eventually, and the symptoms show up in predictable order:
- The plateau. Each prompt tweak moves the eval less.
- Whack-a-mole. The instruction that fixes today's failure mode causes tomorrow's.
- Prompt bloat. The system prompt keeps growing, slows the model down, and gets partially ignored.
- Paying rent. You're re-sending the same correction on every single call.
At that point, prompting stops being cheap. Engineering hours are the priciest line item in most LLM pipelines, and it's easy to burn a month nudging a prompt that plateaued weeks ago.
When to fine-tune
Fine-tuning updates a model's weights on examples of the behaviour you want until the model does it by default, without being told every time. It's worth trying when these conditions are met:
- The task is narrow. Fine-tuning sharpens a model on one job, not general capability.
- You have real data. A few thousand labelled runs, ideally sampled from production traffic rather than synthetic examples.
- Cost or latency matters. A smaller, fine-tuned model can outperform a much larger general-purpose one carrying a bloated prompt, at a fraction of the inference cost.
Overmind is the model training platform for AI teams. It turns your production traces into specialised models you own. Get started.
Top comments (0)