The Missing Layer Between AI and Enterprise Deployment

[00:00:00] Guy: Hello everyone. Welcome back to the AI Native Dev, excited that you joined us today, and we have a really interesting conversation ahead of us, talking about sort of environments and how you kinda have AI co-generation maybe meet the real world where things actually run.

[00:00:15] Guy: And to help us dig into this and more, we have Ron Efroni, who is the CEO and co-founder of Flox, as well as the president of the NixOS Foundation. Ron, thanks for coming in. So, Ron, we’re gonna dig into, you know, like why agents even need environments.

[00:00:33] Guy: And where is this going and how can different tools around help with that. But just for context, a little bit of your world today, can you explain a bit of what Flox is, and maybe a little bit of what Nix is? 'Cause that's an important piece of

[00:00:47] Ron: Yeah, definitely. So, I’ll start off with Flox.

[00:00:50] Ron: Flox today is pretty much your universal cross platform environment manager. With Flox, it's open source. You can create these environments that can go into production, development, building and testing. And these environments are consistent, so you define them once. They can run on any OS, any architecture, lots of inbound from very complex spaces like hardware, security, AI, and financials using the product today.

[00:01:17] Ron: And all of this is based on the amazing magic that is coming in from Nix. So Nix is today, I think, the sixth largest open source project in the world. Over 10,000 active monthly contributors. And Nix is a lot of things. It's the largest package repository that's cross language, over 150,000 packages all the way to its own operating system.

[00:01:38] Ron: So you don't have to do an OS replacement. But Nix is a lot, it's a big community and it's pretty great.

[00:01:46] Guy: And maybe it's fair to say that Flox’s roots were to sort of take the power of Nix, sort of managing granular environments and make it usable.

[00:01:56] Guy: You know, make it a bit more, you kind of have to get a bit of a PhD to get going with Nix sometimes. When you do, you can do wondrous things with it. While Flox is more about, okay, how do we bring this power to the broader audience? Exactly.

[00:02:09] Ron: And the way I would think about it is that, again, Nix does so many things incredibly well. The three things that Flox cares about, and we really are trying to expose to engineers and more developers and democratize it.

[00:02:22] Ron: It’s, first of all, how Nix thinks about having a consistent architecture across pretty much any piece of software in history, right? If it's a dependency, a library, an environment, something that an agent is trying to pull or run, or an LLM, Nix says it's all the same thing. It's a Nix package. So that's the environment piece, that's the consistency in the stack piece.

[00:02:46] Ron: And then it starts going into the build area, creating a lot of ROI there and how Nix thinks about the build and reproducibility and determinism of the build. And the last space that Nix really is shining in my mind is the software supply chain security side.

[00:03:09] Guy: And I guess, it's interesting to think a little bit—this probably sounds more belittling than I mean it—but is whether Nix is like the alt messages of, the alt text of packages on it. Like a lot of it is descriptive of “I need these things to exist or run,” but it allows you to then operate with more specificity, but also in a way that thinks a little bit about when things get upgraded or the likes.

[00:03:40] Guy: So I guess, is Nix actually like a lower level than package management? More control and more granular? Or is it better to think about it as like an abstraction layer that sort of goes above?

[00:03:53] Ron: Yeah, I think that's a great question. The way I would think about it is, folks that are listening are familiar with virtual environments.

[00:04:00] Ron: I think it's like a virtual environment slammed into a package manager. So your question, I would say it's just a different way of thinking about package management. It's not necessarily lower level, it's kind of more on the same level with what we're used to. It just has a different way of defining it because Nix has a concept that we internally in the community call purity. Kind of an interesting word for a package manager, but it requires any piece of software, any piece of code that's derived into a Nix package to come self-contained with everything.

[00:04:34] Ron: It depends on recursively all the way down almost to the kernel. Other packaging managers might not require that. Nix comes and says, and this is why—it’s both a little lower level and to the side of what we're used to—because everything you pull from Nix, you're gonna be pulling with all it needs to be created, built, and run.

[00:04:51] Ron: And I think that's one of the core concepts that allow a lot of upstream benefits, like those things that I mentioned about reproducibility and determinism.

[00:04:59] Guy: Right. Yeah. Makes sense. So how do you see—one of the use cases for Flox that has been shining and growing—is in the context of AI and AI environments and agents.

[00:05:13] Guy: Can you tell us a few examples of how you see Flox and these environment definitions coming into play in the world of AI?

[00:05:19] Ron: Very early on last year,

[00:05:24] Guy: It's like 50% of Tessl's PET lifecycle or something.

[00:05:27] Ron: Yeah. That’s what I mean. So very early on last year, one of the big waves—when we started Flox about four years ago, and Flox has a history coming out of one of the largest quant funds.

