Building the future of collaborative AI development with Akshay Agrawal of Marimo

All right. So, Akshay, I'm a fan of your product and a user of marimo, and I'm sure this is going to get super in the weeds for marimo users shortly. But I wanted to keep at least the first few minutes of this recording accessible to more people. Maybe we should start with: What is a notebook, and why is a notebook important in the AI field?

Yeah, 100%. I view a notebook—and, in particular, most notebooks these days are in Python—as a programming environment that allows for interactive computing. It lets you have blocks of Python code and visualize the output of each block of Python code. You can have plots, visualize your tensors, and visualize training runs. You can interleave your code and visuals with Markdown that documents the exploration, experiment, or whatever you've done.

For data work in particular, whether you're training a machine learning model or querying databases, it's really valuable to have a programming environment that lets you see your data while you work on it. For this reason, notebooks are widely used across the sciences, but they're also widely used to train machine learning models. They're the central interface for compute in a bunch of products, like Google Colab, Databricks, and AWS SageMaker.

I think it speaks to the fact—and this is one of the theses behind Weights & Biases—that the workflow of someone building an AI model is sort of different from a developer workflow. It's more exploratory. You write a lot of code that might not see the light of day or need to be production-ready. A lot of the code you write is to learn what's going on with your data, what's going on with your model, and things like that, right?

Yeah, 100%. Jupyter notebooks are kind of the place where I started. Colab is a little bit different, Streamlit is a little bit different, and marimo is a little bit different. Maybe you could talk about how you thought about marimo and how it fits into this world of notebook variants.

So, to set the stage, I can briefly say what marimo is and how it's different from Jupyter. Marimo is an open-source Python notebook that's built from the ground up to solve what I view as key problems with Jupyter notebooks in particular. Unlike Jupyter, marimo notebooks are reproducible, Git-friendly, and deployable as interactive web apps. You can also execute them as Python scripts.

With marimo, Miles, my co-founder, and I are really trying to blend the best parts of interactive computing with the rigor and discipline of traditional software engineering, as well as the developer experience associated with engineering. You can think of marimo as a modern replacement for Jupyter, but also for Streamlit.

What do you mean by reproducible?

There are 2 types of reproducibility. There's an interesting study by JetBrains where they took 10 million Jupyter notebooks from GitHub, downloaded them all, and studied whether rerunning them from top to bottom would produce the same results that were serialized in the notebook. Over a third of them weren't reproducible, meaning you would get different outputs.

There was another paper from 2019 that did a similar study and found similar results. In my own experience, when I was at Stanford doing my PhD, my co-authors—who are amazing, great people, but not software engineers—would hand me a notebook and say, "Here's my code." I would run it and say, "I can't reproduce your science."

I think there's a reproducibility crisis in that the code on the page doesn't necessarily match the outputs you see in Jupyter notebooks. That's specifically because a Jupyter notebook is really a dressed-up REPL, like a Python REPL. It's just code that you executed and the output at the time, but it doesn't capture the execution history in a meaningful way.

1. The vision behind Marimo

That's one kind of reproducibility, and it's the biggest kind. The other kind, which we can talk about later, is package reproducibility. You may run an experiment without having all the packages you used documented clearly, so others can't reproduce your environment.

No, I mean, the initial experience of marimo feels a lot like a notebook. What's different about what's going on that adds reproducibility?

Marimo provides the user with a guarantee: the code on the page matches the outputs you see. The way we do that is that marimo looks like a notebook and feels like a notebook, but it actually has code intelligence built in. When you run 1 cell, all other cells that refer to the variables defined in that first cell are automatically run.

It's reactive, not unlike a spreadsheet. That means that if you edit 1 part of your notebook, you'll see downstream cells updating to stay in sync with your code.

But it's only the cells below, right? It doesn't update the cells above as well?

It updates cells above as well. We statically parse all your cells, define the dependencies across variable definitions and references, and form a DAG from them.

How do you keep it acyclic? Couldn't there be circular dependencies here?

