Today's concept: model versioning vs code versioning, what changes
Here's something that trips up people moving from software into ML: commit the exact same training script to main, run it twice, and you can get two different models out. Same code, different result. In ML, that's just how training works.
In software, "version" means the source code: commit it with git and it behaves the same way forever. ML flips this: your code is just a recipe, and what matters, the thing behind your agent's decisions, is the output: the trained weights that come out once training finishes. Versioning "the code" tells you almost nothing about versioning "the model."
Hugging Face Hub, a top hosting site for open models, builds this into its infrastructure: every model repo is a real git repository, and every set of trained weights becomes its own commit. Teams pin an exact commit hash, not just a model's name, the same way software teams pin a dependency version instead of trusting main: a name can drift, a commit can't.
You've likely met this via an LLM API: Anthropic's claude-sonnet-4-5 floats to the newest snapshot in that line, while claude-sonnet-4-5-20250929 is a dated snapshot, pinned to that exact version for as long as it's served. Most LLM providers offer this same pair, a floating alias for convenience and dated IDs you can pin. Build an agent on the floating alias and its behavior can shift overnight. Pin the dated snapshot instead: same "commit hash, not branch name" logic, wearing an API key.
Fine-tuning adds a twist: instead of saving a new multi-gigabyte model copy per experiment, LoRA freezes the base model and trains a small adapter, often a few hundred MB, capturing just the difference: version the delta, not the whole model.
And "what changed" needs its own paper trail: the model card, a doc format proposed in 2019, now standard on Hugging Face and most model hubs, recording the training data, intended use, and evaluation results behind that version. That's the gap between "v2 shipped" and knowing if v2 changed the data or the hyperparameters.
Bottom line: in software you ship code. In ML you ship trained weights plus everything that produced them. Track only one, and debugging "why did this break" turns into archaeology.
Sources: huggingface.co/docs/hub/en/repositories-getting-started, platform.claude.com/docs/en/about-claude/models/model-ids-and-versions, research.google/pubs/model-cards-for-model-reporting
Quick check before you scroll: Why can't you rely on git commits alone to version your ML model?
Full breakdown + the answer: frankduah.me/learnings/2026-07-26-model-versioning-vs-code-versioning-what-changes
New here? I post a bite-size AI / ML concept like this every day, follow me for the daily drop, and it compounds fast. Why I do it: https://lnkd.in/gK8knHDH
#ModelVersioning #AI #LLM #AIAgents #MachineLearning
The answer
Because git only tracks code, but ML models are the trained weights (numbers learned from data), not the code that created them. Two commits of identical training code can produce different models if the training data or random seeds changed. You need to version and track the actual trained model artifacts separately.