Whybook

[?] Whybook, a JupyterLab extension

You ask the questions. Agents write the code.

Whybook is a view of a Jupyter notebook for asking questions about data and understanding every result. It has no chat box. The analyst, the person working in the notebook, picks one of the questions it offers, or types or says their own. The offers follow what the analyst points at (a column dragged onto a cell or clicked, a region of a plot, a value on a cell). The code comes from a template, written in advance, or from the AI model of the analyst's choice, and Whybook places the cell and runs it. Every constant, default and choice that Whybook finds behind the result is shown on the cell as a chip, where the analyst can question it.

  • Any .ipynb opens in Whybook, next to the classic notebook
  • The initial questions come at once from templates, with no model call; a connected model adds more a few seconds later
  • Branches, other versions of a cell, run in parallel in kernel subshells
Try it in your browser Install it

Watch a 4-minute demo, or a whole analysis

Drag IL6 onto the model cell. Or click IL6, then the button that appears on the cell.

[5]

Mixed model: does arm change the trajectory?

Model check
reml True left joinAI re_formula ~monthAI missing dropAI 
pain_score ~ treatment_arm * month + age
[5b]

Ordinal model

Model check parallel run 1
bins [-1, 3, 6, 10]AI distr logitAI 
pain_level ~ 0 + arm_b * month + age
A replay of the prototype on its demo data, a synthetic clinical cohort. The questions, where each one goes and the code change are the ones the prototype produced.

§1 Why

The understanding gap

Language models now finish well-defined programming tasks that take an engineer hours, and they beat the best students at programming contests. They can also run a complete statistical analysis that experts judge sound in most cases. Software development went through this change first. Engineers now spend more of their time reviewing and fixing code they did not write. Projects that adopted coding agents show more complex code and less stable releases, and developers who hand the coding to an AI assistant understand it less. Data analysis is going through the same change now. Tim Hanewich calls the result the understanding gap: a divide "between what is being produced and our understanding of what was produced". In data analysis the gap opens in four ways.

An answer without a question

A chat that is asked to "analyse this data" returns an analysis. It does not build insight and it does not exercise curiosity. The analyst no longer decides what to ask next. Asking a chat is the lowest-effort route. Under pressure, analysts default to it, unless their tools make a question-driven exploration fun and fast.

Assumptions inside generated code

Generated code carries modelling choices that the analyst never sees. In the demo cohort, a constant in prep.py leaves out 27 of 318 patients, and no cell of the notebook sets it.

Code that moved into files

Even before language models, analysis code moved from notebooks into modules. A default set in a module does not show in the notebook that uses it.

Hidden reasoning

Models reason before they answer, and the analyst does not read that reasoning. Claude never returns its raw chain of thought, and by default its newest models return not even a summary. A trace that is shown does not always report what the model used.

There is no point in analysing data if no one asked the question.

Mathematics has the same debate: is mathematics about solving problems, or about the understanding gained on the way to the solution? OpenAI's AI-made proof that the Navier-Stokes equations can blow up revived the debate in September 2026. An answer has little value when no one understands why it holds.

