Pith. sign in

REVIEW 3 major objections 5 minor 41 references

Plainbook restores notebook verifiability and extensibility for non-coders by centering natural-language cell descriptions, enforcing linear top-to-bottom execution, and verifying values rather than code.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · grok-4.5

2026-07-11 03:09 UTC pith:VUNAELSR

load-bearing objection Solid systems/HCI design for NL-first notebooks with a real checkpointing kernel and value tests; the verification claim for non-coders is still an unmeasured hypothesis, but the engineering is concrete enough to engage. the 3 major comments →

arxiv 2607.05717 v1 pith:VUNAELSR submitted 2026-07-07 cs.HC cs.AIcs.SE

Plainbook: Data Science, in Plain Language

Luca de Alfaro , Mathis Aubert , Ranjit Jhala , Eliana Pastor , Elena Baralis This is my paper
classification cs.HC cs.AIcs.SE
keywords Jupyter NotebooksData ScienceAI Generated CodeCoding in Natural LanguageLinear Execution SemanticsUnit TestingReproducible ResearchComputational Notebooks
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Jupyter notebooks deliver reproducible, shareable data analysis only for people who can read code. Plainbook redesigns the notebook so natural-language descriptions of each cell are the primary, persistent artifact; AI generates the code behind the scenes and keeps it stable unless the description changes. Because natural language is read top to bottom, cells execute strictly in order with no hidden state. Users who cannot inspect code instead verify correctness by inspecting intermediate values through local cell tests and global assertions that relate states across the notebook. A checkpointing kernel caches the state before and after every cell so this linear semantics and the value-based checks remain efficient even when a user iterates on a single cell.

Core claim

By promoting natural-language cell descriptions as the durable source of truth, generating code from them, enforcing a linear execution model free of hidden state, and supplying value-centered local and global verification tools, Plainbook lets people who cannot read or write code still create, share, reproduce, and extend computational analyses with the same guarantees Jupyter provides to programmers.

What carries the argument

The snapshot (checkpointing) kernel: it stores the Python namespace state before and after each cell so every cell always runs from a deterministic prior state, re-execution of a single cell is cheap and idempotent, and both cell tests (run a cell on simplified data prepared in natural language) and global tests (assertions that relate nicknamed states across the notebook) become practical.

Load-bearing premise

Current AI models, given a cell description plus prior-cell context and variable schemas, will produce code correct enough for the intended analysis, and that cross-model checks plus value inspection will catch residual errors without the user ever needing to read the generated code.

What would settle it

Give non-programmers a set of realistic data-analysis tasks, let them build and share Plainbooks, then have independent users re-run the notebooks under a different AI model and inspect the value tests; measure whether the intended results appear and whether any silent semantic errors survive both the value checks and the cross-AI validation.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Committee members and domain scientists can collaboratively edit analysis steps by rewriting plain-language prompts rather than code.
  • Shared notebooks remain fully verifiable by recipients who choose their own AI model for cross-validation and who run the built-in value tests.
  • Hidden-state bugs that break reproducibility in ordinary Jupyter notebooks are eliminated by construction.
  • Cell tests become possible for any cell without wrapping logic in functions, because the linear model already supplies a clean prior state that can be simplified.
  • Safety checks for dangerous operations can be performed by an AI of the recipient’s choice before a shared notebook is executed.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same linear-plus-checkpoint design could be ported to reactive notebook systems, combining Marimo-style dependency tracking with Plainbook-style natural-language tests.
  • If AI code generation improves further, the residual need for value inspection may shrink, yet the linear semantics and persistent descriptions would still be required for non-coder collaboration.
  • Extending the kernel with transactional database logs would remove the main remaining source of non-idempotence for users who leave connections open across cells.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper introduces Plainbook, a computational notebook that centers natural-language cell descriptions rather than code, targeting data-science users who cannot read or write programs. Code is generated from descriptions by commercial LLMs and stored for stability; execution follows a strictly linear top-to-bottom semantics enforced by a checkpointing kernel that caches per-cell Python namespaces. Verification is value-centered: AI cross-validation of code against descriptions, cell tests that run a target cell on simplified data prepared in natural language, and global tests that assert relations across nicknamed checkpointed states. The design is realized as an open-source web application with an orchestration layer that tracks validity indices (i_code, i_out, i_exec) to regenerate and re-execute only the necessary prefix of the notebook. Evaluation is anecdotal, drawn from university-committee data-analysis tasks, and is presented as a design and engineering contribution rather than a controlled user study.