[00:05:38] Ron: So there's a big scientific history to Flox with my co-founder Michael. But we weren't planning for AI when we were building it. Right. It was just that Flox came in and said, Hey, why can't this entire first four layers of software infrastructure be mushed into just one command?

[00:05:57] Ron: Where developers back then—humans—just didn't need to think about it. I think it's like the spec-centric aspect of what you guys sometimes talk about. Fast forward to last year when AI starts picking up and we see this wave come in of folks utilizing and building, like the AI engineers that need to access their systems, right?

[00:06:20] Ron: They need to accelerate the GPUs. Suddenly, they need to really work and stay in tune with things. And that's where we did feel a big wave come in because Flox can sit on anything. Flox can sit locally, it can sit in the cloud, it can sit in a container, but the local aspect was the most important because that meant that these engineers could actually touch and be aware of the system around them.

[00:06:42] Ron: Their environments were aware of everything going on—aware of the GPUs, the hardware on the machine—and that created the first wave. So that was the initial use case. Then, on the AI front, I think the most active areas are definitely folks creating environments for agents today. Because just like a human, Flox abstracts away the need to think about the infrastructure—we do the same thing for non-humans.

[00:07:13] Ron: And the thing about non-humans is that we're really trying to make it more reproducible on the output front. We've seen a lot of folks use that as a baseline.

[00:07:25] Guy: Right. And still on the first point—on being aware of the infrastructure—can you explain that a little bit more?

[00:07:34] Guy: So what does this awareness manifest as? I understand the need to reproduce what is sort of an elaborate production environment in your local dev environment. I guess that's part of the advantage of these reproducible environments—in the name.

[00:07:52] Guy: But what do you mean by hardware aware?

[00:07:54] Ron: Pretty much the way you should think about it is, Flox and containers work together. And if we want to, we can dive into that. But one of the main differentiations between Flox and anything like a container or a VM or a micro VM is that Flox is able to run fully locally with your system.

[00:08:12] Ron: While it creates the isolation via file path mechanism, Flox lives with the system—in the system. There's no abstraction. You don't need to poke holes to tell it to grab your GPU or do something with that GPU. And I think that was a very native initial adoption motion coming in from AI ecosystems that were just like—

[00:08:30] Ron: We need to use these GPUs for a plethora of reasons, in the initial front-running wave of AI.

[00:08:38] Guy: Yeah. Okay. So I think that really helped. A useful alternative that has not provided what was necessary was to say, okay, I want to create these shareable environments for my AI engineers, but then if I create a VM or a container, those are too far abstracted from the hardware. And then Flox solves that problem.

[00:08:58] Guy: It gives them the ease of portability while actually running on their machines so they can take advantage of it, which is the world of anybody building models or training models or frankly, even in inference, you need that proximity.

[00:09:14] Guy: I think it's kind of a useful mental model for Pro—probably more people are familiar with containers than with sort of Flox or those.

[00:09:24] Ron: A hundred percent. And the more recent, right? This like six to nine month stretch, which is part of the AI wave, is just that there's a little shift. I guess there's two groups thinking about local AI and cloud AI.

[00:09:40] Ron: And again, because of those core principles inside of Flox and Nix, there's also a huge wave of adoption from folks who are kind of like local AI first—where you can spin up your models locally, you can run all of that. And that's also another piece to it.

[00:09:56] Guy: I think so. I guess that's another interesting use case to understand AI.

[00:10:02] Guy: So if the first one was really applicable to people that are maybe closer to the science side of it, right? You want to run on it. As you get into inference and you talk about using AI, I think what we definitely find—we see this in our landscape and we see this in conversations with Tessl beta users and such—is how, and I was about to say the word disloyal, people are to their tools.

[00:10:28] Guy: People are very much in experimentation mode. They want to move around and they load up their machines with all sorts of things to try them out. They would use multiple IDEs, which, you know, was a heresy moments ago, right? Yeah. They're probably more loyal to VS Code than they are to Cursor or Windsurf or Copilot.

[00:10:48] Guy: And so as they build around, I guess the tactical advantage is just this ability to try out the thing quickly without messing up your system—while being able to run something like a local LLM in your setup. So I guess, I don't know if there's a question in there, but I just find it interesting. That's definitely an era of experimentation for

[00:11:16] Ron: Right.

[00:11:17] Ron: And that's definitely another core benefit that we're bringing in for that amazing open-source ecosystem. It's that the isolation happens via the local file system. So you can spin up and spin down these environments that have local LLMs or local models—have everything you need. And any time you do that, there is a hundred percent certainty of zero conflict on the system itself.

