Building a Research OS: From Django to 30,000 Samples

0:00

01:02:49

Links Episode Deep Dive Transcript

In 2020, a gastroenterologist in Glasgow did the math on his new research study and came up with 30,000 samples, arriving over two years from three cities and a dozen hospitals. He asked around about how researchers keep track of that. The answer was Microsoft Excel. Shaun Chuah had written some HTML by hand in Notepad back in high school and that was about the whole of his programming experience, so he opened the Django tutorial and started reading. Six years later that app is Foundry120, holding 10 terabytes of clinical and genomics data with an agentic AI running on top of it.

Play on YouTube

Watch the live stream version

Episode Deep Dive

Guest Introduction and Background

Dr Shaun Chuah (Cher Shiong Chuah) is a gastroenterologist and clinical researcher at the University of Glasgow, where he is a Clinical Senior Research Fellow in the School of Infection and Immunity and an Honorary Consultant Gastroenterologist. His clinical practice centers on inflammatory bowel disease (IBD), the family of conditions that includes ulcerative colitis and Crohn's disease, and his research with the Gut Translational Research Group looks for the causes of those conditions and new treatments for the patients he sees in clinic. He also has a strong personal interest in machine learning and agentic AI, and he has been a Talk Python listener for about five years.

Shaun is not a classically trained programmer. His coding background before 2020 amounted to hand-writing HTML in Notepad in high school and a few R and Python scripts to produce graphs for statistics. When the MUSIC study he signed up for needed a way to track roughly 30,000 biological samples across multiple hospitals, he taught himself Django from the official tutorial, books, YouTube, and podcasts, and built the app himself. Six years on, that project has grown into Foundry120, a research operating system for translational science teams, complete with cloud storage, burst compute on Azure, and an agentic AI assistant named Helix.

What to Know If You're New to Python

This episode is less about Python syntax and more about what happens when you use Python to build something real that other people depend on. A little familiarity with web frameworks, cloud storage, and how modern AI agents actually work will help you follow the architecture Shaun describes.

Django and "batteries included": Django is a mature Python web framework that ships with authentication, database migrations, and an admin interface out of the box. Shaun chose it specifically because a non-programmer could lean on those battle-tested pieces instead of building them, and it is still the backbone of Foundry120 today.
Localhost versus production: Getting an app running on your own laptop is one thing; keeping it running securely, with backups and access controls, on a server other people rely on is a different skill. A big part of Shaun's learning curve was that jump, including learning the Linux terminal and setting up continuous deployment with GitHub Actions.
Object storage and "everything is a file": Cloud blob storage such as Azure Blob Storage lets you store an effectively unlimited number of files and pay for what you use. Foundry120 treats every dataset, from CSV files to endoscopy videos to genomics sequencing output, as a file in blob storage with a metadata layer on top.
Agentic AI versus chatbots: A chatbot answers a question from its training. An agentic AI system is given a task and a set of tools, then loops: it calls tools, writes and runs code, reads the results, recovers from errors, and keeps going until it has an answer. Helix, the AI inside Foundry120, works this way, much like Claude Code or Codex do for programmers.
Role-based access control (RBAC): In clinical research, who can see which data is tightly governed. Foundry120 enforces permissions in Django so that the AI can only see exactly the files the human asking the question is allowed to see.

Key Points and Takeaways

Foundry120 is a research operating system built on three ideas: organize, centralize, and let AI operate on it

Shaun describes Foundry120 as a research operating system for translational science teams, meaning groups that recruit patients, collect samples, run experiments on them, and try to find mechanisms that could lead to new treatments. The platform rests on three ideas. First, organize your samples, studies, and participants into a single database so nothing gets lost. Second, centralize every data output in one place, whether that is clinical data like radiology images and endoscopy videos or scientific output like genomics, microbiome, and spatial transcriptomics. Third, once all that context lives in one governed platform, connect an AI to it so researchers can ask questions directly. The concrete example Shaun gives is a colleague asking whether the team has samples from any participant treated with a particular drug. Historically that meant joining a clinical dataset with the sample database by hand, a couple of days of work; with the platform, the agent can pull the data into a sandbox, write the join, and return the answer.

It all started with 30,000 samples, a spreadsheet, and the Django tutorial

In 2020, while still training as a registrar, Shaun joined a study that would recruit about 200 people across three cities and multiple hospitals, following each of them every three months and collecting blood, stool, and saliva samples at every visit. A back-of-the-envelope calculation came to roughly 30,000 samples over a couple of years. When he asked how researchers normally track that volume, the answer was Microsoft Excel. Enterprise lab systems were expensive, took months to set up, and were designed for hospital operations handling millions of samples rather than a one-off study. After surveying the off-the-shelf options, he decided the right move was to write a web app himself in Django, starting from the official tutorial. The first version was a sample-tracking system: print a QR code, stick it on a sample, scan it to register it in the database, and scan it again as it moved between sites.

Why Django: batteries included for someone who could not afford to get authentication or migrations wrong

Shaun's reasoning for choosing Django in 2020 is a good template for anyone picking a framework for a serious project without a big team. Django was mature and had been around a long time. Its authentication framework was battle tested, which matters when you are a non-programmer handling sensitive data. Its built-in database migrations meant he could evolve the schema without losing data, and in clinical research you cannot lose data. He notes that those two features alone were enough to persuade him before even counting the admin dashboard. The framework's own tagline, "the web framework for perfectionists with deadlines," matched his situation exactly: about two years to deliver a study and no time to spend forever on infrastructure. Michael also flagged fresh Django news for listeners: Django is moving to an annual release cycle with calendar-based version numbers, with every release getting long-term-support-level care, which should make the versioning simpler for newcomers to decipher.

Books, YouTube, and the community filled the gaps for a self-taught developer

Shaun credits the Django documentation, YouTube tutorials, this podcast, and a stack of books for getting him from zero to a production app. He specifically mentions Two Scoops of Django, Obey the Testing Goat for test-driven development, Designing Data-Intensive Applications by Martin Kleppmann, and Ralph Kimball's The Data Warehouse Toolkit for dimensional modeling once the project matured into a data problem. His point about textbooks is that they give you a holistic, fundamentals-first view so you do not have gaps in what you are building, and that topics like TDD tend to live in books rather than on YouTube because they are not flashy. Michael shared that his own path was similar, coming from math into scientific research software, and that self-taught developers often have blind spots around data integrity and things like foreign key relationships. Both agreed that being aware of what you do not know, and closing those gaps deliberately, is what makes an app reliable enough for others to depend on.

The steepest learning curve was going from localhost to production

Running the app on a laptop was the easy part. Production meant reliable, secure, accessible infrastructure with backups, and it meant learning to operate a Linux server from a terminal when Shaun's instinct was to ask "where is the UI?" The practice that made it manageable was continuous integration and continuous deployment through GitHub Actions, so fixes could reach production in minutes rather than by hand. Michael made the case that CI/CD is at least as valuable for beginners as for big teams: if all you have to do is push to GitHub and the new version is live, a huge amount of intimidating complexity disappears. Shaun added that every time he teaches a new team member the terminal, he is reminded what a big jump the command line is for most of the population, and Michael noted that phones being most people's primary computer only widens that gap.

github.com/features/actions

Ten terabytes and counting: the real problem became the data, not the samples

Tracking samples was the operational problem, but every sample then enters an experimental pipeline and produces data, and every data type looks different. Stool samples become microbiome data; blood samples become genomics data. For Shaun's own cell-free DNA sequencing work, each participant's file was 5 to 10 gigabytes of gzipped FASTQ data headed into a bioinformatics pipeline. The group currently holds about 10 terabytes, with much of the 30,000-sample backlog still unprocessed because some pipelines take a person 12 hours to handle a couple of samples. Before the platform, data was scattered across laptops, shared drives, and one-off Excel files per experiment, which Shaun calls one of the big problems in biomedical research today. Looking ahead, some newer instruments produce a terabyte of data for a single sample, grants typically cost storage for ten years, and nobody wants to rerun a 100-terabyte pipeline, so deciding which processed outputs to keep is an open question with no easy answers.

azure.microsoft.com/en-us/products/storage/blobs

Everything is a file: blob storage plus a metadata layer as the universal data model

After years of wrestling with how to aggregate wildly different datasets into a common model, Shaun's team landed on something simple: all data exists as files in Azure Blob Storage, even tabular data, which they keep as CSV. They tried loading tables into the database in the past, but files are the universal denominator across endoscopy videos, MRI images, digital pathology slides, and sequencing output. What makes the files useful is the layer of metadata and relationship data the platform keeps on top of them. Michael pointed out that tools like DuckDB and Parquet already let you treat files like databases, and asked about embedded databases like SQLite; Shaun said they use Parquet, finds SQLite an interesting idea, but keeps CSV because his end users live in Excel and CSV. The payoff of the file model is that an AI agent can run across all of the files and pull out what it needs. Moving to blob storage also replaced the old university quota, where you emailed IT to raise a terabyte cap, with a monthly bill.

Helix is an agentic AI, not a chatbot, and that distinction is the whole point

Michael opened the AI discussion by noting that "AI" means two or three different things and people talk past each other, comparing a chatbot getting a math problem wrong with a tool-using system that writes Python to answer its questions. Helix is firmly in the second category. Shaun's description of the paradigm: you give the AI a task, it looks at its tool set and what you are trying to do, and it goes away and works until it has an answer. He estimates 95 percent of people's AI experience is closer to a Google search, so there is a huge gap in understanding how powerful agentic systems can be, and Helix is one of the first demonstrations of applying that approach in science. In the one-minute screencast on the Foundry120 site, Helix answers "what plasma samples do we have for the MUSIC study, broken down by disease group" by joining the clinical data frame with the sample database, then plots CRP against cell-free DNA by writing matplotlib code, hitting an error, reading the tool output, and correcting itself. Helix does not use a fine-tuned or retrained model; the team swaps in newer base models as they come out, because fine-tuning is expensive, needs training data that is hard to make, and does not generalize.

Django as the security guard between the AI and the data

The most distinctive architectural idea in the episode is where the permissions live. When Helix wants to process a file, the request goes through Django first: Django screens the staged code and data, spins up a VM, transfers the file from blob storage into that sandbox, runs the AI's analysis code there, and stores the output back in blob storage. The AI never calls directly into the files or the compute environment. Because the tools run on the back end, the same role-based access controls that apply to a human apply to the agent, so when a team member queries Helix, it can only see files that person could already open. Michael underlined why this matters with a story about Claude quoting his GitHub issues and offering to check something on his production server, having discovered an authenticated GitHub CLI and SSH access on its own. These agents are not malicious, but they will use any path they can find to get a better answer, so the guardrails have to be enforced outside the model.

