How this course works

One path, not two products

ShipAI is a single self-paced course. There is no beginner SKU and no advanced SKU, no "lite" track that skips the hard parts, and no "pro" track that assumes you already shipped agents in production. Everyone follows the same arc — from lab setup through building a tiny language model, training a small language model, and shipping agent systems with real evals.

That design choice matters. Many AI courses split audiences early: one path for people who want to prompt ChatGPT, another for people who want to train models. The problem is that modern AI engineering sits in the middle. You cannot responsibly deploy an agent without understanding token costs. You cannot fine-tune a model without knowing what a training loop does. You cannot debug a RAG pipeline without grasping why retrieval fails on paraphrased queries.

Freshers start at the beginning and climb. Experienced software engineers skim early theory if they already know it, but they still hit every milestone — the concrete deliverables that prove you can execute, not just read. If you already know Docker and API keys, you might finish the setup module in a day. You still initialize the portfolio repo, because later modules assume it exists.

You will not attend live classes. Content unlocks as written lessons plus hands-on projects; videos may appear later on the same pages, but the written artifact is the source of truth. Progress is measured by what you commit to a growing monorepo — not by hours watched or quizzes clicked.

Callout — what "done" means: A module is done when its milestone passes: runnable code, honest README, and eval artifacts where the curriculum asks for them. Reading every word of every lesson is encouraged; it is not sufficient on its own.

How modules are structured

Every module in ShipAI follows the same three-layer pattern. Understanding this upfront saves confusion when you hit a dense theory lesson followed by a tiny coding exercise — the exercise is not optional padding; it is how the theory becomes muscle memory.

Lessons

Lessons are blog-depth articles with callouts, examples, and checklists — like the one you are reading now. They explain why before how, connect concepts to industry practice, and point forward to where you will implement the idea. Some lessons are conceptual (the history of symbolic AI). Some are operational (how to store API keys). All of them end with a micro-project.

Micro-projects

Each lesson has one micro-project: small, shippable, and testable. A micro-project might be a 30-line script, a markdown essay, or a JSON fixture with a pytest file. The point is frequency — you ship something every lesson, not once per month. Small wins compound into a portfolio that tells a coherent story.

Milestones

The milestone is the module exit bar. It aggregates the micro-projects and adds any capstone requirement. If you skip theory because you already know it, you still owe the milestone. Milestones are how ShipAI stays one path: experienced engineers cannot bypass the builds that prove competence.

Design rules appear everywhere in the curriculum:

• Hand-roll first, frameworks second. You will implement a training loop before you lean on Hugging Face trainers, because debugging requires knowing what the framework hides.
• Evals before demos. A flashy UI without a test set is a prototype, not an engineering artifact.
• Real APIs and/or local open models. No fake agents that return hardcoded strings.
• Python primary. The ecosystem for AI tooling is Python-first; the course matches that reality.
• Industry realism. Production modules cite public engineering blogs. The industry labs module is full case studies, not toy examples.

The portfolio monorepo

Across the course you grow one repository, conventionally named course-portfolio. This is not a collection of disconnected homework folders — it is a single codebase that evolves from "hello world LLM call" to "agent system with evals and deployment config."

Suggested layout:

course-portfolio/
  README.md
  Makefile
  m0/                 # doctor, first LLM call, golden fixture
  m1/                 # field-map write-up
  m2/                 # training-loop section
  m3/                 # mini-LLM
  m4/                 # prompts + eval set
  m5/                 # domain RAG
  m6/                 # SLM adapter + serve
  m7/                 # single agent
  m8/                 # skills + MCP
  m9/                 # multi-agent / workflows
  m10/                # evals + guardrails
  m11/                # deploy + cost + traces
  industry/           # industry labs
  m13/                # capstone design doc
  m14/                # frontier brief
  capstone/           # final capstone

You do not need every folder on day one. Create directories as you enter each module. The root README.md becomes your living index: background, goals, module checklist, and links to milestones.

The monorepo model has practical benefits. Interviewers can clone one repo and see progression. You reuse utilities (logging, config loading, eval harnesses) instead of copy-pasting. Git history shows how your thinking evolved — useful when you write about what failed and what you would do differently.

