How to Learn AI Engineering: A Path That Starts With Shipping

Most study plans for this field are ordered by dependency: linear algebra, then calculus, then neural networks, then transformers, then — eventually — something you can use. That order is correct for building a model and wrong for building with one, and the difference is most of a year.

Why the usual curriculum is backwards

The dependency order assumes you will one day need to derive backpropagation. If your job is to make a product work using models somebody else trained, you will not, and the cost of pretending otherwise is that you spend six months on material you cannot yet attach to anything. Knowledge you cannot attach to a problem does not stick, which is why so many people finish a course sequence and still cannot ship a feature.

The alternative order is by unblocking. Learn the smallest thing that lets you build something that works, build it, find the place it breaks, and let the breakage tell you what to learn next. This is slower to feel impressive and much faster to be useful, and it has one large secondary benefit: at every point you have an artefact. An artefact is what a portfolio, an interview and a performance review are all made of.

A caveat that is not false modesty. This path produces someone who can build reliable systems on top of models. It does not produce a researcher, and it does not produce someone who can train a frontier model. Those are different jobs with a genuinely different curriculum, and if that is what you want, the dependency order is the right one after all. Decide which before you start; the two paths diverge early.

Five stages, each ending in an artefact

Each stage ends with something specific you should be able to build without looking at a tutorial. If you cannot build it, the stage is not finished, however many videos are ticked off.

Stage 1 — Call a model and understand the bill

Learn what a model actually is at the level of what it does when a request arrives, what a token is, and how a request turns into a charge. Nothing else.

Artefact: a command-line tool that takes a file, sends it to a model with a prompt you wrote, streams the answer back, and prints the token counts and the cost of the call at the end. It should handle a timeout and a rate-limit response without crashing.

Stage 2 — Make the output usable by a program

The step where most people discover the real job. Prose is not an API contract. Learn how to get output a parser can trust and what happens at the edges of a schema.

Artefact: a service that takes an unstructured document and returns a validated typed object, with a repair path for when validation fails and a test suite that includes three inputs designed to break it.

Stage 3 — Give the model information it did not have

Now retrieval. Understand what an embedding is, what retrieval-augmented generation actually solves, and the two decisions that dominate its quality — chunking and reranking.

Artefact: a question-answering service over a corpus you care about, which cites the source of every claim and answers “I do not know” when the corpus does not contain the answer. The abstention behaviour is the hard part and the whole point.

Stage 4 — Find out whether it works

The stage that separates people who can demo from people who can ship. Learn to build a frozen evaluation set, when a model can judge another model and when it cannot, and enough statistics to know when a difference is real.

Artefact: an evaluation harness for stage 3’s service that runs in CI, fails the build on a regression, and reports a number you would be willing to defend in a meeting.

Stage 5 — Run it in front of people

Production. What to log, how to behave under rate limits, what to do when a provider is down, and the security floor — prompt injection and the combination that turns it into an incident.

Artefact: the same service, deployed, with a dashboard showing p95 latency, cost per request and the failure rate from your own evaluation, plus one alert that has fired at least once for a real reason.

When to go and get the theory

Theory is best learned in the hour after it would have helped. Some specific triggers, each of which sends you to a specific thing rather than to a course:

• Your retrieval returns plausible-looking nonsense → go and understand what similarity actually measures and why semantic nearness is not relevance.
• The same prompt gives different answers → sampling parameters and why temperature zero is not deterministic.
• Long inputs degrade quietly → the position effect and the gap between the advertised and usable window.
• The bill jumped → the levers and which one is worth your week.

This is also the honest answer to the maths question, which has a page of its own: you need the maths that appears in the failures you actually hit, and that is a much shorter list than a syllabus.

Three traps

• Tutorial accumulation. Following along with a framework tutorial produces the feeling of learning and none of the substance, because every decision was made for you. The test is whether you can rebuild it from an empty file. If you cannot, you watched.
• Chasing the frontier. The stages above are unaffected by which model is currently best. Time spent tracking releases is time not spent on the parts of the work that transfer, and there is a cheaper way to stay current.
• Skipping stage 4. It is the least fun stage and the one that most distinguishes a professional. A person who can say “this change improved the extraction accuracy from 71% to 84% on a frozen set of 400 documents” is in a different category from a person who says the new prompt feels better.

How to tell you are actually progressing

Not by hours logged. Three signs, in rough order of how much they mean:

• You can predict, before running it, roughly what a change will do — and you are right more often than not.
• When something fails you form a hypothesis about which layer failed (retrieval, prompt, schema, model, plumbing) before you start changing things, and the hypothesis is usually right.
• You have started deleting things. Removing a step, a tool, a framework or a model call because it turned out not to be earning its place is the clearest sign the mental model is real.

Expect the path to be uneven: stages 1 and 2 go quickly, stage 3 takes longer than it looks, and stage 4 is where people stall because nothing about it produces a demo. It is the stage worth being stubborn about.