TL;DR: Skills and fine-tuning solve different problems. Skills specify behavior through structured prompting and are updated in hours. Fine-tuning adjusts model weights and requires training data, weeks of iteration, and retraining when requirements change. For most recurring workflows with human review gates, skills win on iteration speed, transparency, and total cost of ownership.

At AEM, we build Claude Code skills for recurring enterprise workflows. That context matters here, because both approaches are pitched as solutions to the same problem: "Claude is not doing exactly what we need for this workflow." The diagnostic question is: why is it not doing what you need? The answer determines which approach is correct.

Fine-tuning changes what the model knows. Skills change what the model does with what it knows. Most production failures are the second problem.

What does fine-tuning actually do?

Fine-tuning adjusts model weights on a training dataset to shift the model's default behavior permanently. It changes what the model knows and how it responds by default, not what it is instructed to do in a given session. It is the right choice when you need a behavior baked into the weights:

  • You need style or tone alignment at high volume: a brand voice that must be consistent across 50,000 outputs per month
  • You are working in a specialized domain with vocabulary, formats, or conventions that are too extensive to encode in a prompt
  • The task requires implicit pattern recognition from a large corpus of examples that cannot be expressed as explicit rules
  • The workflow is fully automated with no human review, meaning instruction interpretation errors will not be caught before output is used

Fine-tuning has real costs. Training a custom model requires labeled examples (typically 100-1,000+ per behavior you are tuning), compute time, and evaluation cycles. At OpenAI's current pricing of $25 per million training tokens, fine-tuning GPT-4o on a 1,000-example dataset costs $50-$100 in training compute alone; the fine-tuned model then incurs a 50% inference premium on every subsequent output (OpenAI API Pricing, 2024). More importantly, when requirements change, the fine-tuned model does not update automatically. You retrain. That cost reality is reflected in adoption numbers: only 9% of production models in enterprise are fine-tuned, despite heavy vendor promotion (Menlo Ventures, 2024 State of GenAI in the Enterprise, n=600 US IT decision-makers).

What do skills actually do?

Skills specify behavior through structured prompting: a description that activates the skill, process steps the model follows, output contracts that constrain the format, and reference files that provide domain context. Output contracts with constrained decoding reach 100% schema compliance regardless of model size, eliminating the hallucinated fields that make freeform output unreliable in production pipelines (OpenAI Structured Outputs, 2024).

A skill is updated by editing a text file. Deployment is immediate. The full iteration cycle from "requirements changed" to "new skill version in production" is measured in hours, not weeks.

Skills are also transparent. When a skill produces wrong output, the failure is diagnosable by reading the skill file. Is the description activating correctly? Is the output contract specific enough? Did the model read the relevant reference file? Each failure mode corresponds to a specific, fixable element of the skill design.

Fine-tuned model failures are less transparent. When a fine-tuned model produces wrong output, the cause is in the weight adjustments from training, which are not directly readable. Fixing it requires more training data or a different training approach, both of which require another full training cycle.

"The failure mode isn't that the model is bad at the task — it's that the task wasn't specified tightly enough. Almost every production failure traces back to an ambiguous instruction." — Simon Willison, creator of Datasette and llm CLI (2024)

Fine-tuning a model to execute ambiguous instructions produces a model that executes ambiguous instructions consistently. The consistency does not fix the ambiguity. Skills force you to resolve the ambiguity in the specification before deployment. That constraint is an advantage.

When do skills win?

Skills are the better choice for most recurring enterprise workflows because of four properties that fine-tuning cannot replicate: iteration speed measured in hours rather than weeks, transparency that lets a non-ML engineer read and debug the failure, native support for human review gates, and per-workflow specificity without model management overhead. Each matters for different reasons.

  1. Iteration speed: business requirements change. A skills-based workflow adjusts in hours. A fine-tuned model takes weeks to retrain. For workflows that evolve quarterly, fine-tuning creates a permanent lag between requirements and model behavior.
  2. Transparency: a skill is a document that a non-ML engineer can read, debug, and update. A fine-tuned model's behavior requires ML expertise to diagnose and modify. For teams without ML infrastructure, skills are the only viable option.
  3. Human-in-the-loop compatibility: most enterprise recurring workflows include a human review gate before output is used. Skills are designed for this: they can pause for approval, present multiple options, and route different output types to different reviewers. Fine-tuned models do not have a native mechanism for this workflow structure.
  4. Per-workflow specificity: a team with 15 recurring Claude workflows does not want 15 fine-tuned models. Skills allow multiple specific workflow behaviors from the same base model without any model management overhead.

The enterprise evidence matches this pattern. 88% of organizations now report regular AI use in at least one business function, up from 78% a year prior (McKinsey State of AI, March 2025). Of those using generative AI, 70% augment base models with retrieval systems rather than fine-tuning (Databricks State of Data + AI, 2024). The dominant enterprise pattern is prompting-first, not fine-tuning-first.

In our builds at Agent Engineer Master, we have not seen a small-to-mid team workflow where fine-tuning produced better production reliability per dollar than a well-designed skill library. The economics do not favor fine-tuning at this scale: the preparation, training, and retraining costs exceed the value before the first production run.

