Ep. #24, Runtime for Agents with Ivan Burazin of Daytona

Brian Douglas: Welcome to another installment of Open Source Ready. John, how are you doing?

John McBride: I'm doing fine, Brian. How are you doing?

Brian: I'm great. We got some colder weather out here in San Francisco. Clouds. Fog is a thing. Well, fog actually sort of stopped now, so now it's just straight up cold.

I've got extra layers on. I am not turning on the heater until like January. That's the goal here. Yeah, not paying for that.

John: We just had one of the Nor'easters I got to experience for the first time.

Brian: Oh yeah, I heard about these.

John: It's basically a hurricane and I could not believe how much rain and wind there was. But we do always intro with the weather, so why don't we intro the guest instead?

Brian: Yeah, yeah. Well, we'll stop talking about the weather and I want to introduce you, Ivan Burazin. And Ivan, you're from Daytona. We've known each other for a couple of years now and super happy to chat about Daytona, but why don't you introduce yourself and what Daytona is.

Ivan Burazin: Well, thanks so much, Brian. We've known each other for quite a while, since pre our pivot, so about two years ago. And you've been part of this journey for a while, so thank you so much. And so yeah, I'm the co-founder and the CEO of a company called Daytona that creates infrastructure or runtime infrastructure for AI agents.

Brian: Yeah, yeah. So I know you from, you have to correct me, your previous company. Was it Code Anywhere?

Ivan: Code Anywhere was one of our previous companies. Yes, yes, one of them.

Brian: Yeah, yeah, yeah. So you know the space around just basically coding in the browser essentially. So you started Daytona as that and you guys did a pretty good job around that. You chose to do an open source angle as well.

So it's an open source project, you can go run this and literally Code Anywhere. Even though Daytona is not the name anymore. But do you want to explain what you were doing and what your historical record in the space is?

Ivan: Sure. We did a bunch of things. So before Code Anywhere we were actually doing server rooms as a service. We were pretty poor so we couldn't build a product so we were just selling time. So we knew how to stack servers, do virtualization, Cisco routers, all these things and we knew how to use a screwdriver among other things. And so we did this for quite a while.

So like OG virtualization and stacking of servers, sold that and then we started Code Anywhere. And so Code Anywhere was very, very much the very first browser based IDE, as far as I know, that has existed ever. In 2009 we started that.

The interesting thing is when you're doing a browser based ID, at that point in time, there's no VS code so it doesn't exist. You have to do it. There's no Kubernetes, so there's no Orchestrator. Docker had started just then, but we were doing some other container runtime we were using, but we had to create everything from the editor to the orchestration player to everything else.

And so that company or product was kind of useful, kind of successful. It was never a breakout success. But millions of people have used it and we learned a lot of things. We did some things in the meantime, but basically started Daytona two years ago to take the learnings of Code Anywhere and create an enterprise-first, on-prem automation tool for human developers.

And so some of our first customers were Fortune 500 companies and that's when we started, when me and Brian had talked about, and because of the experience with Code Anywhere and the need inside of these large enterprises.

So if you work, probably if anyone's listening that works at Google or Meta or whatever, their dev environments are super well done, more or less. Pretty easy to get up and running. But if you work anywhere else, it's just a total pain in the ass and also not very secure.

And so one, it can be a pain in the ass. Two is if you're in a very large, let's say bank, you sometimes have to code through a remote desktop, which is just like a horror story. And so what Daytona did was basically offer that same security with even better developer experience and enabling you to run that through your local IDEs or local VS code. Cursor had just started when we did that, but we ended up pivoting away from human developers into running that for agents. So that's the history.

Brian: Yeah. And some of that history is actually public where you had gotten a pretty significant revenue pipeline. What made the decision of you going from you're doing runtime for developers and now you're doing runtime for agents?

Ivan: For agents, yeah. So we were about a 300ish run rate ARR. Actual ARR. Not run rate, which was pretty significant at that time. Less so today. Today it's basically if you're not adding a million of run rate a month, you're not doing anything.

And so we had some really big customers, we had a huge pipeline, we were expanding customers, things were going great. But it was slower. Enterprises are definitely slower. But also I felt like something was off in the sense of like pull or PMF or whatnot.

You can force-sell a product if it's good enough. But the urgency was really missing. Like you'd take a call with a large company, they'd be interested in and then go for procurement, and it takes a while. There's just a lot of things to do there.

But what we had noticed end of last year is we started getting more and more inbound from people making AI agents, which was not a lot like Q3, beginning of Q4 of 2024, there was not that many people building it and they're like, "oh, I need a runtime for my agents."

And we would naively say like, "oh, here's our CDE, cloud development environment. Just use that because it's the same thing, human agent."

And then that would basically quote unquote break. The system wouldn't break, but it wouldn't work really well for the agent. And we did a bunch of research and started figuring out and sort of seeing beyond the bend. And I've mentioned this before, but basically I think it was in April of this year when both Anthropic and OpenAI said agents need runtimes or environments to be able to do a lot of their tasks.