Heavy compute stays in the cloud: 350 CPUs on Azure and embarrassingly parallel biology

Michael asked whether Pyodide or JupyterLite could push some computation into the browser to save server costs. Shaun explained why that does not fit: files are gigabytes in size and genomics pipelines are CPU and RAM hungry. Foundry120 has access to about 350 CPUs on Azure, and when a user asks Helix for a heavy transcriptomics analysis, Django orchestrates a compute job that spins up as many CPUs as needed, runs for anywhere from half an hour to a couple of hours, and returns the result later. Many biological problems are naturally parallel: with 200 participants at 5 gigabytes each, you might as well spin up 200 machines, process everything at once, and tear it all down, which he sums up as minimal cost for maximum impact. There is a second reason to keep compute server-side: the platform runs sample collection in hospitals across Scotland, where front-line IT is not always the best and some machines date to 2010 on decade-old chips, so a server-rendered app guarantees a fast experience regardless of the client.

Django REST Framework on the back end, TypeScript and React on the front end

The original app was pure Django with Django templates handling registration and CRUD workflows. As the platform moved into AI, Shaun rebuilt the front end in TypeScript and React talking to a Django REST Framework back end. His reasoning is that AI is inherently asynchronous: every model call can take what feels like forever, and running an agent loop involves many such calls, which JavaScript and TypeScript are well suited to handle interactively. He calls the combination a great setup because it gives the team the entire Python data science ecosystem on the back end and the full TypeScript and JavaScript ecosystem for the interactive, async-heavy front end that AI applications need.

Governance decides everything: where inference runs, why there is no MCP server, and why you cannot just sign up

Foundry120 runs on the University of Glasgow's Azure tenancy, with most workloads in the UK South data center and EU-compliant work in Sweden. All inference happens inside Azure under GDPR-compliant controls, which is why, when Michael asked about adding an MCP server so people could query Foundry from their own AI tools, Shaun said the limiting factor is governance: they are not allowed to put patient data into Claude Code and send it to Anthropic. The same constraints shape who can use the platform. Over the last six to twelve months the foundation has been made generalizable beyond Shaun's group and beyond IBD, with team management and permission assignment built in, but onboarding is a hands-on process that depends on data types, volumes, modalities, and each study's research ethics approval. That is why the site offers a platform walkthrough rather than a self-serve monthly subscription. Michael noted that GDPR applies to US companies with European customers as well, and that this same territory covers IRB approvals and HIPAA in the States.

Cloud versus the basement cluster: the economics of research computing and AI

Michael reflected on how universities have gone from a Cray or Silicon Graphics machine in a basement to renting effectively unlimited cloud capacity. Shaun argued the cloud is far more cost-efficient for universities because most analyses are one-off bursts: you might process a huge dataset once every year or two, which is a poor fit for owning hardware that sits idle in between. He is even more definitive about AI, where a single NVIDIA rack costs a couple of million dollars and needs a power plant to plug into; he cannot see any university building its own AI data center, so cloud adoption is inevitable unless specific governance requirements force otherwise, and even then a shared local provider makes more sense than each university going alone. The two also speculated about the future: Michael suggested that if frontier subscriptions became dramatically more expensive, a ten-thousand-dollar local workstation would suddenly look like a bargain, and imagined an orchestration layer routing to small domain-specialist models. Shaun agreed small models are getting more capable and not every workload needs a frontier model.

azure.microsoft.com

The job changes from writing the analysis to verifying it

Historically, every new team member had to sit down with Shaun and learn enough Python or R to get a graph out of an Excel file. Now they can hand that to Helix and let it write the code, and their job becomes checking that the result is correct. Shaun is candid that the reliability threshold has not been crossed: even the best models like Opus and Fable still make mistakes, so understanding what you are trying to do matters more today than it did five years ago, because you have to know enough to supervise the AI. He tells his scientific colleagues that answers must pass the smell test and land in the expected magnitude range, and that disposable work can be delegated more freely while critical workflows need every step verified. Michael's counterpoint is that humans are not 100 percent reliable either, and people expect perfection from AI because software has always been deterministic. He pointed to the recent tension around AI pre-screening of Linux kernel patches as an example of that expectation clashing with a tool that is often as good as the people doing the job. Shaun's framing: an AI is like a colleague who writes code faster and better than most people, but the human still supplies the strategic view and the direction.

Most of the world has never touched a coding agent, and closing that gap is the real work

Shaun's read on the next few years is optimistic but grounded. Agentic AI has a genuine role in shortening bottlenecks in drug discovery and will transform how science and clinical work are done, but the real world will take a while to catch up to today's capabilities. Most Talk Python listeners have used a coding agent; almost everybody else in the population has not. Scientists he demos Helix to are often seeing an agentic system for the first time, and their reaction is that work which used to take months or a long email chain now takes minutes. His closing call to action is generous: the team does not yet know whether Foundry120 generalizes beyond their group or stays hyper-personal software, so he has shared the principles widely and encourages other institutions to take the ideas and build their own, while inviting anyone interested in a partnership to reach out through the website.

Interesting Quotes and Stories

"When I first visited the Django website, it said the web framework for perfectionists with deadlines. And I think that described exactly the situation I was in." -- Shaun Chuah

"I wasn't very good of a programmer. What I did was basically write some websites in high school. And back in those days, we used to use Notepad. We used to open the brackets of HTML manually by hand." -- Shaun Chuah

"A simple back of the envelope calculation came to about 30,000 samples that we were going to generate over a couple of years. When I first saw that challenge, I started asking everybody around me, how are we going to keep track of all that? The common way that researchers track the samples is to use Microsoft Excel." -- Shaun Chuah

"You have a bill instead of a limit." -- Michael Kennedy, on moving from university storage quotas to Azure Blob Storage

"Some of the newer technologies are generating like a terabyte of data for a single sample." -- Shaun Chuah

"Who wants to run another 100 terabyte pipeline anyway?" -- Shaun Chuah, on deciding which processed outputs to keep

"We've actually put a Django in as a security guard between your AI and the raw data and the compute environments that we run." -- Shaun Chuah

"These AIs are sneaky. They will find a way to access the files." -- Michael Kennedy

"In agentic AI, you give the AI a task. It looks at its tool set. It looks at what you're trying to do. And then it goes away and works at it until it gives you an answer. And that's incredibly powerful." -- Shaun Chuah

"So the work changes. Instead of you as a researcher writing the analysis code, you get the AI to do the analysis for you. And then what you have to do is verify that it is correct." -- Shaun Chuah

"Having an AI by your side is like having a colleague on your team. Except this colleague can write code tremendously faster and much better than most people." -- Shaun Chuah

"Because it's a computer, people expect it to be perfect. Software is typically deterministic. So if it works once, it's always going to work. And AI isn't like that. But people also aren't like that." -- Michael Kennedy

"A single rack from NVIDIA is like a couple million dollars, right? And you need a power plant to plug it into. I can't see any university building their own AI data center in the future." -- Shaun Chuah

"I think most people on this podcast would have used coding agents, but I can tell you that almost everybody else in the population has never touched a coding agent." -- Shaun Chuah

"Please feel free to just take the idea and run with it." -- Shaun Chuah

The Silicon Graphics machine that ran out of bytes. Michael told a story from his university days in a math research lab, where the whole department shared a Silicon Graphics mainframe with no disk quotas. A grad student debugging their code added logging, accidentally created an infinite loop, and left it running overnight. By morning the machine would not respond, and it took a day or two to figure out why: the log had filled the hard drive to the very last byte, and the operating system needed a few temp files to function. Shaun's takeaway, delivered with a laugh, was that those limits have a reason to exist.

Claude finds the GitHub CLI. While working with Claude on his code, Michael was surprised when it referenced two GitHub issues he had never given it access to. It had noticed the GitHub CLI was installed and already authenticated because Michael had logged in at some point, so it simply used that. Later it offered to check something on his production server, having worked out from the code that it could SSH in. His point was that these tools are not malicious, they are just trying to give you a better answer, but "we fixed the problem by resetting the database" is a real risk if the guardrails are not enforced outside the model.

Key Definitions and Terms

Inflammatory bowel disease (IBD): A group of chronic conditions, principally ulcerative colitis and Crohn's disease, in which the immune system reacts to the environment and the inflammation never switches off. Shaun describes it as rare but growing in both developed and developing countries.
Translational science: Research that recruits people with a condition, collects samples, runs lab experiments to understand the biology of disease, and looks for mechanisms that could be targeted for new treatments. Foundry120 is built for teams doing this kind of work.
MUSIC study: The multi-site IBD biomarker study at the University of Glasgow's Gut Translational Research Group that Foundry120 grew out of. Its projected 30,000 samples were the original reason Shaun learned Django.
Helix: The agentic AI assistant inside Foundry120. It uses tools to query samples and clinical data, writes and runs analysis code in a sandbox, and recovers from its own errors.
Agentic AI: An AI system that is given a task and a set of tools, then works autonomously through a loop of tool calls, code execution, and self-correction until it produces an answer. Contrasted in the episode with chatbots, which are closer to a search engine.
Role-based access control (RBAC): A permissions model where what a user can see and do is determined by their role. Foundry120 enforces RBAC in Django, and the AI inherits exactly the permissions of the person asking.
Sandbox: An isolated compute environment, in Foundry120's case a VM spun up on demand, where AI-generated code runs against a copy of the data so the agent never touches the raw storage or production systems directly.
Azure Blob Storage: Microsoft's cloud object storage service. Foundry120 keeps every data file there, replacing scattered laptops, shared drives, and university storage quotas with pay-as-you-go storage.
Microsoft Foundry: Microsoft's platform for building and governing AI apps and agents on Azure. Michael references it alongside Azure as part of the stack Foundry120 has integrated with.
CI/CD (continuous integration and continuous deployment): The practice of automatically testing and deploying code on every push. Shaun uses GitHub Actions so fixes reach production in minutes.
Django REST Framework: A toolkit for building web APIs on top of Django. Foundry120's TypeScript and React front end talks to Django through it.
Calendar versioning (CalVer): A version numbering scheme based on the release date. Django is adopting it as part of its move to annual releases, so future versions will be named for their year rather than incrementing 5.2, 6.0, and so on.
FASTQ: A text-based file format for DNA sequencing reads and their quality scores, usually gzipped. Shaun's cell-free DNA files arrive this way at 5 to 10 gigabytes per participant.
Cell-free DNA: DNA fragments circulating freely in the blood. Sequencing it was the focus of Shaun's personal research project within the MUSIC study.
CRP (C-reactive protein): A common blood test marker of inflammation. In the Helix demo, it is plotted against cell-free DNA levels.
Parquet: A columnar file format widely used in data engineering that tools like DuckDB can query directly. Shaun's team uses it alongside CSV.
Pyodide and JupyterLite: Pyodide is a port of CPython to WebAssembly that runs Python in the browser; JupyterLite is a JupyterLab distribution built on it that needs no server. Michael raised them as a way to offload compute to the client, which does not fit Foundry120's gigabyte-scale workloads.
Model Context Protocol (MCP): An open standard for connecting AI assistants to external tools and data sources. Michael suggested a Foundry MCP server, which governance rules currently rule out.
GDPR: The European Union's General Data Protection Regulation. It is the reason all Foundry120 inference stays inside Azure data centers in the UK and Sweden.
Dimensional modeling: The data warehouse design approach from Ralph Kimball's The Data Warehouse Toolkit, which Shaun read as the project shifted from sample tracking to data management.