There's a contract between marimo and the user, and 1 of the rules is that you can't have cycles. We can detect that, so if you type in code that introduces a cycle, we won't let you run it. We'll say, "Hey, you have a cycle. It's across these cells. Here are some suggestions on how you can fix it."

I see. What about the other part of this? What makes notebooks not compatible with Git? Is it the giant files with the output included that make it annoying for Git? Is that what you're talking about?

Yeah. They typically use JSON files to store the notebook code and the outputs, and you get this giant blob. You make a small code change and get a giant diff. Marimo notebooks are pure Python, and we guarantee that small code changes yield small diffs.

That makes sense. What are your thoughts on Streamlit? When Streamlit started, it was an exciting new thing that added interactivity to notebooks in a really cool way. You had the Streamlit founder on the podcast and talked about what he was thinking at the time. What's your take on Streamlit? Why isn't it a satisfying solution to some of these problems?

Streamlit is a really cool project, and I think there's a reason it took off so quickly: data scientists and machine learning folks hate writing any front-end code. The interactivity was really delightful.

But what's special about notebooks, as you mentioned earlier, is that they're great environments for exploring your data and interactively prototyping algorithms, querying databases, and so on. Streamlit isn't designed for that. Streamlit comes in when you've finished building those things and just want to create an application.

What I noticed is that a lot of Streamlit applications, if you go to the GitHub repository, have a Jupyter file and then a Streamlit file, and it's a direct port. Marimo bridges that gap. Every notebook can be seamlessly run because we understand the relationships across cells, and marimo ships with a bunch of interactive elements, like sliders and data frame transformers.

I took some inspiration from Streamlit. From the command line, you can say, "marimo run my_notebook.py," and it will hide the code and run it as a web app. I think the reason Streamlit doesn't solve the full problem is that you can't start your data work in a Streamlit file, whereas you can in marimo. You write 1 line and it's going, and you're seeing the results.

Is that what you mean?

More or less. In Streamlit, if you interact with a slider or something, it runs your whole script from top to bottom. In marimo, we have a very granular DAG, so when you interact with the slider, it only runs the cells that depend on it. You still have that fast, iterative, interactive programming environment that I think many people have become familiar with after using Jupyter for so many years.

That makes sense. Anthony Goldbloom was talking to me about his use of marimo, and I think he has the same workflow: He has notebooks and then puts them into Streamlit. He was so excited to avoid that step in order to publish things. He told me it went from 6 hours to 5 minutes to deploy, and I was like, "How is that possible?" Then I realized that you're translating notebooks into Streamlit, and now, with marimo, you clearly don't have to. You just get it for free.

Is adoption something you're intentionally trying to grow, or do you feel like you make the best product and it's naturally viral because people share it as a notebook and then use it? Do you have growth hacks you're using to drive adoption?

We're trying to do both. In the past couple of months, we've been leaning into the natural virality, and people have started to share their notebooks more. We recently did an integration with Hugging Face, so it's really easy to deploy your marimo notebooks as apps on Spaces. We also have a WebAssembly-powered playground where you can create unlimited notebooks for free and share them with a link.

In the early days, we started to spread through a post on Hacker News. Some of those really took off. Our Show HN post is the second-top Python Show HN post if you drill down. We got a lot of users initially through Hacker News. We haven't done too many growth-hacky things, probably because we're not expert growth hackers.

I feel like when Show HN works well, the comments can be mean. Was there pushback from the Hacker News crowd?

We were actually lucky. People were really quite nice.

That's good to hear.

2. Collaborative tools for AI development

Simon Willison, the creator of Django and now doing a bunch of cool projects with datasets, commented and was really positive. Maybe that set the tone or something. I'm not sure. People are pretty nice.

One thing I noticed about your background is that you spent a little bit of time at Netflix. Is that right?

I did an internship there.

I was thinking that Netflix famously ran a lot of its production stuff on notebooks, or at least that's what people were saying 4 or 5 years ago. Was that still the case when you were there, and did that inform any of your thinking about marimo?