Sources for this section
  1. Tasks of hours. METR times tasks on experts and measures which ones models finish: in May 2026 the best model finished tasks of about 3 hours in 80% of tries (METR, time horizons; the method, explained). Against: in a randomised trial in their own mature repositories, 16 experienced developers took 19% longer with AI tools, and still believed that AI had sped them up by 20% (METR, 2025; the paper). In a later round, newly recruited developers were 4% faster, between 15% faster and 9% slower. METR calls that round unreliable, since developers who would not work without AI stayed out of it (METR, February 2026).
  2. Programming contests. Gemini solved 10 of 12 problems of the ICPC World Finals and would have ranked second among the university teams (Google DeepMind, September 2025). At IOI 2026, under the contestants' rules, a model scored 535.4 of 600, above the best human score of 498.27 (Ficek and others, NVIDIA, 2026).
  3. Statistical analysis. Two of three reviewers judged 31 of 40 analyses by AI agents free of major methodological errors (Miao, Pritchard and Zou, Stanford, 2026). In a data science competition, agents alone ranked 9th to 11th of 29 teams, above the median (AgentDS, 2026). Against: the same report finds AI alone below the top quarter of participants, with the best solutions from people working with AI, and on long analyses the best model answers 48% right (LongDS-Bench, EMNLP 2026).
  4. Software first. Coding is the most common use of Claude: tasks of computer and mathematical occupations make up 35% of conversations on Claude.ai, and early adopters "favor specific high-value uses like coding" (Anthropic Economic Index, March 2026). 84% of developers use AI tools or plan to (Stack Overflow survey, 2025). By 2026, many developers would not join a trial in which they had to work without AI (METR, February 2026). Employment of software developers aged 22 to 25 fell nearly 20% from late 2022 to September 2025 (Brynjolfsson, Chandar and Chen, Stanford, 2025). Against: in Denmark, up to 2024, AI chatbots had no significant effect on earnings or hours in any of 11 occupations (Humlum and Vestergaard, NBER, 2025, revised 2026).
  5. Reviewing code. An engineer at Anthropic estimated that their work shifted "70%+ to being a code reviewer/reviser rather than a net-new code writer" (Anthropic, December 2025). Engineers surveyed twice, six months apart, reported less time writing code (82%) and a shift "from creation to verification" (Vella and Blincoe, 2026). The biggest single frustration, named by 66% of developers, is AI answers that are "almost right, but not quite" (Stack Overflow, 2025). "Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That's no longer valuable" (Simon Willison, 2025). Against: a survey of nearly 5,000 people found no relationship between AI adoption and burnout or friction (DORA, 2025).
  6. Complexity and stability. Open-source projects that adopted Cursor got a large, short rise in speed and a lasting rise in static analysis warnings and code complexity (He and others, CMU, MSR 2026). AI adoption "still increases delivery instability" (DORA, 2025). Against: in a registered trial with 151 participants, code written with AI help was no slower or worse for others to change later (Borg and others, ICSME).
  7. Understanding. In a randomised trial of 52 developers, AI help "impairs conceptual understanding, code reading, and debugging abilities, without delivering significant efficiency gains on average": quiz scores fell by 17%, and the four who handed all the coding to the AI scored under 40%. Those who showed stronger mastery used the assistant "to build comprehension while doing so" (Shen and Tamkin, Anthropic, 2026; the paper).
  8. The understanding gap. Tim Hanewich describes a divide "between what is being produced and our understanding of what was produced", when agents produce more than a person can follow. Among the skills that the article recommends for work with agents are choosing what to understand, and how deeply (Hanewich, Medium, May 2026). Margaret-Anne Storey calls it cognitive debt: the people involved "may have simply lost the plot and may not understand what the program is supposed to do" (Storey, 2026). Peter Naur argued in 1985 that programming is the building of a theory in the programmers' heads, more than the writing of a text (Programming as Theory Building).
  9. Asking. In exploratory analysis, the way to understand data is to "use questions as tools to guide your investigation" (Wickham, Çetinkaya-Rundel and Grolemund, R for Data Science). "When you've completed a good data analysis, you've spent more time thinking than doing" (Peng and Matsui, The Art of Data Science). Knowledge workers name lack of time among the things that stop them thinking critically when they use generative AI (Lee and others, CHI 2025).
  10. Code in modules. Researchers and engineers may treat configuration "as an afterthought" (Sculley and others, NIPS 2015). scikit-learn's logistic regression notes that "regularization is applied by default" (documentation; a readable account: Scikit-learn's Defaults are Wrong).
  11. Hidden reasoning. Claude's documentation: "what you see is never the raw chain of thought: the text in a thinking block is a summary of Claude's reasoning". On Claude Opus 5.5, Sonnet 5 and Fable 5.1, among others, that summary is off by default and a thinking block comes back empty, and the thinking is billed either way (Claude docs, Thinking). OpenAI hides the raw chain of thought too, for reasons that include "competitive advantage" (OpenAI, 2024). Given a hint to the answer, Claude 3.7 Sonnet mentioned the hint in 25% of the cases where it used it, and DeepSeek R1 in 39% (Chen and others, Anthropic, 2025). Asked how it adds two numbers, Claude describes the method taught in school, which is not the one it uses (Anthropic, 2025).
  12. Data analysis now. AI agents given one data set reach different conclusions, as teams of people do in many-analysts studies (Bertran, Fogliato and Wu, PNAS, 2026). Databricks offers a data science agent as "a true autonomous partner for data science and analytics" (Databricks, September 2025). Data scientists are among the 25 occupations where generative AI applies most (Tomlinson and others, Microsoft Research, 2025).
  13. The Navier-Stokes proof. On 8 September 2026 OpenAI announced a proof, found by AI agents and checked in Lean, that the 3D Navier-Stokes equations with a smooth force can blow up in finite time, one of the four alternatives of the Millennium problem (the paper). The Clay Mathematics Institute wrote that the problem "has apparently been settled", and that its own review "is deliberately unhurried" (Clay, 11 September 2026). The proof is not refereed yet. Coverage: Quanta Magazine and Nature.
  14. The debate. 25 Fields medallists: "solving problems is only a tool and proxy for achieving the primary goal of conceptual understanding and insight" (declaration, 11 September 2026). "What OpenAI has given us is an answer. But it is not clear that they have delivered a fruitful solution" (De Toffoli and Duede). Against: "there is a spectrum of attitudes in mathematics to the relationship between problem-solving and conceptual understanding" (Timothy Gowers, who did not sign). The Clay problem page: "a proof gives not only certitude, but also understanding" (Clay).

§2 The idea

A notebook view built around questions

Whybook opens any .ipynb file as a second view, next to the classic notebook. Both views share one notebook model and one kernel, so an edit in one shows in the other. Agents do most of the work, under one rule: the result is an ordinary notebook, and the questions, choices and assumptions go into its metadata. The analyst chooses how deep to go on each cell: its question, the choices on its chips, or its code.

A chat assistant Whybook
How the analyst asksTypes a promptDrags a column onto a cell, or clicks the column and then the cell, and picks a question or types one
What comes backText to readThe cells the question needs, run in the notebook, and an answer that links them
Where the assumptions areInside the generated codeChips on the cell, coloured by where each value comes from: the notebook's code, the AI in Whybook, or a default
How to try an alternativeStart another conversationBranch the cell; the branch runs in parallel, in a kernel subshell of its own
What is keptA chat logAn ordinary .ipynb, with the questions in its metadata

Drag or click

Ask by pointing at the data

Anything in the Variables and Contents panels can be dragged onto a cell, a variable or a column, and so can files and database tables. Whybook lists up to 12 ranked questions of , each with in the notebook.

Questions from templates show at once, and most of them run code with no model call: a template is code written in advance, with the selected names filled in. For those marked , an AI writes the code. A connected model adds up to 5 questions of its own a few seconds later. Above the questions, a box takes .

Dragging is optional: in Click mode the analyst clicks the source, then the target, or uses the keyboard. The modes change which questions rank first: Wonder is for finding what else is in the data, Do for carrying the analysis on, and Report for building what goes into a report.

What the prototype offers when the analyst drags, selects or clicks

  • IL6 column onto cell [5]Add IL6 as a covariateModel checkedit [5] in place
  • MIN_DAYS constant onto cell [4]What changes if MIN_DAYS changes?Model checkbranch of [4] · runs in parallel
  • sleep_hours column onto pain_scoreAre sleep_hours and pain_score associated, within or between patients?Associationnew cell
  • diary data frame onto itselfProfile diary: types, missingness, duplicatesData qualitypreview only
  • Weeks 14 to 24 selected on a plotWho is still in the data here, by treatment_arm?Data qualitynew cell after [4]
  • The text of the SummaryCan each number in this text be recomputed from the data?Data qualityafter §8 Summary · needs AI
  • patients data frame onto cell [5]Screen every column of patients against this cell's outcomeAssociationnew cell after [5]
  • visits SQLite table onto cell [5]Join the per-patient_id means of visits to model_dataDescriptivenew cell after [5]
  • Cells [4] and [5] selected on the mapIs the trajectory in [4] what [5] estimates?Model checkedit [4] · needs AI
  • Bar A clicked on a bar plotIs treatment_arm A different from treatment_arm B by more than chance?Associationnew cell after [17]

Decision chips

Every choice in plain sight

After a cell runs, Whybook reads its code against the live kernel and lists the values that the result depends on. Each value becomes a short chip, its name and its value, such as MIN_DAYS 14, or inner join ×2 for two merges that keep pandas' default. The colour shows where the value comes from, and the tooltip describes what the value does. Constants defined in imported files are shown on the cell that uses them.

