Fine-tune moves one job
A fine-tune on a small instruct model changes how often the model hits a named job. It does not raise general intelligence. The weights you add are a LoRA adapter: a thin set of matrices you can load, swap, and throw away. The 1.5B (or 0.5–3B) base stays the same model you started with.
That distinction is the whole chapter. Teams reach for fine-tune when a demo felt "almost smart enough," then act surprised when the adapter still fails at math, still invents APIs, and still needs retrieval for anything that changed this week. The adapter never promised those things. It promised a tighter distribution on one behavior you can write down and test.
The living job in this chapter is the CI-triage labeler from agent studio. Given a failing job's log tail, emit exactly one label:
| label | meaning |
|---|---|
flake | the test fails randomly; a rerun is the cheap move |
product-bug | the failure is real and belongs in an issue |
needs-human | prod, security, or an unknown that should page someone |
A strong prompt can describe those three buckets. After a week of real logs, the same prompt still flips flake and product-bug on the same stack trace. That flip is a consistency failure. Fine-tune is on the table only after you have said so out loud, with examples.
You will ship specialist-adapter-receipt/: the job card, a reviewed example set, leak-safe splits, an adapter pointer (live T4 or fixture), an eval table, and deploy notes. The receipt is the product. The GPU run is optional evidence attached to it.