Prompting Inside Jupyter Notebooks

TL;DR: A Jupyter notebook can run its cells in any order you choose, so the code visible on screen and the actual state sitting in the kernel are often two different things. An AI model reading the file top to bottom can't see that history, so the highest-leverage move is telling it which cells you actually ran, in what order, before asking it to debug, refactor, or explain anything.

Why can't an AI model reliably reason about your notebook's state?

A notebook is a document that combines code, its output, and prose. Jupyter's own introduction describes a notebook document as "a shareable document that combines computer code, plain language descriptions, data, rich visualizations". Nothing in that description requires the cells to run in the order they appear on the page, and in practice they routinely don't: you run cell 4, get an error, fix cell 2, rerun cell 2, then rerun cell 5 without touching cell 3 again. Jupyter's own documentation describes exactly this working style as normal, not a mistake: "Typically, you will work on a computational problem in pieces, organizing related ideas into cells and moving forward once previous parts work correctly."

That flexibility is the entire point of a notebook, and it's also the thing an AI model reading your .ipynb file cannot see. The file stores each cell's source and its last output, but a model skimming it top to bottom has no way to know that cell 5's variable came from a run that happened before you edited cell 2, or that a variable referenced in cell 7 was actually defined by a cell you deleted twenty minutes ago. It will describe the notebook as if it executed in document order, because that's the only order it has access to, and that description can be confidently wrong.

A concrete version of this happens constantly. Say cell 3 builds df_clean by dropping some rows from a raw import, cell 9 uses df_clean in a model, and somewhere in the session you edited cell 3 to change the drop condition, then reran only cell 9, not cell 3. The file on disk shows the new cell 3 source but the old result baked into cell 9's output; the kernel still holds whatever df_clean was before the edit. Paste that notebook into an assistant and ask "why does my model's accuracy not match what cell 3 should produce," and it has no way to know the two cells are out of sync, because the mismatch lives in kernel memory, not in anything written to the file. It will read cell 3, read cell 9, and reason about a pipeline that, as executed, never actually ran.

JupyterLab's own tooling makes the gap explicit rather than papering over it. Its documentation notes: "You can connect a code console to a notebook kernel to have a log of computations done in the kernel, in the order in which they were done." That's a separate, ordered record from the notebook's own cell order, useful specifically because the two can diverge. If a tool built for exactly this environment needs a second, separate log to show real execution order, an AI model reading only the notebook file is working with strictly less information than that.

What makes a Jupyter cell safe to re-run?

A cell is safe to re-run when running it twice in a row, without rerunning anything before it, produces the same result both times. Most exploratory cells fail this quietly:

# NOT safe to re-run: each run appends again, growing the list forever
results = []
results.append(process(row))

# Safer: rebuild from a fresh source each time, rather than mutating
results = [process(row) for row in load_rows()]

The same idea applies past lists: a cell that increments a counter, opens a file in append mode, or inserts a row into a database each time it runs is not safe to re-run, because rerunning it changes the outcome instead of repeating it. A subtler version shows up with randomness: a cell that samples rows, shuffles a dataset, or trains on a random split without a fixed seed gives you a different answer every run, which looks like instability in your analysis but is actually just an unpinned random state. Asking an AI for a cell that's "safe to re-run" should also mean asking it to set an explicit seed anywhere randomness is involved, so re-running produces the same numbers, not merely code that doesn't crash.

When you ask an AI to write or fix a cell, ask specifically for a version that produces the same result if you run it five times in a row without touching anything else. That single constraint rules out most of the accidental-state bugs notebooks are known for, and it's a much sharper ask than "make this cell better."

How do you turn a messy exploratory cell into a real function?

The honest version of this prompt names what actually has to change, rather than just asking for "a function version." A cell built for exploration usually references variables defined in earlier cells, reads a hardcoded file path, and prints instead of returning a value. Turning it into a function means making every one of those implicit dependencies explicit:

Turn this cell into a standalone function. Specifically:
- Every variable it currently reads from an earlier cell (list them) should
  become a parameter, not a closure over notebook globals.
- Replace any hardcoded file path or credential with a parameter or an
  environment variable, and tell me which lines you changed.
- Return the result instead of printing it; keep the print as an optional
  call site, not something the function does itself.
- Tell me if the cell relied on state from a cell you can't see, and name
  what's missing rather than guessing a default.