So this was pre that. And so as we saw this going, we're like, okay, we have this product, it's going pretty well, there is interest, but it's not super pull. And then we have just like these random people reaching out to us for infrastructure for agents.

And so if you sort of plot it out, the number of agents that will be in the world where this is going directionally, a need that's not met. It's like, are we going to build for the future, for the past? And so we took a really, really, really big bet where we said we can't do both things at the same time.

And we thanked our original customers in January and rebuilt the entire product starting end of January and we launched it end of April. But the other thing is as we got to that point we built more and more conviction. And basically in February we had just started rebuilding.

We actually kicked off our Go to market motion. Like we went out and sold this thing without actually having people. And so that was like an interesting experience for about three months until we launched it and then basically just been great since then.

John: What differentiates a sort of human environment or, really, those building blocks? Because I can think about what I need to go and do something in infrastructure or an environment like the GO toolchain and Vim, or something. But what does that look like for an infrastructure for an agent? Is it a lot of similar tools? Are they getting a desktop? Break that down for us, what that actually looks like.

Ivan: Sure, there's a bunch of things that are specific to agents. And sometimes you need them, sometimes you don't. There's a bunch of tools.

What I like to say first is that we're building a composable computer for an AI agent. What that means is we have different types of computers that we use as people. And so you might be running on a MacBook Air because like you just do spreadsheets and email and that's good enough for you.

You might have this huge box under your desk that has graphics cards because you play video games. Or let's, let's remove video games, let's say you do 3D rendering, like that's your job. You're like an architect or a video game designer or whatever. And so you have this thing there, right? So there's different types of computers.

And so what I think about as an agent--A lot of people think about like rendering, running code, which is our slogan. Run AI code. But there's much more than code because agents will need computers to do absolutely everything.

So is it a container-use, a computer-use, or a browser-use, any of those? They do need a computer. And what are the different use cases for that? And when I think about that, the agent should be able to, at create time, say, "I need this many CPUs, I need this much RAM, I need this much disk."

But also, "Do I need a gpu? Do I not need a gpu? Do I need a Linux machine? Do I need a Mac machine or do I need a Windows machine?"

And so this should be composable at create. Basically at create, you can decide what you want. And so, to address your question: What is the difference? Well, one is speed. We all like speed as humans, but setting up a dev environment for a human is 30 to 60 seconds usually. And that was fine. Like, you click, take a sip of your coffee, you're good.

But agents, especially if they have to do multiple iterations, you want that to be insanely fast. Plus if a human is waiting on the other end. So let's just say ChatGPT is an agent, Claude is an agent, Devin is an agent, whatever. You don't want to wait a minute. Just for the startup, the boot of the machine, you want it to just go to work, right? So you want that there.

The second thing is we as humans solve things in a series. So John, you do things in a series, and I do. If you have a math equation, you're not going to try five outcomes at the same time. You're going to try to get to the end. If it's wrong, do it again. It's wrong, do it again. Same thing with coding. You do it in a series.

Agents can say, "oh, I have three options, four options, five options, and I can basically fork the machine that many times and try all those outcomes at the exact same time."

And you can fork those again and again and again. And anyone watched, and I've said this a few times, it's just like it's the multiverse in the Marvel movies, right? And so, we provide the infrastructure for that and enable the agent to figure out what is the best path to get done. Right?

And so even if you don't want to do forks, you want points in time where you can sort of go back and do these things again. And the last part is what I call machine native interfaces, or agent native interfaces, which is when you think about computers, you all have a computer. When you buy a computer and install an operating system, there are apps on it.

So the File Explorer, the terminal, those types of things are in there. And so what we try to do is make the agent's probability of success much, much higher. You do that by wasting less of their time, wasting less of their tokens, wasting all of this.

And you do that by when an agent spins up a Daytona machine, inside these machines, there are like a headless File Explorer, headless terminal, Git client, you know LSB, like all these different things that an agent needs, hopefully to faster get to their outcome.

Now there's things outside of this as well. I think of us as a computer, not just as a software in there, but as the peripheries as well. So, "oh, do I need to attach a quote, unquote USB drive or an external drive? Can the agent do all these things and have access to those things autonomously to reach its outcome?"

And so when you start breaking down these things, it's quite different. And just a last note on that is, if you look at the infrastructure or what you can find on any of the clouds that exist today, all the variations of quote, unquote, sandboxes or runtimes for agents are serverless infra. It is either something running on Kubernetes or a Lambda or Cloudflare Worker or whatever.

These things are not suited for agents because in my mind, infrastructure for agents or runtime for agents have to be super fast, long running and stateful. And having all three things at the same time does not exist in any product right now on the cloud.

John: Yeah, it's very true. I mean, those three things would be kind of a new offering in compute in a lot of ways.

You describing kind of the shape of what those environments look like actually reminds me of some of the ways that operations get done at AWS. Despite all the news with the AWS outage recently, one of the things that we used to do at AWS was have these kind of matrixes of environments or variables or whatever, and then go spin up a bunch of EC2 instances to ssh into to go and do work.

