Today you’re going to train your first AI model. Absolutely no code and no technical ability required. You just need to have a computer and the ability to type English words. That’s it.

First, we are going to cover why being able to fine-tune models is one of the most desirable enterprise skills of the next ten years. And no, not just for AI engineers, as the technical barrier is so low that anyone can train them.

And I’m about to prove it to you today.

To be a good model trainer, you just need to learn how to think in first principles about the results you’re seeing. It’s not about having Math Olympiad medals, 4.0 GPAs, or a 160 IQ. Instead, it’s mostly intuition driven by experience.

Through a series of small training runs toward a desired model behavior, we’re going to see the progression of the experimentation required, with all the in-between lessons (balancing, preservation, set sizing, multi-turn preservation, hyperparameter tuning, etc.), and other tricks researchers do to churn out models, ending up with your first fine-tuned AI.

Next stop, training yours. Let’s dive in.

As this piece is entirely about teaching you a simple way to train your own models on any task or dataset you want, we need to understand why it is such an important skill to learn.

If you train an AI to predict the price of used cars by getting information about their mileage, age, model version, prices of sold similar cars, etc., the model will quickly learn to associate which characteristics correlate with higher prices and which ones put downward pressure on prices.

Newer cars tend to be more expensive; more mileage tends to reduce the price; accidents reduce the price; more powerful engines often increase the price; luxury brands tend to command higher prices; certain models depreciate faster than others.

Imagine we give the model thousands of examples like “2022 BMW, 20,000 miles, no accidents → $35,000” and “2015 BMW, 120,000 miles, two accidents → $9,000.”

Then the model starts discovering patterns such as “as mileage increases, price tends to decrease” or “holding everything else constant, newer cars tend to cost more.”

By seeing thousands or even millions of examples, models will eventually pick up more subtle patterns, such as “100,000 miles might hurt the value of a Ferrari much more in dollar terms than a Toyota” and eventually develop intuitions that can only be built after seeing millions of examples, something no human can do.

The point here being: data is at the center of it all. Data creates the models; data decides whether the AI learns the fact or skill.

If we accept this to be true (it’s undeniable), then you quickly understand how important it is that, if you want a model to be good at something, you'll likely only get meaningful performance if you train the model on that task.

However, over the last few years, the industry tried to make you believe that wasn’t necessary anymore, thanks to foundation models.

AI has almost eight decades in history, at least when it comes to having a name.

And for the longest part of those eight-ish decades, AI was always a narrow system, one that was trained to be very good at one thing (e.g., our used car price predictor, or a house price predictor), and one thing only.

The reason was that our ability to feed models a lot of data was limited, mostly because we lacked two things:

But during the 2010s, especially after the emergence of the Transformer architecture back in 2017, a new type of AI model came to be: the foundation model.

The Transformer architecture, build to the image and likeness of GPUs, which were now much more powerful unlocked our ability to scale the amount of training data a model could ingest by orders of magnitude, gave us the GPTs (Generative Pre-trained Transformers) which, as you are probably guessing, give the name to ‘ChatGPT’ and to OpenAI’s large language model (LLM) family, as they were the first to actively head in this direction, at least publicly.

As mentioned, these models reframed our intuitions about ‘how much data can we feed models’ to a whole other level. And when we did, we made an incredible discovery: models don’t have to be narrow; they can become general. That is, they can become good at many tasks, not just one.

This is what we define as generalization: if you train a model on a lot of diverse data, it learns several skills, and even when it sees new data, it can perform well if it’s sufficiently similar to what it saw during training.

Large-scale data also has another big benefit: pattern overlap. A model trained on a lot of physics data also develops capabilities in maths, and vice versa.

Seeing this, for the better part of the last decade, the AI industry has had only one obsession: increasing model sizes in order to unlock new data and skills.

And seeing models like Mythos, Sol, or Kimi K3, it has become really difficult to argue against this decision. The proof is in the pudding; scaling works wonders.

However, there’s something AI still misses. In our quest to conquer generalization, we lost what made AI work well in the first place: depth. And it’s precisely this problem that I believe fine-tuning, or retraining models to our tasks, is going to be instrumental to adoption.

But why?

In all its amazing highlight reels that AI has created over the last few years, involving maths discoveries, AIME maths gold medals, the ability to write code better than most developers, and the lot, AI falls surprisingly short in the last mile.

GPT-5.6 Sol does take you 90% of the way, even perhaps 95%, but almost always falls short in the very last moment.