I believe it was still the case when I was there, but I actually wasn't in that part of the organization. I was more on the algorithms engineering side, so I probably used 0 notebooks during that internship. It didn't really inform my thinking too much. I think they managed to make it work, but the way Jupyter is set up, you have to jump through a bunch of hoops to make that work. It is cool that they were able to.

Most of my inspiration came from 2 projects. One was a project from the Julia language called Pluto.jl, which is an alternative to Jupyter that shares a lot of similarities with marimo. Marimo, by extension, is modeled after that, as well as Streamlit to an extent.

Interesting. What did you pull from those projects? Tell me about that.

I pulled a lot from Pluto. Pluto is a reactive notebook for Julia that has the same spreadsheet-style automatic execution. It lets you create sliders and other UI elements seamlessly. It also has built-in package management, as marimo does, so that your notebook files are a self-contained, reproducible unit.

I saw Pluto in late 2021, after I had just finished my PhD. I thought, "This is an amazing project. People are switching from Jupyter to Pluto." It's the most-starred GitHub repository for the Julia programming language, aside from Julia itself. I immediately thought, "We need something like this for Python."

From Streamlit, I saw Pluto and thought, "Wow, these things look like web apps." Then I saw Streamlit and thought, "These things are web apps." I realized you could merge the 2 together and have a single notebook-like thing that lets you do the notebooking and also create data apps.

Are you a fan of the Julia language? How did you find yourself working with Julia notebooks?

I admire what they're trying to do. I used Julia a bit a long time ago during my undergrad. I did math and machine learning at Stanford, as well as computer systems, so the idea was really appealing: to have a single language that bridged the gap between usability and performance.

I think it's still a relatively new language, so it has some things that make it difficult to adopt. I wasn't using Pluto notebooks at the time. At the end of my PhD, I did a broad survey of different tools for working with data. I just wanted to see what people were working on. I went down some rabbit holes and somehow found Pluto. I immediately fell in love with the project.

Were you doing that survey because you thought, "I want to start a company doing tooling for machine learning"?

That's right. I used to work at Google Brain, where I worked on TensorFlow. During my PhD, I did machine learning and optimization, but a huge part of it was open-source tooling for machine learning and optimization.

I realized that what I like most is building developer tools that let other people solve problems instead of solving the problems myself. That's why I did the survey. I wanted to see how I could use my systems background and my machine learning background to make the biggest impact.

What else did you look at? What other rabbit holes did you go down in that survey?

I should pull up my Obsidian vault. It's pretty gnarly. One area was making it a lot easier to access cloud computing, in a few different directions. One was improving provisioning. I think Modal and the folks from the Sky Computing Lab at Berkeley are doing this really well now. Every PhD student feels like it's absurdly difficult to run something in the cloud. You just want to ship 1 function there and run it on a GPU. It's cool to see that happening.

The other area was related to what I did at Netflix: studying cluster management and optimizing cluster usage to minimize cost and maximize utilization. I think a company called Antimetal and probably a few others are doing this now.

How did you choose notebooks?

There was the systems part of me that was really attracted to these cloud-computing problems, but there was also the part of me that likes designing for humans and individuals, which was really attracted to the notebook project.

3. Challenges in scaling AI workflows

Ultimately, after watching a bunch of people—and myself—do research and work with data, I saw that a lot of it starts in notebooks. People love notebooks, but they also kind of hate them. If you search Reddit for "Jupyter notebook," you'll find people complaining about hidden state, the JSON file format, and so on. People feel strongly that something better should exist, but nothing did.

Once I saw Pluto, I thought, "Okay, there is a way to make something better, and this will have a huge impact on so many people." To me, it was clear that this was what I should do next.

It's funny. I remember seeing an interview with the founder of Jupyter notebooks, and he was talking about how he was inspired by Mathematica, which I remember from my math undergrad at Stanford. I don't know if people still use it, but it had some more delightful features where you could do more complicated inputs than just a linear block of code.

I'm curious if you've experienced Mathematica or view that as an interesting kind of notebook.