When does fine-tuning win?

Fine-tuning wins in three specific scenarios where skills reach a ceiling: high-volume automated pipelines without human review, deep domain specialization with vocabulary too extensive to encode in a file, and knowledge gaps the base model genuinely cannot fill. Outside these three cases, skills are the faster and cheaper path to production reliability.

  1. High-volume automated pipelines: when a workflow runs 10,000+ outputs per month with no human review and the failure cost of individual outputs is low, fine-tuning's upfront investment is amortized across enough volume to justify it. Style consistency at this scale benefits from weight-level adjustment that skills cannot provide.
  2. Deep domain specialization: legal document analysis, medical coding, financial instrument classification: domains with specialized vocabularies and implicit conventions that are too extensive to encode in a skill file. When the domain knowledge is deep enough that a reference file cannot capture it, training data can.
  3. When the base model genuinely lacks the knowledge: if Claude has not been trained on the specific terminology, schema, or pattern you need, fine-tuning can add that knowledge directly. Skills can encode instructions about how to apply existing knowledge; they cannot add knowledge that the base model does not have.

The economic crossover point for fine-tuning vs skills is approximately 50,000 automated outputs per month for style-alignment tasks, and somewhat lower for domain specialization tasks. Below this volume, the retraining overhead and iteration lag of fine-tuning outweigh the benefits for most workflow types.

What about the compound value comparison?

Skills compound in value through institutional knowledge accumulation over months: learnings, edge cases, and approved examples that make the skill more accurate and consistent over time. This compounding happens as a side effect of production use; no separate data pipeline or retraining cycle is required. Each production run makes the next one more reliable.

Fine-tuned models also compound, but in a different way: more training data produces better fine-tunes. The difference is that skill compounding happens as a side effect of production use, through the self-improvement loop. Fine-tune compounding requires deliberate data collection, labeling, and retraining cycles.

For teams with ML resources and an annotation pipeline, fine-tuning compounding can produce measurable accuracy gains: one 2024 study found up to 64.7% accuracy improvement with targeted schema optimization over freeform generation (PARSE framework, arXiv:2510.08623, 2025). For teams without this infrastructure, skill compounding is the available option and it is substantial.

When should I use skills and fine-tuning together?

Use both when your workflow has a domain-specialization problem and a workflow-structure problem. Fine-tuning handles weight-level style and domain knowledge. Skills handle the workflow contract, human review gates, and output format enforcement. The two layers are complementary: fine-tuning sets what the model knows, skills govern how it applies that knowledge to a specific task.

23% of enterprises are already scaling agentic AI systems in at least one business function; another 39% are experimenting (McKinsey State of AI, November 2025). The most production-mature workflows in that 23% use both: a fine-tuned model for domain specialization and style alignment, wrapped in a skill specification that handles workflow structure, human review gates, and output contract enforcement.

Fine-tuning handles what the model knows. Skills handle how the model applies what it knows to a specific workflow. They are complementary layers, not competing alternatives. Skills won't replace fine-tuning for style consistency at scale: that is a weight-level problem, not a specification problem, and no amount of prompt engineering closes the gap at 50,000+ outputs per month.

For teams building their first production Claude workflow, start with skills. Add fine-tuning only when skills cannot achieve the required output consistency at the required volume. That threshold is higher than most teams expect.

Frequently Asked Questions

For most recurring workflows, skills are the right starting point: they deploy in hours, require no training data, and update as requirements change. Fine-tuning becomes relevant above 50,000 automated outputs per month or in domains with knowledge the base model does not have. The questions below cover the specific decision points.

Is fine-tuning available for Claude models? Anthropic offers fine-tuning for Claude through their API for enterprise use cases. It requires a minimum number of training examples and involves a defined training and evaluation process. Check the Anthropic developer documentation for current availability and pricing.

Can a skill achieve the same consistency as a fine-tuned model? For structured output tasks with a specific format, yes. For style and tone alignment across free-form text at high volume, no. The distinction matters: output format compliance is a skill problem; brand voice consistency at 50,000 outputs per month is a fine-tuning problem.

What does it cost to fine-tune a model vs build a skill? A production-grade skill costs 6-12 hours of engineer time to build and test. Fine-tuning preparation (data collection, labeling, evaluation) costs 40-200+ hours before training, plus compute costs. For most teams, the skills breakeven is reached before fine-tuning preparation is complete.

How do I decide which approach to use for a specific workflow? Ask three questions: How often do requirements change? (If quarterly or more, skills.) Does it need human review? (If yes, skills.) What is the monthly output volume? (If under 50,000 automated outputs, skills. If over, evaluate fine-tuning.) When all three answers point toward fine-tuning, you have a genuine fine-tuning use case.

Can I use evals to compare a skills-based workflow against a fine-tuned model? Yes. This is the correct evaluation methodology. Define your quality criteria, build test cases, run both approaches against the same inputs, and measure against the same criteria. The evaluation-first development approach applies to both.

Last updated: 2026-04-29