There’s a reason I always say AI is easy to demo, hard to productionize; it can output a good demo basically out of the box, but rarely will you see LLMs in production environments, even today!

But why does this happen?

The reliability problem, and how it gets purposefully hidden from all of us, can be quickly visualized in AI’s central evaluation system: benchmarks, in particular how benchmarks truly assess AI’s abilities.

The simplest example is the all-too-common ‘pass@k’ evaluation metric. In these evaluations, the model gets several attempts and receives full credit as long as just one succeeds. If the benchmark is ‘pass@10’ the model is tested ten times on each task, and as long as it gets one correct, it gets a pass.

Imagine you give your employee ten tries at drafting a contract to an actual customer, risking sending 9 wrong contracts, instead of insisting they have to get it right on the first try.

Pass@k is useful for measuring whether a model can eventually solve a problem, but almost useless for telling us whether it will solve it reliably when you actually need it to.

It’s the demo issue all the way; it shows an AI can do a task, but it doesn’t ask whether it can do it reliably.

Then you have pass@1 benchmarks (i.e., the model gets one try). However, some of these allow for substantial partial credit.

These are better than pass@k, but a 90% score still does not mean “90% of tasks were completed flawlessly.” The model can make mistakes and keep most of the points.

There are also stricter benchmarks. Terminal-Bench, ProofBench, SWE-bench, and others generally ask for one successful final outcome: the tests pass, the proof verifies, or the issue is resolved. That gives us something close to real pass@1.

But even this hides a huge reliability problem.

If a model succeeds on 95% of tasks once, we still do not know what happens when we ask it to perform the same task repeatedly. Again, we’re testing accuracy, not robustness.

The difference between the two is hard to see if you haven’t thought about the problem before, but some quick maths makes it very clear.

A model can have a 95% accuracy on a benchmark and still have terrible reliability. If we assume independence between tries, that accuracy implies a probability of doing 50 tries in a row correctly of 7.6%. A probability of doing the task 100 times in a row of 0.59%. You get the point.

This is not a reliable model that can be applied at scale, because for every 50 customers you give it to, you’re going to have a handful of them cursing you to oblivion. Instead, what you’re actually aiming for is accuracies of 99.99% or higher.

At 99.99%, 50 successes have a probability of 99.5%, and 100 consecutive successes have a probability of 99%, or only one in every 100 will fail. Now that is reliability.

Some benchmark creators are realizing this and are moving into more aggressive evaluations like pass^k, essentially the inverse of pass@k: instead of asking whether one of k attempts succeeds, they ask whether all k attempts succeed.

τ-bench and newer evaluations such as Claw-Eval repeat tasks several times and explicitly measure this consistency. That is much closer to what real reliability means.

However, there’s a catch. To hide AI’s biggest problem and not scare model providers of publishing scores in your benchmark (at the end of the day, you’re a business like any other), they aggregate performance across tasks, so while they give a sense of overall reliability, they hide per-task reliability, which is the crucial one for adoption because models in production are deployed for single tasks.

And what is the culprit behind these issues?

In my view, we’ve leaned way too much on generalistic models with heavy prompt engineering, hoping our examples illustrated in the prompt are enough for our superduper math savant to suddenly be flawless at evaluating the risks associated with insuring a certain potential customer.

It doesn’t take a genius to realize this; pre-LLM AI adoption, with all those narrow models, was actually way better than what we have today.

The difference is that those models were trained for the task. Therefore, why don’t we… just train the models on the task?

Thinking Machine Labs, a startup packed with ex-OpenAI/Meta/DeepMind/Anthropic researchers, has bet its entire existence on this direction: to get production-grade models, fine-tuning is necessary.

Not only that, but fine-tuning allows you to use models for the task that can be way smaller, cheaper, and even locally runnable compared to having to run Mythos to run your emails.

Yes, at a certain scale, models like Mythos do become very reliable for certain very simple tasks, but let me ask you: are you happy paying a premium to access that model to get the desired reliability, when you can just train a model that is 100 times smaller and cheaper on the task and get the same performance if you fine-tune it on the task?

Furthermore, fine-tuned models are also more secure; you have more control over them, and unmatched privacy (no need to send your data over the Internet).

All in all, my thesis is actually quite simple to summarize: just like we expect our junior employees to get ‘on-the-job training’ to go from overqualified-but-useless bookworms that just came out of college to actually useful coworkers, what made us all think for a while that AIs wouldn’t benefit from the exact same principle?

And with that, are you ready to fine-tune your first model? You’re now literally minutes away from starting the most important journey one can take in this industry:

Let’s do it.