Callout — experienced skip: If you already know Docker and API keys, finish the setup module quickly. Do not skip initializing the repo; later modules assume it exists and reference paths like m0/fixtures/golden/.

Milestone culture

ShipAI treats milestones like production release gates, not participation trophies. A milestone is done when three conditions hold:

Code runs from a documented entrypoint. Usually make <target> or uv run …. A reviewer (future you, a hiring manager, a teammate) should be able to clone, install deps, and reproduce results without guessing.

There is a short README. What you built, how to run it, what failed, what you would do with more time. Honesty about limitations is a feature, not a bug. "Val loss plateaued at epoch 5; I would try a lower learning rate" tells more than "it works."

Where the curriculum asks for evals, there is structured output. A JSON file with scores, cases, and timestamps — not a screenshot alone. Screenshots lie; JSON can be diffed in CI.

This culture starts in the setup module and intensifies through the evals and guardrails module. The habit you build now — log everything, test deterministically, document honestly — is the difference between demo engineering and AI engineering.

What to do when you get stuck

Stuck is normal. The intended workflow:

1. Re-read the micro-project requirements (they are deliberately scoped small).
2. Check make doctor and your .env setup.
3. Write down what you expected vs. what happened — that gap often contains the answer.
4. Move on to the next lesson if you are blocked on compute or API access, but mark the milestone incomplete in your README checklist.

Do not fork the curriculum into a personal variant with different folder names. Consistency matters when you link artifacts in your field-map write-up later.

Engineering problem (staff framing)

The engineering problem is not consuming AI content — it is producing reproducible portfolio evidence: runnable entrypoints, eval artifacts, and honest READMEs that survive an interview clone-and-run.

Diagram — Lesson → milestone delivery loop

flowchart LR
  L[Lesson] --> MP[Micro-project]
  MP --> MS[Module milestone]
  MS --> PF[Portfolio commit]
  PF --> EV[Eval / golden JSON]
  EV --> L

Precise definitions & mental model

• Milestone — exit gate: code runs, README honest, evals when required.
• Micro-project — smallest shippable contact with the idea.
• One-path — same curriculum for fresher and senior; seniors skim, never skip builds.
• Monorepo portfolio — one evolving course-portfolio/ so progression is visible.

Tradeoffs — when to use what

Failure modes (interview + on-call)

• Reading without shipping → empty portfolio.
• Inventing private folder layouts → later modules break.
• Treating milestones as optional → cannot claim the module.

Production & OSS practices

OSS/FAANG bar: make/uv targets, pinned deps, secrets out of git, golden fixtures. Start that hygiene now.

Interview cue card

How would you structure a 6-month learning repo so a hiring manager runs your demos in <15 minutes?

Deep dive (FAANG / OSS bar)

Portfolio as an interface

Hiring managers skim. Your root README should answer in <30 seconds: who you are, what you built, how to run the best demo, where evals live. Each module folder should have a local README with the milestone command.

Diagram — evidence hierarchy

flowchart TD
  Claim[Resume claim] --> Demo[Runnable demo]
  Demo --> Eval[Eval JSON]
  Eval --> Trace[Trajectory / logs]

Micro-project: Init course-portfolio

This is your first shippable artifact. Keep it simple; perfection is the enemy of started.

1. Create a new git repo course-portfolio (private is fine; you can open-source later).
2. Add a root README.md with:
   • Your background (fresher / SWE / ML adjacent — one paragraph).
   • Goal after ShipAI (pick from the graduate promise in the curriculum: e.g., ship a RAG system, pass an AI eng interview loop, fine-tune and serve a small model).
   • Empty checklist of modules (you can label them the full curriculum in the checklist; prose elsewhere should use module titles).
3. Add a .gitignore for Python (.venv/, __pycache__/, .env, model weights, large data files).
4. Commit: chore: init course-portfolio.

Optional but recommended: add a one-line note about your compute situation (local CPU only, M-series Mac, access to cloud GPU, etc.). Future you will thank present you when the mini-LLM module asks where to train.

Checklist

• Repo exists and is cloned locally
• README states starting point + goal
• .gitignore ignores secrets and venvs
• First commit pushed (or at least created)