[00:11:39] Ron: So you can have Cursor running next to Windsurf, running next to five different models. All of them might be requiring different versions of a hundred different dependencies, and Flox would be able to actually self-sustain each of them, spin them up, spin them down—and you, the agent, the human—don't even have to care about it.

[00:12:01] Guy: Yeah. Very cool. Okay, cool. And that's kind of a good time to remind that Flox is really an open-source, open kind of core—actually more than open core—really properly open-source solution. And so I think we're describing and digging into it, but I think that gives the opportunity for everybody listening to try it out, but also for broader adoption as people experiment once again with these tools.

[00:12:26] Guy:

[00:12:27] Ron: Yeah. So I guess—and by the way, key point—everything I've mentioned up until now is open source and free. I haven't even touched anything that's not. Ah, yeah.

[00:12:37] Guy: Yeah. There's probably a whole business around it and all that, which is its own merit, but it's important to know this is readily available to you.

[00:12:44] Guy: Cool. So maybe let's expand a little bit out of—so like Flox is a means of enabling some sort of, I guess, environment-as-code in an easy fashion to define it, I guess. We talked about more tactical use—AI engineers being able to work or experiment.

[00:13:05] Guy: Maybe let's dig a little bit more into this agent use case that you brought up. I guess what is the value proposition or the problem to be solved that you're seeing people use environments-as-code, specifically Flox, for agents' evolution?

[00:13:24] Ron: Obviously opinionated take, right? This could change probably 50 times between now and two weeks from now when DeepSeek 5 comes out. I think the core concepts of Nix and Flox, when we were building it, still stay the same, right? Because at the end of the day, something is writing code, something is deploying that code.

[00:13:47] Ron: Someone is using that code. And here's my opinionated take: the more progress we can make on making the output from humans or agents—or any mix between—to be deterministic, to be more trusted, the more ROI we're going to get out of AI. Because I think about it as human assist and human replace.

[00:14:16] Ron: Not replace me in the evil kind of way, like we don't need engineers, but just more in the sense that it's actually giving me, an engineer—or me, Ron—value over necessarily building another new feature on top of AI. When I think about it this way, what Flox does today and what Flox represents for me in the agentic world is that bottom three steps of infrastructure.

[00:14:42] Ron: If we can go and tell you that you're just going to tell us what you need, Flox is going to create that for you. It's going to have full reproducibility, full isolation, no conflict, and it's going to output the same thing every time you give it the same input. We just maybe took a ten-step stack and told you the first three steps are solid.

[00:15:05] Ron: So I think that's one of the big use cases for agent systems—they come in, they use Flox for those reasons. That's one. The second piece is that with Flox, it allows, just like humans, for the agents to run, test, and deploy software on whatever the latest and greatest is. They want to run it on some Linux variant at 8:00 AM, and at 10:00 PM there's a recommendation that shifts some of the model to test it locally or in ten different case variants for a hardware-software mix. The Flox environment will stay consistent. Neither the agent nor anyone else needs to change it.

[00:15:45] Ron: And the last thing I'll say on that general thread—again on the opinionation side—is I think the highest paid engineers are going to start becoming the test engineers, the QA. I don't even know how we call that yet. I don't think we yet have a name for it, but it's the engineers that take millions of lines of code and somehow—as humans—validate it.

[00:16:06] Ron: There's going to be a validation phase at the end. And imagine that whatever that code is—as long as the Flox environment was the baseline for it—anything else can take it, slap it onto something, and run it. So I think there's going to be a huge portion of portability that comes into it that Flox provides today for agents.

[00:16:27] Guy: Yeah, I think so. Very good point. I feel like each of them kind of needs a bit of a breakdown. And I think the meta point that I'm getting from what you're describing—which is an analogy that I like—is that AI and agents, what they do is supercharge patterns that we've already seen in the real world.

[00:16:45] Guy: So maybe before you could rely on people keeping their environments in sync and being able to represent what happened in production—and create something that is similar to what they created previously in the test environment. As you supercharge it and you turn it from something that happens once a day to something that happens once a minute, then any percentage deviation from accuracy starts multiplying and becoming unusable.

[00:17:14] Guy: Exactly. Is that right?

[00:17:17] Ron: Exactly. And the simple way—and I obviously don't want to call out different products—I test different products all the time. I just built another app a few days ago to test the waters and see where things are, and it's freaking amazing, right?

[00:17:31] Ron: As long as it's simple, you define the app. You define it as a spec. You define it with English instead of code. It goes and builds it, hooks up the database product, hooks up everything for me. I only needed to do the authentication and the connections. But then I thought—okay, this is super basic.