So that may actually be like a matrix of the different regions to go and do releases across all those regions. And it was always a pain because I would then have to manually go ssh into them, tmux around to then do the thing in that region, you know, spin the machine down or whatever.

So I can kind of see the magic of being able to enumerate almost immediately with these autonomous agents.

Ivan: Exactly.

Brian: Yeah. So I recently just started playing around with the Claude Code Web, which is very, very confusing. They have Claude Desktop, but then there's like this web version that you can spin up a remote runtime.

And I found that actually pretty frustrating because I'm not sure if it wants to be like a SaaS, like bottom-up experience or do I need to actually have some platform engineering experience? Because it asks you a question, like network, is there network privileges? Is it only sandbox? Is it "only allow" listed URLs?

And there's a lot of stuff that, for me, who's just sort of skating by and trying all these tools out, that's a lot of decisions I don't want to make. So I'm just curious, with Daytona, where do you fit within the stack? Is it for platform engineers? Is it for the bottom-up, v0 type experiences?

Ivan: Yeah, so yes, on all ends. A slight comment on that, the experience on the Claude Code the great thing is we're also listed as officially, we didn't push on this, on the Claude Code docs as a sandbox to run your own Claude Code.

So literally there's instructions on how you can do that from their side inside of Daytona. So it's not just purely on their side. The reason why I believe they have these limitations is the same with Codex, where running compute or hosting or whatever cloud is really prone to issues.

So anyone that's tried this in their life has people trying to do phishing attacks, people trying to do DDoS attacks, people trying to crypto mine on these. There's so many things that people try to do on these and it's a really hard thing to do at scale while offering a great experience for the benign users that are just trying to do what they're trying to do versus the users that are trying to be destructive.

Right? So you have to stop the ones that are being destructive, you have to create a great experience on the other side. And so the easiest way is just like block ports, disabled updates stop all these things. Right?

So it's really hard to do. The way we've created Daytona is it is a full VM that Claude Code can just go crazy on depending on the tiering. As a customer inside of Daytona, there's different limitations that we add on just to make sure that you are a good person.

And once we know you're a good person, all bets are off and you can, everything is gone. But we just want to make sure that what you're doing there is safe. And that's really hard to do, but as a customer--

So, for example, let's say you are trying to build the Claude Code Web using Daytona. Like you work at Anthropic. For you, Daytona offers you the ability to do whatever, in the sense of you can enforce firewalls on each of the sandboxes manually and say, "anyone using your product that uses Daytona is locked into these firewalls."

You can develop basically that all in creation time that can be set on and off. You can do all the things that you want or you have to do nothing. Basically, you can leave it all on and it all sort of works. So to answer your question: Daytona is a product that you integrate into a product that you are creating.

So if you are creating this product, you should be savvy enough to be able to decide what your customers will do, but we give you the optionality to decide what you want to do.

So if Claude Code Web had used Daytona, they could have made it the same experience as you have now, but they could also made it like a truly seamless experience where they just give everyone everything in that and then we take care of that in the back end.

Brian: I'm actually curious if we can go back into more use cases for this. So you mentioned that folks are embedding Daytona in the product. So Claude Code is one of those examples that you can leverage and run that on demand.

And actually they have a pretty decent SDK, Codex SDK. Gemini CLI has an SDK for this. So what are you seeing folks leveraging Daytona for in production?

Ivan: Yeah, so the way we think of Daytona originally, and so this slightly changed, is that we think of AI agents from like a three-prong. When I define an AI agent, there's three parts to it.

So the AI agent is a piece of deterministic software usually. So it's like one web app, mobile app, whatever, that you've created. And on one hand it's connected to a model or multiple models. And that's its intelligence on one side.

On the other side, it's connected to an interface with humans, like voice, text, whatever. So a human will prompt the deterministic software, the determinist software will pull in the model. The model will think, give you an answer, if it knows. But if it doesn't, on the third side, it has access to tools, right? And tools can be anything.

And in our case, the tool is the computer. And so it can call on a Daytona machine to do whatever it wants, like clone a GitHub repository, run some code, do some data analysis. There's a bunch of use cases. We can get into those in a second. But basically that's how we think of the structure.

But what has happened now is with these, a la Claude Code, as the ones you've mentioned, people have just been doing, "oh, Claude Code works good enough, I can give it a task, but I want to do it at scale because I need like twenty or one hundred or a hundred thousand or a million of these Claude Codes. I also want to make sure that it doesn't break anything. So I'll just throw it into a sandbox, lock it in, and then let it go wild."

And so we've seen more and more of these use cases where people are using us in that fashion, which is basically a cage for your CLI coding agent.

And so that has been a new use case for us, and we kind of pushed away from it originally because it confuses people to if we a sandbox for the agent? Or are we like a computer for the agent? And so it ends up that we are both, because that is directionally what people have been adding.

But people use this for a vast majority of things. And so obviously the vibe coding platforms, bunch of them. So not Lovable, but a la Lovable, there's a bunch of those. You have the general purpose agent.