Significance. If the design works as claimed, it would make the classic Jupyter strengths of verifiability, reproducibility, and extensibility available to non-programmers at a moment when LLM-generated code is already common but opaque. The concrete engineering contributions—linear semantics via a snapshot kernel, orchestration indices, and natural-language cell/global tests—are clearly specified and released under an open-source license, so they can be inspected, reused, or extended. The work is therefore a useful systems artifact for the HCI and computational-notebook communities even if the strongest user-facing claim remains only partially demonstrated.

major comments (3)
  1. Section 6 and the abstract claim that Plainbook restores verifiability/reproducibility/extensibility for non-coders. That claim rests on two unmeasured premises: (1) that commercial LLMs, given the prompt construction of §5.1 (description + prior cells + variable schemas), produce code correct enough for the intended analysis, and (2) that residual errors are caught by cross-model validation (§4.1) plus cell/global value tests (§4.2–4.3) without users reading code. The only evidence is anecdotal committee experience and one illustrative double-counting failure (Figures 2–3). No generation-error rates, false-negative rates of AI validation, or user studies of non-programmers inspecting simplified outputs are reported. Without at least a small controlled evaluation of these rates, the central user-facing claim remains a design hypothesis rather than a demonstrated result.
  2. Section 4.1 presents cross-model validation as a safeguard against sleeper-agent or model-specific vulnerabilities, yet supplies no evidence that independent models systematically disagree on the same incorrect implementation. A short experiment (e.g., deliberately buggy cells validated by two distinct APIs) would be needed to substantiate that the safeguard is more than theoretical.
  3. Section 5.2 and §6.2 acknowledge that the checkpointing kernel cannot track external state (open files, database connections). The discussion treats this as a minor limitation for “typical” users, but many data-science workflows involve multi-cell database or file-handle usage. The paper should either quantify how often such patterns arise in the target population or provide a concrete mitigation path (transactions, logs) so that the linear-semantics claim is not overstated for realistic notebooks.
minor comments (5)
  1. Author list and affiliations: Elena Baralis is listed with the email of Eliana Pastor; this should be corrected.
  2. Figure 4 is a useful schematic of the cell-test flow, but the optional validation cell is mentioned only in the caption and not shown; a brief expansion of the figure or surrounding text would clarify the full test harness.
  3. Section 5.3’s orchestration rules are clear, yet the invariant i_code ≥ i_out is stated without a short proof or invariant-maintenance argument; a one-paragraph sketch would help readers trust the index logic.
  4. Related Work could more explicitly contrast Plainbook’s single comprehensive description per cell with the iterative multi-prompt style of Cursor/Claude Code, beyond the brief remarks already present.
  5. The paper repeatedly uses “Plainbook” in roman and italic inconsistently; a single house style would improve readability.

Circularity Check

0 steps flagged

No circular derivation chain; systems/HCI design paper whose claims rest on architecture description and anecdotal committee use, not on fitted parameters, self-definitional equations, or load-bearing self-citations.

full rationale

Plainbook is a tool-design paper (natural-language cells, linear checkpointing kernel, value-centered cell/global tests). It advances no numerical prediction, uniqueness theorem, or first-principles derivation that could reduce to its own inputs. Code generation is delegated to external commercial LLMs (Claude/Gemini) with an explicit prompt recipe (Section 5.1); verification is defined as AI cross-checks plus user inspection of simplified values (Section 4), not as a quantity fitted to the same data later called a prediction. The sole empirical statement (Section 6) is openly anecdotal (“we put Plainbook to the test by implementing the main data analysis tasks in the university committee… This exercise was successful”) and is not presented as a quantitative result derived from the system’s own parameters. Self-references are limited to the authors’ motivating committee anecdote and the open-source repository; none supply a uniqueness or correctness theorem that the paper then treats as external fact. Consequently the derivation chain contains no self-definitional step, no fitted-input-as-prediction, and no load-bearing self-citation, yielding a circularity score of 0.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 3 invented entities