[00:17:47] Ron: I want to take it away and build on top of it. That transition from agent to human wasn't as easy as I would have wanted it to be. And I think that's going to be a big part of it. We've seen it before, with all the other waves—from cloud to local, or just from one engineering team to another.

[00:18:10] Guy: Exactly. Distributed engineering teams are sort of the same. So it's a multiplier, but it may happen more—and might happen between agents too, like two different agents doing it. So I think in the three bullets you mentioned before, the notion of trust really is: hey, there's a whole bucket of problems that might occur because you set up the environment incorrectly.

[00:18:33] Guy: Maybe in an alternate universe, or another alternative you have, is to have the agent make up an environment, create a bunch of commands that it's going to run, and create that setup based on some instruction. If it's doing it every time, it's not going to do it the same every time.

[00:18:49] Guy: So can you make that deterministic set? Right. That makes sense. That's a bullet—or a bucket—of useful items, and that increases trust because it reduces variability. We'll talk later about generating environments—that's probably its own kind of creature—but at least for now,

[00:19:07] Guy: So that’s a trust-building exercise. And then subsequently, there's the portability or reproducibility piece of: can you hand it back over to me and avoid the “works on my machine” type environment and move it over. So I guess that’s bucket two—or maybe I’m mixing in your bucket two and bucket three.

[00:19:29] Guy: Which you also mentioned: consistency or consistent delivery. I probably blended a little bit of your three bullets, but it's about controlling the variability in a world that's naturally statistical—to at least not multiply the other variables. And then, being able to do handoff—whether it's between agents or between agent and

[00:19:49] Guy: In a clean order.

[00:19:50] Ron: Exactly. And if we're looking at the opinionated five-year vision for some of the AI-native areas—just like code switches hands, human hands—developers move companies, they move teams. This year, to your point earlier, folks are jumping around between different editors.

[00:20:11] Ron: I can totally imagine us using one agentic platform one year, and then the next year the latest and greatest, the smartest agent platform is a different one. Maybe because I'm paying more of a premium or whatever the new ecosystem is. But I want that agent system to be able to tap into my code just like I want a senior engineer swapping into the team to tap into the code immediately.

[00:20:34] Ron: And I think that's going to be a big part of being—at least that's how I see AI-native in the future. Can you actually be AI-native in that world?

[00:20:44] Guy: Yeah, I think that makes sense. But I feel like, to me, that opens up a slightly different question, which is, okay. What we talked about up until now is just about reproducible environments, right?

[00:20:53] Guy: And then, there are multiple ways to achieve reproducible environments. One I think you're referring to that's easy to disqualify is a specific platform offering you its own reproducible environments—correct. You know, heck, using Flox behind the scenes. But if it doesn't show that, then for all intents and purposes, you can't move from one agent framework to another if you've defined your environments within that, with no sort of standards.

[00:21:15] Guy: So I think that one's easy. I don't know if there's a ton to say. We'd benefit from standards. The world of open source is there for a reason. I think the second one is more interesting, which is—probably by default—if I was to approach this and I'm just less up to speed on the latest, I might default to containers. I'd say, well, containers are my shared environment. That's how I define my infrastructure, my production environments. So how do you think about the pros and cons or sort of differences between using these declarative Flox definitions versus, I don't know if I'm presenting it correctly, and a built container?

[00:22:03] Ron: So I think the way we look at it today is that—first of all, why not both? Right. I think containers—again, opinionated—and I know for many people, containers are a lot of things. I think containers inherently came in and solved the world's problem about the transportation layer, the orchestration layer. I think that's where containers are amazing, right? You have an Amazon facility, everything goes into boxes. And those boxes, guess what, are really easy to ship around because they're square. They fit in things that are square. We humans like square-shaped things.

[00:22:44] Ron: I think where there's a heavier differentiation is in how you define that container and what can move under you. That removes the reproducibility and determinism. At the end of the day, it doesn't matter how well defined your container is—and I think best practices around containers are usually not that well followed. Even if you do define the container as well as you can, you still have layers on the operating system that can move from underneath you. That makes it significantly less reproducible to an extent that—in my opinion—it doesn't matter when you have such a hyper-scaled world with everything building code and deploying it at 10x, 20x, 100x.

[00:23:24] Ron: So in my mind, it's pretty much free to go and define that container with Flox and now be able to make sure that you have that full reproducibility and then run the container and do your flows. But once you've set up that environment concept with Flox, two things now happen.

[00:23:44] Ron: One, whenever you want to move off containers—when you don't want to necessarily use them for developing parts. I'm not talking about orchestration. I think that's where containers stay strong. But for the dev environment, the builds, that whole ecosystem—whenever you want to move off it, you have a common baseline to do so. You can move back to the local, to the latest and greatest thing. You can use agents that prefer containers and agents that don’t. You become agnostic to it. That's very powerful.

