The lab bench of AI.
Prototype here, ship there.

Every artificial-intelligence (AI) paper, tutorial and Kaggle competition ships notebooks for one reason: you can run code in pieces and see the result inline. The source’s framing is blunt — trying to learn AI without a notebook is “doing math homework without scratch paper”. But a notebook is not a script with prettier output, and the difference matters enough to learn first.

Cell one: code. A code cell is Python, and the last expression in it is displayed automatically — no print required. The source’s example:

Cell two: markdown. A markdown cell renders formatted text: headers, bold, italic, LaTeX math such as $E = mc^2$, tables and images. Use it to document what you are doing and why — that is the half of a notebook that makes it a lab notebook instead of a scratch pad. Markdown cells never touch the kernel, which is why they cannot cause a NameError; they only render.

Cell three+: rich output. The last expression can render as more than text. Put a pandas DataFrame as the last expression and Jupyter renders an HTML (hypertext markup language) table instead of a text dump — this is the four-row frame from the lesson’s notebook_tips.py:

Read those numbers like an engineer, because this is exactly what a notebook is for. The best accuracy is the neural network’s 0.94 — and it costs 45.6 s, which is 19.8× the random forest’s 2.3 s for +0.05 accuracy, with 24× the parameters (1,200,000 ÷ 50,000). XGBoost sits between: +0.02 over the forest for 3.6× the training time (8.2 ÷ 2.3). Whether any of that is a good trade is a modelling question; the point here is that the table, the timings and the parameters were on one screen, two keystrokes after the code that produced them. The source’s script prints the same conclusions in text — Best model: Neural Network, Fastest model: Linear Regression — but the dataframe is where your eye does the comparing.

Plots work the same way. In modern JupyterLab and Colab, %matplotlib inline is the default; the source teaches the line anyway, and it costs nothing to be explicit. Images render from memory or disk with the display helpers of IPython (Interactive Python), the kernel Jupyter grew out of.

And now the invisible half. The kernel is a Python process running in the background. When you run a cell, the interface sends the code to the kernel, the kernel executes it and sends back the result. Every cell in the notebook talks to the same kernel, so a variable defined in cell 2 is still in memory when you run cell 7 — and it is still there even if you never run cells 3 through 6. Three properties follow, and the source lists them: the kernel keeps variables in memory, it runs cells in whatever order you click, and it dies when you restart it.

That middle property is the superpower and the foot-gun at once. Click cell 6, then cell 2, then cell 7 and you have built a state the file does not describe. Restart the kernel and all of it is gone: the variables, the imports, the model you just trained — while the notebook file still shows every output as if nothing happened.

The name Jupyter honors the project’s first three languages — Julia, Python and R — even though an AI workflow is almost always Python. The three interfaces below are the ones the source lists, with its install lines and its summary of who each one is for:

All three read and write the same .ipynb file, so “pick one” is not a commitment — and moving a notebook between them is an open, not an export. JupyterLab — the full integrated development environment (IDE) option — is the most common in AI work, which is why the rest of this lesson shows its menus and shortcuts; VS Code users get the same cells and the same kernel behind a different chrome.

One habit pays off immediately: put pip install work in the environment the notebook runs in. A notebook is only ever as good as its kernel’s packages — if import torch fails in a cell, the question is not what is installed on your machine but what is importable by that kernel.

Everything you just clicked through has a consequence worth stating plainly: the notebook file stores your evidence, not your state. Outputs, execution counts and cell sources are in the JSON; the variables that produced them live in a process the file only names. That is why a notebook can be reopened hours later with the same plots on screen and none of the objects in memory, and why “the outputs look right” can never substitute for “the file replays from a fresh kernel”.

This is the one part of the notebook you should learn by muscle memory rather than by menu. The source gives two short tables, and Shift+Enter is the one you will use a thousand times a day — learn it first.

Why two modes at all? Because the alternative is a menu for everything:DD deletes a cell in two keystrokes, and A / B let you grow a notebook as fast as you can think. The price is that D is not “delete” until you press it twice — the first press only arms it — so a stray keystroke in command mode is recoverable with Z or Escape. Nothing about a notebook’s state changes when you switch modes; modes are about the keyboard, not the kernel.

The two timing magics are the pair everyone meets first, and they answer different questions. The source’s examples, with their outputs:

The rule is one sentence: %timeit runs the code many times and averages; %%time runs it once. Use the first for microbenchmarks and the second for training runs. The reason is worth the arithmetic, because the source’s single line hides a real scheduling decision. %timeit first grows an internal loop count until one timing run lasts at least about 0.2 seconds, then repeats the measurement seven times (its default) and reports the mean and standard deviation.

Two things follow. First, a number without its spread is a rumour: the ±1.3 us is what separates “45 µs” from “somewhere between 40 and 50 µs”, and the mean of seven runs is more trustworthy than any single reading. Second, the cost of that trust is time — 3.16 seconds for a microbenchmark is nothing, but the same magic on a 2.34-second training run re-trains the model seven times and burns roughly 16 seconds of compute for a wall-clock number you could have had once. The numbers above are the source’s example readings; the loop arithmetic beside them is derived from timeit’s documented behaviour, so run it on your own machine and compare.

