calmrocks/ai-engineer-notebooks: A Framework-Free Colab Track for AI Engineer and FDE Interviews

The gap this fills: applied-model skills without a framework in the way

Most LLM tutorials start by importing a framework. That is convenient and it hides the mechanics. The README states the project's position plainly: you write the agent loop, RAG, and evals from raw API calls first, so you understand what LangChain or LlamaIndex actually do before you reach for them. The stated audience is backend or full-stack engineers moving into AI Engineer, FDE, Applied AI or Solutions Engineer roles, people who already ship production code and want the applied-model layer on top. That framing matters because it sets the difficulty. This is not an introduction to programming with an LLM chapter bolted on. It assumes you can read a Python function, handle an API key, and reason about a failing test. The repository is also positioned as the hands-on companion to an external career-transition plan hosted at calm.rocks, which explains what to learn and why, while the notebooks are where you run it. That split is worth noting: the repository is not self-justifying. It defers the curriculum rationale to a page outside the repo.

What the notebook track actually covers, section by section

The learning order runs from setup through serving. Section 00 covers environment and cost hygiene: API keys via Colab secrets, spend guards, model picking. Section 01 covers model APIs across five notebooks: prompting fundamentals, structured output, tool calling, streaming, and context and caching. Section 02 is a single notebook on measuring outputs, and the README describes it as installing the measure-before-you-tune habit before you build anything you would need to tune. Section 03 covers RAG in five parts: what RAG is, embeddings and retrieval, hybrid and reranking, chunking, and why RAG fails. The remaining sections, per the repository description, cover agents (loop from scratch, tool design, guardrails, MCP, Skills), fine-tuning versus LoRA, prompt injection and security, LLMOps, and customer craft. Three case studies close the track: a support assistant debugged in production, a pipeline-versus-agent cost showdown, and a red-team robustness benchmark. The breadth is the selling point and also the risk. A track that touches RAG, agents, evals, fine-tuning, security and LLMOps in one repository will necessarily be shallow somewhere.

The mechanism: raw HTTP calls to an OpenAI-compatible endpoint

The architecture is deliberately thin. Notebooks call the Groq API directly, and the README notes the API is OpenAI-compatible throughout, so every pattern transfers directly to OpenAI and, with small changes, to Anthropic. In practice that means swapping a base URL and a model identifier rather than rewriting logic. Each notebook is described as self-contained: it installs its own dependencies and reads API keys from Colab secrets. There is no shared library, no package the notebooks import from the repository, and no orchestration layer. The agent loop is written by hand in the notebook that teaches it. RAG is assembled from an embedding call, a vector search step and a generation call. Evals are computed inline against a golden set. This is the same shape as a script you would write to prove a concept before deciding whether a framework earns its place. The trade-off is real: nothing here is reusable as an import. You copy patterns, not code.

Getting it running: Colab secrets, a Groq key, and the free tier

The entry point is the badge in the README, which opens 00-setup/00-environment.ipynb directly in Colab from the main branch. That notebook handles API keys via Colab secrets, spend guards and model picking. The Groq API is free and, per the README, requires no credit card, which removes the usual friction of a tutorial that asks for billing details before it shows you anything. Two topics cannot run on Groq: LoRA fine-tuning in section 06 and self-hosted serving in section 09. The README describes these as concept-first with optional, fenced Colab-GPU appendices that were verified on a real Colab T4. That distinction is the one to watch when you open a notebook. If the code you want to run sits inside a fenced GPU appendix, the free path does not cover it. Everything else is described as runnable end to end on the free tier. The repository carries an MIT licence, which is permissive and places few restrictions on reuse of the notebook content, though the usual caveat applies: the notebooks call third-party APIs whose own terms are separate from the repository licence.

Evals as a spine, and why that ordering is the strongest design choice here