So like the actual Claude, like ChatGPT, like Manus, like those types of ones that, you know, you ask it to do something and then it needs to analyze data or has to spin up a browser or it has to do whatever. Like, you can do all those things on Daytona.

You have large enterprise. Like we have a bunch of Fortune 500 companies that run it internally on their own, and they do that to do their own versions of all the coding agents or all the agents that exist in the world.

A newer use case is like AI scientists, which is actually really interesting. So you have actual pharmaceutical companies and health genome type companies that will have agents do these things like do whatever they actually do.

I don't know what they are, but they have to spin up these very, very large machines which essentially ends up being like a full on bare metal machine that we wrap into a sandbox. Which is interesting.

They could have just taken a full machine but they need the tools, the interfaces, the things that I mentioned at the beginning to John's question for the agent to do it really, really well.

So it's interesting that we take a full VM and wrap that into a single sandbox for these use cases. On top of that, you have the new agent-native productivity tools. So you can think of the agent-native excels and Notions of the world. There's like a bunch of these companies right now.

And so it's a production productivity tool for humans, but there's like an agent in the background doing things for you. And these agents need machines to be able to execute on them.

So that's the general use cases. On top of that, I just have to mention benchmarking and RL. So a bunch of people use Daytona for RL instead of spinning up a Kubernetes cluster or for benchmarking against like terminal bench or something like that. And they will spin up a bunch of these to do that.

John: Interesting. What's the security story? Because it sort of ends up being like an entire compute platform, obviously for agents. But how do you keep them from breaking Daytona itself?

Ivan: Yeah, there's a lot on that. We do like pen testing every month. We're compliant across all things and so those are like the general ones. But basically each of the individual VMs has to be one, completely isolated, you can't get out of there. Whatever they do, it can just break themselves and nothing else.

But that's just the beginning of the story. And so one of the things that we had to build early on is basically a L7 firewall inside of each of these so that you as the owner of the thing that's orchestrating these VMs, these sandboxes, can define what can go outward, what can come inward of these machines.

Secrets Management. So our Git client actually obfuscates your token from the agent as well. That's the only thing we have to add the rest of Secrets Management, which is not your exact question.

But the minute you let your agent inside the sandbox and if all your tokens, that's sort of the issue when you put the agent inside it, literally, then it can see all its tokens, all its API keys, it can see everything, which means it can do a lot of damage in general.

And so you have to create a system that obfuscates all those things from the agent as well, so that it does have access, but you have to remove these things. So there is definitely the security of the sandbox itself not being able to come out, the network security of what can come in and what can go out, and then all the secrets that are managed inside of that.

And lastly, it's not necessarily security, but in the sense of telemetry, so OTEL endpoints, so that you can see if anything goes wrong, what has gone wrong, and why it's gone wrong, inside of these sandboxes.

John: Interesting. Yeah. One of the ways I've been thinking about it, because I think you're kind of touching on how it's almost a different security mindset where, if you're spinning up VMs in the cloud to go SSH onto or do operations on, sure.

You need to have good firewalls and good security and all that stuff to do the operations. But it's almost like you're hiring a contractor.

Ivan: Exactly.

John: And that contractor may be convinced to go do something really terrible by something it read or something. Right? But you can generally trust this contractor. But still, you want.

Ivan: You don't want to. You don't want to do that. Which I also find interesting is where a lot of people run these things on their own machines.

And so you run Claude Code on your machine. And it can kill your machine. It will. It can brick your machine. Why would you do this? Like, again, I'm on the sell side of this, and I'm basically telling people, "use Daytona," but it's not necessary to use Daytona. Like, spin up an EC2. Do whatever you want. Why are you doing it on your computer? That makes no sense to me. Because it is quite a dangerous thing to play with.

Brian: Yeah. Yeah. I've done some weird things where, man, I was trying to unblock something where it deleted my .in file which is not in Git, and I'm like, "oh, well, how can I get that back?"

And then it started doing even weirder things. And I won't pick on the agent that was doing this. But yeah, there needs to be some guardrails and some rules around that.

Ivan: And--

Even if the agent becomes very intelligent, it can still mess up . To John's point, it could be like a contractor, it could be a junior person. They can mess things up. You have to put in guardrails, so it can't mess you up. So these are some of the things that we have to think about in this new world.

And then when you think about how many tasks. So there's a new product called Conductor, which is going really well, and they can spin up multiple of these agents. They're still on your machine.

And so even if you're not worried, from a security perspective, there's that scale perspective. It's like, "okay, I can spin up 2 or 3 or 5 or 7, but I can't spend a hundred thousand, right? But I want to spin up 100,000 because I want to get this job done as fast as possible."

And then, so how do you do that at scale and then how do you do the security and all those things around that? So yeah.

Brian: Yeah. So we haven't even talked about Continue, because I try not to make this a Continue podcast, but we do a remote agent experience and that was one of the selling points, is to have a sandbox for folks to send your code to in a secure environment that agents and LLMs can do, but very similar to work trees.

