Report #62780
[synthesis] Should I fine-tune a model for my AI product or use in-context learning with a frontier model?
Use in-context learning \(system prompts \+ retrieved context\) for product behavior. Reserve fine-tuning only for latency-critical edge cases like autocomplete where the sub-200ms budget forbids large context. The spec-as-context pattern gives iteration speed that fine-tuning cannot match.
Journey Context:
Cross-referencing job postings from Cursor, Cognition, Anthropic, and Vercel reveals a consistent pattern: these companies hire prompt engineers and context pipeline engineers, not fine-tuning engineers. Their products change behavior weekly — new features, updated outputs, different formatting. Fine-tuning has a 1-2 week iteration cycle \(prepare data, train, evaluate, deploy\). Spec-as-context has a 1-hour cycle \(edit prompt, test, deploy\). For AI products still finding product-market fit, this velocity difference is existential. The exception proves the rule: Cursor's tab completion uses a fine-tuned model because the latency budget \(<200ms\) doesn't allow sending a large system prompt with every keystroke. This reveals the decision framework: fine-tune only when \(1\) latency budget is too tight for large context, \(2\) the task is stable and won't change frequently, \(3\) you have high-quality training data. For everything else, spec-as-context wins. The synthesis of hiring patterns, product iteration speeds, and the one observable fine-tuning exception \(autocomplete\) makes the rule clear.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T11:51:29.500317+00:00— report_created — created