Week 0: Why a Research Engineer Should Know LangGraph

The work this course is about

Picture an evaluation you might run in your first month on an applied-AI or research team. Five hundred questions. For each one, a model writes an answer and an LLM judge grades it. At the end you report a pass rate. That is 1,000 model calls, and three things tend to go wrong.

1. The run dies halfway. A provider times out, a notebook runtime resets, a laptop sleeps. If nothing was saved, you pay for the first half again.
2. The judge is unsure. Some verdicts come with low confidence. Left alone, those calls move your headline number, and nobody can say by how much.
3. Nobody can say what it cost or how reliable it is. "It ran" is not a number. A team will ask for the pass rate with an error bar, what the run cost in dollars, and how often the pipeline finishes without help.

A literature pipeline has the same shape: search, screen each paper, summarize, write up. So does a sweep that runs one configuration per branch and collects the results into a table.

What LangGraph gives you, and what it does not

LangGraph describes a pipeline as a graph: nodes are Python functions, edges say what runs next, and a typed state object carries data between them. Four of its features map straight onto the problems above.

It does not make the model right. It does not put an error bar on your pass rate; you compute that. It does not make an external side effect safe to repeat; that is your design. The profrod.ai book builds the same machinery from scratch in plain Python (a bounded loop in chapter 3, durable SQLite state in chapter 4, crash recovery in chapter 13), and lesson 08 compares the two honestly.

View full-size diagram

How this course checks its claims

Every graph in the lessons was run while writing them, with langgraph 1.2.12 on Python 3.12, and the printed output you see is what that run printed. To make that possible without an API key, the model and the judge are stand-ins: small deterministic functions that behave like a model that is right about 80% of the time and a judge that is sometimes unsure. You can run every listing on Colab and get the same numbers. Where a lesson shows how to swap in a real Claude model, it says the code was not run for the lesson, and it shows no output for it.

The course does not report a pass rate for any real model. When it discusses cost or latency for a real model, it shows the arithmetic with prices from Anthropic's pricing page and token counts it labels as assumptions, and it gives you the code to measure your own.

The API moved once already

Most LangGraph tutorials you will find start with from langgraph.prebuilt import create_react_agent. That function was deprecated in LangGraph 1.0 in favor of create_agent in the langchain package. In langgraph 1.2.12 the old import still works and prints a deprecation warning pointing at the new one. Lesson 01 shows both. The broader habit is the one worth keeping: before you trust a snippet, check the import against the current reference, and pin the versions you ran.

Why this matters for a lab role

The work requires numbers you can defend: a pass rate with an interval, a cost per run, a reliability you derived rather than hoped for. An interview loop or a take-home can probe any of these, and it can also probe the design choice itself: why use a framework here at all? By lesson 08 you can answer both kinds of question with arithmetic and with runs you did yourself. If you want to see where you stand first, the lab-readiness quiz takes a few minutes.