Learning Resources

If this episode has you thinking about building a Django app for your own research group, wiring an agent up to real data, or simply understanding how tool-using AI works under the hood, here are some places to go deeper.

Django: Getting Started: Build a real Django app from the ground up, covering the models, migrations, authentication, and admin features that convinced Shaun Django was the right choice for a non-programmer with a deadline.
Agentic AI Programming for Python: Learn to work effectively with coding agents like Claude Code and Codex, the same style of tool-using AI that Helix brings to scientific research.
LLM Building Blocks for Python: A practical introduction to programming against LLMs from Python, including tool use and structured outputs, the foundations of building an agent like Helix on your own data.
docs.djangoproject.com/en/stable/intro/tutorial01: The official Django tutorial, which is exactly where Shaun started in 2020.
obeythetestinggoat.com: Harry Percival's Test-Driven Development with Python, free to read online, and one of the books Shaun credits for closing his testing gaps.
dataintensive.net: Martin Kleppmann's Designing Data-Intensive Applications, recommended by Shaun for understanding the fundamentals of data systems.
djangoproject.com/weblog/2026/aug/10/annual-release-cycle: The Django announcement Michael mentioned, explaining the move to annual, calendar-versioned releases.
foundry120.com: The Foundry120 site, including the one-minute Helix screencast narrated in the episode and the platform walkthrough request.

Overall Takeaway

Shaun Chuah's story is a reminder that the most consequential software is often built by the person closest to the problem, not the person with the most credentials in programming. A doctor who had last written HTML by hand in Notepad looked at 30,000 samples and a spreadsheet, opened the Django tutorial, and kept going. Six years later that decision has become a governed research platform holding 10 terabytes of clinical and genomics data, orchestrating hundreds of CPUs on Azure, and giving scientists an AI colleague that answers in minutes what used to take days of manual joins.

The technical lessons are just as portable as the personal ones. Pick boring, battle-tested foundations when the stakes are high. Treat every dataset as a file with metadata on top so that both humans and agents can reason over it. Keep permissions and guardrails in your own code, in Shaun's case Django standing between the AI and the data, rather than trusting the model to stay in its lane. And when you hand analysis to an agent, understand that your job has not disappeared; it has shifted to supervision and verification. As Shaun puts it, most of the world has never touched a coding agent yet. If you are a Python developer who has, you are unusually well placed to close that gap for the scientists, clinicians, and researchers around you, and to take these ideas and run with them.

Links from the show

Guest
Shaun Chuah: github.com

Up and Running with Rust Course: talkpython.fm

Foundry120: www.foundry120.com
Designing Data Intensive Applications: www.oreilly.com
Microsoft Foundry: ai.azure.com
ChatIBD: www.chatibd.com
Blog: shaunchuah.github.io
@drshaunchuah: x.com
github.com/shaunchuah: github.com

Watch this episode on YouTube: youtube.com
Episode #560 deep-dive: talkpython.fm/560
Episode transcripts: talkpython.fm

Theme Song: Developer Rap
🥁 Served in a Flask 🎸: talkpython.fm/flasksong

---== Don't be a stranger ==---
YouTube: youtube.com/@talkpython

Bluesky: @talkpython.fm
Mastodon: @talkpython@fosstodon.org
X.com: @talkpython

Michael on Bluesky: @mkennedy.codes
Michael on Mastodon: @mkennedy@fosstodon.org
Michael on X.com: @mkennedy

Episode Transcript

Collapse transcript

WebVTT format On GitHub

00:00 In 2020, a gastroenterologist in Glasgow did the math on his new research study and came up with

00:05 30,000 samples arriving over two years from three cities and dozens of hospitals.

00:11 He asked around about how researchers kept track of that. The answer was Microsoft Excel.

00:17 Sean Chua had written some HTML by hand in Notepad way back in high school. That was about the

00:23 entirety of his programming experience. Even so, he opened the Django tutorial and started reading.

00:29 Six years later, that app is Foundry 120, holding 10 terabytes of clinical and genomics data with

00:36 agentic AI running on top of it. This is Talk Python To Me, episode 560, recorded August 26th,

00:44 2026. Talk Python To Me. Yeah, we ready to roll. Upgrading the code. No fear of getting old.

00:52 Async in the air. New frameworks in sight. Geeky rap on deck. Quartz crew. It's time to unite.

00:57 We started in Pyramid, cruising old school lanes, had that stable base, yes sir.

01:02 Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists.

01:07 This is your host, Michael Kennedy.

01:09 I'm a PSF fellow who's been coding for over 25 years.

01:13 Let's connect on social media.

01:14 You'll find me and Talk Python on Mastodon, Bluesky, and X.

01:17 The social links are all in your show notes.

01:20 You can find over 10 years of past episodes at talkpython.fm.

01:24 And if you want to be part of the show, you can join our recording live streams.

01:27 That's right.

01:28 We live stream the raw uncut version of each episode on YouTube.

01:32 Just visit talkpython.fm/youtube to see the schedule of upcoming events.

01:36 Be sure to subscribe there and press the bell so you'll get notified anytime we're recording.

01:41 Let me quickly tell you about a new course we have running over at Talk Python.

01:46 Up and running with Rust.

01:48 The tools reshaping how you write Python, Ruff, uv, Firefly, ty, Pixie, and others.

01:53 and the libraries pushing past its performance ceilings.

01:56 Polars Pydantic, Cryptography, and Granian increasingly share one secret under the hood.

02:02 They're written in Rust.

02:03 That code that used to be written in C when Python needed real speed now

02:07 is more and more being written in Rust.

02:10 So having some Rust proficiency is a great skill as a Python developer.

02:15 Christopher Trudeau is back with the Up and Running with Rust course.

02:20 Check it out over at talkpython.fm.

02:22 Just click it courses in the top and you'll find it right there.

02:25 I hope you love this new Rust course.

02:27 Getting a course at Talk Python is one of the best ways to support the show.

02:32 This episode is brought to you by Sentry.

02:34 You know Sentry for the error monitoring, but they now have logs too.

02:37 And with Sentry, your logs become way more usable, interleaving into your error reports to enhance debugging and understanding.

02:45 Get started today at talkpython.fm/sentry.

02:48 And it's also brought to you by Talk Python Courses.

02:52 Course completion certificates are now live.

02:54 If you finished a course, there's a certificate waiting for you on your account page right now.

02:59 Download it as a PDF or add it to your LinkedIn profile with one click under licenses and certifications.

03:06 Same section as your formal degrees.

03:08 Visit training.Talk Python.fm account to see what you've already earned.

03:13 John, welcome to Talk Python To Me.

03:14 How are you doing?

03:15 Great.

03:16 Thanks very much, Michael.

03:17 A big fan of the show.

03:18 Keen to be here to share a few things of what we've learned.

03:22 Amazing. Thank you so much. And now you're here creating the show. It's going to be amazing.

03:27 And you're doing really interesting work with biological and medical research, Python,

03:33 Django, AI. I think there's a lot of cool things that we're going to dive into here. So

03:38 I know even for people who are not in medical research, I think there's going to be some

03:43 super interesting angles that will translate for them.

03:46 Fantastic. Looking forward to it.

03:48 Now, before we dive into that, as usual, just tell people about yourself.

03:51 Who are you?

03:52 So I'm Sean.

03:53 I'm a gastroenterologist, and I'm a clinical researcher as well.

03:57 So my primary area of practice is in the field of inflammatory bowel disease that comprises

04:02 ulcerative colitis and Crohn's disease as the kind of conditions that we deal with when

04:09 we see patients in clinic.

04:10 But in parallel, I also work in research, trying to find out the causes of these conditions

04:16 together with the GUT Translational Research Group here at the University of Glasgow.

04:20 Personally, for this podcast, we use Python a lot in our work, both for research,

04:25 so trying to analyze the data that we're doing, but also as well as for the infrastructure that

04:29 we're running. So how do we actually deliver the research studies that we have to deliver?

04:34 And personally, as a researcher, I've also got an interest in agentic AI and machine learning,

04:39 and that's what attracted me to try to use some of these techniques to see if we can find

04:43 new breakthroughs that can bring, you know, new treatments for our patients that we see in clinic

04:48 every day. Awesome. Very cool research. That's the kind of stuff that can make a big difference

04:53 for people's lives. If you can make them better, right? It's like, I couldn't leave the house,

04:58 but now I'm back with my friends or whatever, right? Yeah. I mean, you know, the work that we

05:02 do is motivated in the patients that we see day to day. Inflammatory bowel disease is not very

05:09 common. It is rare, but it is growing not just in developed countries, but also in the developing

05:15 world. And we see a great burden of this disease coming the next 10 to 20 years. What do you think?

05:20 Diet? Environment? Why is it growing? Obviously, that's the research a little bit, right? But

05:26 what is your ideas here? Well, these are really complex conditions, and the environment is

05:31 absolutely a major player in this. The diet that we're eating nowadays is different from what we

05:36 used to eat. But when we dive into the science of it, it's a lot more complex than just that.

05:41 There are some patients who have genetic susceptibility, although not all. And we know

05:46 that there is this problem that happens when the immune system reacts to our environment. And for

05:51 some reason, the alarms don't switch off and the inflammation keeps happening, which leads to the

05:56 symptoms and the problems that we see every day in clinic. So let's start by examining all the