Embarrassingly, I haven't, probably because I was a computer science major and a math minor. I do know that some of the folks in the math department who come from more of a math background still use Mathematica. I'm sure marimo has the imprint of Mathematica on it, but probably indirectly, through its impact on Jupyter. I guess marimo is a grandchild of Mathematica in that case.

I want to ask you about real-world use cases. One of the really cool things about what you're doing is that it's so broad. What are some of the interesting things people are doing today with marimo?

That's 1 of the fun things, because it is so broad. You mentioned Anthony Goldbloom. He identifies 1 persona, and there are many people like him who first use a marimo notebook to explore some data. Ultimately, what they end up with is a little mini-app—a reusable tool they can use daily to do analytics work or some kind of internal task.

That's probably the Streamlit-style application: creating tools for yourself and your company to do analytics and other things. What's interesting is that these users don't just interact with data. I've also had software engineers reach out to me who have never used notebooks before and never wanted to, but marimo appeals to them because of the developer experience. They're using it to manage and build a dashboard for their EKS cluster or something like that.

I'm surprised to hear that, because I feel like the first interaction with marimo is just a notebook. At least for me, it took a little while to notice what the difference was. Are notebooks so offensive to software developers? It's hard for me to imagine that.

It's surprising. A number of people come into our Discord and say, "I haven't ever used a notebook." When we try to put that in context and ask them about it, they're like, "I've never used notebooks, and I never wanted to."

I think maybe it's because we mention that it's Git-friendly and stores everything as pure Python. Software developers think, "Okay, cool. I can work with that."

Actually, as a bit of a tangent, I'm pleasantly surprised—but really quite surprised—by the extent to which Git-friendliness has brought in users. I thought it would be the reproducibility, the super-duper interactive elements, or the fact that if you output a data frame in marimo, you automatically get a filterable, searchable table. You can page through the whole data set, not just see a tiny static HTML preview like you get in Jupyter.

I thought that would be the thing that brought people in, but I keep hearing over and over again that it's the Git-friendliness. I gave a talk at NYU in a business analytics class last week. I talked about all the data-related features and how we have built-in support for SQL. At the end, the professor said, "I'm going to use this because it's Git-friendly." I'm so surprised.

I've used notebooks for years and Git for years. I feel like the execution model of marimo is really cool, and deploying to the web is super cool. I didn't even notice the Git-friendliness. I don't know. I guess people are freaking out about big diffs in their notebooks.

4. Innovations in model evaluation and iteration

How do you actually handle that? Do you not store the output? What if the output is a giant table? How do you handle it?

We don't store the output, but we have an option to store the outputs alongside the notebook. They're just in separate files, and you may not track your HTML files with Git. If you did, you would know to ignore the diff, and you could at least see the code diff without having to run it yourself.

That's why we have that snapshotting feature. There's sometimes a nice experience with a notebook of looking through it without having to run it yourself.

A lot of people come for the Git-friendliness, but then they stay for all the other goodies they discover along the way. They discover the execution model, the interactive elements, and all the other things.

I talked to someone else who does business analytics, I think at Capital One, and she was also like, "Oh yeah, the Git-friendly." I think she was traumatized by having to deal with Tableau dashboards where you have no idea of the provenance of what you're looking at, and if an audit comes, you get really scared. I'm going to stop talking because I don't know anything about that field, but totally. That was a tangent. You were asking about use cases.

BI is an important use case for you, but I meant more practically: What are some real stories of people using it in interesting ways?

Anthony is building his little mini-apps. He calls them mini-apps. A lot of people use marimo as just a better Jupyter notebook, so everything you would do in a Jupyter notebook—whether it's munging data frames or training a machine learning model—people will use it for that workflow. They'll find that the reactive execution and UI elements, like sliders and drop-downs, make them much more productive.

The simple experience of having a data frame where you can type into a search box and get filtered results in real time is a big step up from the experience you have in a Jupyter notebook.

A lot of our users get a little scared when they first hear about marimo, especially machine learning folks, because of the automatic execution. They're like, "I don't want to accidentally kick off a training job on GPUs, or hit my OpenAI endpoint."