As a systems paper the central claim rests on engineering design choices and on the practical competence of contemporary LLMs for code generation and validation, not on free parameters or new physical entities. The ledger therefore records the domain assumptions that must hold for the claimed accessibility and verifiability benefits to materialize, plus the invented system components that realize those assumptions.

axioms (4)
  • domain assumption Contemporary commercial LLMs can translate a natural-language cell description plus prior-cell context and variable schemas into correct Python data-science code often enough for practical use.
    Stated throughout Sections 1, 5.1 and the Discussion; the entire workflow collapses if generation quality is too low.
  • domain assumption Linear top-to-bottom execution matches how non-programmers read natural-language narratives and therefore eliminates the need for them to track hidden state.
    Core design premise of Section 3.2; if users still need out-of-order execution, the linear model becomes a limitation rather than a feature.
  • domain assumption Users who cannot read code can still understand and inspect intermediate data values (tables, counts, simple plots) sufficiently to validate correctness.
    Foundation of the “verify the values” principle (Section 4); without it the cell-test and global-test machinery loses its audience.
  • domain assumption Checkpointing Python namespaces is an adequate model of notebook state for typical data-science workflows that do not leave open file descriptors or database transactions across cells.
    Explicitly acknowledged limitation in Section 5.2 and Discussion; the linear semantics rest on this approximation.
invented entities (3)
  • Plainbook notebook format and UI (NL-primary action cells, files/instructions tabs, validation buttons) no independent evidence
    purpose: Make natural-language descriptions the persistent, editable source of truth while hiding generated code by default.
    The primary artifact introduced by the paper; no independent existence outside this work.
  • Checkpointing / snapshot kernel that stores per-cell Python namespaces no independent evidence
    purpose: Realize linear execution efficiently and supply the before/after states required by cell tests and global tests.
    Key implementation contribution (Section 5.2); enables the verification mechanisms that distinguish Plainbook from prior linear notebooks.
  • Cell tests (data-preparation + target + optional validation cells) and global tests over nicknamed states no independent evidence
    purpose: Let non-programmers verify individual cells and cross-cell value relationships without reading code.
    New verification layer built on the checkpointing kernel (Section 4); not present in standard Jupyter or Marimo.

pith-pipeline@v1.1.0-grok45 · 20511 in / 2993 out tokens · 27340 ms · 2026-07-11T03:09:20.064205+00:00 · methodology

0 comments
read the original abstract

Jupyter Notebooks have become widely adopted in data science, as they allow the sharing of reproducible computational analysis. They are, however, accessible only to people who understand computer code. To reach the broader audience of scientists interested in data analysis and computation, but unfamiliar with code, we introduce Plainbook, notebooks centered on natural language rather than code. Plainbook is based on two principles: promote the natural language descriptions, and verify the values. In plainbook, the natural language descriptions are preserved, rather than the resulting code; the code is generated automatically from the cell descriptions. As natural language is read top to bottom, Plainbook adopts a linear execution semantics, in which cells are guaranteed to be executed in the order in which they appear; there is no "hidden state" or out-of-order execution as in Jupyter. To allow users who may not understand code to verify the correctness of the computation, we have built into Plainbook verification mechanisms centered on values and value inspection. These include mechanisms that focus on individual cells, akin to unit tests, as well as global mechanisms. Both the linear execution semantics, and the verification mechanisms, are underpinned by a snapshot kernel that caches execution states and makes execution and verification efficient.

Figures

Figures reproduced from arXiv: 2607.05717 by Elena Baralis, Eliana Pastor, Luca de Alfaro, Mathis Aubert, Ranjit Jhala.