[00:24:16] Ron: The second piece is exactly that—where you have that spec-centric definition. Again, I hope I'm using your words right—but you have that definition at the base layer that scales throughout time with you. You always have that in your back pocket should you want to pull it out. And yeah, we have a large doc on this. Today, Flox and containers go hand in hand. If you want to continue the container flow—great. You just added another value point for yourself, almost for free.

[00:24:46] Guy: Yeah. I think that makes a lot of sense. Part of it is like AI is the great multiplier, including multiplying probabilities. And containers—it’s not that hard. Especially if you're pulling from latest as a base image. You build today, you build next week—you’re very unlikely to get the same environment. It doesn't take long to get into that stage.

[00:25:14] Ron: Right. And some of the additional use cases there—we said it earlier—if you need to take a container into development and start poking holes at it, then what's the point of putting things in a box? Use Flox for the local things that need to be system aware and those more complex areas. Then check it into a container when you're ready to ship it. Can you ship it with Flox and Nix? 100%. But that’s not something you have to do today. It’s all integrated.

[00:25:47] Guy: Yeah. I do think—I don’t know if there is a correct way to use spec-centric. I think it’s intentionally broad. But it does rhyme well with declarative, and the idea of saying containers are an implementation of your environment. And once again, you don’t really have a higher-level abstraction of what it is you’re trying to achieve. If you go to a higher level, you have something inherently more portable and adaptable.

[00:26:35] Guy: We talked about spec-centric development being a means of creating software that is adaptable because it takes in relevant context and generates the implementation that's right for it. Maybe today in a good percentage of the cases, it’ll be a container. But even earlier, you pointed out proximity to hardware. Maybe you want a tool with direct GPU access. Maybe containers offer you that—maybe they don’t. But you have a choice.

[00:26:50] Guy: One more interesting thing—the pace AI multiplies. Part of it is the frequency of actions. How often is code deployed or tested? And with that comes the pace those actions take place, and therefore the overhead tools create. At Teal, we generate code in many ways and kind of abuse it. We try to have some version control that tracks all these changes.

[00:27:32] Guy: We defined that Git is a slowdown factor. It's not optimized for that use case. In a good subset of cases, we needed something else. The team has literally written a service called NotGit—to clarify it's not Git—but it feels like Git. It’s fast and local. Not as fully featured, but it allows for many more cycles. So depending on what you want your agents to do, maybe the ramp-up and down of containers or the speed of execution plays a role.

[00:28:11] Ron: I fully agree with you. I'm sure cloud-native had a lot of meanings to many people—and still does. We were just asked on a procurement form about AI-native. One of the things it means to me now—and the difference—is the speed of change, the speed of iteration. Having more solid ground to stand on is always a net benefit. If the bottom rungs of your infra are more solid, that speed of iteration—you’ll be more resilient to it.

[00:29:09] Ron: I think that's another part of AI-native. Things are moving so fast. It's not just about moving to a cloud provider or operating in a cloud ecosystem. AI-native takes it to a whole other galaxy.

[00:29:15] Guy: Yeah. I think we’ve spent a decent amount of time here talking about environments. First of all, we kind of skipped over the fact that agents need environments because they need the code they generate to face reality. They need to run it or get some kind of execution feedback.

[00:29:34] Guy: We kind of skipped over that, but I think it's core. Is that indeed the kind of agent environment you're seeing most commonly? I created some code and I need a place to run it to see if it works?

[00:29:59] Ron: Yep. I think it's definitely the testing, the validation, the build areas. One of the most beautiful things—we didn’t talk about Nix that deeply—but Nix, 20 years ago, redefined the SDLC. It said we don’t start with the developer environment. If we start with the build and define it, we get everything else for free.

[00:30:23] Ron: Coincidentally, I see that aligning very well with agents. The first time an agent really cares about the ecosystem is when it's trying to build that code. Test it, check for exceptions, check for bugs—whatever it is. That’s why I’m starting to see Nix and Flox really align with this thinking. That’s also why we’ve been seeing huge growth over the last year or two.

[00:30:55] Guy: Yeah. That makes sense. It needs to be lean, fast to execute, and portable. The other thing we didn’t talk too much about—but I think it’s core—is reproducibility between the output of tools.

[00:31:19] Guy: You can think of three domains in which environment management manifests in AI—probably more like four. One is runtime—we’ve covered that. I need a place to run code. The second is generating an environment. The third is picking an environment or tool use, maybe even learning over time. We’ll get to that. Let’s talk about the second—tools like vibe coding tools—they try to give you an output that would run somewhere, so they need to generate an environment.

[00:32:02] Guy: Has that been a use case you’ve seen? And is it one you think is important?