06:03 the research and the work you did and maybe the 2020 version of your research projects.

06:09 It all started with Django, right?

06:11 Yes.

06:12 So back in 2020, I was still training as a gastroenterologist.

06:16 So over here, we do a period of registrar training, we call it.

06:20 And as part of my developing interest in understanding these medical conditions, I sign up to do a

06:27 research study with one of the principal investigators.

06:31 And the proposed study was basically to recruit quite a few patients from three different cities,

06:38 multiple hospitals, and collect extra samples that we can run science experiments on to work

06:43 out what's going on with an immune system. So when we first started, that was 2020. And I know

06:51 we all remember that in 2020, you know, we had COVID and COVID had a significant impact both on

06:57 hospital operations, but also on research operations. And when I sat down to look at

07:02 what we were supposed to do in terms of the research studies, the first challenge that I

07:07 faced was calculating the number of samples we were going to do. So we were going to recruit about

07:12 200 people and we're going to follow them up every three months. And at every time point,

07:17 we would take extra blood samples, extra stool samples, and saliva samples. So that was a lot

07:23 of extra samples and a simple back of the envelope calculation came to about 30,000 samples that we

07:29 were going to generate over a couple of years. Now, when I first saw that challenge, I started

07:33 asking everybody around me, how are we going to keep track of all that? How are we actually going

07:37 to deliver that problem? How do we solve that problem? And from my chat with a lot of people,

07:45 the common way that researchers track the samples is to use Microsoft Excel.

07:49 That's exactly what I was thinking is like, how big is the Excel file?

07:53 And, you know, how many little worksheet tabs does it have?

07:57 Yeah, I mean, most research teams do not really have a lab system because lab systems, you

08:01 know, enterprise software, which is really expensive to procure, it'll take you like

08:06 six months to set it up.

08:07 And it's usually designed really for hospital operations where you're taking, you know,

08:12 millions of samples.

08:13 And it's not really designed for a one-off research study across a lot of different spaces.

08:18 So then I started looking into what are the, you know, are there off the shelf options or

08:24 stuff that we could use to just get up and running?

08:26 But after looking at a few different options, I think I had to bite the bullet and decided

08:32 that, you know, the best thing was to go and write a web application with Django.

08:38 What was your programming experience at this point?

08:40 How good of a programmer were you?

08:42 So I wasn't very good of a programmer.

08:45 I mean, what I did was basically, you know, write some websites in high school.

08:51 And back in those days, we used to use Notepad.

08:53 We used to open the brackets of HTML manually by hand.

08:57 It was rough.

08:58 Those were tough times, I remember.

09:00 Yeah, I don't know how many people listening to this podcast can relate.

09:03 But we used to write, you know, the head, the body and stuff.

09:06 And then later on, I did use a bit of programming to do some, you know, statistics, a bit of,

09:12 writing an R script or a Python script just to generate a graph.

09:15 So that's probably that level of programming experience when I was looking at how do we actually write a web app with Django.

09:23 Yeah, okay. So a Django web app was kind of a pretty big stretch at that point, right? Yes, but the Django...

09:31 How'd you get started? I mean, this predates all the AI, agentic stuff.

09:35 You had to earn it for this one. Yeah, definitely. I mean, when I first visited a Django website. It's the web framework for perfectionists with deadlines. And I think

09:44 that described exactly what a situation I was in. You know, I came out program and we had about a

09:50 two year time period to deliver a study. And you can't spend forever trying to get this up and

09:54 running. You just have to get the study going. So the Django tutorial was where I started. But

10:00 actually, I just want to take this opportunity to thank a lot of people in the community and those

10:04 listening because it's the documentation, the YouTube tutorial, your podcast. I've been listening

10:09 for five years. Books that were written, Two Scoops of Django, famously. I read a ton of books just

10:16 to be able to get things up and running. Yeah, the books are great. And honestly, YouTube is really

10:22 good. People knock YouTube for many reasons. You know, it's one of the ills of social media that's

10:27 like scrambling their brains. But if you use YouTube for education, it's an incredible resource.

10:33 Yeah. I mean, there are a lot of creators on YouTube that are just, you know, teaching lots

10:37 of different things. And it's so helpful. But I also think some of the textbooks are great, you

10:43 know, for things like test-driven development. You know, back in the days, I think you would only

10:48 read about it in textbooks rather than on YouTube videos because it's not really an attractive topic.

10:53 Yeah, you mentioned Obey the Testing Goat, which is a really fun book. And you also talked about

10:58 using designing data-intensive applications. And that's by Martin Klepman. I haven't heard of that

11:05 That's a pretty interesting one that people might want to check out.

11:08 Yeah, down the line, as our studies matured and we started dealing with the data, I started

11:13 reading some of the other data textbooks like Data Warehouse Toolkit by Kimball.

11:17 I think that's the one that all data engineers used to talk about dimensional modeling and

11:23 all that kind of stuff.

11:24 So lots of textbooks.

11:25 I think they're really helpful because they give you a kind of a holistic, fundamental

11:30 approach to learning the basics and making sure you don't have gaps in what you're doing

11:35 to build some of these things.

11:36 When you come from the background of programming that you did, which, by the way, that's a very similar story to me as well.

11:43 I studied math, and then I got involved helping people with research projects and working for a scientific research

11:50 and visualization company.

11:52 So you kind of build up the pieces as you go, and it's super fun.

11:55 It's really neat.

11:56 But there's a lot of gaps in your sort of data integrity, programming, like what is the foreign key relationship?

12:05 All that.

12:06 Yeah, yeah.

12:07 So I think books are really important, especially for self-taught people like us.

12:12 Definitely, definitely.

12:13 You do learn a lot as you go.

12:16 And it's quite important to be aware of what you don't know and try and close those gaps

12:21 so that the applications that you write end up being reliable enough for people to depend on.

12:26 Let's talk about Django for a second because you shouted out, Django, some of the features of it that kind of made that possible.

12:33 I think this is one of the reasons that people choose Django, especially when they're getting started.

12:38 You know, it's like it's got the built-in migrations.

12:40 It's got the automatic database management, the admin.

12:43 So what was it about Django that drew you to this?

12:46 So I think, you know, when we looked at the landscape back in 2020, Django definitely stood out because it was a mature project.

12:53 It's been around for a long time and it's batteries included, which is really important because, you know, I'm conscious that, you know, as a non-programmer coming into trying to write these things,

13:03 You want your authentication framework to be battle tested.

13:05 Database and migration is incredibly important.

13:08 You can't lose any data.

13:09 And I think just on those two features alone, we haven't even come to the admin dashboard,

13:13 but just those two features alone, I think was enough to persuade me that Django is the right framework

13:18 for the problem that we're dealing with.

13:21 Okay, very interesting.

13:22 And by the way, just big news for Django folks.

13:26 Is it on their blog, maybe?

13:27 Big news for Django is they just announced that they're switching the Django long-term support

13:34 to yearly releases, just like Python itself, and calendar version.

13:39 So there'll be Django 2028, Django 2029, and every single release is a long-term support,

13:44 whereas now you're kind of juggling like, well, 5.2 is a long-term, but the one before it.

13:48 I think that'll also make it a little simpler for people who are coming,

13:51 like they don't have to decipher the versioning and what it means.

13:54 Definitely, yep.

13:56 Yeah, yeah, that'd be cool.

13:57 What else?

13:58 What else did you run into trying to navigate this world of becoming, running one of these

14:05 like real web apps rather than just Excel or buying some off the shelf, you know, square

14:11 peg round hole type of system that doesn't really fit what you're trying to do?

14:14 Yeah, I mean, I think one of the steep learning curves is how do you go from a local host

14:19 development project into something that's in production?

14:22 Because production is obviously a whole different ballgame.

14:25 you need to ensure your infrastructure in production is reliable.

14:30 It's secure. It's accessible.

14:32 You've got backups running, all sorts of things.

14:35 And for us, one of the key things that enabled us is continuous integration and continuous deployment practices.

14:42 So using GitHub Actions to deploy continuously so we can fix problems, get it into production in minutes

14:50 rather than trying to do any of these things by hand manually.

14:54 Yeah, the CI-CD stuff, I think, is really valuable.

14:56 It's valuable for big teams, but it's also really valuable for people who are really new.

15:01 Because if all I have to do is save my work to GitHub, and now that's the new stuff that's out there.

15:07 That takes a lot of the complexity out.

15:09 People forget just how intimidating logging into a Linux computer is.

15:14 Oh, yeah.

15:15 Now what?

15:15 Yeah?

15:16 Yeah, I had to learn how to use Linux on a terminal, right?

15:19 Exactly.

15:20 It was like, where is the UI?

15:22 This is very different.

15:25 How am I supposed to accomplish anything with just the terminal?

15:27 And, you know, you get used to it and it's amazing in its own special way,

15:31 but it doesn't feel amazing at the beginning most of the time, I think.

15:34 Well, I'm reminded of the...

15:35 It feels intimidating.

15:36 Yeah.

15:36 Every time I teach somebody how to use the Linux or the terminal, it's a big jump, I think, for people who are not familiar with CLI,

15:44 which is, I think, the vast majority of people in the population.

15:47 Yeah.

15:47 Well, and things like people being primarily on phones for their computing device

15:51 don't make that easier. It's only harder, right? This portion of Talk Python To Me is brought to

15:57 you by Sentry. You know Sentry for their great error monitoring, but let's talk about logs.

16:02 Logs are messy. Trying to grep through them and line them up with traces and dashboards just to

16:07 understand one issue isn't easy. Did you know that Sentry has logs too? And your logs just became

16:13 way more usable. Sentry's logs are trace connected and structured, so you can follow the request flow

16:19 and filter by what matters.

16:21 And because Sentry surfaces the context right where you're debugging, the trace, relevant logs, the error,

16:26 and even the session replay all land in one timeline.

16:29 No timestamp matching, no tool hopping.

16:32 From front end to mobile to backend, whatever you're debugging, Sentry gives you the context you need

16:36 so you can fix the problem and move on.

16:39 More than 4.5 million developers use Sentry, including teams at Anthropic and Disney+.

16:44 Get started with Sentry logs and error monitoring today at talkpython.fm/sentry. Be sure to use our code talkpython26. The link is in your

16:53 podcast player show notes. Thank you to Sentry for supporting the show. Let's talk about your project

17:00 Boundary 120. So when you started, you built this bespoke Django app for, was this for the music

17:08 study or which study was this for? This was for the music IBD study. And the first version was

17:14 really to track samples and to come up with an efficient way for our teams to handle the, you