Like, you're not running this on the main branch or even on the branch that you're trying to get some real work done. You're spinning this off like in an ephemeral environment and then coming back and reporting, "hey, it worked or it didn't work."

And we're finding that a lot of folks do like having that story of, "We got a century error. The century error kicked off an issue and then kicked off a PR and they either worked or it failed."

And whether we decided to move forward with that, at least we had that artifact of like, it didn't work or did work. But let's back out of this and move on to some real work.

Ivan: This is one of the use cases coming up a lot, and I know a lot of these companies will invest in that, but I've heard this for a while, is basically when you get some sort of issue alarm on whatever service you're using, it kicks off one or multiple Claude Code agents instantaneously.

And to your point, is if they solve the problem or not, whatever results you get help you solve the problem.

Brian: Yeah.

Ivan: Like as a human. Right? If they got it right, awesome, done. But if they got it wrong, okay, at least it's not that. So it's like Thomas Edison's thousand ways of not solving something. So definitely that is a directional use case of these things.

Brian: Yeah. I actually want to play around with that too as well. Because when you talk about the multiverse and you think of Doctor Strange sitting there trying to think of all the sort of the things that could happen and could not happen. What I hate doing is sitting in an engineering sync and just talking about it for two hours and no one's done anything.

Ivan: Yeah, exactly.

Brian: But if you're like, and I've done this a couple times during standup, where things get brought up and like within our 15 minute standup-- Because we do stand ups remote sitting down, from our desk.

But what I'm getting at is I'd be like, "oh, let me spin up something real quick and ask a bunch of questions to it in like the two-way environment and then validate. Okay, I've got a summary by the time it's saying it's over that we can like act on later. But then what we do a lot of.

And I want to ask about the open source thing real quick as well. But with Continue, we're open sourced. So a lot of it, it's just like throwing a bunch of ideas back at the issue. Like someone opens up something like, "hey, it doesn't work this way."

I'm like, "cool, if you wanted to fix this yourself, I just chatted with an agent and it said that you could just approach it this way. Let me know if it works for you."

And a lot of that is just looking at other issues, looking at other PRs, looking at other historical records and bringing that to the new issue that's been opened. And I found a lot of success in that.

But I want to ask your thoughts on the open source. So you have an open source product. Are folks approaching using Daytona directly open source, or is this more of like a sandbox where they're testing it out before they buy?

Ivan: Oh yeah. So the open source is there as well. The open source is like the full Daytona, more or less. So we had a bunch of strategies around open source originally and I'm sorry to say that the strategy on Daytona v2, which is the like, agent runtime versus the human runtime, had less time to think about positioning and marketing and how we build that open source and licensing and get all that done.

Because V1, I don't know if you recall, there was a specific open source version created for an individual user which was 100%. It was like Apache 2.0 license, do whatever you want with that. And our enterprise product actually pulled in the open source, basically as a library.

So it was built once, but it's a very different product for the enterprise and for the individual user. Building Daytona V2, which was for agents, since we cut it in January and then launched it in April, the open source was like, "we already have a bunch of people and contributors and they like it. Let's make sure it's still open source."

But we had less time to figure out what was the right positioning on that. So the whole thing is open sourced, more or less, and it's on a AGPL3. So some people will hate us for that, some people won't. There's like different takes on that one, but we had less time.

Brian: Yeah, I'm curious, I was going to ask like, why that license?

Ivan: Well, that's because the whole thing is there. And so it's basically so Amazon doesn't just use it and so you don't get into the Elastic issue. That was the whole reason.

And so how do you make sure you don't get into the Elastic problem? And so that's why we sort of put that on. So we can still quote, unquote, lose revenue. So if you're like J.P. Morgan, you can run the open source thing and like it's totally fine, but like Amazon, Google can't run it and do a competitor to you.

And so that was what we could pull out as fast as we could. Now hopefully if we get time we can evolve that and break it out in to have a full, again, clean Apache, I hope at some point for a section of the use cases. But it just took too much engineering time where we were.

But regardless of that, because it's the whole thing, we do have people that are using it for their internal use cases. So it is the full thing where they're building agents, they're running the Daytona, on their infra internally or on their AWS or whatever it may be to be able to serve these agents and get them to use cases.

And the interesting part about it is that one, the setup wasn't really good until quite recently. So the vast majority of people that are using it over the last sort of month or two, and it's interesting to see people call you is like, "Oh, we've got this up. We're running. We have like 100,000 agents a day using these things. By the way, how do we do this?"

It's quite a shock in the sense of a happy shock, where like, you never knew, never heard about this company and they're like, at scale, using your product. So I think that's kind of cool. Not sure if that was your question.

Brian: Yeah, yeah, no, this is all enlightening too as well, because actually I might have missed the GPL thing. But also John knows, as a former Amazon employee, it's a real thing. And I respect the team at Daytona attempting to solve it and look forward to what the future entails.

I was going to ask, are any of your competitors open source?

Ivan: Yeah, so one of them is Apache 2.0 as well. So you can go and use that. So one of them is. The others are not. They're all closed source.

