Transcript#
This transcript was generated automatically and may contain errors.
Phil Bauscher asked if I would be open to giving a PharmaSug keynote about our learnings in AI in late August of last year. Even then, I was worried about whether what we had learned about the intersection of the AI space and the needs of our customers would be relevant by the time I stood in front of all of you, 10 months later.
These are the three questions we said we would address today. And while I will be touching on all of those items, my goal is to have you walk out of here with a deeper appreciation of how to think about the changes that are increasingly important as you decide how you can help your organization and yourself.
As a reminder, this talk will not give you a formula or predictions. What it will give you is our current account of our exploration and learnings that have changed our thinking in ways we didn't expect, and the principles we have arrived at that we believe can give you a foundation for your own path forward and the decisions you will be looking to make.
Given the speed with which the world around us is changing, I expect that some parts of this talk will become completely irrelevant in a year, or maybe sooner. However, this is the latest thinking we have from the conversations with dozens of customers and Posit's own experiences with AI.
About Posit
Before we dive in, I want to make sure everyone knows who we are as a company. For those of you who may be less familiar with Posit, let me give you a quick background. We have been building open source tools for data science and statistical computing for 17 years. Our tools, the Tidyverse, Shiny, Quarto, R Markdown, and of course RStudio are used by millions of data scientists and statisticians around the world.
The pharmaceutical space, specifically, our platform is used by the majority of the world's top pharma companies for everything from drug discovery to regulatory statistical analysis and clinical reporting. In 2016, JJ and I learned about Public Benefit Corporations. We realized that this was the legal construct we had been looking for and one that articulated the type of company we wanted to build.
So, in 2019, we completed our conversion from a C-Corp to a Public Benefit Corporation, which requires us to make a legal commitment to ensure that the interests of the scientific community, not only our shareholders, are part of our charter. In 2022, we re-revented the company to be Posit Software. Our commitment to science is central to the company's mission, and our approach is enshrined in our charter. It is a key tenet of how we think about the tools we build, and it all starts with the Prime Directive.
The Prime Directive
The idea at the heart of everything we're talking about today is from a gentleman by the name of John Chambers. He's one of the most important figures in the history of statistical computing. He created the S programming language at AT&T Bell Labs, which was implemented as R in the 90s. He taught at Stanford, and in his book in 2008, he articulated what he called the Prime Directive.
The Prime Directive is this. Software for data analysis must be trustworthy, and it must be shown to be trustworthy. If you read that carefully, it's not enough for your analysis to be correct. The correctness must be demonstrable. The computation must be transparent. Anyone who receives the results of your work has limited opportunity to verify the results of direct observation. They have no choice but to trust the analysis, and by extension, the software that produced it. That places an enormous obligation on all of us.
The Prime Directive is this. Software for data analysis must be trustworthy, and it must be shown to be trustworthy.
This is why we've always believed in code-first data science. Code is the mechanism by which you satisfy the Prime Directive. Code can be read, code can be reviewed, code can be tested, reproduced, and audited. A low-code or point-and-clicks interface cannot make the same promise unless every operation it performs is expressible as code that others can read, review, and reproduce.
This is the exact lens through which we evaluate every AI claim. Not, is it impressive, or is it fast, but can it be trusted, and can that trust be proven?
The Prime Directive is not just a philosophy. In a GXP environment, it is a practical necessity. When a regulator asks you to explain your analysis, the code and your SOPs are your answer. When an auditor needs to verify that the method was applied correctly, the code is your evidence. When a colleague needs to reproduce your results six months later, the code is your insurance.
This is why we have invested in making code-first data science more powerful, more accessible, and more reproducible. Not because it's trendy, but because it is the only architecture that makes the Prime Directive achievable in a regulated environment. Keep this principle in your mind as we go through the rest of the talk, because the question of whether AI can be used responsibly in your work comes down to one thing. Can it be made to satisfy the Prime Directive?
Two strands of the journey
I want to frame today's talk as a single journey seen through two lenses, in essence, two strands of the same helix that cannot be pulled apart. The first strand is technical and organizational. It is about what Gen-AI can and cannot do in a regulated data science environment. The risks, the guardrails that need to be developed, and what we have already learned along the way.
The second strand is human. It is about change, the very reality of change. It is about change, the very real anxiety of watching your field transform faster than feels comfortable. The question of what your expertise is worth in a world where machines can write code, and the mindset shifts that I believe are necessary to navigate this without either freezing up or throwing caution to the wind.
I want to treat these separately at first, because conflating them too early is part of what makes this topic so hard to navigate and discuss with customers, prospects, and our own employees. But by the end of the morning, I think you will see why they can't ultimately be pulled apart. Both strands are hard. Both are necessary. And I have to admit that we have not mastered either one at Posit, but we have learned several lessons that we hope are applicable to you.
The foundation we built together
Before we talk about AI, I want to take a minute to remind us all the foundation that we are standing on. The tools we use every day, the infrastructure that made the first R-based FDA submissions possible, didn't appear from thin air. The R pilot group, Pharmaverse, the reproducible analysis workflows that are now standard in clinical reporting, were built on a foundation that the Pharma data science community, the R Consortium, and Posit built together over more than a decade.
It was our customers who helped us understand their needs, highlighted the gaps in the software we were building, and often amazed us with the innovations they came up with. We have learned from many of you in this room, and we are so very grateful to be able to help with this important work. This collaboration, grounded in trust and community, has enabled the field to take a giant step forward. The pharmaceutical company is collaborating on tools while competing on molecules. This trust is what we are all trying to preserve as we leap into this new world of AI.
We're looking to extend the same principles we have already proven in a regulated environment. Reproducibility, transparency, audibility, and code as the source of truth. The foundation we are standing on was built carefully, deliberately, and with the prime directive in mind. That is exactly the standard we have to hold our use of AI to.
Posit's evolution of thinking on AI
I thought it might be helpful to share our own evolution in thinking about the applicability of AI. It is not super polished, but it captures four moments in time that can paint a picture of the arc and the speed with which change is coming.
In February of 2024, we hosted a company-wide work week in Minneapolis in the dead of winter because of the cost and direct flight convenience. For one of our sessions, we invited 20 customers and prospects to join us for a conversation. As you can imagine, the question everyone wanted answered was, what does Posit think about AI and the use of AI for data science? We put six of our most brilliant technical minds on a stage, our CTO, our architects, engineering leaders, and some of our most senior data scientists. Each was asked, in their own area of expertise, to share their perspective on whether Gen AI could play a meaningful and safe role in data science.
The verdict was unanimous. None could see how Gen AI could be used for serious regulated data science in any safe or meaningful way. The probabilistic nature of large language models, the inability to validate outputs, and the risk of hallucination were not theoretical concerns. They were architectural problems we couldn't see a way around. These were not timid people hedging their bets. These were genuinely brilliant people giving you their frank and best thinking. And they were wrong. Or rather, they were right about the state of things in February 2024, and the world moved faster than any of us expected.
One year later, in the same venue, we watched our CTO, Joe Cheng, unveil a small experiment he called DataBot. In front of all of us, Joe downloaded a data set he had never seen before in a domain he had no personal expertise in. He opened DataBot, an agentic AI assistant, that could visualize data, slice and dice it, ask questions about it, and suggest next steps. And he started exploring the data in front of us. In under 10 minutes, he had developed a genuine feel for the data set. He had identified data quality issues, found interesting patterns, and generated visualizations. He had asked questions that would have taken hours of manual exploratory work to answer. And he got answers he could verify by reading the code that it wrote.
The room was quiet. This wasn't just a demo of a faster way to do something we already knew how to do. It was a demonstration of something qualitatively different. An AI that could serve as an active intellectual collaborator in the early stages of data science work, accelerating the path from raw data to understanding. Our thinking shifted. Not all the way, mind you. The concerns about validation, about regulated environments, about the prime directive were all still completely valid. But the question changed. It was no longer, can this be useful? It was, under what conditions can this be used responsibly?
Then came November of 2025. We, as a technical and product team, tend to have a bit of a skeptical approach to promises of technology. It is too easy to get caught up in the hype otherwise. With the Cloud Sonnet 4.5 release in September, Cloud Opus 4.5 release in November, along with the improvements to Cloud Code, some of our most senior engineers moved from being skeptics to advocates. That exploded across the tech industry during the Christmas break, when everyone woke up to what the early adopters had discovered a few weeks earlier. GPT 5.2's release in December further stoked that fire.
It is clear that the threshold has been crossed. The ability to build real applications, debug complex code, iterate on problems, and have the AI not just generate a first draft, but actively collaborate through the debugging cycle, was transformative in a way that is hard to describe if you haven't experienced it. For those of us who had been watching and playing with these tools, the question had already shifted with DataBot in February. In November, this was something different. It was the moment, someday this will change everything, became, today is that someday. At least for software engineering. The abstract promise had landed.
For the statisticians, statistical programmers, people whose work involves building, debugging, and validating code, I'd encourage you to find a way to play with some of these tools, even if it is on your own dime. We launched Posit.AI in March specifically to make that easier. It includes a free trial that lets you experience the capabilities with your own personal data.
In April, I joined Phil Bauscher, our industry director of life sciences, on a tour of 11 pharma and life sciences companies in Japan. We also met with nine additional companies when we attended the stats programming council. At the council meeting, Phil demoed the capabilities of AI tooling in our latest IDE, Positron. For nine of our customer visits, he ran the team through a two- to four-hour workshop that provided a safe sandbox environment for them to explore and understand how to use AI to help build, debug, and understand data.
We use Positron for the demos and workshops because of the deeper native integration across programming languages since data science teams are increasingly multilingual with Python and SAS. We could have used RStudio since the AI integrations for the R language are virtually identical. The good news was that the reaction we saw from customers and prospects in Japan has been consistent with what our visits across the U.S. and Europe have shown, whether in pharma or other industries. That makes it easier to gain conviction that we are working on a problem with wide applicability.
Internally, the shift in our engineering to use AI for coding has also sparked some genuinely interesting questions about the nature of the work itself. We've been exploring tools like RoboRev from Wes McKinney for code reviews in engineering, which when paired with the latest models can have superhuman capabilities, detecting correctness issues and understanding how two far-flung pieces of code can interact subtly. For some of our engineers, the question now is not whether a human has reviewed the PR, but whether an agent has reviewed it.
We have talked about giving our customers the ability to introduce adversarial agent models for data science in which code and conclusions can be challenged by agents with different contexts. And underneath all of that is a question we keep coming back to, one that I want you to hold on to because we will return to it later in the talk. Who actually wrote the code? I'm not going to answer that now, but I want you to notice that it's not really a technical question. It is a human one. And it is the question that connects everything in strand one to everything in strand two, the human side of change.
The shift everyone is wrestling with
Mid-2024, we were already saying we need to figure out how to do this right. What changed between then and now is that the question stopped being one that forward-looking teams were wrestling with and became one that everyone is wrestling with. This is not a small shift. And the speed of change, the capabilities for coding, especially, have become impossible to ignore in a matter of months, not years. We are all at varying speeds and with varying degrees of comfort, desperately trying to adapt.
The technology is not going to stabilize and wait for the field to catch up. The models will continue to improve. The capabilities will continue to expand. Just 12 days ago, Michelle Ryder from Sanofi gave a talk at BioIT where she estimated that by 2030, 45% of R&D activities will, quote, undergo significant transformation, creating unprecedented opportunities for productivity gains and breakthrough discoveries. If I were a betting man, I would bet that it won't take that long.
The pressure from your organizations to engage with these tools will continue to grow. So the question is no longer whether Gen AI has a role in pharmaceutical data science. Something that can explore a data set in 10 minutes and build a working application in 20 minutes has a role. The question is how do we ensure that its role satisfies the prime directive? How do we ensure the work can be trusted and shown to be trusted? That is what the rest of this talk is about.
Five common objections
Over the past two years, we've had conversations with dozens of pharmaceutical data science leaders across North America, Europe, and Japan. The concerns are remarkably consistent. Five objections come up in almost every conversation, whether it's in pharma, healthcare, or even governmental agency. So let us tackle them one by one.
We cannot validate AI-generated code. This is the most common objection. It spawns several smaller questions, including can we trust code that a machine wrote? And the answer is not without some means of confirming its correctness. There are important best practices that the industry is still learning and codifying. Still, the approach we are committed to is one where every piece of an analysis is written as code and therefore is inspectable.
Another question is who is responsible when it is wrong? And the answer is ultimately you are. You can't tell your management team that the AI said that this was the right answer. For some organizations, you have seen the practice of double programming. Ultimately, the goal is to make sure that two independent individuals will get the same results given the same inputs. You can simulate that type of process with AI. Most importantly, you need to make sure you understand the work produced and ensure that it is well documented and tested. The readability and succinctness of R plus the tidyverse should be particularly helpful for organizations as a human's ability to review massive amounts of code is the next bottleneck.
Can an auditor verify the process? And the answer is absolutely, because the output of the work is code that is reproducible, inspectable, and testable. There should be no reason why an auditor would have an issue with it. The fact that an AI wrote that code is irrelevant. What is relevant is that the testing of the code followed your SOPs.
The GXP anxiety is very real. AI systems are probabilistic. They can generate code that looks correct when it may not be. They can miss edge cases. They can be confidently wrong. But guess what? So can humans.
But here's what we have learned. The answer is not to keep humans out of the loop as a safety check at the end. The answer is to design the human into the loop as an architectural requirement throughout. The statistician or programmer is not the last line of defense against AI errors. They are the pilot. AI is a copilot that can do a great deal of useful work. But the pilot always has a hand on the controls, always understands what's going, what is happening, and always bears responsibility for the outcome. Code First makes this possible. When AI outputs our code, our readable, executable, and version-controlled code, the human expert can review, understand, test, and validate the output before it becomes part of the permanent record. That is the prime directive applied to AI-assisted work.
The statistician or programmer is not the last line of defense against AI errors. They are the pilot. AI is a copilot that can do a great deal of useful work. But the pilot always has a hand on the controls, always understands what's going, what is happening, and always bears responsibility for the outcome.
The second objection is AI will replace our statisticians. I mentioned our company-wide workweek in the dead of winter in Minneapolis in 2024 and 2025. This year, we held it in Monterey, California, to give us all an opportunity to see each other outdoors. See, I'm not entirely heartless. My keynote focused on the traits and mindsets that we all need in order to navigate the changes stemming from AI. Our team's fears echoed those of some of our customers who wonder what would become of them if 50, 70, or even 100% of their day-to-day work was no longer relevant in this new world.
The truth is, none of us can really predict which jobs will disappear altogether. The introduction of cars in the early 1900s eliminated many roles and radically curtailed the number of other jobs. For today, I believe it is most helpful to focus on jobs that will continue to exist, but whose means of doing the work are fundamentally changed.
The statistician and programmer who uses AI tools to accelerate their work is not a lesser statistician or programmer. They are the statisticians and programmers who finish the job in three days. What AI eliminates is the syntax tasks, the hours spent on translation errors, boilerplate code, and copying and pasting. What it frees is judgment, domain expertise, and scientific insight. Those are precisely the things that took decades to develop and that no AI currently replicates.
The domain knowledge you have built over your career, how clinical trials work, what the regulatory standards require, what the science demands is most valuable in this new era, not less. The AI amplifies that knowledge. It doesn't replace it.
Think about the process of generating tables, listings, and figures at the end of a trial phase. Now ask yourself, what if the question isn't, how do I generate TLS faster? But why are we waiting until the end of the trial to look at safety signals at all? That question isn't about tools and speed. It's about the system and the constraints in the system. We'll come back to that question, but hold it for now because it is the question that separates those who think of themselves as carpenters with better tools and those who reimagine themselves as the person who designs and builds the whole outdoor space, the deck, the wiring, the grilling station.
Objection three. We can't trust the models with our data. This is a governance question, not an AI question, and it has a governance answer. I've had at least a half a dozen conversations over the past few months about this topic. The concern is legitimate. Patient data, trial data, proprietary compound information, historically, there would be no scenario in which that data could leave your systems. For some companies, that requirement is still true, and local models may well be the right answer here if your organization is not using any cloud capabilities.
The good news is that local models have had a genuine step change in performance this spring, particularly Google's Gemma 4 and Alibaba's Quen 3.5 and newer models, bringing them much closer to the mainstream usefulness for this class of work. However, many more companies have already embraced the cloud or used some of the top data platforms. There's another path forward that will allow you to access these models safely.
While the models themselves are stateless and your prompts and data are not stored by the model, the providers all have the ability, and in almost all cases, the legal requirement to store the prompts and responses for safety or abuse reasons. There is a concept called zero data retention, known in the industry as ZDR, which is provided by a few of the cloud providers and data platforms today, but it is not uniformly available across all the platforms. ZDR is meant to ensure that the provider is not permanently storing the prompts in addition to the usual commitments of not using the data for any training.
IT and governance teams will push back on the use of AI because of the concerns that data is moving outside the boundaries that they have defined for it. Our counter argument is that for most of the customers we have met, they are already trusting AWS, Azure, GCP, Databricks, Snowflake, and Palantir with the security of their systems and their data, and they likely already have the legal agreements that would protect them.
There is no world we see where your team is better off without secure, approved access to AI tools. You will be using hand tools to compete against people with power tools. This is not a winnable game in the long term. Instead, our approach has been to build the right level of scaffolding and guardrails that organizations will need to allow their teams to truly flourish. The foundational pieces are available at the infrastructure level. We're moving through the backlog quickly to add the guardrails that our conversations with all of you have highlighted. The good news is that we are able to go faster than ever, which is both frightening and exhilarating.
Objection four. We don't know which model to trust. This is a very real concern. However, the answer is not to wait for an evaluation of a given model before you give your teams access to AI. The reality is that models are changing at breakneck speed and leapfrog each other regularly. The organization's focus should be on building systems that enable you to switch between models.
We have some customers who can only run on Azure and use Copilot, and others may be locked into Anthropic or Gemini. We believe that organizations will need the flexibility to seamlessly switch between models, possibly even for different tasks or use cases. What was state-of-the-art in mid-November had changed by the end of the month.
Like the validation process, which varies widely across organizations, our belief is that we should make it as easy as possible for you to understand how the tools are being used and to assess the quality of the work being produced. Your strategy for AI adoption shouldn't start with ensuring you have a trustworthy model. It should start with accepting that you can never trust any model implicitly.
The answer is to shift the validation target. What you validate is the environment, the governed system within which the output of the AI operates, the reproducible, auditable infrastructure, the human review process, the code-first output standard, the version control and traceability that make every step of the analysis inspectable. A model that operates within a well-governed environment producing code-first outputs that a qualified human reviews and approves satisfies the prime directive, regardless of which underlying model generates it. The architecture is what you validate, not the weights of the model.
Objection five, we are not ready yet. We are in those very same shoes. In February 2024, if you had asked us, we have said, no. And there's genuine wisdom in that instinct. The risks of moving carelessly in a regulated environment are very real. Posit's own story is instructive here. We were genuinely skeptical to start, but we started experimenting. We found a responsible approach and started introducing AI into our products in a manner that we could defend and with the caveats that we thought were important. The November 2025 releases gave us the confidence to push our organization harder on the adoption curve because our regular engagement with the tools meant we could see exactly how much the models had advanced.
There's a genuine discomfort that we see when talking to our customers and even our own employees, and they often fall into one of two buckets. In one bucket, the questions are, how do I know that this is safe? And where are the guardrails? And in the second bucket is, what is my role in this new world? We should not confuse the discomfort of doing something differently than we have before with the worry that what we are doing is wrong. There's also a coupling of our professional identity with the tasks we have grown up mastering.
Within Posit, we are still working through what this means for a variety of roles in the organization in development, QA, sales, marketing, finance, and data science. We have people who have restructured their entire workday around these tools, and others who are deeply uncertain whether that restructuring is responsible at all. Both groups have a point.
Here's what I can tell you with confidence. Using AI effectively is a skill. It takes time to build, and it is genuinely hard to teach. You have to learn it through experience. Some organizations have been racing up the learning curve for well over a year, and others are still getting their shoes on. That gap is not going to close on its own.
Running experiments means getting tools into the hands of a small group of people as quickly as possible. The learning only happens through doing. Organizations that spend months eliminating every conceivable risk before allowing anyone to touch AI tools are going to find themselves in trouble. There is no shortcut to learning, and frankly, learning is the new game for us humans.
So here's the most concrete thing I can offer. Find one bounded problem in your current work and try something. Not because the tools are ready for everything. They are not. But because your judgment about what they are ready for will not improve until you have enough experience to have a judgment. Start narrow. Scope is the variable, not the importance of the problem. And don't wait. The risks of falling behind are too high, not just for your organization, but for you personally.
Four principles for responsible AI
We promised you a list of principles. So what does responsible AI in regulated data science actually look like? Based on our own experiences, the customer conversations we've had, and the work we are doing in our products, we have arrived at four principles. They're not the final word. We are still learning, and the field is still evolving. But these are the non-negotiables as we see them today.
Code first, always. AI outputs must be inspectable, reviewable, version-controlled code. Human in the loop, by design. The expert is the pilot. The AI is the co-pilot. Govern environments. Reproducible, validated environments where the system, not the individual, enforces compliance. Session aware, data private. AI that understands your context deeply without your data leaving your infrastructure.
We are currently working to build these principles into our tools, not as optional features, but as the default architecture. The goal is to build a system where users can, quote-unquote, fall into the pit of success, a phrase coined by Microsoft's Rico Martin in 2003 and repeated by our chief scientist Hadley Wickham. We want an environment where doing the right thing is also the easy thing, where the statistician who uses AI assistance is automatically in a governed, auditable, reproducible workflow, not because they remember to turn on the right settings, but because the environment made it impossible to do otherwise.
The human strand: mindsets for change
Which brings us to the second strand, one that I now believe is the harder strand to solve for. Before I move into the second strand, I want to return to the question I left you with a few minutes ago. Who actually wrote the code? On the surface, it sounds like a provenance or a version control question. But the more you sit with it, the more you realize it is asking something deeper. It is asking, what does authorship mean when a machine does the drafting? What does expertise mean when a tool can generate in seconds what used to take hours? What does professional identity mean when the skills you spent a decade mastering are no longer the limiting constraint?
These are not questions with clean technical answers. They are human questions, and they are exactly where the two strands meet. As you likely saw through the conversation about strand one, the human dimension kept surfacing. In the carpenter analogy, in the TLF question, in the anxiety underneath objection five, these strands are intertwined because you can't really make progress on one without engaging with the other. But solving them requires radically different skill sets and approaches, which is why I wanted to keep them separate long enough to see each one clearly.
The challenges of adapting to AI are not unique to Pharma. They are universal. And the mindset shifts I'm about to share are the same ones we are working through at Posit every day.
So what does it actually take to change? I've been thinking for a long time about what it actually takes, not to survive this transition, but to thrive in it. And I have come to believe it comes down to mindsets, not skills. Skills can be learned. Tools can be mastered. But the underlying disposition you bring to an uncertain, fast-moving environment is what determines whether you adapt or freeze.
I introduced seven mindsets, I believe, that mattered at our work week in March of this year. Today, I want to focus on three that I think speak most directly to the people in this room, to what you do, who you serve, and what you will need to think through.
To me, it all starts with curiosity, the refusal to accept that's just how it is. There is power in asking, why is something the way it is? Not to be disruptive for its own sake, but because the answer often reveals the assumptions that are built into the system and the constraints that no longer need to exist. I planted a question earlier and I said we'd come back to it. Here it is. Why are we waiting until the end of the trial to look at safety signals at all?
Think about what the question is really asking. The process of generating tables, listings, and figures at the end of a trial phase exists for reasons. It was designed around constraints, computational, organizational, logistical, that were real at the time. But what happens when those constraints change? Some companies are no longer asking, how do I generate those TLS faster? They're asking, what becomes possible when our teams are entirely freed from writing boilerplate code? And the answer they are arriving at looks something like this, a safety monitoring board that doesn't wait for a quarterly report. Instead, they log into a secure, interactive Shiny with CVars or Teal application, where clinical data is processed end-to-end automatically, from raw data to a publication-ready Kaplan-Meier plot, allowing them to slice and dice adverse events on the fly with the underlying reproducible R code generated in the background.
And it all starts with a single question asked by someone with enough curiosity to look at a workflow they had run 100 times and ask, why does this exist? And what becomes possible if it doesn't have to exist this way? That is curiosity applied at the systems level, not how do I do this faster, but what does this system exist to accomplish?
I recently came across a thought-provoking book, Reshuffle, by Sangeet Paul Chaudhary, in which he defines the idea of unbundling and re-bundling of work as systems are disrupted by technology. AI accelerates the breaking up of the system into its components, allowing us to restructure the work and assemble it into something new. Most of us spend our careers getting better at working inside a system. That is how we build up our expertise. But curiosity is what will allow us to step back and see the system itself.
Curiosity opens the aperture, but it is customer-centricity which gives it direction. I want to offer you a reframe of what a customer means in your work, because I think most of us define it too narrowly, and that narrow definition limits what we can see. The patient is your ultimate customer. They are putting their faith into the science behind the solutions you put in the market. That is not in question. The integrity of your analysis, the reproducibility of your methods, and the trustworthiness of your submissions, all of it traces back to the people who participated in the trials, the data they generated, and the obligation to honor that contribution with science done carefully and correctly.
But the patient sits inside a system. And the system has other constituents whose needs also shape the work. The regulator whose job is to ensure the science behind an approval is sound. The physician who will prescribe based on the evidence you have helped generate. The organization that has hired you, whose competitive position in its ecosystem is shaped, in part, by whether it can move faster, more reliably, and more transparently than its competitors. Here's why this matters. When you map all of these customers, not just the patient at the center, but every ring of the system surrounding them, you start to see your work differently. The question, why are we waiting until the end of the trial to look at safety signals, is not just a patient safety question. It's an organizational competitiveness question. The company that answers it first is improving its competitive position in the competitive market.
But here's the uncomfortable implication. The tasks that define your role today were designed to serve all of those customers within a set of constraints. As AI removes these constraints, or reshuffles them, the tasks will change. The workflow will be unbundled and re-bundled. The question is not whether that will happen. The question is whether you will be one of the people shaping what that re-bundled version looks like, or whether someone else will shape it for you. Mapping all of your customers is how you stay oriented as the process unfolds. It is how you move from being a carpenter with better tools to someone who designs the build and builds the whole outdoor space.
Curiosity opens the aperture and customer centricity gives it direction. Courage is what closes the gap between seeing and doing. Once you can see the system clearly and you have mapped and understood the customers you are serving, you'll be able to see the gaps. Seeing the gap is the first step. Acting on it is critical. We all know that the culture of pharmaceutical data science appropriately rewards caution. Errors have serious consequences. The instinct to wait until something is proven, to not put your name on something you cannot fully defend, is not timidity. It is professional discipline. It is part of what makes this feel trustworthy.
But the same instinct applied without judgment to this moment becomes a different kind of risk. So let me offer you another reframe. Courage in this context is not a disposition. It is a decision. It is the decision to run one small bounded experiment.
And I want to be clear about what I mean by bounded because it may not be what you expect it to be. I'm not asking you to start with unimportant work. The whole argument we've been making this morning is that AI-assisted code is inspectable, reviewable, and verifiable. The prime directive is satisfiable. If that is true, and we believe it is, then there's no reason in principle why those tools cannot be used for serious work. The risk is not in the importance of the analysis. The risk is in the scope of change you introduce before you have built the judgment to manage it well. So start narrow, pick one bounded problem, not because the tools aren't ready for serious work, but because your judgment about how to deploy them well needs room to develop. Scope is the variable, not the importance of the problem.
That is the unit of courage I'm asking for. One bounded experiment on real work. And then, because the tools will have changed, the courage to run it again three months later, particularly if the first attempt didn't succeed. That willingness to rerun the experiments is a form of intellectual curiosity, an acknowledgement that what you concluded about those tools in January may no longer be true in July. That kind of willingness to revisit your own assumptions gives you an advantage over those who will write off these tools after a single disappointing experiment.
We as humans struggle to think in exponential terms. What feels like a modest improvement today can look like a transformation six months from now, given tools that are growing exponentially. The experiment you set up in January needs to be revisited in July, because the tools will not be the same tools. Here's what I can tell you with confidence. The people who are running those experiments today are building something that cannot be transferred. It is not knowledge you can read in a paper or learn in a workshop. It is judgment, the accumulated sense of what these tools can and cannot do,