[00:32:14] Ron: We're very much seeing it come up. It's a newer aspect—everything is new. One year is a lifetime. We're seeing it more in the last one to two months. A lot of these vibe coding products are trying to maximize time-to-market. They're not yet thinking about handoff, sustainability, or high-impact long-term products.

[00:32:40] Ron: They’re thinking: how do I release? Someone told us at a dinner about building a Bingo app while in line at a concert. Her friends wanted to have fun—that's what vibe coding is for. They even optimize to let you self-deploy on their platform. They minimize human interaction after that. And that saves them from thinking about: What environment do I need? Will someone work on this six months from now?

[00:33:31] Ron: In the last few months, a lot of these vibe coding products are starting to think: How do we monetize more? How do we build a sticky customer base? That’s led to inbound conversations with us. So much so that it’s made us think: What does it mean to be the bottom rung of infrastructure for an AI-native world—with all this data about what are the best packages, dependencies? What is the fastest, most secure?

[00:34:01] Ron: That gives us a glimpse into what AI environment creation could look like. So that’s a quick—not so quick—thought from my end.

[00:34:15] Guy: Yeah, makes sense. I like analysis. I love the term "minute app." I hadn’t heard that. I’ve heard of disposable apps, but minute apps make me think of food.

[00:34:24] Ron: Same here. It makes me think: Would you serve this? Probably not.

[00:34:30] Guy: But if you’re home and hungry, and that’s what you've got—then yeah. I like the term. I think it’s legit. Vibe coding platforms especially are trying to just get you something working. That’s both a pro and a con. In the short term, they benefit from prepackaged environments. They can pull one off the shelf and run it.

[00:35:00] Guy: Though maybe they don’t care about variety. Many pick a specific stack—like Supabase—and harden that environment. But as they think about reproducibility and the long-term, the other key is portability. Especially open-source ones—like Allhands—may generate a more portable format, so you can run it anywhere.

[00:35:42] Guy: SaaS platforms might say, "I'll handle it end to end." That’s back to standards. It allows for chains of tools. It means one tool doesn’t have to be best at everything—codegen, deploy, operate. Another tool can be picked up because they share a common language.

[00:36:15] Ron: That’s another strong opinionation for the future. Could there be an AI Skynet that does it all—and gives us a curfew at 8 PM? Hopefully not. At the end of the day, there will be products, companies, and agents that specialize. The ecosystem is going to be rebuilt.

[00:36:27] Ron: You have the AI stack that you guys are building. I think we’ll slowly see that condense into the AI-native stack—what you use for each part of your flow.

[00:36:52] Ron: And maybe the infra map and SDLC will look totally different. Maybe it won't be code, build, deploy. Maybe it'll focus more on testing. At the end of the day, I think you're 100% right. We're going to have different products, different agents that specialize in various areas, and they'll need to interoperate.

[00:37:09] Ron: Maybe not as much as twelve separate teams across a large company needing to build out a product. Maybe it's just three. But you're always going to have that transition. I don't think one agent or one company will be able to do everything the best.

[00:37:27] Ron: I think you're going to have a whole ecosystem built around it.

[00:37:31] Guy: Yeah, I think a lot about the right scope of tools in the world of AI dev. I said this a while ago in an episode—there are two trajectories. One is a big brain platform that needs to know it all. It’s the super-intelligent Skynet environment. We become dependent on it for everything, and if it fails, we're stuck. Maybe we learn to be power users of it.

[00:38:05] Guy: I think that's a sad reality. It limits innovation. It means someone with a great new idea can’t participate. There's another reality where we have a chain of tools and allow different components to blend.

[00:38:24] Guy: We had Matt Billman from Netlify on the show—serial co-founder. He had great insights. He’s passionate about the web manifesto and the open ecosystem. He talked about how tempting it is to lean into the closed garden due to the non-determinism in AI.

[00:38:51] Guy: One way to mitigate that is to stay in a closed environment—fewer variables. It's tempting and sometimes faster to get something working. But as a development ecosystem, we want openness. We want to hand things off between tools. Each tool should be best-of-breed at a particular phase.

[00:39:12] Guy: I like the idea of open environment definitions. Environments are overlooked in software. Platform and ops people understand their importance, but many developers don’t think about them enough.

[00:39:32] Guy: I like investing in agents with outputs that are portable and standards-based.

[00:39:44] Ron: And obviously you're talking to someone biased—I'm running open. I won’t disagree. Every AI agent—again, opinionated—is going to be specialized. Whether you're building the best agent for testing or for biotech development, there will be an open-source equivalent.