We do believe that open source is really important to get the community on board and to help them build these things. I strongly believe the number of agents in the world will be the number of humans to the power of n. Like large, large orders of magnitude more agents, and all these agents will need computers to do things at scale.

And so we don't need to be charging for all of these agents, but we do want to be the platform that enables all these agents to be able to get their job done. And so having an open source story around that, I think, helps a lot. Plus you do get customers because it's open source.

"Oh, like there's this issue. We'll just create a PR." And we have more and more of these, which is actually quite interesting. Like, all our customers are in our Slack, like our larger customers, and they'll be like, "There's this issue and oh, by the way, we just solved it. And so here you go."

So it's a great two-way thing and I appreciate the open source quite a bit. So we're going to work harder on that as well.

John: Very nice. Yeah, the licensing thing is always really hard, especially as these things have evolved. I don't know if Richard Stallman ever imagined the scale at which behemoths like Amazon or Google would be able to go and monetize software.

So it's like the conventions of what we have to do with open source licensing today, to protect businesses, I think it makes a lot of sense.

Ivan: I mean the part with the story we had originally with Daytona v1 in which I feel the open source works, is can you actually separate the code that accrues value for large enterprises and the code that accrues value for individual people?

And so if it accrues a value for individual developers, like I have no issues with any individual using us for any use case. Like we don't really care. That's not a problem. Like the problem is like is Amazon making money off of you versus or like someone else? Then that is sort of like not really nice because those are the people that do that.

And so if you can do that at a code level where you can basically separate these things, I think that works really, really well. It's really hard. It is more the open core model in that sense.

But I would even separate the repos where like this is a clean 100% repository that's 100% open source, you can use it freely. It is like either MIT or Apache, go use that freely, contribute, whatever.

And then all this other stuff where that sort of accrues and though that is things of actual monstrous scale, things of logging, reporting, compliance, all these things are just split out of that completely. And I think if you can build an open source project like that, then you basically can't have that, you know, full on, spiritually what open source is supposed to be.

But then you've also removed the risk because all the things that are valued at scale are pretty much out of that and the people that want to use it don't care about that stuff anyway. So it's not discounting the product in any shape or form.

Brian: Yep, cool. Actually we've got to wind down the conversation to picks. But I did want to encourage people to check out the open source repo, check out Daytona. When you sign up, do you get like a couple dollars in credits or anything like that?

Ivan: Yeah, it's a hundred dollars in credit.

Brian: Oh, a hundred. Wow, nice.

Ivan: You have to add your credit card just so we know you're a real person. That's it. But we don't charge it and you get a hundred bucks right away.

Brian: Oh, nice. Yeah, yeah. A hundred bucks is generous. I was thinking $5, but yeah, $100 is great.

Ivan: On that note, if you are a startup and listening to this, we give out 50k in credits to startups, like if you're eligible. So like feel free, check out Daytona IO startups, sign up 50k, so that's even more generous. Sorry for the plug in there, I just had to do it.

Brian: No, no worries. And I'll also mention, if you're enterprise and you want to ship Daytona at scale without telling the team, that's also an option.

Cool. So we've got these reads. So I got to ask you, Ivan, are you ready to read?

Ivan: I guess I am. I'm never ready, but yeah, reads excellent.

Brian: These are our picks. These are reads. These are articles and things that John and I have been reading around the space. We actually touched on the first read, so I'll go first, John.

Quesma had a blog post around LLM securities, like the Paradox of Security. And they did some testing with Deepseek and GPT-OSS and the ability to add a backdoor into some of these large language models.

So they're all freely accessible, but a lot of folks are interacting with these direct providers. So folks, check out the provider, make sure they're legit. But yeah, we're finding that there was like 95% success rate of malicious prompts downstream, which is , in the space of like Daytona, we're just having this conversation and security, like being a thing--

Yeah, I'll just mention that because, it's just like eye opening because you would think that, actually this is a new world. So I guess it's fair to not even think about this until it happens. So it's happening.

Ivan: I feel that it is. I don't know if there's a question in there or an answer in there. But what I find really worrisome is that any sort of restrictions in the sense of like I get malicious prompts, but I don't know how you get rid of that because the models are open source.

And so you can sort of regulate Amazon who's running them or someone else, but it's not like a random company on some random server running somewhere. How are you going to enforce that?

Like it's on some server. It's the same thing as Pirate Bay or whatever in that in the sense of like torrents or anything else. It can always be run on some server somewhere and you can have access to it and then the AI can always do malicious things. And so I don't know how you regulate that.

The extreme is if you do that in the United States of America, you can create a great firewall of America and then stop you from going outside of it and then everything's regulated inside, which is okay, but then that is not really what you want to do because it's not the World Wide Web anymore. And so, I'm not sure how you solve that in this world.

John: It's interesting because it's kind of the alignment problem anyways in AI/ML where it's hard to align these ginormous large language models, especially the open source ones that don't get a lot of the post training safety measures put on them.

Like Anthropic, the GPTs on OpenAI, they're all putting these additional safety measures on the models. I don't think the open source ones get that. So yeah, Ivan, I think you're correct.