MIN_DAYS = 14 is set in prep.py. It leaves out 27 of 318 patients, and no cell sets it. Drop MIN_DAYS onto cell [4] and Whybook re-runs [4] with 7, 14 and 21 in a branch.

x
Written in the notebook's code: by the analyst, a colleague, or an agent outside Whybook.
xAI
Chosen by the AI model that wrote the cell in Whybook.
x
Not set in the notebook: a parameter left at the library's default, or a constant from an imported file that no cell sets. The tooltip shows which.
[4]

Weekly pain per patient, by arm

Association
prep.py § drop_sparse()line 31
31MIN_DAYS = 14
32
33
34def drop_sparse(df, min_days=MIN_DAYS):
35    """Keep patients with at least ``min_days`` diary days."""
36    keep = df.groupby("patient_id").size() >= min_days
37    return df[df["patient_id"].isin(keep[keep].index)]
[4c]

What changes if MIN_DAYS changes?

Model check parallel run 1
MIN_DAYSweekly rowspatientsmean pain_score
75,8683072.324
145,8372912.309
215,8372912.309

The prototype's output. With 14 or 21 days, 27 of the 318 patients are left out. With 7 days, 11 are.

Plot selection

Question the result

Every mark of a plot drawn by Whybook's helpers maps to rows of its data frame. A selection on the plot shows how many rows it holds, what differs there, and questions about it. The analyst can keep the selection as a variable and drag it like any other.

Try it: drag across the plot. This is the plot of the demo's cell [4], weekly pain per patient by treatment arm, with bootstrap intervals. The numbers next to the plot are computed from the plot's data the way the prototype computes them.

pain_score by week

Drag across the plot to select weeks. Every mark maps to rows of weekly.

Markdown cells

Question the writeup

The text of a markdown cell shows in each of Whybook's views of the notebook, and it can be questioned like a result. Whybook first lists each number the text states, with the outputs that show it, rounded as the text rounds it. A number that no output shows stands out. Then come the questions, which an agent answers with the cells they need after the text. Words selected in the text are the subject of the questions instead.

Try it: the panel shows the questions about the words "by 0.32 points more per month", marked in the summary. Select other words to question them instead, or press Question this text. This is the summary of the demo after six more hours of analysis, and the matches are the ones the prototype finds in its outputs.

Pain falls over the six months in both arms, faster in arm B, by 0.32 points more per month, and the difference holds without site east and for each value of MIN_DAYS. More patients stop keeping the diary in the first 12 weeks in arm A (26%) than in arm B (9%), so the patients who stay are not a random half of either arm. Of the 4,812 proteins, only NGF tracks how fast pain changes once the false discovery rate is controlled.

Shift+drop, Alt+drop

Branch in parallel, keep one line of cells

Shift+drop turns any question into a branch. Alt+drop starts several branches at once. Whybook calls each one a parallel run: underneath, each branch runs in its own kernel subshell (Jupyter Enhancement Proposal 91, in ipykernel 7), so branches run in parallel on the same data without copying it.

The notebook stays a single list of cells. The Code view shows the cells as the notebook does, branches included. There is no reactive execution: an edit to a cell does not re-run the cells after it.

[4]

Weekly pain per patient, by arm

Association
Branch of [4] · runs in parallelDoes MIN_DAYS = 14 change the result of [4]?
[4b]

Does MIN_DAYS = 14 change the result of [4]?

Model checkparallel run 1
done
[4c]

What changes if MIN_DAYS changes?

Model checkparallel run 1
done
[4d]

Make MIN_DAYS an explicit choice in this cell

Model checkparallel run 2
done
[5]

Mixed model: does arm change the trajectory?

Model check
[5b]

Ordinal model

Model checkparallel run 1
Parallel 0/8Python 3 (ipykernel)

Answers by an agent

One question, as many cells as it needs

When a question needs AI and its answer goes into a new cell, an agent answers it in the notebook. It adds and runs the cells that the question needs, reads what each one shows, and compares choices side by side as branches that run in parallel, such as another model or another subset. It ends with an answer of a few sentences that links the cells that show it, and with follow-up questions. When one cell is enough, it writes one, and code too long for a cell goes into a module next to the notebook.

Each cell goes into the notebook as it runs, marked as written by AI, with the choices in its code on chips. Stop ends the run, and one click removes its cells, with an Undo. With the data kept on this machine, the agent reads what local models wrote about each table, and only the kind and size of other outputs, never their values.

A cell with a table of pain by arm, and under it the agent's run for the question 'Does the fall in pain over the weeks differ by arm?': three steps with the cells they added, [3], [4], and the branches [4b] and [4c], an answer that links them, and two follow-up questions. The agent's first cell, a table of mean pain by week and arm, follows.

A run answered by the screenshot script: the cells ran in the kernel, and the script wrote the steps and the answer.

Code, Bench and Map

See the whole analysis, then the lines that matter

Whybook shows one notebook in three views. The map draws the cells and the data frames they use as a graph. The bench shows each cell as a card with its title, its chips and its outputs, and Show code opens its code. The Code view shows every cell as the notebook does. Within each view, the Detail slider sets how much of each output shows, down to a tile with its size and a label.

An agent, Whybook's or any other, does not tire after a hundred cells. The analyst still has to understand those cells, and chooses what to understand, and how deeply. The map shows the whole analysis, the bench each step, and the Code view each line. This is the order of Ben Shneiderman's Visual Information-Seeking Mantra: "Overview first, zoom and filter, then details-on-demand".

In a long notebook, the analyst finds a cell on the map: a double-click on its card shows the cell on the bench. With the setting Minimap on, a minimap in the corner of the bench opens the map again.

Try it: switch between the views, each in a box of the same size, move the Detail slider, and double-click a card on the map.

[4]
Weekly pain per patient, by armAssociation
MIN_DAYS 14 inner join ci bootstrapAI n_boot 1000AI
[5]
Mixed model: does arm change the trajectory?Model check
reml True left joinAI re_formula ~monthAI missing dropAI
[5b]
Ordinal modelModel checkparallel run 1
bins [-1, 3, 6, 10]AI distr logitAI

Exploration panel

Make it feel like a game

Analysis tools have to be fun to use, or analysts take the lowest-effort route of §1. In web design, language models gave people new room to explore, and many of them are happier for it.