That last line matters more than it looks, for the same reason the whole state problem exists: if the model can't see where a variable came from, the honest answer is to say so, not to invent a plausible source.

How do you get useful help with an opaque traceback?

A traceback tells you where the code failed and, usually, what type of error it hit. It does not tell an AI reading it in isolation why a variable held the wrong value three cells earlier, because that's execution history, not source code. The fix is supplying that history yourself rather than expecting the model to reconstruct it:

Here's the traceback: [paste it]
Here's the cell that raised it: [paste it]
Here's what I actually ran before this, in order: [list cell numbers, and
flag any you reran out of sequence or edited after running]
Don't guess at what an upstream cell produced — ask me to paste it if you
need to see the actual value, rather than assuming a type or shape.

Explicitly inviting the model to ask for a missing cell, instead of assuming its contents, is the single change that turns a plausible-sounding wrong diagnosis into a real one.

Consider a KeyError: 'customer_id' raised in cell 12. Without more context, a plausible-sounding but ungrounded answer is "your column is probably named differently, check for a typo." The actually useful answer depends on something the traceback can't show: whether cell 6, which built the dataframe, was rerun after a later cell renamed that column, and if so, whether cell 12 ran before or after that rename. Paste both cells and the real run order, and the same model can usually tell you exactly which rerun order produced the mismatch, rather than guessing at a typo that was never there.

How do you turn a whole notebook into a script?

nbconvert, the standard tool for exporting notebooks, has a dedicated mode for exactly this. Its own documentation describes it plainly: "Convert a notebook to an executable script. This is the simplest way to get a Python (or other language, depending on the kernel) script out of a notebook." The command itself is a straight CLI invocation:

jupyter nbconvert --to script your_notebook.ipynb

One documented limit is worth knowing before you run it: nbconvert's own usage guide adds that if a notebook uses IPython magics (%matplotlib inline, %%time, and similar), the resulting script may not run outside a Jupyter session at all. A useful prompt for the AI step that follows the conversion is to ask it to find and either remove or replace every magic command with its plain-Python equivalent, so the exported script actually runs as a script, not merely exists as one.

What does each notebook environment's AI feature actually do?

This is worth checking directly rather than assuming, because the surfaces genuinely differ and they change often.

Google's own FAQ describes the Colab feature set directly. Two entries in its own list: "Next-Generation Data Science Agent (DSA): An agent that can autonomously analyze data, generate a plan, execute code, and present findings." and "Effortless Code Transformation: The ability to modify existing code across your notebook using natural language descriptions." Jupyter AI, JupyterLab's own extension, describes itself this way: "An open source extension that connects AI agents to computational notebooks in JupyterLab." Its current feature list names using "Claude, Codex, GitHub Copilot, Goose, Kilo, Kiro, Mistral Vibe, OpenCode, or other agents directly in JupyterLab."

VS Code's Jupyter extension and Deepnote each ship their own AI surface too, with their own scope, limits, and eligibility rules. Rather than describe features here that would be stale within a release or two, the honest answer is to check each tool's own current docs before assuming its AI assistant behaves like Colab's or JupyterLab's; they are built by different teams on different timelines and there is no reason to expect parity.

Why is pasting a notebook cell into a third-party AI tool a real data-privacy risk?

Because a data-science notebook is unusually likely to contain the exact things you don't want leaving your machine: a database connection string typed in for a quick test, an API key pasted directly into a cell instead of loaded from an environment variable, or a .head() preview built from a real customer table. None of that is unusual in an exploratory notebook, and all of it is plain text the moment you copy a cell.

Whatever you paste into an external AI chat tool is sent to that tool exactly as typed. If a cell contains a live credential, that credential leaves your machine along with the question you actually wanted answered. Before pasting a cell anywhere outside your own notebook environment, it's worth a five-second scan for three things: a connection string, a key that starts with something like sk- or AKIA, and a dataframe preview that shows real rather than synthetic rows. Redacting those three categories before you paste costs almost nothing and closes the most common way a notebook prompt leaks something it shouldn't.

If a language-specific coding prompt is what you actually need once the notebook's own quirks are handled, prompting for Go and Rust covers two languages whose failure modes are nothing like a notebook's. For general debugging help once you've supplied the right execution context, 30 AI prompts for debugging and why AI sometimes rewrites code you didn't ask it to touch are worth reading next, and if a prompt just isn't landing at all, this diagnostic flowchart is a faster fix than rewriting it from scratch.