How do you even begin to regulate autonomous agents out there going and doing crazy things if the open source ones are doing malicious things for you. But also, where's the AI research going to land around the alignment problem and making sure that we're not building systems that we just can't control in the end.

Ivan: I mean, I think it's fair that people are trying to control these, I'm going to say regulate, but in the sense of making them safe and in the big labs and you can tell that to like OpenAI, Anthropic, whatever, but we have so many, there's like labs around the world that you cannot regulate.

So the ones in China you cannot regulate. And I'm not trying to make this political in the sense of like China and America, but you can't regulate what someone does in another country and then when it's open source, then someone in a third country, like pick any country off the map, you spin up like some servers and you run that open source model and there you go, it's out there.

And it can do things and so I have no idea how people expect that to be regulated at that scale.

Brian: Yeah, very cool. I've got another pick. I saw one of your competitors had an announcement with Docker MCP and having MCP and runtimes. I've got a lot of questions. Why is Docker hosting MCPs? Is that a business that they're expanding into?

Ivan: I have no idea. Yeah, I have no idea on that one. Same question in my head.

John: Yes, I could tell you.

Ivan: Oh, go ahead, John.

John: With Zuplo, we've been shipping a bunch of-- I don't know, in some ways we're competing with Docker because they're hosting these MCPs. And it kind of makes sense where MCP sort of ends up being the layer, the HTTP or the even like SSL between agents and services doing things.

So it makes a lot of sense for Docker where they can just host containers that probably can come up and down really quickly to just go do something. On Zuplo, that's APIs where MCP can just like get the translation for whatever APIs you might have. Maybe it's the MBA or it's some weather stuff or whatever.

You can just go and like get the weather data, translate that through MCP. So I think because Docker is hosting-- Well, they have all the images. People are just pushing their images to Docker anyways.

Ivan: They have the images.

John: Yeah, they could just run them and then just be like, "here's the MCP layer."

Ivan: But are they running them? Are they creating their own cloud? I missed that. If Docker is running an MCP cloud, I did not know that that was happening.

Brian: Yeah, they had a couple quick hit announcements over the summer and I've been paying slight attention to it. I know some folks over there, but I haven't really touched any of it becauseI've been using Docker images as MCP servers and like doing that, sort of hand rolled. But I haven't tried the thing that they've shipped recently.

But I did have another question which was, is the world moving that runtime will have MCP baked in? Because it sounds like that's what the announcment that they announced was. But I wasn't sure, is that a necessity, having MCPs baked into your runtimes?

Ivan: I'm not sure. And I just saw the announcement walking into this. So, to be clear, I had no time to digest. And so there's mixed feelings internally where I'm like, I've never heard anyone that ever wants this ever once at any customer. So like, am I missing something or something else?

The other side is, I'm still not sold that MCP is the thing that is going to exist going forward. So there's a bit of that in my mind as well.

Like the thing I can tell you is also Cloudflare, which has a competing product to an extent, they have their own sandbox as well. Great team building things there. They have this article called MCP Code, I think the article is called, where it's basically that there's so many problems with MCP and how it fills the context window, whatever.

And the best way to actually use MCP is to spin up a sandbox and run code against the MCP and then deliver that to the agent so it doesn't fill up the context window.

Brian: Yeah.

Ivan: So that seems bananas. Like I get the solution and that's great. And also more sandboxes, great. But we went from API to wrapping an MCP to then spinning up a sandbox, like to the code. That seems like just a lot of layers around an API.

So I don't think like directionally long term that that, at least where it's sitting, I don't think that ends up being the end solution that we have. So to answer your question, I haven't seen inbound interest for that yet at this state.

So that's why we don't even have it on our roadmap. On the other side, I don't think MCP is the win-all of platform standards that will be there. So my answer is not that specific yet, but that's where my head's at at this moment, an hour after seeing the announcement.

Brian: Yeah, I mean it was pretty raw and I actually just also just saw the announcement a couple hours ago as well. So I appreciate your quick hit, top -of-the-dome feedback on that. But we'll see how it does in the next couple weeks, months.

But John, do you have reads you want to share?

John: Yeah, sure. I got a few. A couple quick hits. One is this GitHub repo. It's Onsi/Ginkgo, which Onsi was actually the CTO at Pivotal, which was one of the first places I worked way back in like 2018, on CloudFoundry.

And this was a pretty core part of how we worked at Pivotal, which was the test driven development and doing the pair programming and all of the extreme programming practices. And I've actually found myself going back to a lot of these practices with agents.

Like Ginkgo and Gomega from Onsi are Go testing frameworks for behavior driven development, which makes kind of the whole like nastiness that is Go testing the framework, it just makes it so much nicer so you can do stuff like describing behaviors in tiers and creating trees of behaviors inside your tests.

And it just really makes the experience great for testing with agents. I know some other of these frameworks, like Jest and some other BDD frameworks had a resurgence in popularity for a similar reason, I think, with AI. So, yeah, go check it out. GitHub.com/onsi/ ginkgo. It's great.