We let you configure the runtime to be lazy. If you execute a cell, the downstream cells will be marked as stale, with a visual cue, but they won't automatically run. There's a button to bring them back up to date. People do use marimo for more expensive computations as well.

Tell me how you think about AI coding inside marimo. Another notable difference that maybe you don't highlight as much is that you have code generation built right into the application. It seems like the code generation looks at your data as well as the code, which is cool for data-centric applications.

We have built-in AI integrations. We try to be batteries-included across a lot of dimensions. There's built-in support for GitHub Copilot and Codeium. If you bring your own keys, you can generate code using the context of your notebook, as well as the schemas of your data frames and your attached DuckDB tables.

We should probably highlight that more.

Yeah, we should. I was talking to Anthony at a table, and he was talking about another product. He said, "What's really cool is that I told the product to generate some Matplotlib code and then change it to Plotly, and it did." I said, "You can do that in marimo." He said, "What?"

So we should highlight it more.

It's funny. I started doing notebooks and Streamlit inside Cursor because it was so fast to develop, and I was used to the coding tools. Could you also develop marimo inside VS Code or something like that? Is that a common pattern?

We have a VS Code extension that does a split-pane kind of thing. You can type in the code cells on the left, and it automatically runs the notebook UI on the right. I think we have some more work to do to make that feel seamless.

It's a little tricky because our editor has so many features. It's not quite an IDE, but it almost is, with the data explorer panel, live documentation, and built-in AI features. I feel it's best experienced in the marimo editor. People do ask, "Can I use it in Cursor? Can I use it in VS Code?" The answer is yes.

5. Real-world applications of collaborative AI platforms

I'm feeling the growth team telling me that this podcast is going off the rails, so I'll take it further off the rails and ask my own tech-support questions. One of the great things about Cursor is that you're chatting. Marimo doesn't feel oriented toward chat-based code generation. Is there a way to ask it more broadly, "What's going on, and can you fix this up?" Maybe, as Anthony was saying, "Convert Matplotlib to Plotly," or something like that?

You can do that on a per-cell basis. You can refactor the cell. As we build out our roadmap for the next year, part of it is IDE features, and part of that would be more modern AI features, such as a Cursor-like experience.

What else is on your roadmap? How do you even think about it? Are you a 2-person organization now?

We're 2 people. We did raise a seed round, which I just announced this week.

Congratulations.

Thank you. We're looking to grow the team, but it's just been Miles and me.

There are a lot of things we want to build. Some of them are better, more thorough integrations with SQL. I mentioned that marimo supports SQL. Marimo is pure Python and is stored as pure Python, but you can embed other languages in it. One of those is SQL, and we actually build a data-flow graph across both Python and SQL. That could be a conversation for a whole other podcast, but the point is that in your SQL, you can query data frames and get a data frame out. This is powered by DuckDB.

One thing we want to do is build out that experience more: make it easier to connect to other types of databases, whether it's Postgres or whatever you're querying, and have richer column previews so you can explore all your data at a glance without having to execute queries—or without having to execute very many queries.

Another part of our roadmap is exploring some of the infrastructure-side things I mentioned earlier. I think there are interesting things related to hybrid execution. A common model is that a lot of your notebook code can be run locally, except for some really expensive cells that you may want to ship off to remote servers. We're looking at making it easier to run expensive workloads.

We're also looking at better support for making it really easy to share marimo notebooks in 2 ways. We're building out a Community Cloud, which is free because it's powered by Pyodide and WebAssembly, meaning it runs entirely in the browser. We may also look into static-site generation, so that in your MkDocs or Sphinx documentation, you'll have marimo notebooks running with live code, interactive widgets, and all those things.

That tees up an obvious investor question. Streamlit was sold for a lot of money, but it was sold before monetization, or just as they were starting to monetize. I don't know if they ever really got to meaningful monetization. Jupyter notebooks are obviously an incredibly successful project that was never intended to be monetized.

It seems like we haven't quite figured out the right monetization model for this type of thing. How do you think about that?

I think the way marimo is different from Streamlit is that Streamlit usually came in at the very end of a data project, for the small fraction of projects where you wanted to deploy an app. Maybe Streamlit was focused primarily on the app deployment.

