curiousily/AI-Bootcamp: A Notebook-First Curriculum That Mixes Classical ML With LLM Tooling

What the repository actually contains, and what it does not

The README opens with a slogan about getting things done with AI, then hands you three tables. The first covers AI/ML foundations: Python essentials, mathematics for AI, linear models, and PyTorch. The second covers MLOps: data exploration on a Bank Marketing dataset, validation with pandera plus scikit-learn Pipelines plus DVC, training pipelines with DVC and MLflow and LightGBM, a FastAPI service in Docker, and AWS deployment through S3, ECR, ECS and EC2. The third, AI Systems Engineering, is where Ollama, LLMs, RAG, LangChain, LangGraph, DSPy, fine-tuning and CrewAI live. Every row points at a tutorial on mlexpert.io and, in some rows, a video.

That structure tells you what this is. It is a curriculum index with companion notebooks, not a framework you install. There is no package on PyPI, no CLI, no importable module named after the project. The primary language is Jupyter Notebook, which is the honest signal: you consume this by opening files, running cells, and reading prose between them. The repository also links a Discord server and a YouTube channel, and the README points to a paid AI Engineering Academy, so the free repository and the commercial course sit on the same domain.

Who the two-audience split is really for

The tables serve two different readers and do not pretend otherwise. The foundations and MLOps rows assume you can already write Python and want the production half of machine learning: validating raw data, versioning datasets, tracking runs, containerising a model, pushing it to AWS. Someone who has trained models in notebooks but never shipped one is the target there.

The AI Systems Engineering table assumes the opposite starting point. You may know nothing about retrieval or agents, but you are expected to be comfortable with APIs and environment variables, because the material runs against local models through Ollama and against hosted models from OpenAI, Anthropic, Google and others. The README's own description lists ChatGPT, gpt-oss, Claude, Qwen, Gemma, Llama and Gemini, which is a statement about breadth of provider coverage rather than depth in any one SDK. If you are choosing a single stack and want it taught thoroughly, this breadth works against you: the same concept appears once per provider family, and you have to decide which instance is your reference implementation.

How a lesson is wired: notebook, model runtime, provider

The mechanism is consistent across the LLM material even though the README does not spell it out in one place. A notebook is the unit of work. Inside it, a model is reached either through a local runtime (Ollama is named in the description and topics, and ollama-python appears as a topic) or through a hosted provider SDK. On top of that sit the orchestration libraries: LangChain for chains and retrieval, LangGraph for stateful graphs, DSPy for programmatic prompting, CrewAI for multi-agent crews. RAG notebooks add a retrieval layer, which in practice means an embedding step, a vector store, and a prompt assembled from retrieved chunks.

The data flow in the MLOps half is described more concretely in the table text: raw data validated with pandera, features built with scikit-learn Pipelines, artefacts and pipeline stages versioned with DVC, experiments tracked in MLflow, then a FastAPI service packaged with Docker and deployed to AWS. That is a defensible end-to-end path and the table names the tools at each stage, which is more than most curriculum READMEs do. What the README does not give is a dependency manifest, a Python version, or a pinned set of library versions, so the notebook is also the environment specification. That is the trade-off of the format.

Getting a notebook running: Colab badge, local runtime, environment

The fastest documented path is the Open in Colab badge at the top of the README. It points at the repository root, so Colab opens the file browser for the repo rather than a single notebook; you then pick the .ipynb you want. On Colab, the hosted-provider notebooks need an API key in the environment, and the local-model notebooks need something else entirely, because Colab cannot reach an Ollama server on your laptop.

For local work the pattern implied by the material is: clone the repository, create a virtual environment, install the packages each notebook imports, and start Ollama as a background service so the client can call it. The README itself does not print these commands, and I will not invent them. What you can verify from the repository is the file layout and the imports inside each notebook; those imports are your install list. The practical consequence is that setup cost is per notebook, not per repository. A RAG notebook and a fine-tuning notebook will not share a requirements file, because there is not one.

Where the format breaks down

The clearest limitation is version drift. LLM client libraries and orchestration frameworks change their APIs at a pace that notebook screenshots cannot follow, and with no releases retrieved and no lockfile in the described layout, nothing in the repository pins a working combination. A notebook that ran when it was written may fail on an import line today. The last push timestamp is recent, which suggests active maintenance, but maintenance of a link hub is not the same as tested execution of every notebook.

A second limitation is assessment. There are no exercises with expected outputs, no tests, no grading. You read, you run, you move on, and you have no signal about whether you understood the material or merely executed it. A third is provider churn: the description names seven model families, and each hosted one carries its own pricing and availability terms that the repository cannot control or guarantee. If you are evaluating this for a team, the absence of a pinned environment is the thing that will bite first, because two engineers following the same table can end up on incompatible library versions with no documented baseline to compare against.

How it differs from a single-framework course

The obvious alternative is a course built around one stack end to end, for example a LangChain-only or LlamaIndex-only curriculum where every lesson reuses the same abstractions and the same vector store. The difference in approach is real. A single-framework course gives you depth and a coherent mental model, and you finish knowing one tool well. This repository does the opposite: it shows the same problem solved with LangChain, with LangGraph, with DSPy, and with CrewAI, plus the same model accessed locally through Ollama and remotely through several providers.

That breadth is useful for one specific job, which is choosing a stack. Seeing how a retrieval pipeline is expressed in two orchestration libraries makes the abstractions legible in a way a single-framework tutorial does not. It is the wrong tool for the opposite job: if your goal is to ship one agent this month, the switching cost between libraries is pure overhead, and you would be better served by picking one and reading its own documentation. There is also a lighter alternative for the local-model portion specifically: Ollama's own documentation and model library, which is narrower but tracks the runtime rather than a curriculum.

Licence, maintenance and what the upgrade cost looks like

The repository is MIT licensed, and the README carries a licence badge pointing at the LICENSE file. MIT is permissive: it allows reuse, modification and redistribution with the copyright notice and permission notice preserved. That covers the code and notebooks in the repository. It does not cover the mlexpert.io tutorials, the YouTube videos, or the Discord community, which are separate works with their own terms, and it does not cover the model weights or hosted APIs the notebooks call. I am not a lawyer and this is not legal advice; if you plan to reuse notebook code inside a commercial product, read the LICENSE file in the repository and check the terms attached to each model and provider you call from it.

Maintenance cost falls on you, not the maintainer. Because there is no release artefact and no dependency lock, an upgrade is whatever you decide it is: you re-run a notebook, fix the imports that broke, and pin the versions yourself if you want reproducibility. The repository's job is to point at tutorials, and that job does not require it to keep every cell executable. Budget for that gap before you build a study plan on top of it.

Editorial conclusion

Adopt it if you learn by reading and re-running notebooks and you already know what you want from Ollama, LangChain or CrewAI; the MIT licence and the Colab badge make that cheap to try. Skip it if you need a pinned, versioned course with exercises and grading, because the repository is a link hub with no releases and no dependency lockfile. Before committing time, open the Colab badge, pick one notebook from the AI Systems Engineering table, and check whether the model names and package imports inside it still resolve on your machine.

Official sources

1. curiousily/AI-Bootcamp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README