Ivan: Awesome.

John: One of my other reads, speaking of test driven development and behavior driven development, I wrote this little thing that I'm calling Dopamine Driven Development, which is this feeling I sometimes have when I'm using AI coding agents locally. That's just like, yeah, I don't know, just like one more hit, like one more prompt.

And Brian, I think you and I maybe even were talking about this and I think it's almost like taking vibe coding too far, where you're just waiting for like that next dopamine hit as you're trying to get to some solution or something.

You know, this isn't a knock on like using AI agents or even like vibe coding as a practice. Maybe it has its place, but where that leads us and like where that brain drain goes, do either of you find yourself in this dopamine driven development phase ever?

Ivan: But on the good side, it is an alternative to playing video games. So instead of playing video games, you're actually doing something. Right?

John: Right.

Ivan: It's the same feeling though, right? It's like the next level, the next, like 15 more minutes, just do one more and it's just a dopamine hit, like whatever you're playing and in this sense you're actually hopefully building something useful. So it's a better way.

So we're all addicts, to degrees, to dopamine, right? Like some more, I'm more, I'm very much more addictive person than maybe some others. And so, how can you funnel that dopamine hit to be from something that's actually productive.

And so as long as you're like making something productive, I'm not necessarily actually that bad.

Brian: Yeah, yeah. Choose your vice. And I'm definitely in a space where like, I've been doing a lot of like--

I remember a couple years ago when AI got really big and all like ChatGPT and folks were building these apps so you could talk to Steve Jobs and you'd be like, "Steve, tell me how you'd start a startup. "

And it's like, it seemed very silly, but I find myself doing the same thing like where I'm like, I'm not talking to Steve Jobs, but I'm like talking to Claude Desktop and I'm like, "oh, I think I'm gonna build this thing. Like do you think I need Kubernetes for this? And like, let's go through all the scope."

And I get a kick of just asking a bunch of technical questions to the LLM and then asking for articles and going in the deep dives and then I'll go implement it like through a bunch of GitHub issues. And then I get to the point where I'm like implementing it and it works and I'm like, cool.

Again, it's 1:00 AM and I'm just cranking through the next thing. I'm drinking the Kool-Aid and I'm all in to building out infrastructure that I don't even need at this point. But because it's fun and I'm learning a bunch of stuff.

Ivan: Yeah. So in that sense, it's really good and so why not do that? I mean it's completely different, but similar to when you, if anyone starts training a lot, like running or weightlifting, whatever, it becomes a dopamine hit.

Like you have to go, like you have to go to the gym, you have to do your run. And that's not a terrible thing. Better than doing like, take your vice, like drinking, smoking, whatever it may be. So as long as it's still productive, I think John, that's actually a good thing.

John: That is actually my main critique is that a lot of the AI labs, OpenAI, Sam Altman, Anthropic, whoever, they're the ones really pushing this development model with things like Claude Code, Amp, Codex, and my very, very cynical take is that they're pushing this because they get the API usage per token and then you slowly kind of whittle away your understanding of your code base over time.

And over years, that could be effectively zero, where you then are reliant on dopamine driven development to do anything and then you're just continuing to pay dollars and dollars and dollars to these AI labs.

Ivan: One question. Do you think that these models are created or not created to have a dopamine effect on them?

John: I think unfortunately they are. It's clear that they make them more sycophantic to increase engagement.

Ivan: There you go. That's the answer. I don't know.

John: That's not even a hot take. That's something that Sam Altman has said, that they like try for engagement on a lot of these models.

Brian: I feel like with the Claude models, it definitely tries a bit too hard to like, "cool, like, we've got the thing down. Let's go scale out a test suite."

And I'm like, "I didn't ask for that. Like, hold on, slow down."

John: Yeah.

Brian: Or like it creates all these scripts in your root. It's like these patterns of like, "oh, I could see it working," but maybe this is not how I actually want to write code or want to engage with those things.

So I've dipped into it. But I've also learned how to leverage the models for good and like, don't do a bunch of random scope-creep. And I think a lot of folks who've been heavily using these vibe coding platforms at all to these CLI tools and these interactions, you kind of learn where to go left and where to go right.

The challenge is juniors don't have that intuition to unblock themselves out of that.

Ivan: Yeah, exactly. But it's with everything. So I also use it for the non-coding where it's like I'm writing an email. Like really serious emails. I ask, "how will the other person interpret this?"

Or like if you get one, you're like, not sure what the person was trying to say. Like, "give me the bull-bear case. Give me all the variations." Because the model also doesn't know, but it can read it in multiple ways.

And also like, "don't suck up to me" is the end of the prompt. Don't bullshit me. Give it to me clear, right? So.

John: Yeah, yeah.

Brian: Amazing.

John: That's very true.

Brian: Ivan. Thanks so much for coming on and talking about Daytona, talking about runtime for agents.

Folks, if you're not already testing agents, test out Daytona. Get a hundred bucks in credit. And, with that said, stay ready.