Work in progress always has a progress bar. The Exploration panel counts each question by type once its answer has run, apart from those that failed. It also counts guesses: while a cell about a relation or an effect runs, the analyst can say with one click what they expect, such as higher or lower. The panel fills a square for each column that the analysis has used, and suggests what to ask next, with the reason. Once a causal question is asked, and while fewer than 15% of the questions are causal, the panel shows the note "Few causal questions so far: the effect estimate rests on untested paths."

The panel rewards questions of one's own. A question the analyst types counts in a darker shade than one picked from the offers, and a column reached only through offered questions gets a lighter square. The box for a question of one's own sits above the suggestions, and the setting "Offered questions per request" at None hides the offers, so that every question is typed.

Writing one's own questions helps understanding

Across 26 studies, students taught to write questions about what they read understood new texts better.1 In a tool for data, a display of the columns already covered doubled the questions that analysts asked, and raised their main findings from 5.2 to 7.6 each.2 The kind of question counts more than their number: in tutoring, students who asked a larger share of "why" and "how" questions had higher exam scores, and students who asked more questions did not.3

A count on screen makes people do more of what it counts, and the extra work is not always better,4 so we weigh four designs before any reward grows.

Try it: type a question of your own, or press Ask on a suggestion, and watch the counts change. The panel starts from the demo notebook's state after Run all.

Questions asked5

Darker: questions you typed. Lighter: questions you picked.

Variables explored
1subanalysis
3open assumptions
0guesses
Worth asking nextsuggested

Sources for this block
  1. The median gain was 0.36 standard deviations on standardized reading tests and 0.86 on tests the researchers wrote, from grade 3 to college (Rosenshine and others, 1996). Writing questions helped no more than answering someone else's (Weinstein and others, 2010). ↩
  2. 20 business students, 60 minutes each: 18.7 questions against 9.7, and 7.6 correct top-level findings against 5.2 (Sarvghad and others, 2017). When findings could be checked against the model that made the data, over 60% of those from open exploration were false (Zgraggen and others, 2018). ↩
  3. 27 college students in tutoring: exam scores went with the share of deep questions (r = 0.47), not with their number (r = -0.56 and -0.12) (Graesser and Person, 1994). ↩
  4. A count on screen: more pictures coloured, rated less creative (Etkin, 2016). Where the counted activity helps learning, counting it can help too: badges raised self-testing and exam scores for 701 students (Denny and others, 2018). ↩

§3 Evidence

What studies and products have found

Several choices in Whybook follow from user studies. Each finding names the choice it supports and links to its source.

Assumptions on the cell

Stated assumptions help analysts find errors

In a study of 22 analysts who checked analyses an AI wrote, participants "often noticed errors faster in tasks where the AI clearly stated its assumptions about the data". Gu et al., CHI 2024

Questions at each step

Guidance does better than full automation for exploration

With 20 users, a copilot that guided each step did better than a fully automated one in user control, software utility and learnability, "especially for exploratory and creative tasks". The automated one saved time on simpler visual tasks. Khurana et al., CHI 2025

Branches beside the answer

AI agents disagree with each other

AI agents given the same dataset and hypothesis reached different effect sizes, p-values and conclusions, from different choices in preprocessing, model and inference. Another model or persona gave other results. The authors ask for multiverse-style reporting of AI analyses. Bertran et al., PNAS 2026

Editable steps in place of a chat

Analysts feel more in control

Against a chat, two systems that showed editable assumptions and steps gave 18 participants significantly more control, and made intervention, correction and verification easier. Task success and completion time did not differ. Kazemitabaar et al., UIST 2024

Offered questions can take the place of the analyst's own. In the Voyager 2 study, recommended views made one participant "start thinking less", while the tool that adds them cut the share of fields that people overlooked from 20% to 7%. Handing the whole task to an AI costs more: developers who let an AI write all the code understood it less than those who asked it only about concepts. Offered questions sit between the two. Studies of overreliance suggest two safeguards: a guess before each result, and a question back in place of an answer.

Sources for this paragraph
  1. Voyager 2. "These related views are so good but it's also spoiling that I start thinking less." With Voyager 2, which adds related views and wildcards, "subjects overlooked 20% of the fields in a dataset on average when using PoleStar, while only 7% were overlooked using Voyager 2" (Wongsuphasawat and others, CHI 2017).
  2. Full delegation. In a randomised trial of 52 developers, AI help lowered quiz scores on the code by 17%; the 4 who delegated all the coding scored 39%, against 65% for the 7 who asked only about concepts (Shen and Tamkin, Anthropic, 2026). Students who practised with an AI tutor that gave answers did 17% worse once it was taken away (Bastani and others, PNAS, 2025). No study compares offered questions with full delegation directly.
  3. Safeguards. In two crowdsourced experiments, people who stated what they expected before seeing the data made 21% more correct inferences and 12% fewer false discoveries (Koonchanok and others, CHI 2023). Questions from an AI helped people spot flawed statements more than explanations did (Danry and others, CHI 2023). Designs that made people think before seeing the AI's answer (decide first, wait, or ask to see it) reduced overreliance, and people liked them least (Buçinca and others, CSCW 2021). A tutor that gave hints in place of answers reduced the harm to learning (Bastani and others, PNAS, 2025).

§4 Prototype

It runs today

The prototype is an extension for JupyterLab 4.4 and later, with a Jupyter server extension. Its demo is a synthetic clinical cohort: a daily pain diary, patient characteristics, a protein panel and a SQLite database of clinic visits. A second copy of the demo shows the notebook after about six more hours of analysis, with 28 cells, larger tables and a written summary.

Watch it work

Each video is one recorded session in JupyterLab, on public data, with a live AI model. Start with the 4-minute demo: a validator checks a notebook that someone else wrote. Or watch a whole analysis, from the raw file to the answer.

Image

A model developer hands over a credit scorecard notebook (today, often written with an AI agent), and a validator checks it in Whybook. The chips on the model's cell show the settings that the code never wrote. A click on a chip reruns the cell with another value, in a branch. An agent writes the same model in R, and Whybook compares every estimate with R's. The data are 30,000 card holders of a bank in Taiwan; the scorecard notebook was written for this video.