17:19 know, the 30,000 that we are projecting to sort out. So one of the key functionalities that we

17:25 wrote in at the start was this ability to, you know, stick a QR code, stick it onto a sample

17:29 label, scan it in, and that will register it into a database. And then we could move the sample

17:34 around between sites and scan it and update. So that's where it started out as a sample tracking

17:39 platform. So nothing too amazing. It was just kind of a really basic operational problem that just

17:46 needed to be solved. But over time, when you get samples, the next thing that happens to the sample

17:51 is that it gets processed into an experimental pipeline and you get data out of it. So the

17:56 lifecycle of an experimental sample then leads you on to dealing with the data that comes back.

18:02 Now, because we were taking so many different types of samples, one of the key challenges that

18:06 faced our team was how do you handle the data that was coming back at us? Because we have stool

18:11 samples that becomes, you know, microbiome data. We have blood samples that become genomics data.

18:18 And every data type that comes back just looks a little bit different, comes back in different

18:22 formats, you know. And one of the difficulties as well is the size of the data that we get.

18:28 So for my personal research project during that time, I was looking at sequencing out the cell-free

18:34 DNA. So the DNA fragments that you have floating around your blood and each sequencing file for a

18:40 participant will be about five to 10 gigabytes of data. And it comes back in a, you know,

18:44 in a fast QGZ format, and that has to go into a bioinformatic pipeline. So it's the one of the

18:49 key challenges is how we build that data. So Foundry 120 actually became a project that

18:54 started from sample tracking into data management and handling. And in 20, you know, in the last year

19:01 too, it's also become a platform where we can apply agentic AI into it to kind of accelerate

19:07 our workflows. Yeah, it's a really neat platform. And I'm definitely going to dive into it. I think

19:13 it's neat how you had this smaller bespoke thing and you're like, all right, let's sort of pull

19:18 out the essence of it and make it useful for all kinds of scientific research. Going back to the

19:24 samples. You said each one is five to six gigabytes. That's each of the 30,000?

19:30 Not all the 30,000. So a subset of them, but it depends on what essays were being run on which

19:37 samples. And there could be a ton of essays all running different types of samples. And each of

19:43 them will have their own data type that comes back. So for my cell-free DNA work, we ran it on a subset

19:51 of the population, not the entire population.

19:53 But for some of the other larger scale things like genotyping, we would genotype the whole

19:57 population.

19:58 So there are lots of moving parts and tiny little details here that cause so much operational

20:04 problems.

20:06 That's a lot of data.

20:07 Where did you, how much did you end up with at the end and how did you store it and manage

20:11 it?

20:12 So currently we have about 10 terabytes of data and we've only, you know, processed only

20:19 a fraction of those 30,000 is still being processed because some pipelines takes a human

20:26 12 hours to process a couple of samples. So there's still a lot of work to be done.

20:32 But yeah, it's about 10 terabytes of data that we're handling. And initially, it would be scattered

20:38 across our group. Somebody's doing a microbiome project, it would be on their laptop. Otherwise,

20:42 it'd be on a shared drive, on a file share somewhere in the university server. So data

20:48 tends to be scattered. So if somebody is doing a specific experiment, they might create an Excel

20:53 file with the readings from certain essays, and that would be the data set. And that's, I think,

20:58 one of the big problems that we face in biomedical research today. Yeah, that's a lot of data. Are

21:03 using things like blob storage? I know this Foundry 120 project is pretty strongly based in

21:09 the Azure cloud. Are you using Azure blob storage and stuff like that? Or is it really just all on

21:15 on-premise with regard to the university?

21:19 So back in the days, that was the situation that we were in.

21:22 But today, we're now migrated everything into Azure Blob Storage.

21:26 That just gives us a scalable way of not worrying, you know, how much space we had in our shared drives.

21:33 Because back in the days, you know, the university would give you a quota on your shared drive

21:37 and you have to email somebody in IT to get it increased.

21:40 So you might have a terabyte cap on your file share.

21:45 But with Azure Blob Storage, what you end up having is just a bill at the end of the month rather than hard limits.

21:52 You have a bill instead of a limit.

21:54 Yeah, yeah, yeah.

21:55 Interesting.

21:57 When I was working way back when I was in college, in university, working in this math research lab.

22:03 I told this story a couple of times, but it's been a while, so maybe I'll share it again.

22:06 And the whole of the math research department got access to the Silicon Graphics mainframe

22:14 beast of a computer.

22:15 We all had shared sort of workstation access to it.

22:19 And one of the students, grad students, was having a problem with their code.

22:24 And so they started logging out what it was doing.

22:26 And they got it into an infinite loop and ran it.

22:28 You would run stuff overnight and come see it in the morning.

22:31 We came back one day and it just wouldn't turn on or it wouldn't respond.

22:34 And nobody could figure out why.

22:36 The students, we had no, the reason I'm telling you this, we had no quotas, no limits.

22:41 The student used up the entire hard drive of the Silicon Graphics machine to the very last

22:46 byte, and apparently it needed a few temp files to operate the operating system.

22:50 And it just died.

22:51 And nobody could get it to come, it took a day or two for it to come back because somebody

22:56 destroyed it.

22:57 Well, these limits, they have a reason they're there, you know?

23:00 They do.

23:01 But when we look at the next five to 10 years of biomedical research, file storage is actually a big problem.

23:09 Is it? Okay.

23:10 Some of the newer technologies are generating like a terabyte of data for a single sample.

23:14 Wow. Yeah, that's absolutely crazy.

23:17 You know, this also goes to reproducibility and long-term viability of this research, right?

23:23 Because if you have 100 terabytes of data, it's one thing to say, well, here's the Excel file and here's the Parquet file and here's the Docker image that runs it.

23:32 Save that as a, you know, you can stamp these as like, here's what the paper was published on, right?

23:37 And here's the digital assets.

23:39 But when it's 100 terabytes, it doesn't matter if you can name it or not.

23:42 That's a hard thing to store.

23:43 Yes, definitely a big problem.

23:46 And I think the question then becomes what is the most valuable data that you store?

23:51 because perhaps you don't need to store the raw files and you want to process files

23:56 because who wants to run another 100 terabyte pipeline anyway?

24:00 But yeah, these are challenging questions.

24:01 There are no easy answers.

24:03 And most groups, we do cost our data storage, but for most grants, we cost it out for 10 years.

24:10 And beyond that, it becomes a challenge to maintain all this data.

24:14 Yeah. What are you going to do?

24:15 I guess the only bonus is in general that storage is getting cheaper by a lot.

24:21 And I say by in general, because the last couple of years or last year and a half, that's not true.

24:26 Yeah, I was going to say the AI revolution might not keep that falling price curve the same.

24:33 It might change things just a little bit.

24:36 All right, so let's talk about this Foundry project.

24:38 So this is sort of the next generation of what you maybe dreamed of building.

24:44 Also maybe a little bit in the agentic age as well, right?

24:47 Yeah, definitely.

24:48 Okay, so tell us about this Foundry 120.

24:51 So Foundry 120.

24:51 People will find it at foundry120.com.

24:54 It's a research operating system for translational science teams.

24:57 So I've got to explain that a bit.

24:59 So translational science is basically when you're trying to discover things by recruiting

25:05 humans with a problem and you're taking samples, bringing them back to the lab and running all

25:09 sorts of experiments to just kind of understand the biology behind disease and then find out

25:14 whether there are mechanisms that we can target for therapeutic development and things like that.

25:19 So that's kind of translational science.

25:21 And Foundry 120 is a platform that allows teams to operate seamlessly and use AI to accelerate their workflows.

25:29 It's built around three ideas.

25:31 The first idea is to organize everything.

25:33 So you organize your samples, your studies, your participants into a database

25:39 that just helps you keep track of everything.

25:42 And then the second bit is the idea of centralizing all your data outputs into a single platform.

25:47 So this will be things like clinical data, including radiology images, endoscopy videos,

25:54 digital pathology slides, and then the scientific outputs such as spatial transcriptomics,

26:00 genomics, microbiome, or all the data volume that we're seeing from all the different scientific

26:06 modalities are just going up exponentially. But as we know in the AIH, if you can bring all your

26:11 context into a single platform, then you can let AI connect to that and operate on that to answer

26:18 questions that researchers might have. So, I mean, I'll give you a concrete example. For example,

26:24 you know, if one of my scientific colleagues were looking for, you know, do we have any samples that

26:29 belong to a participant who's been treated with this drug? Can we find that? And historically,

26:35 what you would have to do is to take the clinical data set, join it with your sample database,

26:41 and then filter that through and find the samples that you want. And that usually would have taken

26:47 a couple of days to do. But this is a great use case, I think, for agentic AI, where you can just,

26:52 you know, access the data, put it into a sandbox, write the code to do the join, and then just give

26:58 you the answer that you want. So just eliminate all the steps in between and get you to the answer

27:03 faster. And that's the whole concept behind the platform. Sounds great. It's a really nice looking

27:09 web app too. What's its current status? It's available not just for you all, but for others,

27:15 but it doesn't have quite a just create an account, get started. So you have a request a platform

27:22 walkthrough. What's the situation here? Can other research teams use it? Is it a paid product? Is it

27:28 just sort of gated because it's not ready for people overwhelming it? So it's quite early stage

27:34 at the moment. So over the last six to 12 months, we've made the entire foundation generalizable

27:41 beyond just our group and beyond just disease. So what I mean by that is, you know, for another

27:46 group to join, they would need the access controls to be in place. So they need a way of managing

27:51 their team, being able to assign permissions to individuals, you know, without me having to do it

27:58 But I think more importantly is that onboarding a team into this platform is actually quite a hands-on process because it really depends on what data you're handling, the volumes that you're dealing with, what modalities of data you need to do.

28:13 And also the other major thing that we have to look at if you want to join the platform is the governance around your data.

28:21 So in clinical research, there are strict rules around how you handle data and where that data can sit, where can it be processed.

28:28 And these are subject to your research ethics approval.

28:33 So before a team can join us, we do want to review all those things to make sure that we're in compliance before anybody can join.

28:40 So that's the reason why it's not just a simple, you know, I can sign up, pay a monthly fee and start using the platform.

28:47 There's a lot more issues that have to be looked at before we can bring a team on board.

28:52 But we're willing to do the work to kind of review the situation and start getting other people access to it.

28:59 Makes a lot of sense.

28:59 You've got IRB research stuff.

29:02 You've got HIPAA and the equivalent in all the other countries.

29:07 And yeah, so you don't want to get in trouble.