[00:40:03] Ron: Even if you have AI Skynet, there will be open-source AI Skynet. Whether that's scarier depends on who owns the closed one. Your point catalyzed a realization—even if we don’t have multiple companies in the stack, we’ll have open-source vs. non-open-source best-of-class already. Traversing between them lets us go further.

[00:40:48] Guy: Yeah, I fully agree. We’ve talked about runtime—how defining environments can make agents better. Then we discussed outputs—creating runnable apps and environments in an open standard. Flox is a contender for that.

[00:41:11] Guy: The third part is the environment as a tool. As developers, we get better at choosing tools—including SaaS apps, containers, etc. How do you think about empowering agents with environments to improve their decisions and capabilities?

[00:41:47] Ron: We're spending a lot of time thinking about how to solidify the first step of infrastructure right above your OS. We're also seeing data on what it means to build best-in-class environments. What runs faster, more reproducibly, more deterministically—we're learning all of that.

[00:42:34] Ron: The next step is this: eventually the human or agent just tells us what they’re trying to do. You won’t need to specify Python 3.12 or some database version. You describe your intent—like you do with the agent—and the infra layer outputs what’s needed for consistent environments.

[00:43:00] Ron: I think that's where environment creation is heading. Say I want to build a voting app for my family where everyone can see votes live. The agent translates that, builds code, and we either read the code or the description and know what to pull in.

[00:43:39] Ron: That process can be bidirectional. The agent tells Flox what it's trying to build—we generate the environment. Or Flox suggests the ideal environment, and the agent builds on it. That’s where we’re heading.

[00:44:14] Guy: That’s interesting—it blends into application creation. Today with vibe coding, you don’t run into these problems because platforms offer confined, predefined environments.

[00:44:46] Guy: Say you deploy to Netlify or a specific React stack—they’ve chosen the environment. They only generate code for that stack. So the pain isn’t felt yet, but it will be.

[00:45:19] Ron: Look at our careers—software is specialized. Job descriptions require years of language-specific experience because you gain intuition about which packages are best. In the future, we’ll 10x or 100x the space by defining the best requirements.

[00:45:49] Ron: These apps today can create minute apps. In the future, they'll create a hundred minute apps, ten-year apps, maybe even hundred-year apps.

[00:46:05] Guy: I think environments are overlooked due to speed being a focus in AI generation. From my lens, people building with AI focus on enabling agents. They want to create code. To do that, they need environments to run tests, tools, etc.

[00:46:37] Guy: They’re not thinking about outputs—they’re in closed gardens. They’re not focused on declarative patterns—it's already hard enough to get correct code generation. And long-term viability isn’t a concern. There’s no thought about what happens when an environment needs updating.

[00:47:22] Guy: That’s seven or seventy steps away from the current top-of-mind issues. Yet it feels foundational for software longevity. Is that a fair read? Do most people build environments just to test code vs. aiming for portability or declarative outputs?

[00:48:21] Ron: I think agents today optimize for the minute app—basic, low-cost outputs. Users ask for something simple. Agents spin up environments, test it, and ship it. Environments are transactional in that flow.

[00:49:02] Ron: But lately, teams are realizing minute apps are becoming commoditized. Many tools can generate voting apps that hook into Supabase. Now they’re thinking: where’s the ROI?

[00:49:31] Guy: And the differentiation.

[00:49:34] Ron: Exactly. They're starting to say: we need a baseline. Our users need to export apps and work on them easily—like sitting on the same team with the agent. That’s where we move from human assist to human replace—in tasks that let humans focus on innovation.

[00:50:01] Ron: The agent becomes a team member, not just an intern making a lunch-ordering app that we throw away in three weeks.

[00:50:16] Guy: Yeah, and in that sense, we must think long term. You wouldn’t keep hiring someone who only builds three-day apps.

[00:50:30] Ron: There are use cases for that, but the differentiation and market cap will be very different between minute apps and platforms that scale into large ecosystems.

[00:50:44] Guy: Yeah. I don’t think either of us are dissing today’s apps. They’re magical. They help us tap into the power of AI. But it’s important to think about the gaps between now and the future.

[00:51:04] Guy: I’ve got one more question on environments, then want to ask about that dinner you mentioned. Just one more—CPS is all the rage. I know you have Flox Hub, which holds tons of environments. From a layman's view, it feels like an ideal front-end for MCP. Have you thought about that? What's your view?

[00:51:34] Ron: So—I was going to say something obvious. My head of marketing Ross—super creative—has a saying that stuck with me. When we started looking into MCP—because Flox has been exploring it—he told me: MCP is like giving a super sharp machete to a random number generator.

