[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[?] Whybook, an open-source JupyterLab extension
Whybook is a view of a Jupyter notebook with no chat box. Point at a column, a plot or a value, and pick one of the questions it offers, or type or say your own. Whybook writes and runs the cell, and shows each choice it finds behind the result.
- Any .ipynb opens in Whybook and stays an ordinary notebook
- The initial questions come at once from templates, with no model call and no data sent out; a connected model adds more a few seconds later
- Branches, other versions of a cell, run in parallel in kernel subshells
Drag IL6 onto the model cell. Or click IL6, then the button that appears on the cell.
[5b]
Ordinal model
Model check branch
bins [-1, 3, 6, 10]AI distr logitAI
pain_level ~ 0 + arm_b * month + age§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.
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
- 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).
- 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).
- 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).
- 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). 83% of developers use AI tools at work (Stack Overflow survey, 2026). By 2026, many developers would not join a trial in which they had to work without AI (METR, February 2026). Employment of workers aged 22 to 25 in the occupations most exposed to AI, software development among them, stood 19% below where it would be had it kept pace with less-exposed peers by June 2026 (Brynjolfsson, Chandar and Chen, Stanford, August 2026). 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).
- Reviewing code. At Anthropic, the code changes merged per day went from about 2,500 in May 2026 to over 30,000 in September. The engineers who built its new source control "would now rate Claude as better at writing code than them". They "still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code" (Anthropic, October 2026). 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).
- 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).
- 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).
- 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).
- 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).
- 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).
- 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).
- 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.
- 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, in JupyterLab or in Jupyter Notebook 7. 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.
| Aspect | A chat assistant | Whybook |
|---|---|---|
| How the analyst asks | Types a prompt | Drags a column onto a cell, or clicks the column and then the cell, and picks a question or types one |
| What comes back | Text to read | The cells the question needs, run in the notebook, and an answer that links them |
| Where the assumptions are | Inside the generated code | Chips 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 alternative | Start another conversation | Branch the cell; the branch runs in parallel, in a kernel subshell of its own |
| What is kept | A chat log | An 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
IL6column onto cell[5]Add IL6 as a covariateModel checkedit [5] in placeMIN_DAYSconstant onto cell[4]What changes ifMIN_DAYSchanges?Model checkbranch of [4] · runs in parallelsleep_hourscolumn ontopain_scoreAre sleep_hours and pain_score associated, within or between patients?Associationnew celldiarydata 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 [5]
- The text of the SummaryCan each number in this text be recomputed from the data?Data qualityafter §8 Summary · needs AI
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 branch
| MIN_DAYS | weekly rows | patient_ids | mean pain_score |
|---|---|---|---|
| 7 | 5,868 | 307 | 2.324 |
| 14 | 5,837 | 291 | 2.309 |
| 21 | 5,837 | 291 | 2.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 checkbranch
done
[4c]
What changes if MIN_DAYS changes?
Model checkbranch
done
[4d]
Make MIN_DAYS an explicit choice in this cell
Model checkbranch
done
[5]
Mixed model: does arm change the trajectory?
Model check
[5b]
Ordinal model
Model checkbranch
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.](https://whybook.dev/img/roadmap/agent-strip.png)
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 checkbranch
bins [-1, 3, 6, 10]AI distr logitAI
| Row | patient_id | diary_day | week | pain_score | sleep_hours | analgesic_use | cycle_day | bleeding | mood | notes |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | P001 | 1 | 1 | 2.0 | 7.4 | none | 17 | False | 4.0 | |
| 1 | P001 | 2 | 1 | 2.0 | 7.5 | none | 18 | False | 5.0 | |
| 2 | P001 | 3 | 1 | 2.0 | 8.4 | none | 19 | False | 4.0 | |
| 3 | P001 | 4 | 1 | 3.0 | 7.6 | none | 20 | False | 4.0 | |
| 4 | P001 | 5 | 1 | 2.0 | 7.3 | none | 21 | False | 5.0 |
| Term | Coef. | Std.Err. | z | P>|z| | [0.025 | 0.975] |
|---|---|---|---|---|---|---|
| Intercept | 5.009 | 0.355 | 14.113 | 0.000 | 4.313 | 5.705 |
| treatment_arm[T.B] | -0.857 | 0.160 | -5.359 | 0.000 | -1.170 | -0.544 |
| month | -0.750 | 0.036 | -20.595 | 0.000 | -0.821 | -0.679 |
| treatment_arm[T.B]:month | -0.318 | 0.050 | -6.383 | 0.000 | -0.416 | -0.221 |
| age | -0.003 | 0.009 | -0.281 | 0.779 | -0.021 | 0.016 |
| patient_id Var | 1.751 | 0.211 | ||||
| patient_id x month Cov | -0.250 | 0.051 | ||||
| month Var | 0.152 | 0.020 |
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, Series or array 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.
1subanalysis
1open assumption
0guesses
Worth asking nextsuggested
Sources for this block
- 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). ↩
- 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). ↩
- 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). ↩
- 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
- 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).
- 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.
- 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, on a laptop or on JupyterHub, 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.
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.
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 needs no kernel and no file format of its own: the notebook's kernel runs the cells, and the sandboxed kernel that it adds is ipykernel in a sandbox.
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, or by a model of the analyst's choice. Code edits on the syntax tree. Local models through llama.cpp, and the review guard. Calls to the models of the AI provider that the analyst connects, with a default cost cap of $0.50 on each call and $2 on each run of an agent, where the 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, and the version of its layout, so later releases can migrate it.
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 labels, titles and questions, for three sizes of machine, decision models for user questions and the order of the questions, three guard models, 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 support.
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.
- Methods to control or correct for the multiplicity of tested hypotheses: Whybook encourages exploration, so it is well placed to remind the analyst how many hypotheses were tested, and to help correct for them.
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.
| Aspect | Frontier for everything | Data stays here | All local |
|---|---|---|---|
| Reads the data | The frontier model | Local models | Local models |
| Writes the code | The frontier model | The frontier model | A larger local model |
| Sent out | Tables, pictures and variables, as each task needs | , code, questions and the text of markdown cells | Nothing |
| Gives up | Control over where the data goes | Questions about pictures, and labels written by small models | Code from the best models, and the hardware costs up front |
| Works offline | Templates only | : all but AI-written code | Yes |
| Costs | Each call to the provider: about $0.0002 for the questions each time the analyst drags or clicks, and $0.001 to $0.06 for a cell, from GPT-6 Luna to Claude Sonnet 5 | Each call to the remote model: the code, and by default more questions each time the analyst drags or clicks | The hardware, once |
| In the prototype | Built | Built |
When the first notebook opens, Whybook asks which of the three ways to use. Later, 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. c.Whybook.way_to_use_models sets the way for every user, and with "all-local" the server refuses every model outside this machine and its network.
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.
| Aspect | Data privacy | Execution safety |
|---|---|---|
| Reads | Every prompt to a model on another machine: questions, a cell's request, an agent's question and each step's result | Every cell, set of branches and Python module that a model wrote, before it runs |
| Looks for | An ID next to a personal detail, several details that point to one person, small counts, names and keys | The 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 sandbox | Checks every prompt the same way: a prompt carries the same data in and out of the sandbox | Asks about installs and shell commands, and rejects the network and secrets |
| In the sandbox | Allows what the sandbox stops: the network, files outside the folder, installs and shell commands | |
| A model on this machine | Does not check prompts: the data stays on this machine | Checks 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 pageThe 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. For table labels, the column lists the five models that the settings offer, by the memory of the laptop that each one suits.
How the methods compared
Labels on table tiles
a table
small model, this machine
mixed model coefficients3 significant
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.
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.
Kernels fit a sandbox
The notebook reaches its kernel only through messages, so the kernel can run in a sandbox with access to one folder of files. Whybook runs it under bubblewrap on Linux and Seatbelt on macOS.
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 tool | What it shares with Whybook | What it lacks |
|---|---|---|
| Mito AI, a JupyterLab extension | Next-step buttons, and the assumptions of an analysis stated so that the analyst can correct them | Both sit in a chat, and the chats are kept outside the notebook |
| Notebook Intelligence, a JupyterLab extension | The prompt and the code it generated, kept in the cell's metadata | The prompt is typed, and no questions are offered |
| Positron, Posit's IDE | Three to five next steps as buttons | No branches, and assumptions only as the reasons for a chart |
| marimo, a notebook | The rows behind a plot selection, as a data frame | No question is offered from the selection. With the Lens add-on, the analyst types a note about a marked region for an agent |
Sources for this section
- The notebook and AI in Jupyter. Project Jupyter is "encouraging subprojects to experiment and develop their own AI-related work", and Jupyter AI and Jupyter AI Lite, formerly 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).
- 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, over ten open models run in the Jupyter server and the settings can add others, and the remote model and decision models of several makers, such as Jev 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, tested on real use
Whybook offers decision models for the type and the place of a user question. On 276 questions from public notebooks, Decider V1.2 of Perplexity and 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, Clef of Cloudflare put 82% right by balanced accuracy, against 43% for the first words on the Ask button. The places that analysts pick in Whybook will test the classifiers 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]"
python -m whybook.demo pain_diary
jupyter lab pain_diary/pain_diary_cohort.ipynbAdd 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 7 GB.
The second command writes three files of the installed release into the folder pain_diary: the notebook, prep.py and clinic.sqlite. The notebook imports its helpers and data from prep.py. In JupyterLab, choose "Open Notebook in Whybook" in the command palette. The first time, Whybook asks which of three ways to use models: pick one, or press Decide later. Then press Run all. The run takes under a minute. The demo after six more hours of analysis is on GitHub, 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.
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.
Work together
Talk to OpenTeams about a trial with a team, funding or sponsorship, or contribute on GitHub.
Ask in public
Ask a question or share an idea where others can join in. Mike, who created Whybook, replies on GitHub and on the Jupyter forum. No GitHub account? Use the forum.
Talk in private
Send Mike an informal message on LinkedIn or in Jupyter's Zulip chat. On LinkedIn, add your question to the connection request.