29:10 Yes.

29:10 And you did mention earlier that this is quite tied into Azure at the moment.

29:14 And that's because we run on the University of Glasgow's Azure Tenancy.

29:19 So everything has to be located specifically for our studies within the UK data centers and things.

29:25 So we have all the controls in place to do that.

29:28 And that's backend infrastructure for the people who are listening on the podcast.

29:34 This portion of Talk Python is brought to you by Talk Python Courses.

29:38 Here's the thing that always bug me.

29:40 You finish one of our courses, that's hours of video, a pile of code you actually wrote,

29:44 and real skills you didn't have a month before, and then nothing happens.

29:48 No paper, no credential, nothing to show for it.

29:51 So we fixed it.

29:52 Every Talk Python course now generates a completion certificate automatically.

29:56 Go to your account page in your dashboard section, scroll down to your completed courses, and click Certificate.

30:02 That's the whole process.

30:04 Two things you can do with these course completion certificates.

30:07 download the full PDF, which is handy if your employer reimburses training or gives you credit

30:12 for finishing it. Or you can make the certificate public and hit share on LinkedIn, which adds it to

30:18 your LinkedIn profile under licenses and certifications. Not a poster that scrolls away

30:22 in a day, an actual credential sitting on your profile where your manager and recruiters can see

30:27 it. Plus, if you've been taking our courses for a while, you've probably earned several of these

30:32 without even knowing they existed. Just visit training.talkpython.fm/account and collect

30:37 them. Thanks to all of you who have taken a Talk Python course. It's a great way to support the podcast.

30:44 What a different time it is for universities. And I think they're going through a similar

30:49 upheaval, I guess is the word. When I was in university, and we're talking like 90s,

30:54 there was a giant Cray supercomputer or maybe a couple of supercomputers at the heart of the

31:00 university in some basement, and you could get access to that if you needed mega computing

31:05 resources. And now it's just scaled into some ginormous cloud infrastructure. And the limit

31:12 is really just how much are they going to give you, not what does the university have in its

31:16 basement or something like that, which is really interesting. Well, I mean, there are still some

31:21 universities that are trying to build their own clusters. But I think if you look at the economics

31:25 of it, it is way more cost efficient to be running on the cloud compared to on the cluster, because

31:32 many of the analysis that we do in the universities once off. So you might process a ton of data,

31:38 but that might be after a year or two years before you get that amount of data to process.

31:42 So if you look at a workload, the IT workload within the university, I think the cloud is

31:46 quite an attractive proposition. That's an interesting angle. Yeah, of course, because

31:51 you're going to process your samples. Maybe you're like, ah, we really want to try a different

31:55 algorithm and you'll run it all through again. But generally speaking, it's not steady state.

32:00 Whereas if you're going to go buy your own hardware and then put it in a basement and it's kind of a steady state situation, then you could really predict, you know, we're saving, you know, 50% less expensive to run on this.

32:11 And just, yeah, didn't really think about that.

32:13 And so I said, there's another such wave coming because this was, you know, when was the cloud?

32:17 The cloud is 10 years ago, 2008, I think.

32:21 A little bit, a little bit, really caught going a little bit after that.

32:25 But it's been a little while.

32:27 Now we've got all this AI stuff going and we're proving, you know, unsolved airdosh mathematical problems and all sorts of things, you know, with AI and other, you know, trying to do protein folding and other things that are really computational, but also really different.

32:45 And so I feel like this whole AI wave, especially the agentic AI, is going to roil what's happening at the universities all over again.

32:54 I mean, if you look at the data center economics around AI, it's quite interesting, actually.

32:59 Like a single rack from Nvidia is like a couple million dollars, right?

33:03 It's crazy.

33:04 And you need a power plant to plug it into.

33:07 I can't see any university building their own AI data center in the future.

33:11 So I think cloud adoption is inevitable in the sense that the economics of trying to

33:17 use agentic AI doesn't make sense to try and build your own AI computer, unless you have

33:23 specific governance requirements, which do apply to certain studies and certain aspects of work.

33:30 But even then, you might contract a local AI company to do it and then share it between

33:36 businesses and universities rather than having a university do it on its own.

33:40 Yeah. People talk about the AI bubble. I don't know if there's actually an AI bubble. This stuff

33:45 is so productive. The last bubble we had that was tech-related was the dot-com bubble. And there

33:51 was really stupid stuff with a lot of money spent on it you know like there's always the pest.com or

33:57 the weird investments you know thing and people are spending millions of dollars on ads to just

34:02 like have dancing monkeys running it was a weird time and this is also a weird time but I feel like

34:06 there's actually something legitimately at the core of it that is really changing the way people

34:12 work and and do research and so on so I don't know it's going to bust if there is a bubble and I don't

34:17 know if the bubble is going to burst. But if it does, I think that's also going to create an

34:22 explosion of local AI. You know, all of a sudden, right now, if you have to pay $100 for your

34:28 Anthropic subscription, that's totally reasonable. But if that becomes a $2,000 a month bill,

34:32 well, then buying a $10,000 workstation that can do legit local AI is all of a sudden a bargain,

34:38 you know what I mean? So it could be in the future that there's sort of a coming back to

34:43 local compute as well for AI, maybe. Yeah, I mean, the small models are getting more and more capable

34:48 as well. So not every workload needs a frontier model at the moment. So what you're saying is

34:53 probably true in the sense that there is definitely going to be a role for local AI.

34:57 I think Gemma maybe works this way, but certainly I can also see a world where there's kind of an

35:02 orchestration layer and then 100 or 50 specialists that get selected, right? Right now, if you ask a

35:10 frontier models to do something on genomics, it uses the same giant model as it would to use to

35:16 like write Shakespeare derived things. Right. But if you had one that just is trained on genomics,

35:23 you could have a much smaller model that could run locally and you could say, okay,

35:27 this part of the question goes to this, this sub model. And I don't know, it's going to be

35:31 interesting where it goes. And that let's, so coming back to it, let's, let's talk a little

35:35 bit about Foundry. There's a little demo you've got going right here at the beginning. Let me see

35:40 if I can go to the front of it. And maybe, I guess there's the stuff you talked about before,

35:46 the sample gathering and organizing and all that kind of stuff, right? And then on the back of that,

35:53 once you get it all done, there's this local tool using AI that understands all of your research

36:00 data. So maybe tell us about the data collection and the non-AI bit, and then it'll be fun to talk

36:07 about the AI because it's kind of non-standard. It's kind of powerful. Yeah, let's talk about the

36:11 data bit because that has been one of the most difficult problems I've been thinking about for

36:15 the last few years is how do we aggregate all these types of data sets into some kind of a common

36:22 model that an AI... Well, nowadays we can use AI, but it still applies to humans. So when my

36:29 colleagues are looking for data and trying to match, you know, data set A to B, what is the

36:36 way we do it? And at the end of the day, I think, you know, we've brought down everything to a model

36:42 where all data exists in files. So even tabular data, we keep it in CSV file. Well, historically,

36:48 we've tried to put, you know, tabular data into the database. But I think going forward,

36:53 we're just going to keep the files because that's the universal denominator. So whether you're

36:58 dealing with endoscopy videos, MRI images, digital pathology slides. Everything's a file, and each

37:05 file has each set of, you know, each type of data has its own file structure, but the common language

37:11 at the end of day is files. So we put files, and the thing that makes the files useful is putting a

37:16 layer of metadata and relationship data on top of the file. So I think by coupling the two of them,

37:21 we found this common model that can generalize across all the data sets that we use.

37:26 Very interesting. And, you know, to your point of just keep it in the files, you know, with things like DuckDB and other really cool things and Parquet files, you can kind of treat them like databases already. So I don't know if people know, but with DuckDB, you can say things like select star from read Parquet input, you know, which is pretty insane.

37:47 Yeah, Parquet is great. We use it as well.

37:49 Yeah. So also things like, what do you think about little SQLite files or DuckDB file where there's these just embedded no server databases?

38:01 And I think there's probably some really good use cases and research for that.

38:05 Potentially, you know, SQLite's a very interesting concept of having an entire database in a file.

38:13 But when I think of my end users, my colleagues who are running science experiments and such,

38:18 they're used to dealing with Excel and CSV files.

38:21 So we try to keep the same file format everybody's familiar with.

38:25 But I think for some of the future work that we're going to do, we can use some of these

38:30 more specific file formats.

38:32 Because as you know, if everything's a file, then an AI agent can run across all the files

38:37 and pull out the data that it needs for what it needs to do.

38:40 Yeah, absolutely.

38:41 Yeah, sure.

38:41 If you're giving them the files directly, here's either your Excel workbook or here's your CSV file.

38:49 But if it's coming in and out of a platform like Foundry 120, you can store it as one thing and then export it or import it as another, right?

38:57 Yeah. I mean, so fundamentally, what we do is that the files sit in Azure Blob Storage.

39:04 And when Helix, our AI agent, wants to process a file, it spins up a VM.

39:11 The file gets transferred from the Azure storage into the VM.

39:15 The AI sends its analysis code, whether it's in Python or any other language, into the VM.

39:21 The computation happens, and then we return the output to Helix and store the output back in Azure storage.

39:28 So by doing that, we put the sandbox guardrail around the AI agent for security purposes.

39:35 but it also allows us to enable the AI to do processing, generate new files, store it.

39:41 And I think that's the kind of model that works for us in Foundry while keeping it all within an institutional Azure environment

39:48 and also allows us to enforce all the role-based access controls that we need for our team members.

39:54 So when they query the AI, the AI can only see the same files that they would have normal access to.

40:01 And I think that's the design that's very specific for this because of the governance requirements that we have around the data sets that we use.

40:08 These AIs are sneaky.

40:10 They will find a way to access the files.

40:12 I mean, the really big headline cases are like, OpenAI was training its model and it hacked multiple systems

40:20 so that it could get to the answers on Hugging Face instead of just figuring out the, solving the test, right?

40:25 It's like a teenager that doesn't really care about the work is just doing it.

40:29 But what I was thinking was, you know, I was working with Claude and I had some question about my code

40:35 and it said something to the effect of like, oh yeah, you have two GitHub issues on this.

40:40 I never gave it direct access to GitHub.

40:42 I never gave it access to GitHub.

40:43 I'm like, how does it know that?

40:45 It's quoting like GitHub stuff, not through Git history locally, but it like reading the issues and the PRs.

40:51 I'm like, how does it do?

40:52 And then I realized I had the GitHub CLI installed and it's like, well, let me see if the GitHub CLI is installed.