Figure 1
Figure 1. Figure 1: Top bar, and two action cell in Plainbook. The top bar allows users to select the AI model in use, restarting and running all the cells, and using AI to verify that the content of the Plainbook is safe. Below the top bar is a bar with a tab for files, and one for general instructions. The Files tab is used to select the files that are used by the notebook (in this case, the football csv dataset), so that A… view at source ↗
Figure 2
Figure 2. Figure 2: Plainbook can ask AI models to validate a cell’s code against its description. In this case, validation fails, and Plainbook displays diagnostic explanations returned by AI. AI source. Indeed, it has been shown that AI models can contain hidden vulnerabilities, buried in the models in or￾der to perform attacks [16, 23, 31]. The attacks can be quite specific, triggered only when the code is generated in par… view at source ↗
Figure 3
Figure 3. Figure 3: A cell test for verifying that the target cell of [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Execution flow of a cell test. To test a target cell𝑐𝑖 , Plainbook executes it in a parallel flow, where the data 𝑠𝑖−1 has been simplified into 𝑠𝛼 by a data preparation cell. Users can check 𝑠𝛽 by inspection, or via a validation cell [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: A global test. The test relates the state immedi￾ately preceding the test, with the notebook state after cell count_country, which created a count of countries. The test checks that all the football matches that each country played are properly accounted. the code that faithfully implements the user’s natural lan￾guage description for that cell. Second, we need to be able to execute the generated code and … view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

41 extracted references · 41 canonical work pages · 7 internal anchors

  1. [1]

    2023.marimo - an open-source re- active notebook for Python.https://github.com/marimo-team/marimo Original-date: 2023-08-14

    Akshay Agrawal and Myles Scolnick. 2023.marimo - an open-source re- active notebook for Python.https://github.com/marimo-team/marimo Original-date: 2023-08-14

    work page 2023

  2. [2]

    2024.The Claude 3 Model Family: Opus, Sonnet, Haiku

    Anthropic. 2024.The Claude 3 Model Family: Opus, Sonnet, Haiku. https://www.anthropic.com/news/claude-3-familyModel Card

    work page 2024

  3. [3]

    2026.Cursor: The AI Code Editor.https://cursor.sh Developed by Anysphere

    Anysphere, Inc. 2026.Cursor: The AI Code Editor.https://cursor.sh Developed by Anysphere

    work page 2026

  4. [4]

    2019.Google Colaboratory

    Ekaba Bisong. 2019.Google Colaboratory. Apress, Berkeley, CA, 59–64. doi:10.1007/978-1-4842-4470-8_7

    work page doi:10.1007/978-1-4842-4470-8_7 2019

  5. [5]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian...

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2107.03374 2021

  6. [6]

    2026.Plainbook.https://github.com/lucadealfaro/ plainbookGitHub repository, accessed: 2026-06-29

    Luca de Alfaro. 2026.Plainbook.https://github.com/lucadealfaro/ plainbookGitHub repository, accessed: 2026-06-29

    work page 2026

  7. [7]

    Ahmed Fawzy, Amjed Tahir, and Kelly Blincoe. 2025. Vibe Coding in Practice: Motivations, Challenges, and a Future Outlook – a Grey Literature Review.arXiv(2025). doi:10.48550/arxiv.2510.00328

    work page doi:10.48550/arxiv.2510.00328 2025

  8. [8]

    Gemini Team, Google. 2023. Gemini: A Family of Highly Capable Multimodal Models.arXiv preprint arXiv:2312.11805(2023)

    work page internal anchor Pith review Pith/arXiv arXiv 2023

  9. [9]

    Gevorkyan, Anna V

    Migran N. Gevorkyan, Anna V. Korolkova, and Dmitry S. Kulyabov

    work page

  10. [10]

    doi:10.22363/2658-4670-2023-31-1-5-26

    Julia language features for processing statistical data.Discrete and Continuous Models and Applied Computational Science31 (2023), 5–26. doi:10.22363/2658-4670-2023-31-1-5-26

    work page doi:10.22363/2658-4670-2023-31-1-5-26 2023

  11. [11]

    2026.GitHub Copilot.https://github.com/features/copilot AI-powered code assistant

    GitHub. 2026.GitHub Copilot.https://github.com/features/copilot AI-powered code assistant

    work page 2026

  12. [12]

    2026.Google Colaboratory.https://colab.research.google.com/ Accessed: 2026-05-08

    Google. 2026.Google Colaboratory.https://colab.research.google.com/ Accessed: 2026-05-08

    work page 2026

  13. [13]

    Péter Ferenc Gyarmati, Dominik Moritz, Torsten Möller, and Laura Koesten. 2025. A Composable Agentic System for Automated Visual Data Reporting.arXiv(2025). doi:10.48550/arxiv.2509.05721

    work page doi:10.48550/arxiv.2509.05721 2025

  14. [14]

    Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner, and Bogdan Vasilescu. 2026. Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open- Source Projects. In23rd International Conference on Mining Software Repositories (MSR ’26). ACM

    work page 2026

  15. [15]

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large Language Models for Software Engineering: A Systematic Literature Review.ACM Transactions on Software Engineering and Methodology 33, 8 (Nov. 2024), 1–79. doi:10.1145/3695988

    work page doi:10.1145/3695988 2024

  16. [16]

    Ruanqianqian Lisa Huang, Savitha Ravi, Michael He, Boyu Tian, Sorin Lerner, and Michael Coblenz. 2025. How Scientists Use Jupyter Note- books: Goals, Quality Attributes, and Opportunities. In2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 1243–

    work page 2025

  17. [17]

    doi:10.1109/ICSE55347.2025.00232tex.ids= huangHowScientist- sUse2025b ISSN: 1558-1225

    work page doi:10.1109/icse55347.2025.00232tex.ids 2025

  18. [18]

    Evan Hubinger, Carson Denison, Jesse Mu, Mike Lambert, Meg Tong, Monte MacDiarmid, Tamera Lanham, Daniel M. Ziegler, Tim Maxwell, Newton Cheng, Adam Jermyn, Amanda Askell, Ansh Radhakrishnan, Cem Anil, David Duvenaud, Deep Ganguli, Fazl Barez, Jack Clark, Ka- mal Ndousse, Kshitij Sachan, Michael Sellitto, Mrinank Sharma, Nova DasSarma, Roger Grosse, Shaun...

    work page

  19. [19]

    Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training

    Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training. doi:10.48550/arXiv.2401.05566arXiv:2401.05566 [cs]

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2401.05566arxiv:2401.05566

  20. [20]

    Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim

    work page

  21. [21]

    2026), 1–72

    A Survey on Large Language Models for Code Generation.ACM Transactions on Software Engineering and Methodology35, 2 (Feb. 2026), 1–72. doi:10.1145/3747588

    work page doi:10.1145/3747588 2026

  22. [22]

    Mart Jürisoo. 2024. International football results from 1872 to 2024.https://www.kaggle.com/martj42/international-football-results- from-1872-to-2017. Accessed: April 1, 2026

    work page 2024

  23. [23]

    Thomas Kluyver, Benjamin Ragan-Kelley, Fernando Pérez, Brian Granger, Matthias Bussonnier, Jonathan Frederic, and Kyle Kelley

    work page

  24. [24]

    InPositioning and power in academic publishing: players, agents and agendas: proceedings of the 20th International Con- ference on Electronic Publishing

    Jupyter Notebooks-a publishing format for reproducible compu- tational workflows. InPositioning and power in academic publishing: players, agents and agendas: proceedings of the 20th International Con- ference on Electronic Publishing. IOS press, 87

    work page

  25. [25]

    Donald Ervin Knuth. 1984. Literate programming.The computer journal27, 2 (1984), 97–111.https://academic.oup.com/comjnl/article- abstract/27/2/97/343244

    work page 1984

  26. [26]

    Stephen Macke, Hongpu Gong, Doris Jung-Lin Lee, Andrew Head, Doris Xin, and Aditya Parameswaran. 2021. Fine-Grained Lin- eage for Safer Notebook Interactions. doi:10.48550/arXiv.2012.06981 arXiv:2012.06981 [cs]

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2012.06981 2021

  27. [27]

    Christian Meske, Tobias Hermanns, Esther von der Weiden, Kai-Uwe Loser, and Thorsten Berger. 2025. Vibe Coding as a Reconfiguration of Intent Mediation in Software Development: Definition, Implications, and Research Agenda.arXiv(2025). doi:10.48550/arxiv.2507.21928

    work page doi:10.48550/arxiv.2507.21928 2025

  28. [28]

    Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan- Gavitt, and Ramesh Karri. 2025. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions.Commun. ACM 68, 2 (Jan. 2025), 96–105. doi:10.1145/3610721

    work page doi:10.1145/3610721 2025

  29. [29]

    Elizaveta Pertseva, Melinda Chang, Ulia Zaman, and Michael Coblenz

    work page

  30. [30]

    InProceedings of the IEEE/ACM 46th International Conference on Software Engineering

    A Theory of Scientific Programming Efficacy. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering. ACM, Lisbon Portugal, 1–12. doi:10.1145/3597503.3639139

    work page doi:10.1145/3597503.3639139

  31. [31]

    João Felipe Pimentel, Leonardo Murta, Vanessa Braganholo, and Juliana Freire. 2019. A large-scale study about quality and repro- ducibility of jupyter notebooks. In2019 IEEE/ACM 16th international conference on mining software repositories (MSR). IEEE, 507–517.https: //ieeexplore.ieee.org/abstract/document/8816763/?casa_token= SYvtfPxWrAQAAAAA:Bd5tTsysiHU...

    work page arXiv 2019

  32. [32]

    João Felipe Pimentel, Leonardo Murta, Vanessa Braganholo, and Ju- liana Freire. 2021. Understanding and improving the quality and reproducibility of Jupyter notebooks.Empirical Software Engineering 26, 4 (2021), 65

    work page 2021

  33. [33]

    Fernando Pérez and Brian E. Granger. 2007. IPython: a system for interactive scientific computing.Computing in science & engineering 9, 3 (2007), 21–29

    work page 2007

  34. [34]

    Randles, Irene V

    Bernadette M. Randles, Irene V. Pasquetto, Milena S. Golshan, and Christine L. Borgman. 2017. Using the Jupyter notebook as a tool for open science: An empirical study. In2017 ACM/IEEE Joint Conference on Digital Libraries (JCDL). IEEE, 1–2

    work page 2017

  35. [35]

    Nicholas W. M. Ritchie. 2022. Reproducible Spectrum and Hyperspec- trum Data Analysis Using NeXL.Microscopy and Microanalysis28 (2022), 478–495. doi:10.1017/s143192762200023x

    work page doi:10.1017/s143192762200023x 2022

  36. [36]

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, and Tal Remez. 2023. Code llama: Open foundation models for code.arXiv preprint arXiv:2308.12950(2023).https://arxiv.org/abs/2308.12950

    work page internal anchor Pith review Pith/arXiv arXiv 2023

  37. [37]

    Mohammed Latif Siddiq, Joanna Cecilia da Silva Santos, Sajith De- vareddy, and Anna Muller. 2024. SALLM: Security Assessment of Gen- erated Code. InProceedings of the 39th IEEE/ACM International Con- ference on Automated Software Engineering Workshops(Sacramento, CA, USA)(ASEW ’24). Association for Computing Machinery, New York, NY, USA, 54–65. doi:10.114...

    work page doi:10.1145/3691621.3694934 2024

  38. [38]

    April Yi Wang, Anant Mittal, Christopher Brooks, and Steve Oney

    work page

  39. [39]

    doi:10.1145/3359141

    How data scientists use computational notebooks for real-time collaboration.Proceedings of the ACM on Human-Computer Interaction 3, CSCW (2019), 1–30. doi:10.1145/3359141

    work page doi:10.1145/3359141 2019

  40. [40]

    Thomas Weber and Sven Mayer. 2024. From Computational to Conver- sational Notebooks. doi:10.48550/arXiv.2406.10636arXiv:2406.10636 [cs.HC]

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2406.10636arxiv:2406.10636 2024

  41. [41]

    Zibin Zheng, Kaiwen Ning, Yanlin Wang, Jingwen Zhang, Dewu Zheng, Mingxi Ye, and Jiachi Chen. 2023. A survey of large language models for code: Evolution, benchmarking, and future trends.arXiv preprint arXiv:2311.10372(2023).https://arxiv.org/abs/2311.10372 12

    work page internal anchor Pith review Pith/arXiv arXiv 2023