TL;DR
Most AI infrastructure learning stops at tutorials that work on the first try. Here's a 90-day curriculum built around failure modes, evaluation, and cost — the three things that actually get tested.
→ See how this applies to your business (free 30-min call)The reason most people who "learn AI infrastructure" can't get hired or ship anything is that they learned the happy path. They followed tutorials where the API returned in 200 milliseconds, the document parsed cleanly, and the agent finished in three steps.
Production is the other path. The API times out. The document is a scanned PDF at an angle. The agent loops eleven times and burns forty dollars. The retrieval quietly starts returning garbage because someone changed the chunking.
Everything valuable in this field lives in that second category. So here's a 90-day curriculum organized around failure rather than features, where every phase ends with something deployed.
The Prerequisite Nobody States
Before any of this: you need to be comfortable with one programming language, HTTP, JSON, and the command line. If you're not, spend three weeks there first. Python is the pragmatic default; JavaScript is fine and increasingly common at the edge.
You do not need machine learning theory, linear algebra, or a background in data science. AI infrastructure is a systems discipline. The people who do it best usually came from backend, platform, or SRE work, not from research.
Days 1–15: The Loop and the Cost
Goal: understand exactly what happens in a single model call, and what it costs.
Read the primary API documentation from a major model provider — actual docs, not a summary. Learn what a token is, how context windows work, what streaming does, and how tool calling is structured at the wire level.
Then build the smallest possible thing: a script that takes an input, calls a model with one tool available, and returns a result. Print the raw request and response. Look at them. Most people never do this and it costs them for years.
The exercises that matter:
Ship: a command-line tool that does one useful thing for you, with cost logged per run.
Days 16–30: Tools and Failure
Goal: learn that the model is rarely the problem.
Add three tools to your agent — one that hits an external API, one that reads a database, one that writes somewhere. Then break each one on purpose:
Handle every case. Add timeouts, retries with backoff, and idempotency so a retried write doesn't duplicate. Add a hard cap on loop iterations and total spend per run.
This fortnight is the single highest-value block in the entire curriculum, and it's the one every tutorial skips.
Ship: the same agent, but it survives every failure you can throw at it and reports what went wrong.
Tutorials teach the happy path. Everything you get paid for lives in the failure path.
Days 31–45: Retrieval, Properly
Goal: understand why retrieval quality — not model quality — is usually the bottleneck.
Build a retrieval system over a real document set you care about. Then measure it, which is the part almost nobody does.
You'll finish with an intuition that separates you from most practitioners: when someone says "the AI gave a wrong answer," your first question will be whether it ever saw the right information.
Ship: a question-answering system over your own documents with a measured retrieval accuracy number you can state out loud.
Days 46–60: Evaluation
Goal: be able to prove a change made things better.
This is the phase that makes you employable. Almost nobody does it well.
Ship: a regression suite that would catch it if tomorrow's change broke last week's behavior.
Days 61–75: Deploy and Observe
Goal: run it somewhere real, and see everything it does.
Ship: the system running on a schedule or a webhook, with a dashboard you check daily.
Days 76–90: Cost, Scale, and Security
Goal: make it cheap and safe enough to run without supervision.
Ship: a documented write-up of what you built, what broke, and what it costs per thousand runs. This document is worth more in a job search than any certificate.
Where to Learn From
Categories rather than links, because specific resources rot fast:
Skip the aggregator newsletters and the model release commentary. They're entertainment, not education, and they consume the attention that should go to building.
What to Skip
How This Gets Tested
If you're doing this to get hired, interviews for these roles converge on four questions:
"Your provider starts returning errors on 30% of requests. What happens to your system?" They're testing fallbacks and graceful degradation.
"How would you cut inference cost in half without hurting quality?" Routing, caching, prompt compression, smaller models for subtasks.
"How do you know your last change didn't make things worse?" Evaluation. This is where most candidates have nothing.
"Walk me through debugging a quality regression." Traces, eval sets, retrieval metrics, isolating the layer.
Notice none of them are about models.
Where the Learning Actually Compounds
The engineers who get good fastest are the ones running something with real users, because real users generate failure modes no test suite invents. If you don't have a system with real traffic, find one — an internal tool at work, a friend's business, a volunteer project.
That's the same reason our systems improve: AI callers responding to every inbound lead within 90 seconds generate thousands of real conversations, and every week someone reads them and tunes what's awkward. The loop between production and improvement is the entire discipline.
If you'd rather have the outcome than the education — a system that qualifies and books leads without you building it — [book a free strategy call](/book).
Free Weekly Briefing
One AI Marketing Tactic.
Every Tuesday. Free.
What's actually working across our client accounts right now — ROAS moves, follow-up sequences, creative angles. The stuff that isn't in any blog post yet.
No spam. Unsubscribe anytime. 1,200+ business owners already in.