Chapters

  1. 0:00 The task
  2. 0:40 The developer's notebook
  3. 0:57 Run it as written
  4. 1:31 Is it the penalty? (a chip's what-if)
  5. 1:55 The same model in R (another kernel)
  6. 3:19 Let it converge (the limit's what-if)
  7. 3:57 The answer
The bench after Run all. Cells show as summaries with their chips, and at Full, the default level of detail, their tables and plots in full. The notebook's introduction is under its title. The Variables and Contents panels are on the left, the Exploration panel on the right.
Another application: home energy use

A second example, from another field: 360 homes, their electricity meters, and a time-of-use tariff that a quarter of them chose. Nothing in Whybook is specific to either example.

The cell that joins each day to its home and its weather shows two constants that energy.py sets and no cell names: BASE_TEMP_C 15.5 and MIN_COVERAGE 0.9. It also shows inner join ×2: both of its merges keep pandas' default.

How Whybook fits into Jupyter

Whybook is one Python package with two parts: an extension for JupyterLab in the browser, and an extension for the Jupyter server. It brings no kernel and no file format of its own.

When the analyst drags a column onto a cell, the browser part asks the server part for questions. Once the analyst picks one, the server part writes or edits its code, the browser part runs that code in the notebook's kernel, and the result is saved in the .ipynb file.

  • In the browser

    JupyterLab extension

    Three ways to show a notebook: Code, Bench and Map. The panels Variables, Contents, Questions, Exploration and Cell details. Cell details shows all that Whybook knows of one cell, in one place: the cell that the analyst worked on last, or the one picked on the map. A Databases panel sits under the file browser.

  • In the Jupyter server

    Server extension

    Questions from templates, ordered by the rules and a small learned ranker. Code edits on the syntax tree. Calls to the models of the AI provider that the analyst connects, with a cost cap on each call where its price is known. SQLite files, read-only.

  • The notebook's own

    Kernel

    The main shell runs the cells. Subshells run branches at the same time, and list variables while a cell runs.

  • On disk

    The .ipynb file

    Cells and outputs, as in any notebook. The whybook metadata keeps each cell's question, assumptions, decisions and branch, so the notebook opens as it was left.

Whybook builds on these parts of Jupyter and adds its own, such as the questions, the AI models and the kernel sandbox: §9 shows what each part of Jupyter gives it.

Built

  • Three views of one notebook: Code, Bench and Map.
  • Questions by dragging or clicking variables, columns, files, database tables, plots and text.
  • Branches that run in parallel, in kernel subshells.
  • Each answer in a new cell by default, or in an edit or a branch when the first words of the question ask for one. A preview, and the place that a decision model gives, are suggestions under the question box.
  • An agent that answers in as many cells as a question needs, and that redoes an analysis in a new notebook in Python or R and compares the numbers.
  • Local models in the Jupyter server, through llama.cpp: five for three sizes of machine, and any GGUF model the settings add.
  • "Keep data on this machine", which the server can turn on for every user.
  • A review guard, on by default: it checks each prompt before it goes to a model on another machine, and each cell that a model wrote before it runs. Rules check first, and a guard model too when the analyst turns one on.
  • Kernels in a sandbox on and : "Python 3 (sandboxed)", and a sandboxed copy of any other kernel, such as R. Each has access to the notebook's folder only, and to no network.
  • R kernels: the Variables panel, chips on the cells, and questions, whose code an AI model writes in R.
  • Spoken questions, transcribed in the browser or by Moonshine in the Jupyter server.
  • A code change and Undo for every question applied, and an AI tag on text that a model wrote.
  • A machine-readable mark in the notebook on everything a model writes, as Article 50(2) of the EU AI Act asks.
  • A notebook saved from Whybook opens as it was left, before the kernel runs anything.
  • Jupyter Notebook 7: a switch in the menu bar of a notebook's page shows Whybook in place of the notebook editor and back, on the same notebook and kernel.

Not built yet

  • Questions about plots need a Python kernel, and only Python kernels have subshells, so branches in R run one after another. In a kernel of another language, such as SAS, cells run and their outputs show, with no variables and no questions.
  • Question and answer templates for R: in an R kernel, a model writes the code of every answer.
  • The Databases panel opens SQLite files only: tables from PostgreSQL, MySQL and other servers cannot be dragged onto a cell.
  • Whybook is not tested in JupyterLite.
  • The sandboxed kernel runs on Linux and macOS, not on Windows, where JupyterLab inside WSL2 gets the Linux sandbox. It has no network, so packages cannot be installed into it.

The roadmap puts this work on the path to v1, through an alpha and a beta, and lists what waits for v2.

§5 Local models in progress

Small models, on the analyst's machine

Clinical, financial and other personal data should not leave the analyst's machine. Most of the model work in Whybook is small: order up to 12 questions, label a table, title a cell. A small open model of the analyst's choice can do this work in the Jupyter server: label tables, summarise frames, title code cells, suggest more questions, sort a user question and order the offered questions. In the settings, the analyst chooses the model of each task and can add any other model (§7 lists each use, and §8 compares the methods for each job).

Three ways to use models

Any laptop, even a Chromebook

Frontier models for everything

A hosted frontier model reads what each task needs and writes the code.

For
Students and small labs, where the data may go to a model provider. For example, a student who opens the university's JupyterHub on a school Chromebook.
Runs on
Any device with a browser: the Jupyter server can run on a hub, and the model runs at its provider.

A 16 GB laptop or a Mac mini

Data stays on this machine

Local models read the tables and describe them. A frontier model writes the code from those descriptions and the names, kinds and sizes of the variables.

For
Companies, hospitals and government, where the data must stay but its descriptions may go out. For example, a drug company's analyst on the standard 16 GB laptop, or a tax office analyst with personal records.
Runs on
The standard laptop that universities buy for $1,400 to $2,300, with 16 to 32 GB, or a Mac mini from $899. Gemma 4 E2B is a file of 2.8 GB.

An AI PC or a small server

All local in progress

Local models read the data and write the code. Nothing leaves the building, and the work goes on with no internet.

For
Large companies and government, where nothing may leave the building. For example, a bank's analysts sharing one GPU server in its data centre, or a ministry's statisticians on a network with no internet.
Runs on
A PC with a 32 GB GPU, such as the RTX 5090, a desktop with 128 GB of unified memory, such as NVIDIA's DGX Spark or a Mac Studio, or a server with 80 GB GPUs.
Frontier for everythingData stays hereAll local
Reads the dataThe frontier modelLocal modelsLocal models
Writes the codeThe frontier modelThe frontier modelA larger local model
Sent outTables, pictures and variables, as each task needs, code, questions and the text of markdown cellsNothing
Gives upControl over where the data goesQuestions about pictures, and labels written by small modelsCode from the best models, and the hardware costs up front
Works offlineTemplates only: all but AI-written codeYes
CostsEach call to the providerEach call to the remote model: the code, and by default more questions each time the analyst drags or clicksThe hardware, once
In the prototypeBuiltBuilt

One setting, "Keep data on this machine", switches from the first way to the second. Here "this machine" is the machine that runs the Jupyter server, with any model server in its network that the analyst connects as local. c.Whybook.keep_data_local in the server's configuration turns it on for every user, and the setting then shows as fixed.

Connecting a model. The AI models panel finds the model servers that answer on this machine, such as Ollama, and lists their models. There the analyst signs in to OpenRouter, for Claude, GPT, Gemini and open models, or pastes a Hugging Face access token, for open models served by a company that the analyst picks, such as OVHcloud or Scaleway in Europe. It also takes an API key of Anthropic, OpenAI, Google or Mistral AI. A model connected at a provider in one of these ways is the remote model. Each key is the analyst's own, stays on the server and never reaches the browser. A model on this machine reads the data as the small local models do. The calls go through Pydantic AI, which reaches any server with an OpenAI-compatible API.

Marked as written by AI. Every cell, label and question that a model writes carries a mark in the notebook's metadata: which model wrote it, and when. Article 50(2) of the EU AI Act asks providers of AI systems that generate text to mark it "in a machine-readable format", from 2 August 2026. Regulation (EU) 2024/1689, Article 50

§6 Review guard

A guard for what leaves the machine, and for code before it runs

An analyst who lets AI write and run code needs to know two things: what goes out, and what the code can read, change or send. Whybook checks both before either happens, on the analyst's machine. The privacy guard reads every prompt before it goes to a model on another machine, and looks for patient and household IDs, names, ages, dates, health details, small counts and keys. The execution guard reads every cell, set of branches and module that a model wrote, before it runs, and asks about more while the notebook's kernel runs outside the sandbox. In ask mode the guard shows what it flagged and waits; in reject mode it masks the flagged parts, or holds the cell back, and the work goes on.

An agent's cell printed one patient with an age and a stage. Before the result goes back to the model, the guard shows what it flagged and why, and marks it in the lines around it. Send without the marked parts sends the result with the ID written as [identifier].
Data privacyExecution safety
ReadsEvery prompt to a model on another machine: questions, a cell's request, an agent's question and each step's resultEvery cell, set of branches and Python module that a model wrote, before it runs
Looks forAn ID next to a personal detail, several details that point to one person, small counts, names and keysThe network, secrets, files outside the notebook's folder, deletes, shell commands, installs, hidden code, and text written to steer the guard's answer
Outside the sandboxChecks every prompt the same way: a prompt carries the same data in and out of the sandboxAsks about installs and shell commands, and rejects the network and secrets
In the sandboxAllows what the sandbox stops: the network, files outside the folder, installs and shell commands
A model on this machineDoes not check prompts: the data stays on this machineChecks every cell, set of branches and Python module that the model wrote, before it runs, as for a model on another machine

The rules run first, on the analyst's machine, in at most a few hundredths of a second. A guard model, also on the analyst's machine, can read each prompt or cell as well, and the stricter answer wins. Whybook offers three guard models that read a policy written in the analyst's words: IBM's Granite Guardian 4.1, DynaGuard and Mistral AI's Shieldstral. For admin-level enforcement, c.Whybook.review_guard in the server's configuration sets ask or reject for every user and keeps both guards on, and no user can turn them off. c.Whybook.keep_data_local does the same for "Keep data on this machine".

§7 AI uses

Every use of AI in Whybook

AI in a notebook ranges from full agentic control to full user control. Full agentic control gives the fastest results and costs the analyst understanding. Full user control keeps data safe and private but is slow. Whybook keeps the control with the analyst, and one setting keeps the data on the analyst's machine. The analyst still gets results quickly, though not as fast as with full agentic control: the analyst asks the questions, agents write the code, and every choice stays in sight. Each job that Whybook gives to AI: what starts it, what the model reads, where it can run, and what changes when the data must stay on the analyst's machine.

A script draws the list.

§8 Research

What we tested, and what we recommend

Whybook gives AI a few small jobs, such as ordering the offered questions and labelling a table. For each job we tested rules built into Whybook, open models on the analyst's machine and remote models, on what analysts asked in real notebooks. Whybook's default is the simplest method that did the job.

Every result, on the benchmarks page

The method for each job

Each share comes from the tests below. The columns "On this machine" and "Remote" list up to three models that an analyst can pick in Whybook, best first, with their distance from the default in percentage points. A grey line names better models that Whybook does not offer yet.

How the methods compared

Labels on table tiles

A table too large for the bench shows as a tile with a description of one to three words and a headline. A small model on the analyst's machine can write them, so that the table stays on the machine.

Descriptions right, of 20 tables, with one call, and the size of each model's file

Which question to offer first, for a variable dragged onto another variable

300 examples from public notebooks. The score is the share of examples where the first question offered had the same type as the question that the notebook's author asked next, a proxy for a good question.

Which question to offer first, for a column dragged onto a cell

300 examples made from public notebooks, as in the demo at the top. The score is the share of examples where the first question offered had the same type as the question that the notebook's author asked next.

The type of a question that the analyst types

276 questions from public notebooks. The score is the share of questions that a method gave the same type label as a reader who labelled them without seeing any method's labels.

Where the answer to a user question goes

360 questions, each written for one of the four places. The score is the average, over the four places, of the share of questions that a method put where their writer meant.

Where the answer to a gesture goes

650 public notebooks. When the analyst drags something, the rules choose the place of the answer, and no model does.

How we tested
  • 650 public notebooks from five collections: the notebooks of papers in PubMed Central, three newsrooms, the Jupyter gallery, the examples of four statistics libraries, and five textbooks. For 4,790 of the questions their authors asked, the tests work out what an analyst would drag, and onto what, to ask it in Whybook.
  • 272 notebooks of DASWOW, a random sample of data science notebooks on GitHub, whose every code cell data scientists labelled as exploring, building a model, or neither (Ramasamy and others, Empirical Software Engineering, 2023). Their labels check the types that the tests read from code, and they are a second collection to test on.
  • Held out. The logistic regression and the most common type are scored only on repositories that they were not fitted on: the notebooks go into 10 folds by repository, and each fold is ranked by a model fitted on the other nine. Fitted on the five collections and tested on DASWOW, which it never saw, the regression puts the analyst's type first for 54%.
  • 276 user questions from the markdown of the 650 public notebooks, each with the code cell above it. A reader who saw no method gave each a type and a place. An earlier test of 120 questions had one author for the questions, their labels and the rules, and its numbers are in the research notes.
  • Grading of the table labels: a frontier LLM graded every answer without knowing which model wrote it.
  • Remote models got Whybook's own request, one at a time, through OpenRouter with zero data retention, or through the Claude Code login. The rows marked agents came from agents of Claude Opus 5.5 that read 100 requests each, which Whybook does not do. A later request among an agent's 100 could show what the author asked at an earlier one, and asked one request at a time, the same model did worse.
  • Speed on the laptop that universities buy as standard in 2026, such as a MacBook Air with the M5, with a GPU build of llama.cpp: estimated as the time on the test machine divided by 20.

More research is needed on traces of real use. The tests replay saved notebooks, which keep only the questions that their authors asked. They do not show which offered questions an analyst picks, skips or undoes. That needs Whybook's own logs, shared with consent.

§9 Why Jupyter, why now

Jupyter already has the parts

The future of the notebook as an interface is a common topic in the Jupyter community, and Jupyter has the parts to build it from.

Notebooks store the work

A notebook is JSON with room for metadata. Whybook keeps there the question that each cell answers, the model that wrote it, its cost and its assumptions, so the file records how each result was made.

Kernels hold live variables

The variables of the analysis stay in memory while the analyst works. Whybook lists them in the Variables panel. The analyst drags one onto a cell to ask about it, and a chip on a constant offers other values to try.

Outputs can be questioned

An output carries a result in rich forms, such as an HTML table, a picture or a plot with its data. The analyst asks about a picture or a region of a plot, whose marks keep their rows. JEP 129 proposes _ai_repr_, a form of an object written for a model.

Subshells run branches at once

Kernel subshells (JEP 91, in ipykernel 7) run several branches of an analysis at the same time, on the same data in memory.

Extensions are cheap to adopt

Users, universities and companies add an extension to the JupyterLab they already run. A new application costs far more to adopt. A standalone app can come later.

The awesome-jupyter-ai list has over 100 AI extensions for Jupyter. The largest group, nearly 30 of them, are chat panels and agents. We found none built around the analyst's questions about the data. The closest tools each share one part of the idea:

Closest toolWhat it shares with WhybookWhat it lacks
Mito AI, a JupyterLab extensionNext-step buttons, and the assumptions of an analysis stated so that the analyst can correct themBoth sit in a chat, and the chats are kept outside the notebook
Notebook Intelligence, a JupyterLab extensionThe prompt and the code it generated, kept in the cell's metadataThe prompt is typed, and no questions are offered
Positron, Posit's IDEThree to five next steps as buttonsNo branches, and assumptions only as the reasons for a chart
marimo, a notebookThe rows behind a plot selection, as a data frameNo question is formed from the selection
Sources for this section
  1. The notebook and AI in Jupyter. Project Jupyter is "encouraging subprojects to experiment and develop their own AI-related work", and Jupyter AI and jupyterlite/ai each bring AI to the notebook in their own way (AI in Jupyter). The board of the Jupyter Foundation chose "Notebooks and AI" as the topic of the members' round tables in June 2026 (minutes of 5 June 2026).
  2. A kernel in a sandbox. ipykernel 7.3 runs under bubblewrap on Linux, started by a kernel provisioner, the way the Jupyter server starts a kernel. It writes only to the notebook's folder, has no network but its own loopback, runs two subshells side by side, and starts in 1.05 s, against 1.04 s for a plain kernel. Whybook installs it as the kernel "Python 3 (sandboxed)", and a browser test runs the extension against it: Run all, a branch in a subshell and the Variables panel. It runs on Linux under bubblewrap, and on macOS under Seatbelt.

§10 Why it lasts

Designed to last

Many AI tools for notebooks have stopped. Forks fell behind the project they copied. Extensions stopped when the company behind them changed course or closed. Results turned into errors when the service that made them shut down. Each of these projects tried something early, and each left a lesson for the community. Several also gave back to Jupyter. Most of the cases come from a survey of more than 100 AI extensions for Jupyter.

An extension of JupyterLab

Forks miss the fixes

Pretzel forked JupyterLab 4.2 in 2024 and licensed its changes under AGPLv3, which JupyterLab's BSD licence cannot take in, so they could not go upstream. Its development stopped the same year, and its last release lacks the fixes for 11 security advisories that affect JupyterLab 4.2, 5 of them rated high. Whybook is an extension for JupyterLab 4.4 and later. It uses the extension API that has been stable since JupyterLab 4.0, so users update JupyterLab as usual.

Upstream first

Copies stop, upstream goes on

Kite's JupyterLab extension started in 2020 as a copy of jupyterlab-lsp. Kite also contributed improvements to JupyterLab's completer. The copy was last updated in 2021 and Kite shut down in 2022, while jupyterlab-lsp is still maintained, and so are Kite's improvements in JupyterLab. What Whybook needs from other packages goes to those packages as changes, and the roadmap lists them.

No single vendor

Vendors change course

Tabnine's JupyterLab client had its last release a week after its first, and Einblick's extension still installs but calls a server that no longer exists. IBM ended its Qiskit Code Assistant service in 2026 and archived the extension, but the models are open on Hugging Face, and the archived extension still supports Ollama and any OpenAI-compatible endpoint. Whybook names no provider: templates need no model, five open models run in the Jupyter server and the settings can add others, and the remote model and Jev, a hosted classifier of TypeSafe AI, are choices in the settings.

The work is an ordinary notebook

Results outlive the model that made them

Excel's COPILOT function stopped working on 14 September 2026, and a cell that recalculates now shows #NAME?. Each answer in Whybook is code and outputs in the .ipynb, and the questions, assumptions and labels are in its metadata. Any Jupyter frontend opens it, with no model and without the extension. Microsoft Support

Answers inside the project

Exploration feeds the rest of the project

retired Databot, its agent for exploratory analysis, and explained why in public: it was "too narrowly scoped", and "EDA does not happen in a vacuum". Whybook puts each answer in the notebook that the project already has, next to its code and its modules. Posit, June 2026

A linear notebook underneath

Free-form canvases stopped; views of a linear notebook remain

Observable no longer develops Canvases, where cells sat anywhere on an open board (August 2026). The bench and the map are drawn from one linear notebook, in the order of its cells, so the notebook stays usable if the views change or go.

Ordinary code

The code in the notebook stays plain Python

Whybook reads what libraries already produce, and its own helpers are optional. Widgets, tqdm bars and Plotly charts show as in the notebook. The analyst can draw a box on a Plotly scatter chart or a matplotlib figure to ask about the rows in it, with no change to the code that makes them.

Community stewards

Made by people who maintain Jupyter

Whybook comes from long-time maintainers of JupyterLab and its extensions, at a company that builds and supports open-source software. They have reviewed and released JupyterLab for years, so they know which of its parts stay stable, and they can make the changes that the extension needs in JupyterLab itself.

§11 Roadmap

What comes next

  • A study of both ways of asking

    Analysts will ask by dragging and by clicking. The study measures the time to the first question, the questions that go to the wrong cell, and keyboard use.

  • Placement and ranking fitted to each analyst

    Whybook will log picks, changes of place and Undo to a local file. A placement model will be fitted to the rules first and then to those corrections, and the learned ranker to the picks.

  • Classifiers for user questions

    On 276 questions from public notebooks, Jev 1.13 gave the right type for 89%, against 67% for the keywords. For the place, on 360 questions written for a given place, Decider V1.1 of Perplexity put 85% right by balanced accuracy, against 33% for the first words on the Ask button. The places that analysts pick in Whybook will test both on the questions that matter.

  • Packages in the sandbox

    The sandboxed kernel will install a package when the analyst asks for one. Whybook will show in its toolbar which kernel runs in the sandbox, as the AI models panel already does.

  • Beyond Python and JupyterLab

    Templates and questions about plots in R, kernels of other languages such as Julia, JupyterLite, and _ai_repr_ in libraries.

  • Read the roadmap

    The roadmap sets out the path to v1 through an alpha and a beta, and what waits for v2.

Try the prototype

Whybook is on PyPI, and its code is at openteams-ai/whybook. Install it into the environment of your JupyterLab:

Shell
pip install "whybook[kernel,demo,models]"
jupyter lab

Add local for the models that run in the Jupyter server: pip builds llama-cpp-python with the system's C++ compiler, in about 4 minutes, and each model is a download of 1.6 to 4.6 GB.

To try the demo, clone the repository and open examples/pain_diary/pain_diary_cohort.ipynb: it imports its helpers and data from prep.py in the same folder. In JupyterLab, right-click the notebook, choose Open With, then Whybook, and press Run all. The run takes under a minute. examples/pain_diary/pain_diary_cohort_6h.ipynb is the demo after six more hours of analysis, and it opens with its map and panels before anything runs. Questions marked "needs AI", and questions that the analyst types, need a model connected in the AI models panel: OpenRouter after a sign-in, a Hugging Face access token, an API key of Anthropic, OpenAI, Google or Mistral AI, or a model server on this machine. Until one is connected, Whybook greys those questions and shows what to set up. With the setting "Keep data on this machine", no tables, printed outputs or pictures leave the machine.

§12 Nebari

Runs on any Jupyter, made with Nebari in mind

Whybook runs on any JupyterLab or JupyterHub, on any platform and with any model provider, Nebari included. It is an ordinary JupyterLab extension, installed with pip, and the notebooks that it writes open in any Jupyter without it: nothing ties an analysis to one platform or one vendor. It is also made with Nebari in mind: some of its features take their ideas from the Intelligence Hub whitepaper.

The whitepaper, Travis Oliphant's The Distributed AI Economy, describes an Intelligence Hub: the AI deployment that an organization owns and runs inside its own perimeter, built from open source such as Nebari and Nebi. A Hub has six parts. Frames carry context, Cogs do bounded AI work, and Ops package whole jobs. Guards check the work, Gates decide whether it goes on, and Tracks record what happened.

People reach a Hub through applications that the paper calls "products around the Hub", such as a desktop and web application where knowledge workers run Ops, chat with Cogs and manage Frames. Whybook can be that product for data analysis. It calls the same kind of Cogs without a chat: the analyst points at data, and each question becomes a cell. It also serves the use case that Nebari started with, which the paper calls "the Jupyter-based data-science use case that was the original goal of Nebari classic".

Layer 3, economythesis

Ops, Cogs, Frames and Guards move between Hubs. Tracks stay in the Hub that made them.

Interface, products around the Hub
Desktop/Web ApplicationexistsFor knowledge workers: Ops as icons, chat with Cogs, Frame management.
WhybookprototypeFor analysts, in JupyterLab: questions by pointing at data, cells that run.
Other productsGate consoles, Track viewers, Op and Cog builders, Guard libraries.
Layer 2, execution
Frames existcarry context
Cogs in developmentdo bounded AI work
Ops in developmentpackage whole jobs
Layer 1, infrastructureexists

The Intelligence Hub, inside the organization's perimeter. Nebari packs such as data science (JupyterHub and JupyterLab), LLM serving, the Frames registry and the Collab Hub. Nebi environments, which also serve as Jupyter kernels.

Accountability plane

Guards check.

Gates decide.

Tracks record.

Across every layer. First Guard libraries in development; the runtime at scale is a thesis.

The whitepaper's three layers and its accountability plane, with Whybook among the products around the Hub. Each "exists", "in development" and "thesis" comes from the paper's own ledger of what exists. The pack names come from the nebari-dev organization on GitHub.

Build it with us

Whybook is a research prototype, open source under the Apache-2.0 licence. Taking it to v1, along the roadmap, needs people as much as code: research with analysts, reviews of its statistics and its security, and maintainers. We are looking for partners:

  • Organisations whose analysts would try the beta on their own notebooks.
  • Funders and sponsors who would carry it to v1.
  • Developers who would contribute to the extension and to Jupyter.
Talk to OpenTeams Contribute on GitHub
Image