40:57 Oh, and look, it's already automatically authenticated because Michael logged in at some point

41:02 to the CLI. And so it was just using the CLI that it's also, you know, like, oh, let me check that

41:07 on the server for you. I'm like, excuse me. Yeah. Yeah. On your production server, you're doing this.

41:11 How you're not supposed to be there. Why? And you know, it's just like, it's realized in the code

41:15 somehow it's figured out that it can SSH. So you got to be really careful about those things. Right.

41:21 Cause they're not malicious. They're just like, you asked me to solve a problem. And if I can get

41:25 to that, I got a better answer, more concrete data. And, but it could also go and we fixed the problem

41:30 by resetting the database.

41:31 Like, oh, no, you didn't.

41:34 Yeah, so for us...

41:36 So how do you do that kind of stuff in your project?

41:39 So it's the backend.

41:40 So Django enforces the permissions.

41:44 And actually, so when the AI stages data and stages code, that actually goes through Django first.

41:51 So the AI is not calling directly into the files, is not calling directly into a compute environment.

41:56 And then Django screens all that code and activates the VM.

42:02 So we've actually put Django in as a security guard between your AI and the raw data and the compute environments

42:11 that we run in.

42:11 MARK MANDEL: Oh, very cool.

42:12 So Foundry 120 is also written on Django, but it's more Django REST framework and TypeScript React.

42:20 Is that the story?

42:21 FRANCESC CAMPOY: Yep, that's right.

42:22 So on the front end, it's-

42:23 MARK MANDEL: Yeah, so tell us a bit about it.

42:24 FRANCESC CAMPOY: So the old app that we used to run off was just pure Django.

42:30 So we use Django templates to handle all the registration and the CRUD workflows.

42:36 But as we move into this age of AI, AI, as you know, is pretty asynchronous.

42:40 So every call you make takes, you know, sometimes it feels like forever to come back with a response.

42:46 And when we think about the async nature of all the calls that have to be made to run an AI conversation or agent loop,

42:53 TypeScript and JavaScript tends to come to be more suitable for that kind of application.

42:59 So we run both.

43:01 So we have TypeScript on the front end, Django on the back end.

43:03 I think it's a great setup.

43:04 It gives us access to the entire Python data science ecosystem, while also giving us all

43:10 the TypeScript and JavaScript ecosystem for handling all these asynchronous work and the

43:16 interactivity that we want on the front end when you start running AI applications.

43:20 Makes sense.

43:20 Now, what I'm about to ask you doesn't really make sense because of the AI angle and that

43:25 kind of stuff.

43:26 But if you think about scaling this out to other research projects and other groups, have you considered looking at things like PyOxid, Iodide, sorry, and things like JupyterLite for running some of that compute on the front end on people's browsers so that you don't have to basically pay the compute cost?

43:47 So that's an interesting question because now you're asking me about the compute architecture that we have in the backend, which is actually pretty heavy.

43:57 So we've mentioned that some of the files that we have might be gigabytes in size and the compute power you need to run genomics pipeline is pretty high.

44:08 So for a concrete example, so in the backend of our Foundry system, we have access to about 350 CPUs on Azure.

44:16 So if you ask Helix for a very heavy analysis, say on a big transcriptomic data set of something, through Django, we are able to orchestrate up a heavy compute job, which will then go off and run.

44:29 It'll spin up as many CPUs as it needs to, to process the job, and then returns the output later on once it's all done.

44:36 And that process can take half an hour, a couple of hours.

44:40 So it might come back really late.

44:42 And because of that model that we're running, actually, the kind of computational requirements we have is pretty high.

44:48 And so we don't really want to run compute on people's laptops.

44:53 We want to run it in the cloud to handle the data sets that we're dealing with.

44:57 So that's a very specific design choice.

45:00 And it's all to do with the kind of data that we're handling and the need to throw a lot of RAM and a lot of CPU at it.

45:06 Sure. And if your individual files are five gigs, that's a lot of just bandwidth costs.

45:11 So it's like every time you want to load something, you got to pull that five gigs out of the cloud, which has different costs and so on.

45:18 Right. Well, yeah. And many of the biological data problems are parallel.

45:22 Right. So you've got 200 participants each of five gigs.

45:25 You might as well spin up 200 machines and process all of them in parallel.

45:29 So all these problems that we have are very paralyzable.

45:32 And the cloud is a great platform to do that in because you can do it on demand, on the fly, spin it up, finish processing and tear it all down.

45:39 So minimal cost for, you know, maximum impact.

45:42 That's what we're going for in the back end.

45:44 Right. That's the bursting component that you talked about.

45:47 I do think JupyterLite is pretty interesting with the local Piodide execution and all that kind of stuff.

45:54 Just the fact that that's possible is it's pretty neat.

45:56 But yeah, I can see that it really doesn't apply for what you're doing here.

45:59 Well, I haven't talked to you about the front end of sample operations, right?

46:05 Because we're running a sample collection in the hospitals across Scotland.

46:11 And I must say the frontline IT infrastructure is not always the best.

46:14 So by having all our compute power on the server side, we can guarantee a speedy experience for our teams working at the front end.

46:21 So we're not depending on the front end's computational power.

46:25 I'll tell you what, my experience looking over the shoulder at the software that doctors and nurses use,

46:31 there's a lot of room for improving the user experience.

46:35 Oh, definitely.

46:36 I mean, part of the reason we went Django as well is because it was server-side.

46:40 And, you know, on the front end, you know, we have some computers I've used in hospitals.

46:46 They go back to 2010, right?

46:48 You know, we're running on Intel chips like 20 years old.

46:52 Oh, my goodness.

46:54 Yep. And there's a lot of Cisco, remote, whatever there. So let's talk about the AI side now. So we talked about the data, the data handling, some of the tech behind Foundry 120. But I think one of the cornerstones is this Helix AI. Now, when people think there's a bit of a problem here, Sean, like people talk about AI, and there's two or three different things it could be, and they all use the same word.

47:18 And they think they're talking about the same thing, but they're actually talking past each other.

47:22 You know, like I asked ChatGPT for this math problem and it got it wrong.

47:27 It's like, yeah, but we also built incredible software with this other thing that we also call AI.

47:32 And, you know, it's always right because it writes Python to actually answer its questions.

47:36 And yeah, it's just really interesting.

47:38 So there's an AI that you've mentioned a couple of times in here that will help researchers ask questions, find data, look for trends and those kinds of things.

47:48 And this, I think, you give me your thoughts on this, but my feeling is that it's a little bit like a Claude code or a codex.

47:57 One of these sort of tool using self-correcting AIs, not just a chat LL.

48:04 Yeah. So Helix is an agentic AI system. And I think the problem that you're describing is

48:12 because most people's experience of AI is chatbots. You go to chatgpt.com, you ask a question,

48:17 it gives you an answer. But actually the stuff that we're seeing that makes us think that AI

48:22 might not be a bubble is all this agentic AI stuff that we're seeing. So Claude Code, codecs,

48:27 agentic AI is a very different paradigm from chatbots, right? In agentic AI, the AI,

48:33 you give the AI a task, it looks at its tool set, it looks at what you're trying to do,

48:38 and then it goes away and works at it until it gives you an answer. And that's incredibly powerful.

48:42 Whereas I think, you know, 95% of people's experience of AI is almost like a Google search.

48:48 You go to ChatGPT and you ask, hey, what's the directions to this place or what's the recipe for

48:52 that? And therefore, there's this huge gap in understanding of how powerful agentic AI systems

48:57 can be. So Helix is really one of the, we think it's one of the first demonstrations of how you

49:03 would apply agentic AI in the science world. And a lot of the scientists that I'm showing this

49:10 system to, this is the first time that they're seeing an agentic AI system. So, you know.

49:15 What's their reaction?

49:18 I think everybody's quite excited. They're like, oh, that used to take me like months to do,

49:22 or it took me a lot of emails to do.

49:24 Just doing it in minutes right now, it's quite amazing.

49:28 And historically, every team member that's joined our team, I've had to sit down with them

49:32 and teach them how to use Python or R to get a graph out of Excel file or something.

49:38 And now you can just hand it off to Helix, let it do it, let it write the code.

49:42 And then what you do in this situation is that you've got to verify that it's correct.

49:47 So the work changes.

49:49 So instead of you as a researcher writing the analysis code, You get the AI to do the analysis for you.

49:54 And then what you have to do is verify that it is correct.

49:56 So it's a very different way of working.

49:58 But it's incredibly powerful.

50:00 It's much faster.

50:01 It's taken a lot of road work out of everybody's life.

50:04 So I think everybody's really excited about it.

50:06 I would imagine.

50:07 I'm going to have you talk us through just this sort of workflow that it goes through

50:10 real quick.

50:11 But that's the big danger is that it just hallucinates, which I don't know, that's a

50:16 weird word.

50:16 It's just it's wrong, whatever, about the actual data.

50:21 Do you all use RAG, the sort of training on the data, or is it just really the tool-using components that make it go?

50:30 It depends on what you mean by RAG, because we use tools to ground the AI.

50:36 Yeah, I'm thinking like going and actually retraining the model on the research files and data,

50:43 which I'm guessing from looking at it, it doesn't look like it.

50:46 It looks more of a Claude Code tool-using style.

50:49 Yeah, it is more Claude Code style.

50:52 we don't train the AI specifically for it.

50:56 We can swap the base models as newer versions come up.

50:59 Because if supervised fine-tuning or doing some RL on a base, LLM will cost you a lot of money.

51:09 And it's not generalizable, right?

51:11 Yeah, and you need the data to train it on.

51:15 And that's not easy to make as well.

51:18 So yeah, so given the rapid progress, we want a model where we can just update to the latest model

51:23 and just leverage the latest changes that the big labs are coming out with.

51:30 Amazing.

51:30 I think that's the right way.

51:31 So if you go to foundry120.com, there's a one-minute little screencast, silent screencast of it going.

51:38 So I'm going to, Sean, I'm going to hit play and you kind of just narrate what's happening.

51:42 I think that'll give people an interesting sense of what this thing is about

51:45 and give us some talking points here.

51:47 So we asked Helix, you know, what plasma samples do we have for the music study?

51:51 And can you break them down by disease groups?

51:53 So to get to that answer, you need to join the clinical data frame with your sample database.

51:58 And then you got to work out which samples are unused, you know, what sample type it is.

52:02 And then for the disease groups, it's got to inspect the clinical data frame and figure

52:05 out how many disease groups do you have in your disease column.