The other magics in this lesson each replace a trip out of the notebook:

One caveat about !pip install: it installs into the kernel that is currently running, which is convenient in Colab and a common source of “it worked in the notebook but not in my script”. In a local project, prefer installing into the environment from a terminal (Phase 0, Lesson 06), and remember that a kernel keeps the modules it already imported — a package installed from inside a cell can still need a kernel restart before the new version is visible.

The launch path from the source is three steps long: go to colab.research.google.com, upload any .ipynb file from this course, then choose Runtime → Change runtime type → T4 GPU (free). Because a Colab notebook is the same .ipynb format, this is an open, not a conversion — the notebook you wrote locally gets a different machine underneath it.

1. Open colab.research.google.com and sign in with a Google account.
2. Upload an existing .ipynb (File → Upload notebook) or start a new one.
3. Runtime → Change runtime type → T4 GPU, then prove the machine from a cell with !nvidia-smi.

A T4 is a real accelerator, not a demo. The free-tier card carries 16 GB of video memory — enough for the small model experiments in the early phases and for reading other people’s notebooks — and its harness lists the card, its driver and the memory it found. That last part is worth internalising: when a cloud notebook underperforms, the first diagnostic is not the code, it is !nvidia-smi saying which device the kernel actually has. (The 16 GB is the card’s datasheet specification; what Colab offers on any given day is Google’s call.)

The differences from local Jupyter are all consequences of one fact — the runtime is temporary:

Ninety minutes is generous for reading a notebook and tight for training a model, and the difference is not about discipline: a closed laptop lid does not pause a Colab runtime the way it pauses a local kernel. The two-line habit that turns Colab from a scratch pad into a workspace:

The source’s table is worth reading twice, because the two columns are not “easy” and “hard” — they are interactive and unattended:

The left column has a human in the loop, re-running one piece, reading output, changing a line; the right column has a machine — a scheduler, an importer, a server — that needs a program with a beginning, an end and no clicking. The four-step workflow AI teams actually follow makes the handoff concrete:

1. Explore the data in a notebook.
2. Prototype the model in the notebook.
3. Once it works, move the code into .py files.
4. Import those .py files back into the notebook for the next round of experiments.

Step 4 is the one beginners skip, and it is what makes the workflow a loop instead of a one-way exit: the notebook keeps being the workbench, but the parts that proved themselves stop being cells and become importable modules. Concretely, the feature engineering from yesterday’s notebook becomes features.py, and the notebook now reads:

One more judgement call the table implies: a snippet becomes a script when a machine has to run it, not when it crosses some line count. Ten lines a scheduler runs every night is a script; two hundred lines you are still poking at are a notebook. And the reverse migration is normal too — a debugging session on a broken pipeline often moves the pipeline’s functions into a notebook temporarily, where you can watch intermediate values. The code should be the same; only the container changes.

Trap one: out-of-order execution. You run cell 5, then cell 2, then cell 7. The output is correct and the file looks fine — but the notebook now depends on an order that exists only in your fingers. Someone opens the file, runs it top to bottom, and the replay stops with a NameError: a cell above uses something a cell below creates, and the gap was invisible while your kernel kept the value alive. The source’s fix is one command, run before you share anything: Kernel → Restart & Run All. If the replay passes, the file is the notebook; if it fails, you have found a dependency your clicks were hiding.

Trap two: hidden state. You delete a cell — the one that defined scaler, say — and the notebook keeps working, because the variable it created is still in the kernel’s memory. The file now looks clean and depends on a ghost: no cell creates scaler, yet every cell that uses it runs. A fresh kernel is where the ghost shows itself, with the same NameError the source describes. The distinction from trap one is worth holding onto: out-of-order state is in the file, in the wrong place; hidden state is not in the file at all. The fix for hidden state is to restart the kernel regularly — it is the only way to see what the file really provides — and then restore the missing definition into a cell.

Trap three: memory leaks. Load a 4 GB dataset, train a model, engineer features — say the training step added 2 GB — then load a second 4 GB dataset: nothing gets freed, because every object is still referenced by a kernel variable. Python’s memory manager cannot reclaim what your variables still point at, and the kernel is a long-lived process by design, so the numbers add up instead of resetting: 4 GB + 2 GB + 4 GB = 10 GB resident, on a laptop that has to page. Cells that ran in two seconds start taking forty. The source’s first fix is explicit — del the variables you are done with, then gc.collect():

To feel the scale of that one, the source’s own notebook_tips.py prints its arrays’ sizes: 1,000 elements is 0.008 MB, 100,000 is 0.8 MB, and np.random.randn(10_000_000) is 80 MB (10,000,000 × 8 bytes for float64). That is one array in a fresh kernel. Now imagine holding three 4 GB dataframes because the second analysis might need the first one’s raw form — a habit that costs nothing in a script that exits, and gigabytes in a kernel that stays open all afternoon.