[00:52:03] Ron: It's like giving HAL 9000 arms and legs. From the MCP front, at the end of the day, it's just a more capable version of what we're doing. Suddenly, this AI has limbs. This agent can actually go out there and, in the real world, potentially hook up to my email, respond to my banker, review the tip amount to ensure I wasn't scammed—access my bank account.

[00:52:29] Ron: We think MCPs will run software. That software must be reliably provided upfront or dynamically available for agents to extend. From our perspective, that sense of reliability increases. If I'm going to sell you an agent connected to external real-world services, and we don't have that AI trust and reliability, that's just a more dangerous random number generator with a machete and your name on it.

[00:53:28] Guy: Yeah. It's interesting. You're consistently pointing out one of the key challenges: the degrees of freedom—how much can change. MCP is like an API with no structure. That may or may not work.

[00:53:40] Guy: Today, it shines in attended workflows. You give it tools, but if it blunders—cuts off a leg—you at least notice it before approving. That’s a safety net.

[00:54:01] Guy: People talk a lot about MCP as a tool call interface. I actually really like the resources aspect. It gives LLMs awareness and access to environments—like those from Flox—that they can pull down reliably.

[00:54:33] Guy: We've been having immense fun with it—hooking it up to various things, experimenting with partners. MCP is great.

[00:54:48] Guy: It really is. The flexibility leaves room for creativity. But I think it’ll become more structured—or at least offer stricter modes—over the next year.

[00:55:08] Guy: Just before we wrap up, I know you recently hosted a pretty big dinner with some of the top AI companies—both those building with AI and those laying the foundations. Curious what stood out to you from that?

[00:55:42] Ron: One thing was AI's impact on developer productivity. It's still hard to quantify or use for strategic decisions. Even before AI, measuring developer productivity was tough. We had things like inner loop, outer loop, lines of code—all nonsense. So it's comforting to know others are still struggling with this too.

[00:56:27] Guy: Another example of AI being the great multiplier. Developer productivity metrics have always been a challenge—maybe now we have more motivation to track them. I wonder when we’ll start talking about agent productivity.

[00:56:48] Ron: I've seen a few people already start talking about that. The second topic from the dinner that stuck with me was this glass ceiling. How do we push innovation in AI trust rather than just doing more with AI? I used a food metaphor: I want AI to be my sous-chef. I don't need it to make a star meal—I want it to slice bread consistently and lay it on the table so I can focus elsewhere. The problem is, even the best models mess up occasionally. Sometimes they lay rocks on the table or use machine oil instead of olive oil. That inconsistency stops me from fully stepping away and trusting it.

[00:58:06] Guy: Is the issue that AI needs to be more deterministic or that humans need to adjust their expectations?

[00:58:25] Ron: Great question. First, we do want more repeatability. If I ask it to cut bread and place it on the table, I want that to happen most of the time. Humans make mistakes too, sure, but we have a psychological threshold. Second, maybe we do need to lower our standards. Our benchmarks are based on humans with decades of experience. Maybe we just need to label AI responses more clearly—"written by Ron's AI," for example—so people don't expect perfect human phrasing. It's both about shifting expectations and improving AI consistency.

[00:59:49] Guy: Which is especially interesting in software, where we expect determinism. But environments and data can break that illusion. Still, we hold AI to that same high bar.

[01:00:10] Ron: One idea was that maybe these minute apps are just the new normal. Maybe 50% of software becomes disposable—like a cup. Every few weeks, you ship something new with updated features, and no one needs to reproduce the old one. That’s just how it works in some cases. It's more a psychology question than a technical one.

[01:00:47] Guy: Interesting. And I think you had one more takeaway?

[01:00:54] Ron: Yeah, career progression. In startups and tech companies, the traditional path—become a manager, then manage managers—is breaking down. In an AI-native world, maybe we don’t need middle management. Maybe one person can manage 500 reports. So how do we motivate and grow individuals when the ladder isn’t so obvious anymore?

[01:01:51] Guy: Big, important question. Thanks for all the insights—on environments, agent infrastructure, and everything you shared from that dinner. One final question, tying back to career paths: If you had a 15-year-old child today, would you want them to study computer science in college?

[01:02:31] Ron: I'm biased, but absolutely yes. The fundamentals haven’t changed in decades. They’re still essential. My biggest recommendation is to go T-shaped: go deep in one area first—understand the fundamentals. I don’t care if you start with Python because you like snakes or pick C for some reason, just learn the why and how beneath it. Then build breadth. Even as we move from code to English-as-code, someone still needs to understand what’s really going on. That foundation will always be valuable.

[01:03:55] Guy: Cool. Super insightful, Ron. Thanks again for coming on to share your learnings, and thanks everyone for tuning in. Hope to see you next time.

[01:04:05] Ron: Thank you, Guy. Awesome being here.