When I ask a data scientist to explain an analysis, I am often handed a pull request and sent away to understand the implementation. Twenty minutes later, I may understand how the code is organized and still not know what the data showed. I want to understand the question, what we found, and whether the evidence supports the conclusion. The implementation belongs in that discussion, but it cannot carry the discussion on its own.
Coding agents have made this distinction harder to ignore. Tools such as Claude Code, OpenAI Codex, and Databricks Genie Code can write, execute, and revise code as we work through a task [1–3]. They reduce the effort between having an idea and trying it against data. That gives us an opportunity to reconsider where a data scientist’s attention belongs, especially when so much of the work has been organized around producing and reviewing code.
My view is that data science has always centered on discovering what we can learn from data. Mathematics, statistics, and machine learning give us ways to investigate questions that observations alone cannot settle. Code makes those ideas executable. As the effort of writing it declines, we should devote more attention to the inquiry and make that inquiry easier for a colleague to examine. Coding agent development provides a useful example, because reading an implementation and watching the resulting agent work can lead to very different judgments about the design. The same distinction should shape how we review an analysis, including the data and results on which its conclusions depend.
Code is a tool for the scientific work
I see code as an extension of a drafting board, where a hypothesis or design takes a form we can examine and revise as our understanding develops. It also makes those ideas executable against data, repeatedly and at a scale we could not manage by hand, but the discipline is not defined by the technology used to carry it out. An analysis in Microsoft Excel can produce a useful scientific insight, and its credibility depends on the same considerations as an analysis written in Python, including what the observations represent, whether the method fits the question, and what the evidence allows us to conclude. Each tool has limits, but the choice of interface does not establish whether scientific reasoning took place.
The carpenter comparison is useful when considering how well a data scientist needs to code, because knowing how to use a tool is necessary while the craft also depends on understanding the material and examining the work as it develops. For coding agents, I find the calculator comparison more instructive, since understanding arithmetic and formulating the problem remain important even when we delegate the calculation. Programming fundamentals similarly help us understand how code transforms data and determine whether an implementation does what the analysis requires, particularly when generated code may represent the problem incorrectly. Those abilities allow us to direct a coding agent and question its work, while the scientific contribution requires the additional expertise to formulate useful questions and draw defensible conclusions from incomplete observations.
Some applications require substantial software engineering or expertise in efficient computation, and those demands deserve serious attention. My concern is that they can interrupt the exploration needed to determine what the application should do, particularly when code receives more scrutiny than the analysis or an exploratory adjustment must pass through review before we can investigate its merit. In my experience, larger data science teams are more likely to make room for this distinction, while smaller teams often ask the same people to carry responsibility for both the science and the application. This is where I have found the tension most visible, as the demands of building can consume the time needed to investigate, and coding agents offer an opportunity to restore that balance. Discovery and engineering inform each other, but we need room to pursue a question while the answer remains uncertain and let the resulting evidence guide what we build.
Knowing the data is a discipline of its own
My own career has passed through shipbuilding, computational biology, investment management, and cybersecurity. The subject matter changed considerably, while the ability to formulate questions and examine what the data could support carried across. I had to learn what the observations represented, often by working with people who knew the domain much better than I did. I brought expertise in studying the data and choosing methods that could help us understand it.
I do not take that experience to mean domain knowledge is optional in an analysis. Someone has to explain how a measurement was produced, why a record might be missing, or what an apparent anomaly means in practice. It does mean that a data scientist can contribute without arriving as the domain expert. Learning enough to ask useful questions, and recognizing when a question needs a collaborator, are part of the work.
What interests me is what remains across these applications. We work with observations to discover something we do not yet understand. An insight may be a model that captures a predictive relationship, a pattern that changes how we understand a population, or a finding that the available evidence cannot settle the question. This breadth is consistent with Donoho’s account of data science, which includes exploration, modeling, computation, and the study of how we learn from data [4].
Knowing the data requires spending time with it. We look at samples, filter groups, compare distributions, and ask why an observation differs from what we expected. A figure can expose something an aggregate score conceals. A few records can lead us to question the meaning of an entire column. When I say a data scientist needs to touch the data, this is what I mean. We need an interaction in which what we observe can change what we do next.
The methods deserve the same attention. I have seen considerable effort go into implementing an algorithm without a comparable effort to understand why it was developed or what its assumptions imply for the analysis. Learning Python and scikit-learn gives us a useful way into the work. There is then a much larger body of study concerned with what a method estimates, how it behaves under different conditions, and when its results should be questioned. Sometimes a simple technique is exactly what the problem needs. Deeper methodological understanding lets us make that choice deliberately.
Agentic development is a discovery process
Coding agent driven development makes the need for scientific exploration particularly clear. We can choose an architecture, define tools, and write instructions, but those choices express our expectations about what will work. Reading the code and inspecting unit tests can check whether components behave as specified in the cases covered, while telling us relatively little about whether the agent performs the intended task well. Consider an agent investigating a suspicious email that treats missing domain reputation information as evidence that the message is safe. The tool may have executed correctly and the response may satisfy its schema, yet the conclusion is unsupported. Understanding that failure requires examining what information the agent received and how it acted on it.
The scaffolding around an agent gives us a structure we can run and investigate. My concern begins when preserving that structure takes priority over learning whether it works. An unexpected result may reveal that a tool needs to return different information or that the chosen sequence prevents the agent from pursuing useful evidence. If every adjustment must fit the original architecture or pass through a separate pull request before we can try it, the implementation begins to restrict the inquiry. I need room to inspect the behavior, revise the design, and run it again while the question is still in front of me. Coding agents reduce the effort of making those changes, giving us more time to investigate their consequences.
That freedom needs the discipline of data science. A successful rerun does not establish that a change improved the agent; we need comparisons across cases and repeated trials [5], and I would reserve separate cases for evaluating the design after those adjustments. The scientific contribution is in determining what those observations reveal and allowing that understanding to change what we build. When the change reaches review, a colleague should be able to examine the behavior that prompted it, the alternatives we investigated, and the evidence supporting the conclusion. That is the account of the work that code alone cannot provide.
Review should follow the analysis
That is the review I want for data science more broadly. The hypothesis, implementation, data, analysis, and conclusion need to be available together. A reviewer may spot a methodological error in the code, and a pull request can carry substantial supporting evidence. The difficulty arises when the code diff becomes the entire account of the work and the reviewer is left to reconstruct the analysis or accept its conclusion without seeing it.
This is where a notebook, or an interface with the same function, belongs. It provides a place to bring executable code together with data references, figures, results, and explanation. For the agent example, it could compare outcomes across cases and repeated runs while linking to the corresponding traces. The reviewer can examine a different group, change an assumption, or rerun part of the evaluation and see what happens. A notebook earns its place through that function. An experiment interface or executable report can serve the same purpose if it gives the reviewer equivalent access.
In my own work, tested methods live in library code and move through ordinary pull requests. The notebook applies those methods to the question and records the analysis. I want the data source and version identified, the relevant parameters and population definitions visible, and the outputs retained with the explanation of what they mean. For agents, that record also needs to identify the model, instructions, tool versions, and evaluation conditions. Otherwise, a difference between runs may have several explanations that the reviewer cannot separate.
Databricks provides one practical way to support this arrangement. Jupyter-format notebooks can be committed with outputs when the workspace and repository settings permit it [6]. Jobs can run from Git and record the commit used [7], and GitHub Actions can trigger execution as part of a review workflow [8]. The data can remain in a governed location with appropriate reviewer access. I would retain the data references and outputs alongside the execution record so that the claim can be traced to the run that supports it.
Saving a notebook does not establish that it runs, and running it does not establish that its conclusion is sound. I would make clean execution an automated requirement when an analysis is proposed for acceptance. For an agent evaluation, that means completing the defined trials and producing the evidence for comparison, rather than expecting identical text on every run. The reviewer still has to judge whether the cases, measurements, and interpretation support the claim. Reproducibility is part of that examination, with limits that matter when we move from repeating a computation to assessing scientific evidence [9].
Rapid experimentation and careful review belong in the same process. Exploration needs enough freedom to uncover an unexpected problem and pursue it. When we ask someone to accept a finding, we owe them a coherent record of the evidence and the limits of what we established. The purpose of review is to examine that record while preserving the ability to question it.
More time for discovery and insight
Coding agents give data scientists an opportunity to sharpen our focus on extracting insights that can lead to major breakthroughs in fields like drug discovery, cybersecurity, finance, and manufacturing. We can spend less effort working through unfamiliar APIs and syntax and translating every idea into code and more effort understanding the data, studying and developing methods, and pursuing questions that the first result leaves open. That opportunity depends on following the scientific method and testing and refining hypotheses quickly. Just as coding agents can give software developers more time to think about architecture and focus on quality, they give data scientists more opportunity to explore hypotheses, which can improve our chances of discovering something valuable in the domains where we work. An implementation produced quickly has value when it helps us discover something, and the work is incomplete until we can explain what we learned and why we believe it.
Insight is, and will likely always be, the primary currency of data science, so tools that help us achieve this are of particular interest to me. Across the domains I have worked in, the contribution has depended on understanding what the data could tell us and knowing how to investigate further when the answer was incomplete. Our tools are changing rapidly, and our responsibility is to use them well enough to develop that understanding and make that understanding, and the evidence behind it, the focus of what we ask our collaborators to review. Data science has been a distinct and transformative field, and I want us to continue evolving it while keeping discovery at the center of the value we bring across domains.
References
[1] Anthropic, Claude Code overview (n.d.), Claude Code Documentation. https://code.claude.com/docs/en/overview
[2] OpenAI, Introducing Codex (2025), OpenAI. https://openai.com/index/introducing-codex/
[3] Databricks, Genie Code (2026), Databricks Documentation. https://docs.databricks.com/aws/en/genie-code/
[4] D. Donoho, 50 Years of Data Science (2017), Journal of Computational and Graphical Statistics 26(4), 745–766. https://doi.org/10.1080/10618600.2017.1384734
[5] Anthropic, Demystifying evals for AI agents (2026), Anthropic Engineering. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
[6] Databricks, Manage Databricks notebook format (2026), Databricks Documentation. https://docs.databricks.com/aws/en/notebooks/notebook-format
[7] Databricks, Use Git with Lakeflow Jobs (2026), Databricks Documentation. https://docs.databricks.com/aws/en/jobs/git
[8] Databricks, GitHub Actions (2026), Databricks Documentation. https://docs.databricks.com/aws/en/dev-tools/ci-cd/github
[9] National Academies of Sciences, Engineering, and Medicine, Reproducibility and Replicability in Science (2019), The National Academies Press. https://doi.org/10.17226/25303