52:08 And then you've got to do the join and the grouping.

52:11 So in this demo, it's gone ahead and done it.

52:14 And it will come back and tell you, well, within our database, we've got like 4,000 samples belonging for Crohn's disease patients and 2,000 with ulcerative colitis.

52:23 Yeah.

52:23 And since people are just listening, let me just go back, just narrate really quick, like fill in a little background visuals.

52:29 You can see it.

52:29 It'll, using the different tools, it'll be like, get sample and it'll run for a second.

52:33 Then it'll write some Python code to do a thing.

52:36 And then it'll do some more data access and then some more code.

52:40 So it's primarily orchestrating a bunch of the tools and the code writing that it already knows, right?

52:47 It's not just reading 100 terabytes of data or whatever.

52:51 No, you can't read all that data because the context window of your AI is limited.

52:57 So you can't just dump all the raw Excel file into the AI and say, five video samples.

53:03 Yeah, exactly.

53:03 I mean, even the really big ones have a million context right now.

53:06 All right, carrying on.

53:07 So then it's off to get a picture, right?

53:09 So the next question, we've asked it to do some graphing.

53:12 So we've asked to plot CRP, which is a blood test against cell-free DNA,

53:16 which is a scientific experimental output.

53:19 So to do this, it's got to go and find your clinical data frame and join it with your science data.

53:24 And it comes up, writes some matplotlib code and gives you a graph back and tell you what it found.

53:30 So that's what it does.

53:32 In this second segment, the AI runs into an error and it recovers from the error.

53:38 So the AI is able to read the output of the tool, correct, it's working and come back to you.

53:42 So that's just a demonstration of how an agentic AI system looks like.

53:46 Yeah, good narration.

53:48 And people can go and play that for themselves.

53:49 But I think that's the big difference between what you're saying, just the chatbot as kind of a better Google, right?

53:55 It's not that much of the AI thinking.

53:57 It's a whole bunch of the AI using the tools.

54:00 And the tools are deterministic, right?

54:03 The tools are deterministic.

54:04 And actually designing the tools is one of the most challenging things to do is like,

54:09 how many tools do you expose?

54:10 What should each tool do?

54:11 And what's a logical set of tools?

54:13 And how do you make sure that the AI picks them correctly?

54:16 So I think tool design itself is a huge topic of how you do it.

54:22 But because the tools run on the backend, we can then enforce the RBAC controls on the

54:26 tools itself.

54:27 So you can guarantee that your data access is, you know, security around it is solid.

54:33 Have you thought about adding an MCP server to it?

54:36 So then people can just within their own AI or whatever, just, hey, what does Foundry say about this?

54:42 Yeah, MCP is interesting.

54:44 But I think one of the limiting things for us using MCP is the governance around it,

54:48 in the sense that we are not allowed to just put data into a Claude Code and send it across to Anthropic.

54:55 Whereas within this system, all inference happens in Microsoft Azure and it's GDPR compliant,

55:01 which in the UK is important for us from a research perspective.

55:06 So in this...

55:07 It's also important.

55:08 It applies to the US companies as well, if they have European customers.

55:12 Yeah, so because of regulatory compliance things, we need to make sure that we know where the inference is running

55:18 and we can guarantee that inference all runs within us, you know, because we have got the platform controls of Azure,

55:23 we can guarantee where everything happens.

55:26 And that allows us to actually let the AI safely operate on our data.

55:29 I see.

55:29 So maybe you're using a data center in Ireland for your data so it doesn't leave the UK or

55:34 something like that.

55:35 Yeah, we run most of the things in the UK South data center.

55:38 For EU compliance, we run it in the Sweden data center.

55:41 So that's where everything happens at the moment.

55:44 Yeah, that makes a lot of sense.

55:46 Let's zoom out a little bit.

55:48 You've been working on this project for six plus years now.

55:51 You've taken it from working with books to write the Django app to integrating to the

55:56 cloud, Microsoft Foundry, and Azure, and all this tool using AI. What do you see for research,

56:04 either happening now or in the next couple of years with all this kind of stuff coming along?

56:09 Yeah, I mean, I think, you know, we're all very excited about the potential of agentic AI to

56:14 accelerate a lot of the research workflows that we see. And, you know, hopefully, you know, we get

56:20 to discoveries faster because drug discovery is a very long process. And I think agentic AI has

56:27 absolutely a role to play in shortening some of these bottlenecks that we face. So I think it'd

56:35 be very exciting to see. I think agentic AI is going to transform how we do science, how we operate

56:41 also in the clinical world. So I see a lot of potential, but the real world is going to take

56:46 a while to catch up to where the capabilities are today. So I think most people on this podcast

56:52 would have used coding agents, but I can tell you that almost everybody else in the population has

56:58 never touched a coding agent. So the gap between what agentic AI systems can do and what everybody's

57:03 understanding of AI is still very wide. And there's still a lot more work to do to teach people how to

57:09 use the systems, what they're capable of, where the limitations are, and how do you apply it to your

57:13 work. Do you think it can be reliable? Like, do you think we can trust the results and answers

57:18 we're getting from things like Helix and other tools that are working on us? Well, hopefully,

57:24 as things improve over the coming years, the reliability will go up. I mean, personally,

57:30 you know, the coding agents are still not 100% reliable. You know, even like the best models,

57:34 like Opus and Fable, they still can make mistakes. So we're not quite past the reliability threshold

57:40 yet. So we do have to be aware. And I think understanding what you're trying to do is

57:46 actually very important today compared to, say, five years ago, because you have to really

57:50 understand what you're trying to do to be able to supervise an AI to do what you were going to do.

57:55 I totally agree with what you said. But the alternative is to have a human do it.

57:59 And humans are also not 100% reliable. There's recently been this dust up with the Linus Torvalds

58:05 over about using, I forgot the name. There was some AI that they're using as a pre-screen for PRs

58:12 for the Linux kernel. And some people were like, we're not using it. And it's like, look, this thing

58:16 is at least as good as the people often doing it. And it's an accelerator. And there's that tension

58:22 of people expect, I think because it's a computer, people expect it to be perfect, right? Because

58:27 software is typically deterministic. So if it works once, it's always going to work. And AI isn't like

58:33 that, but people also aren't like that. Yeah, that's right. I mean, like, you know,

58:39 certainly everybody, you know, having an AI by your side is like having a colleague on your team,

58:43 except this colleague can write code like tremendously faster and much better than most

58:47 people. You know, today I would say that Claude Code and codex can write code way faster and way

58:53 better than me, but you still need that kind of strategic view from the human to just make sure

58:59 that you're going on the right path because you got to drive the AI and you've got to direct it.

59:04 And it's the same with the scientific work.

59:06 So I tell my scientific colleagues, you need to make sure that the answers

59:09 that come back pass the smell test.

59:11 You need to make sure that, you know, the numbers that you're seeing are in line with your expectations.

59:16 You're expecting a number in this magnitude range and you get it there because sometimes the AI goes off

59:20 and does funny things, right?

59:21 Yeah, I just, you know, if you ask it to verify everything and prove it and write code to back it up,

59:27 like it's better than if you just ask it You know what I mean?

59:29 Like there's techniques, but you do have to treat it with a little bit of skepticism.

59:34 But that's also true for your colleagues and your grad students and whatever, right?

59:38 Like no professor would just take a, like, hey, grad student, write the paper.

59:42 And they don't even read it.

59:43 They just publish, they just send it off to nature or medicine or write the medical journal or whatever.

59:49 I mean, it depends.

59:50 I think for disposable stuff, you can let the AI do more of that.

59:53 But for the real critical workflows, you want to make sure every single step is correct.

59:57 Yeah.

59:58 All right.

59:58 Well, that brings us to our final call to action.

01:00:01 If scientific researchers or medical researchers are out there listening,

01:00:06 either what can they learn from your experience or if they wanted to work with you on some of this, what would you say?

01:00:12 So one of the big questions and why we're putting Foundry out there is we don't know how generalizable it is

01:00:17 or whether it's just going to be hyper-personal software for ourselves, our team.

01:00:21 But I think the general principles, I've shared them widely.

01:00:25 So please feel free to just take the idea and run with it.

01:00:28 I'm very excited to see what other people can do with the ideas.

01:00:32 And perhaps within their own institutions, they might want to build their own systems.

01:00:35 And I think that's absolutely valid.

01:00:37 But if you do want to explore a partnership with us, come and visit us on foundry120.com

01:00:42 and drop me an email.

01:00:43 Yeah, great.

01:00:44 And I'll link to your web page.

01:00:46 You've got email and your GitHub and other ways to get in touch with you there.

01:00:49 You also have a lot of interesting writing here, so people can check that out.

01:00:53 Yeah, that was my journey into coding, really.

01:00:57 Yeah, we all have one of those journeys to tell the story of.

01:01:00 Well, Sean, thank you so much for being on the show.

01:01:02 Keep up the good work.

01:01:03 I think this is a super interesting project.

01:01:05 Thanks very much, Michael.

01:01:06 Very happy to be here, and thanks for the invitation.

01:01:08 Yeah, you bet. Bye.

01:01:09 Bye.

01:01:11 This has been another episode of Talk Python To Me.

01:01:13 Thank you to our sponsors.

01:01:14 Be sure to check out what they're offering.

01:01:16 It really helps support the show.

01:01:18 This episode is brought to you by Sentry.

01:01:20 You know Sentry for the air monitoring, but they now have logs too.

01:01:24 And with Sentry, your logs become way more usable.

01:01:27 interleaving into your error reports to enhance debugging and understanding.

01:01:31 Get started today at talkpython.fm/sentry.

01:01:35 And it's also brought to you by Talk Python Courses.

01:01:38 Course completion certificates are now live.

01:01:41 If you finished a course, there's a certificate waiting for you on your account page right now.

01:01:46 Download it as a PDF or add it to your LinkedIn profile with one click under licenses and certifications.

01:01:52 Same section as your formal degrees.

01:01:54 Visit training.Talk Python.fm slash account to see what you've already earned.

01:01:59 And if you're not already subscribed to the show on your favorite podcast player,

01:02:03 what are you waiting for?

01:02:05 Just search for Python in your podcast player.

01:02:06 We should be right at the top.

01:02:08 If you enjoyed that geeky rap song, you can download the full track.

01:02:11 The link is actually in your podcast blur show notes.

01:02:13 This is your host, Michael Kennedy.

01:02:15 Thank you so much for listening.

01:02:16 I really appreciate it.

01:02:18 I'll see you next time.

01:02:30 I'm out.