The README states that evals return in every section after the evals notebook, and calls the habit the thing that separates an engineer who shipped a system from one who built a demo. The sequencing supports that claim: section 02 sits before RAG, agents and fine-tuning, so a reader meets measurement before meeting anything that needs measuring. That is a genuine editorial decision, not a marketing line, and it is the part of this repository most likely to change how someone works. It also creates an obligation the material has to meet. Evals that return in every later section have to be adapted to each new task, and the quality of that adaptation is where a curriculum like this either holds together or falls apart into a checklist. The README does not describe a shared eval harness, so each return is presumably bespoke. Whether that produces a durable habit or a series of disconnected metrics is something you can only judge by reading the notebooks themselves.

Where this is the wrong tool

The framework-free stance is a teaching device, and it cuts both ways. If your team already runs LangChain or LlamaIndex in production, this repository will not teach you how to debug your actual stack; it will teach you what your stack is doing underneath, which is useful but not the same thing. If you need a deployable reference architecture with a hosted vector database, retries, observability wiring and a CI pipeline, the notebooks are not that. They are Colab documents, and the README frames them around interviews and skill-building rather than deployment. The free Groq tier is another boundary: it is what makes the track accessible, and it also means the model behaviour you observe is Groq's, on Groq's infrastructure. Section 09 on self-hosted serving and section 06 on LoRA are concept-first for exactly this reason, so a reader who came for hands-on fine-tuning gets appendices rather than a full path. Finally, the repository depends on an external plan page for its curriculum rationale. If that page moves or changes, the notebooks lose their stated context.

The alternative: a framework-first tutorial, and the actual difference

The obvious comparison is any LangChain or LlamaIndex getting-started guide, and the difference is not quality but order of operations. A framework-first tutorial hands you a retriever object and a chain, and you learn the framework's vocabulary before you learn what a retrieval step costs or why a reranker changes a result. This repository inverts that: you write the retrieval call, the prompt assembly and the scoring loop yourself, then you are in a position to judge whether a wrapper is worth its abstraction. The README makes the argument directly, saying patterns are durable while wrappers churn. That is a defensible position and a costly one. Framework-first material gets you to a working prototype faster and gives you a supported path when you need streaming, retries and tracing without writing them. This track gets you to an understanding of the mechanics and leaves the plumbing to you. For interview preparation the second is usually the better fit, because interviewers tend to probe the mechanism rather than the import.

Maintenance, versioning and what to verify before you invest time

The project is not archived, the default branch is main, and the last push recorded is 2026-08-28. There is a single release, v0.1.0, described as the full applied-LLM track, dated 2026-08-27. A 0.1.0 version number on a curriculum is honest: it signals a first complete pass rather than a settled one. Because the notebooks call live APIs and install their own dependencies at runtime, they are exposed to two kinds of drift that a normal library would pin away. Model names on Groq can change, and a notebook that hardcodes one will fail when it does. Library versions installed inside Colab can move under the notebooks. The MIT licence covers the repository content, and reuse is straightforward, but the third-party API terms you accept by running the notebooks are governed separately. Concretely, the first thing to check is 00-setup/00-environment.ipynb, to confirm the Colab secrets flow and the spend guards match how you handle keys. The second is whether the specific notebooks you need sit in the free-tier path or in the fenced GPU appendices for LoRA and self-hosted serving. Read those two things before deciding how much of the track you will work through.

Editorial conclusion

Adopt this if you can already write production code and want the applied-model layer demonstrated through raw API calls rather than a framework abstraction, or if you are preparing for an AI Engineer or Forward Deployed Engineer loop that probes how retrieval, tool calling and evals actually work. Skip it if you need a deployable reference architecture, a hosted vector store, or framework-specific guidance for an existing LangChain codebase. Before committing, open 00-setup/00-environment.ipynb and confirm the Colab secrets path matches your own key handling, then check whether the notebooks you care about sit in the fenced GPU appendices, since those are the only parts that cannot run on the free tier.

Official sources

1. calmrocks/ai-engineer-notebooks on GitHub
2. License: MIT
3. Project website
4. README
5. Releases