What's compelling about our product is that marimo is where you start. It's where you first start querying data, where you first start training a model, and so on. You can also carry it all the way toward a data app.

I also mentioned earlier that notebooks are the central interface to compute in a lot of commercial products, like Databricks and Hex. I think there may be an angle for us to lean into there as well. The surface area of the user workflow that we can monetize is much larger than Streamlit's, and larger than Jupyter's, which intentionally started as a nonprofit and had no intention of going into these infrastructure-type problems.

Did you ever consider structuring it like that, or were you always saying, "I want to be a venture-backed startup"?

I didn't really consider that. You can just build a lot faster by working on it full-time with a bigger team, so I was thinking about a startup from the beginning.

I did start with Miles and really focused on crafting what I think is a delightful product. We started with funding from SLAC National Accelerator Laboratory, which was enough for the 2 of us for 2 years.

This is the linear accelerator?

Yeah, exactly. There were some scientists there. I was having coffee with 1 of them one day, and they knew me from my PhD. They asked, "What are you working on?" I said, "I want to build this notebook thing that also lets you make apps and run scripts." They said, "That's really cool. We really need that. We use Jupyter, and it has so many problems. We'll pay you to do it."

I said, "That sounds good." We worked with them for 2 years, and they gave us a lot of early feedback before we open-sourced it. That was really essential for us to make a product like this.

Marimo feels like such a delightfully simple thing, but I'm sure there's so much thought and work that goes into it. Have there been tough product choices along the way, or paths you went down that turned out to be dead ends?

There have been a few. There are definitely tough technical challenges. In terms of product challenges, I think the biggest one was the reactive model.

We've talked about how marimo notebooks are reactive: You run a cell, and dependent cells automatically run. Then you brought up the objection that this means you can't have side effects. It also means you can't define the same variable twice across 2 different cells, because if you do, marimo doesn't know which definition to run first, and your outputs won't be reproducible.

I found that confusing in my first-time user experience. It was a big break from traditional notebooks, but we felt it was necessary to have the amount of reproducibility we wanted. There was precedent: I saw that Pluto did it, and Pluto was doing very well in terms of open-source adoption. I thought, "People can get used to this."

6. The future of collaborative AI

We chose to have marimo essentially be a DAG of notebook cells, with these constraints. We would try to explain them to our users, but we had a number of people come into our Discord asking, "Can you have an option to turn off the DAG so it's like Jupyter again? I want to type random code, do whatever I want, and then toggle the switch back on later."

Did you consider that?

We considered it. Their reasoning was that it would only increase the amount of stuff you could do in marimo. But I thought about the larger ecosystem. People could share notebooks developed in some kind of dangerous mode, and those notebooks wouldn't work. The DAG is necessary for the notebook to run as an app and as a script, so all those downstream things we enabled would break.

In the end, we decided to politely say no. We can't do this. We can't let you turn off the DAG.

Okay, now we're going into my personal tech-support questions. What do you do when you want to quickly tweak 1 thing, but not necessarily save it? You want to copy some block of code into another cell and just see what happens.

I have 2 recommendations. One would be to try to use functions as much as possible. Functions introduce a local namespace, so variables defined inside a function don't get added to the global namespace. You can redefine them as many times as you like.

The first thing you say is, "Wrap that code into a function," and then call it multiple times, which requires a little more engineering and wrangling, but it can be done.

If you don't want to do that, you can prefix a variable with an underscore. In marimo, that makes it local to the cell, so you can reuse that name across multiple cells. You can't access it in another cell, so you don't have reproducibility issues. That's the escape hatch.

I feel really optimistic for you. You've made a beautiful product that's getting incredible adoption, so it's exciting to catch you early in the journey. It would be fun to check back in a year or 2 and see where you are. I really appreciate you taking the time to talk to me.

Of course. It was a pleasure. Working at marimo is definitely a dream job.

Awesome. Good luck. I'm rooting for you.

Thanks, Lukas. Take care.

You too.