One CEO’s Plan to Rebuild How We Deploy AI | Ron Efroni & Flox

13,000 words · about 52 min to read · YouTube’s automatic captions

AI agents multiply accuracy deviations rapidly

0:00 When we started Flock about four years ago, we weren't planning for AI when we were building it. It was just that Flocks came in and said, "Hey, why can't this entire four first layers of software infrastructure be mushed into just one command?" Fast forward to when AI starts picking up. That's when we did feel a big wave come in because flocks can sit on anything. 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. What is the value proposition or the sort of the problems we solve that you're seeing people kind of use environments as code specifically flocks for agents. The core concepts of mix and flocks when we were building it still stay the same. The more progress we can make on making the output from humans or agents or humans and agents or whatever mix we have in between to be more trusted, the more ROI we're going to get out of AI. AI and agents, what they do is they supercharge patterns that we've already sort of seen in the real world. And as you supercharge it and you turn it from something that happens once a day to something that happens once a minute, any percentage

1:01 deviation from accuracy over here starts multiplying and becoming usable. Hello everyone, welcome back to the AI native dev. excited that you joined us today and we have a really really interesting conversation ahead of us talking about sort of environments and how do you how do you kind of have AI code generation maybe meet the real world you know where things actually run and to help us dig into this and more we have Ron Fronny who is the CEO and co-founder of flocks as well as the president of the Nyx OS Foundation Ron thanks for coming on to the show yeah definitely super excited to be here guy uh so uh Ron just we're going to dig into you know like why agents even need environments and and where is this going and how can different tools around help with that? But just for for context a

Flocks provides cross-platform environment consistency

1:55 little bit of uh of your world today, can you explain a bit of what flocks is uh and maybe a little bit of what Nyx is because that's an important piece of its background. Yeah, definitely. So so I'll start off I'll start off with Flock. Uh Flock today is is pretty much your universal crossplatform environment manager. With Flux 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. Uh lots of inbound from very complex spaces like hardware, security, AI and and financials using the product today. And all of this is based on the amazing magic that is coming in from Nyx. So Nyx is today I think the sixth largest project open source project in the world over 10,000 active monthly contributors and Nyx 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. So you don't have to

2:55 do a OS replace but um Nyx is a lot. It's a big community and it's it's pretty great. Yeah. And I think it's it maybe it's fair to say that like Fox's roots were to sort of take the power of Nick. of sort of managing kind of granular environments and kind of make them make it usable, you know, make it a bit more you kind of have to get a bit of a PhD to get going with Nyx sometimes on it. When you do, you can you can do wondrous things with it while sort of flux is more about okay, how do we kind of bring this power to uh to the broader audience. Exactly. And and the way I would think about it is that again Nyx does so many things incredibly well. the three things that flocks cares about and and we really are trying to expose to engineers and more developers and democratize it. It's uh first of all how how Nyx thinks about having a consistent architecture across any pretty much piece of software in history, right? If it's a dependency, a library, an environment, something that a agent is trying to pull or run or an LLM, Nyx and says it's all the same thing. It's a Nyx package. So that's the environment

3:58 piece. That's the consistency in the stack piece. And then it starts going into the build area, creating a lot of ROI there and how Nyx thinks about the build and and pretty much reproducibility and determinism of the build. And the last space that Nyx really is is shining in my mind is the software supply chain security side, but that's kind of um on the right, right? In in a lot of uh kind of tracking I guess of what everything that has happened in the process of that. Yes.

4:23 It's interesting to think a little bit as this will probably sound more belittling than I mean it but uh is is whether Nyx is like the alt messages of uh the the alt text of uh of packages on it like a lot of it is like it's descriptive of I need these things uh to exist to run but it allows you to then sort of operate with with more specificity but also in a way that that thinks a little bit about when do things get upgraded or or the likes. So I guess is it is Nyx actually like a lower level than than package management? It's actually like more control and more granular or is it better to think about it as a as like an abstraction layer as something that that sort of goes above.

5:04 Yeah, I think that's a great question. I

Purity enforces self-contained recursive package dependencies

1 Highlight · Why Nix packages require complete self-containment

5:05 think so so the way I would think about it is is folks that are listening are are are familiar with virtual environments. I think it's like a virtual environment slammed into a package manager allin one. So your question I would say it's just a different way of thinking about package management. Mhm. So it's not necessarily lower level. It's kind of more on the on just on that same level with what we're used to. Just it has a different way of defining it because Nyx has a concept that we internally in the community call purity. Kind of a you know it's like an interesting word for a package manager, but it requires any piece of software any piece of code that's derived into a next package to come self contained with everything it depends on recursively all the way down almost to the kernel. Mh.

5:48 So other package managers might not require that. Nyx comes and says, and this is why it's like both a little lower level and to the side of what we're used to because everything you pull from Nyx, you're going to be pulling with all it needs to be created, built, and run. Um, 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 from Nick. Yeah, makes sense. So I guess how do you how do you see I know one of the of the use cases for flocks that has been sort of shining and growing is is in the context of AI and kind of AI environments and agents. Can you tell us

6:22 a few examples of how you see flocks uh and and kind of these environment definitions come into play in the world of AI? Yeah. So very very early on last year it's like 50% of CHP's lifespan or something like that. Yeah. Yeah. That's what I mean. So very early on last year one of the big waves because we when we started flocks about four years ago and flocks has a history coming out of one of the largest quan funds. So there's like a big scientific uh I guess I guess history to flock with my co-founder Michael but we weren't planning for AI when we were building it right. It was just that flocks came in and said, "Hey, why can't this entire four first layers of software infrastructure be mushed into just one command where developers back then, right? Humans don't need to think about it, right? I think it's like the the specentcentric aspect of what you guys sometimes talk about." Um, fast forward to last year when when AI starts picking up and all of a sudden we see this wave come in of actually uh the folks utilizing and building like the AI engineers that need to access their

7:22 systems. Mhm. Right. They need to accelerate the GPUs all of a sudden. They need to really work and and stay in tune with things and that's where we did feel a big wave come in because flocks can sit on anything. So flocks can sit locally, it can sit in a 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. Their environments were aware of everything going on. So they were aware of the GPUs, they were aware of the hardware on on the machine and and that created the first wave. So that was the first initial use case.

7:57 Then uh the on the AI front, I think the most the most active areas are definitely on on on folks creating environments for agents today because just like a human flocks kind of abstracts away the need to think about the infrastructure. We do the same thing for also non-humans and the thing about nonhumans is that we're really trying to make it a bit more again reproducible on the output front. So we've seen a lot of folks use that as a baseline, right? And I think uh so so we're still on the first point on sort of being aware of the infrastructure. Can you kind of explain that a little bit more? So I guess what what does this awareness manifest as? I I understand the need to to reproduce what is sort of an elaborate production environment in your sort of local dev environment. I guess that's part of the advantage of these reproducible environments. I guess like uh in in the name uh on it. But what do

Local execution avoids container GPU abstraction layers

2 Highlight · Local environments provide direct hardware and GPU awareness

8:50 you mean by hardware aware? So, so pretty much the way you should think about it is is is flocks and containers they they work together and if we want to we can dive into that but one of the main differentiations between flocks and anything that that that like a container or VM or a microVM is that flocks is able to run fully locally with your system. So while it creates the isolation via file path mechanism, Flux is with the system in the system.

9:17 There's no abstraction. So you don't need to poke holes to tell it to grab my 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 we need to use these GPUs for a plethora of reasons, you know, in the initial frontunning wave of AI. Yeah. Okay. So I think that really helped. So uh I think a useful uh uh maybe like alternative that has not sort of provided what was necessary was to say okay I want to create these sharable environments for my AI engineers but then if I create a VM or if I create a container those are too far abstracted from the hardware and then Fox kind of solves that problem gives them the sort of the ease of portability while sort of actually running on their machine so they can take advantage of it which in the world of of anybody kind of building models or training models or sort of frankly probably

10:07 inference you need that proximity um and and I think kind of a useful mental model probably more people are familiar with containers than uh um than with sort of flocks or those local environments or exactly 100% and and the one more recent right this like six to n month which is again part of the AI wave is is just that there's a little shift and I guess there's two groups thinking about local AI and cloud AI um and again because of those core principles inside of flocks and nicks there's also a huge wave adoption of 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 that's also another another piece to it I think. So so I guess that's sort of another um interesting use case to sort of understand in AI. So this if the first one was really like applicable to people that are um maybe uh closer to the science side of it, right? You want to run on it as you get into inference and you talk about sort of using AI. I think what we definitely find, we see this in our landscape and we see this uh just sort of in conversations with uh with

11:08 kind of Tesla beta users and such is how uh and I was about to say the word disloyal, you know, sort of people are to their tools like people are very much in experimentation mode. Yep. They want to move around and they kind of load up their uh machines with all sorts of things to try them out. They would use multiple idees which you know was a heresy uh moments ago, right? they're probably more loyal to VS Code than they are to Cursor or Windsurf or uh or Copilot. And and so as they build around, I guess the sort of tactical advantage is just this um uh ability to try out the thing quickly without kind of messing up your system while being able to run something like a local LLM uh in your in your setup. So I guess you I don't know if there's a question sort of in there but I just find it interesting which is it's of an era of experimentation you know for many developers right and that's definitely another core benefit that we're we're bringing in for that amazing open source nicks right it's that the isolation

12:10 happens on the via the local file system so you can spin up and spin down these environments that have local LLMs or local you know have everything you need and any time you do that there is 100% certainty of zero conflict on the on the system itself. So you can have cursor running next to you know winds surf running next to you know five different models all of them might be requiring different versions of like of hund different dependencies and and flux would be able to actually self- sustain each of them spin them up spin them down and you you the agent the human don't even have to care about it. Okay, cool.

12:45 And it's kind of a good time to remind that Flux is is really sort of an open source open kind of core actually more than open core really like properly open source solution. And so I think we're sort of uh you know describing and kind of digging into it. But I think that gives the opportunity for everybody listening to try it out but also for kind of the sort of broader adoption as uh as people experiment once again with sort of uh with these tools. Yeah. And by the way on that point everything I've mentioned up until everything I've mentioned up until now is open source and free. So I haven't even touched anything that's that's not yeah there's probably a whole business around it and all that that that that is its own merit of it but it was important to sort of know this is kind of readily available to you. Cool. So maybe let's sort of uh expand a little bit out of so like you know flux is a is a is a is a means of enabling some sort of uh I guess kind of environment as code uh in an easy fashion to define it. I guess you know we talked about more tactical you know AI engineers being able to work for sort of experimentations. Uh maybe let's take it a little bit more into this agent use

13:47 case that you that you brought up. I guess what is the the the value proposition or the sort of the problem to be solved that you're seeing people kind of use environments as code specifically flocks uh for for agents. So, so obviously opinionated take, right? This could change probably 50 times between now and two weeks from now when Deep Seek 5 comes out. I think

Deterministic infrastructure increases agent output trust

3 Highlight · Deterministic environments increase agent reliability and trust

14:11 again I think that that the the core concepts of Nix and Flux when we when we were building it um still stay the same, right? Because at the end of the day, something is writing code, something is deploying that code, someone is using that code. And I and here's my opinionated take. My opinion to take here is that the more progress we can make on making the output from humans or agents or humans and agents or whatever mix we have in between to be deterministic, right? To be more trusted, the more ROI we're going to get out of AI because I think about it as like human assist and human replace. now not replace me in the evil kind of way like we don't need engineers but just more in the way that that is actually giving me an engineer or me run value right over necessarily building another new feature on top of AI and when I think about it this way today what flocks does and what flocks represents for me for the agentic world

15:13 is that is that bottom three steps of infrastructure right if we can go and tell you that you're just going to tell us what you need. Flux is going to create that for you and it's going to have full reproduability, going to have full isolation, no conflict, and it's going to output the same thing every time you give it the same input. Right? We just maybe took a 10step stack and told you that the first three steps are solid. So I think that's one of the big use cases for agentic systems where they come in, they use Fox for those reasons.

15:48 That's one. The second piece is that with flocks, it allows again just like humans for the agents to run, test, deploy the software on whatever the latest and greatest is, whatever they want to. They want to run it on some Linux variant at 8 a.m. and at 10 p.m. there was a recommendation that shifted some of the model to go and test it locally or in some like 10 different case variants for a hardware and software mix. The flux environment will stay consistent. Neither the agent nor anyone else needs to change it. And the last thing I'll say on this on on that general kind of p thread again on the opinionation side is I think the highest paid engineers are going to start become to be the the the test engineers the QA I don't know 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, right? There's going to be like a validation phase at the end. And imagine that whatever that code is, as long as the flux environment was

16:49 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

16:58 into it that flocks provides today for for agents. Yeah, I think so. So, it's a very good point. I feel like each of them kind of needs a bit of a breakdown. And I think like the meta point that I'm getting I think from what you're describing which I is an analogy that I like is that AI and agents that what they do is they supercharge patterns that we've already sort of seen in the real world. So maybe before you could rely on people kind of sort of keeping their environments in sync and being able to represent what happened in production and you know create something that is similar to what they created previously in the test environment and and as you supercharge it and you turn it from something that happens once a day to something that happens once a minute then then any any percentage deviation from accuracy over here starts multiplying and becoming unusable.

17:47 Exactly. and and and like the simple way and I don't know obviously don't want to call out different products I've been testing around I test different products all the time and um I just I just built a you know another app a few days ago just to test the waters on where things are and it's it's freaking amazing right you as long as it's simple you you kind of define the app you define it as a spec or defined it with English instead of with code it goes and builds it hooked up you know the database product hooked up all of that for me I only needed to do the authentication and the connections but then I thought about it I was like okay this is super basic. I want to now take it away and and now build on top of it. That was that transition going from agent to human wasn't as easy as I would have wanted it to be. And I think I think that's also going to be a big part of it. And we've seen it before, right? We've seen it before with all the other waves. We've se seen it from cloud to local or just from one engineering team to another engineering team. Exactly. Distributed engineering teams are sort of the same.

18:44 So it's a multiplier but it you know it may happen more and might happen like agent to agent as well like two different agents doing it. So so I think like in the three bullets you kind of mentioned up mentioned before. So the notion of trust really is to say hey there's a whole bucket of uh problems that might occur because you set up the environment incorrectly. So maybe in an alternate universe or like another alternative that you have is to have the agent make up an environment, create a bunch of commands that it's going to run and and create that setup uh based on some sort of instruction or things like that. If it's doing it every time, it's not going to do it the same every time.

19:19 And so can you can you just sort of make that deterministic? So right, I think I think that makes sense. That's sort of a bullet uh or like a a bucket of items that are that are useful and that increases trust because it reduces variability. We we'll talk later about generating environment that's probably its own kind of creature but at least for now right so so that's sort of a trust building exercise and then subsequently when there's the portability piece or reproducibility of like okay can you you kind of hand it back over to me and try to avoid the works on my machine uh type environment and uh and move it over. So I guess that's kind of bucket two or maybe I'm um I'm kind of mixing in your bucket two and bucket three. Uh and you know which which you also mentioned like consistency or sort of consistent delivery. So I probably blended a little bit your sort of three bullets but it is about controlling the variability in a world that is naturally sort of statistics to at least not multiply the other variables and then uh being able to uh do handoff whether it is between agents or it is between agent and human

20:19 in a clean way. Exactly. And I think if if again if we're looking at an opinionated five-year, you know, vision for for some of the AI native areas, I'm like I'm like just like code switches hands, human hands, right? Developers move companies, they move teams. This year, to your point about, you know, the point you made earlier that folks are kind of like jumping around between different editors. I can totally imagine us one year using one agentic platform and then the next year, you know, the the latest and greatest, the smartest agentic platform is a different one.

20:50 Maybe because I'm pairing more of a premium or whatever the new ecosystem is, but I want that agentic system to be able to tap into my code just like I want, you know, the other senior engineers swapping into team to be able to tap into the code immediately. And I think that's going to be a big part of of being at least that's how I see AI native in the future, right? Can you actually be AI native in that in that world? Yeah, I think that makes sense. But I feel like to me that opens up a slightly different question which is uh okay, what we talked about up until now is just about reproducible environments, right? And then there there are multiple ways to achieve uh reproducible environments. Uh one I think that you're referring to that's easy to disqualify is a a specific platform offers you its own reproducible environments. You know, heck, it may be using Fox behind the scenes. But if it doesn't show that, then then for all intents and purposes, you can't move from one agentic framework to another if you've defined your environments within that uh with with no sort of standards. And so I think that one's like easy. I don't know if there's a ton to say is like we would

21:50 benefit from standards. The world of open source is uh it's kind of there for a reason. I think the second one is more interesting which is uh probably by default if I was to approach this and I'm just you know sort of less up to speed on the latest I might default to containers and I'd say well containers are my shared environment. That's how I define you know my kind of infrastructure my kind of production environments on it. So I guess how how do you think about pros and cons or sort of differences between between using these like a declarative if you will

Containers and Flocks solve different infrastructure layers

4 Highlight · Containers handle orchestration while Nix handles reproducibility

22:18 kind of flock uh definitions versus I don't know if I'm presenting it correctly and and a build container. So, so I think I think the way we look at it today is that first of all, why not both, right? Um, I think I think containers again opinion Asian and I know I know for many people containers are a lot of things. I think container inherently came in and solved the world's problem about uh pretty much the entire transportation layer, right? The entire orchestration layer. I think that's like where containers are amazing, right? You have an Amazon facility, everything goes into boxes and then 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. So I think where there's a heavier differentiation is on how do you define that container and what can move under you that removes the reproducibility and removes the determinism and at the end of the day it doesn't matter how well defined your container is. And I think that best practices around containers are usually not that well, you know, not that well.

23:18 But even if you do define that container as as well as you can, you still have layers on the operating system that can move from underneath you. And that just makes it not 100 you know even nothing is 100% reproducible but it makes it significantly less reproducible to an extent that then kind of again my opinionation it doesn't matter when you have such a hyperscaled world with everything building code and building 10x 20x 100x code and deploying it. So in my mind it's like it's pretty much free to go and define that container with flocks and now be able to make sure that you have that full reproducibility and then run the container and do your flows. But you know two things once you've set up that environment that concept with flux two things now happen.

24:04 One whenever you want to move off containers whenever you don't want to necessarily use them for development not talking about orchestration. I think that orchestration is where containers stay really strong. But I'm talking about the dev environment that builds that whole ecosystem. Whenever you want to move off it, you have a common baseline to move off it. You can move back to local. You can move to the latest and greatest thing. You can use agents that prefer containers and agents that don't. You become agnostic to it and I think that's very powerful. The second piece is exactly that where you have that specentric definition right at the base layer that scales throughout time with you. you always have that in your you know in your back pocket should you want to pull it out. So in my mind and and we have a large obviously we have a large dock on this whole thing.

24:50 It's like today flocks and containers go hand in hand and if you want to continue the container flow great you just add in another you know you just add in another value point for yourself almost for free. Yeah. Yeah. I think that makes a lot of sense. I think part of it is like AI is the great multiplier and uh you know including multiplying of probabilities and you know yeah I guess containers it's not that hard right you need to have worked a little bit especially if you're sort of pulling from latest as your sort of base image that uh you know you you build today you build next week you're very unlikely to get the same environment and so part of it just uh it doesn't take far to sort of uh you know it doesn't take long to to to get into that state right and some of the some of just additional use cases there is that you know we said about it earlier it's like if if you need to take a container into development and you need to start poking holes at it then what's the point of putting things in a box right use flocks for the local things that you need to be able to run the things that need to be able to be system aware and and and those more

25:50 complex areas and then throw it chuck it into a container when you want to go ship it out can you ship it out with flux 100 flock and next 100% yeah but that's not something that you have to do today you know it's it's things that integrate fully yeah and I and I Uh I I do think I don't know if there is a correct way to do specentric. I mean I think it's a it's an unintentionally kind of outra but I think it does rhyme well with declarative uh and the idea of saying that containers are an implementation of of your environment.

26:19 And so once again you don't really have like what it is that you wanted to do in there. You don't really have something that is a more higher level abstraction of what it is that you're trying to achieve. Uh and so if you go higher level, you have something that is inherently more portable uh and more adaptable uh to different so we do talk about specentric development being a means of creating software that is adaptable um because it it takes in the relevant context and then generates the implementation that is right for it and maybe today in a good percentage of the cases it'll be context but frankly even earlier uh in this conversation you pointed out for instance proximity to hardware. It might also be that you want, you know, a tool that has access to sort of direct GPU access and maybe containers offer you that, maybe they do

Fast iteration requires a build-first development lifecycle

27:02 not. Um, but you you you have a choice of doing it. I maybe I'll throw in one more interesting thing which is I do feel the pace that AI kind of multiplies. You know, part of it is indeed the frequency of actions. You know, how how often is code deployed or

5 Highlight · Why Git slows down agent-driven development

27:20 written or tested or runs. But then with that also comes just the pace in which the these actions actually take place. Therefore the overhead that use of tools happens. And so at TESL for instance, we're you know we we we generate code in many ways and kind of abuse it many ways on it and we we try to have some version control uh that tracks all these different changes and we define that you know git is a slowdown factor and you know it's not optimized for that type of use case and and at least in in a good subset of cases we feel like we needed uh the team has literally written a service called notg uh to clarify that it is not git but it does kind of feel a little bit like git but it is fast and it's local. It's nowhere near as sort of fully featured as uh as Git, but it allows for many more cycles, you know, or or other capabilities. So, I guess the other thought is depending on what it is that you want your agents to do in certain cases, maybe the ramp up and down of uh containers, maybe the speed

28:18 of execution without it plays a role. That's probably we're getting a little bit into edge cases versus the norm, but um still probably an advantage. No, I I I think I fully agree with you because I'm sure that you know cloud native had a lot of meanings to a lot of different people and I think it still has a lot of meaning to a lot of different people. Uh we were just asked on a uh procurement form are you cloud native and I was like holy Uh AI native one of the things that it it means to me now and the difference between it and and other of these native terms is to your point this the speed of change the speed of iteration. Right. So to me obviously as a biased person having more solid ground to stand on rather than shaky sand is always a net benefit. So if that bottom rungs of your infra are a bit more solid that speed of iteration you're going to be more resilient to it. And I think that's another component of AI native because things are moving so fast all the time.

Agents require execution environments for validation

29:13 It's not just about moving to a cloud provider or being able to operate in cloud ecosystems. Um I think AI native takes it to a whole other galaxy. Yeah. So I think uh I think we've we've sort of spent a decent amount of time here talking about sort of environments and how like I guess the we first of all we kind of skipped over a little bit the fact that agents to begin with they need environments because they need uh the code that they generate to kind of face reality right they need uh uh to to run it or get some form of like execution based feedback and and so we kind of skipped over that stuff but I I think I think that's a core part of that generation. Is that correct? Like is that indeed the type of kind of agent environment you're seeing most uh most commonly is I I I created some code and I'm I I need a place to run it on to see if it actually works. Yep. So I think it's I think it's definitely in the testing uh the validation the the build areas and one of the things that I think is is the most beautiful and we didn't

30:14 talk about Nyx that deeply but Nyx again 20 years ago one of the things it did is that it it redefined the SDLC because it said we don't start with the developer environment and the development if we start with the build and define it we actually get everything else for free. So coincidentally, I see that aligning very well with agents where it's like the first time an agent really cares about this ecosystem is when it's trying to build that code, right? Test it, check for exceptions, check for bugs, whatever it is. And and that's why I'm starting to see Nixon

Three domains of AI environments

30:48 flocks really align with this way of thinking. And I think that's why I've also been seeing, you know, just giant growth over the last year or two that keeps exponentially going bigger. Yeah. Yeah. And that makes sense. It needs to be lean. needs to be kind of fast to execute. It needs to be portable. Um, and I guess what the other thing we didn't talk too much about, but I think I think is core is this notion of reproducibility between the output of tools. Um, so maybe maybe let's talk about that a little bit. So you can sort of think of three domains in which environment management or kind of environments as code manifest uh in the context of AI. There's probably like more like four, but at least you know one is runtime. We sort of just spent a lot of time on it. I was like I need a place to run my code on. Um the second is is the idea of generating an environment. Uh and just to say the third is about like picking an environment or tool use of it and maybe even learning over time. So we'll get to that one but maybe let's talk a little bit about this second one which is you you have uh some tools you know maybe all the vibe coding tools and uh those

31:50 they try to give you an output that would run somewhere and so they need to generate an environment for you. Yes. Has that been a use case that that you've sort of seen uh come up and and al also like conceptually is it a type of use case that you think of as a an important one? So we're very much seeing it come up. I think we're we're seeing it come up as a newer aspect. Again, everything is new, right? One year is new is like three months versus six.

32:16 Yeah. Yeah. in the last one to two months because I think a lot of these vibe coding products and again I'm making an assumption um because this is coming off of like my weekend and while I'm watching Bosch Legacy on you know whatever building out apps I think a lot of the vibe coding products are really trying to maximize their their time to market and they're not yet thinking about okay how do we hand this off how do we build sustainable code how do we actually build like high impact long-term apps and products they're thinking about how do I release. I think this I love this from a dinner we did earlier this week. Uh Dana there was telling us about building this bingo app while in line at a concert, right?

32:53 Because all her all her friends wanted to just have some fun. And that's exactly what VIP coding is for. They even optimize to try and have you self-deploy on one of their you know deployments if it's like uh you know their website or whatever. They try to minimize the amount of human interaction that you have to do after that. And I think that saves a lot of that long-term thinking like what environment do I need to set up? is someone going to work on this six months from now? I think it's like these minute apps that they're optimizing for today. But in the last few months, I think a lot of these uh VIP coding um products have started to be okay, how do we, you know, how do we monetize more? How do we create more of a sticky customer base? and thinking about it and that's been another inbound conversation we've been having so much so that it's made us think also a lot about you know what does it mean to be this bottom rung of infrastructure for an AI native world with all of this data about uh what are the best packages and dependencies to use you know what are the fastest what are the most secure and that's kind of giving us a look at at what the future of like AI environment

33:54 creation would be like so that's you know that's a quick well not so quick thought for mine on on So, I think it makes it uh I I I like the analysis. I definitely like the minute app. I haven't actually heard that term. I heard like disposable apps and all that. Minutes apps is an interesting one. I think about food all the time and for some reason it makes minutes. It's like would you serve this? Probably not. Yeah. Yeah. But it's uh but you know, if you're if you're home and uh and you're hungry and this is this is what you've got to eat. Um so yeah, I like the term and I and I I agree. I think maybe even legitimately a lot of the vioding platforms especially uh are are just trying to kind of get you to something working at the end. And so I I guess that's both a a pro and a con. So in the immediate term they also benefit from prepackaged environments because uh they can pull one off the shelves and they run them. Although maybe maybe they don't care about variety too much. Like many of them are very I'm going to pick a specific you know superb base and uh you know whatever sort of setup that I have. So they might have like really uh hardened

34:56 or like picked a very specific environment to run on. Um but then as they think about repurchasability, they think about something that is long-term. I guess the other aspect of that is is portability, right? You can imagine uh especially leaning into like the open source ones like all hands or or things like that. Maybe generating a more portable uh environment format so that you can run it on whatever infrastructure that you want. uh while maybe the the more SAS environments might bias and saying like look I'm going to handle it end to end for you.

35:25 Um, and I think that's uh that's significant. It's back to that sort of standards benefits of, you know, allow me to pull it up and continuing it. But it also allows for for chains of tools, right? It means you don't need necessarily this one tool to now be both the best at generating um say uh the piece of code and deploying it and another one and and and also know all the way to like being the best at operating it. You can say well there's another tool here and it they they share the same language about the thing that got deployed and they can continue on from there. Yeah. And I think that's another that's another strong opinionation for where we're going in 5 years. I think again could there be an AI Skynet that does it all and also gives us a cure curfew at APM?

36:10 Hopefully not. But I think at the end of the day, there's going to be products and companies and agents that specialize in their areas and therefore that that ecosystem is going to be rebuilt, right? You have the AI kind of like stack that you guys have been creating and and I think we're going to slowly start seeing that, you know, condense into what is the AI native stack? What do you use for each part of your flow? And and maybe the infra map and the DLC will look totally different. Maybe it won't be, you know, code, build, deploy. Maybe it focus a lot about testing. At the end of the day, I think you're 100% right.

36:46 We're going to have different products, different agents that specialize in different pieces of it, and they're going to need to interrupt, right? Maybe not as much as like 12 different teams across a large company needing to build out a product. Maybe it's just three, but you're always going to have I think you're always going to have that transition because I don't think one agent and one company is going to just be able to say that they do everything the best. Um I think you're going to

Open tool chains prevent walled gardens

37:10 have a whole ecosystem built around it. Yeah, I do think I think a lot about sort of the right scope of tools in the world of AI dev and and there is I think I said this in like a while ago on a on an episode where you you can think that there are sort of two trajectories. one is uh there's there's a a big brain platform that it just needs to know it all. It is the sort of the super intelligent Skynet sort of environment. Uh and and therefore because it's so good at that we're basically just dependent on it doing everything and if it doesn't we're just kind of stuck you know we or maybe we know how to like become power users of that platform to be able to do it. Um I think I think that's a slightly sad reality because really it it it limits innovation. It means that someone with a great new idea of a of a piece in the the puzzle can't kick in. And there's another reality in which we do have a chain of tools and we allow different components to come in and blend. And we had Matt Bilman on the show uh from Netifi, the CEO and co-founder of Netify. and he had some

38:10 great insights, but you know, he's also very passionate about the the web manifesto and about the whole kind of open ecosystem and talked about how it's also tempting to lean into the uh kind of closed garden where because for the same reason we've been mentioning a lot this the stoastity, you know, the sort of the uh the uh the non-determinism that is also bothersome in the world of AI. Uh and one way to do that is like, hey, just be in a closed environment, fewer kind of variables. uh and it's very tempting and sometimes faster to get to something working. uh but really I think what we want as a development ecosystem is we want an open system. We want a system that you can you can hand off things and you can have a tool that is best of breed at a at a phase of the journey. Um, and it's uh I I like the concept of open environment definitions because environments are like an overlooked uh piece often times of software like they're critical platform and ops people are well aware of their importance on it but I think for many developers they're just you know they

39:11 don't think about them that much. So, I I I I do really like the idea of of leaning into and maybe investing uh in these different agents at outputs that are portable and and open, so standards based. And obviously, you're you're talking to one of the more biased people coming in from Yeah. I feel like I'm sort of saying this and you're not going to disagree. You know you're clearly as you're saying this I'm like if not just for you know the fact that every AI agent again highly opinated person is going to be a every AI agent every AI specialization whether your company's building the best agent for testing or the best agent for development of like of high throughput you know I don't know biotech um you know protein synthesizing whatever there's going to be an open source equivalent leave alone even if you have the AI skynet you're going to have open source AI skynet U which sounds even I don't know if that's scarier or less scarier than I guess depending on who owns the closed source one but um I guess my point is to your point I think that's what you kind of

40:12 like just catalyzing me I was like even if we don't have different companies in the stack you're going to have the open source and the non-opensource you know best of class already um and being able to traverse across that is just going to allow us you know mere humans to be able to go further. Yeah. Yeah. I I fully agree. So, so anyways, we got I think we're sort of very much on the bandwagon, you know. So, so we want talked about runtime and how do you define things that the agents can make

Natural language infrastructure generation

40:37 the agents better then we talked a little bit about output and how you can uh create runnable applications including their environments on it that are hopefully in the sort of open standard panacea that we want you know flux being a contender for that. Um and then I guess the sort of the the third part is around environments as a tool uh or or or something that we know how to use. So, like I think as a as a as a as a human developer, you know, you uh you get better over time knowing which tools to use, including like some SAS apps, you know, some containers are going to run that have stuff on top of them, I guess. How do you think about I don't know if the word empowering is correct, right? Like powering uh uh agents with uh with environments as a means of, you know, better agentic decision-m or or capabilities.

41:26 So, so we're obviously spending a lot of time thinking about um how do we how do we solidify, you know, that first step of infrastructure right above your OS and and with that time, we're also we're also able to see and put together a lot of data on what it means to build best-in-class environments and how to build them and what runs faster, what runs more repro reducibly, what's more deterministic. We we're starting to see all of that. And I think the next step up is that, you know, eventually you just tell you the human or the agent or the human telling the agent will just tell us or show us what they're trying to do. You're not going to need to say you need Python 3.12 or you need this version of, you know, some database or whatever it is. you'll just tell us what you're trying to do just like you just told the agent. The agent might then

42:26 translate it to us at the info level and we'll just output what that agent needs in order to be having that consistent kind of the software fabric of environments at its baseline. I think that's where it's going in terms of environment creation. That's where we'll be a few years from now where just as much as we're trying to make you just, you know, tell the computer in English or in whatever language what you wanted to do, the agent or the human is going to be able to do the same thing but just for the entire infrastructure below it. And I think that's where we're going with environment creation where it's like I want to, you know, I let's say the last thing I just built was like I wanted to build a a voting app for my family that's dynamic and everyone can see everyone else's vote for something. That agent would be translating it, right?

43:13 And then saying, "Hey, I'm building this piece of code. We'll look at either that piece of code or the words in English and automatically know what to pull in for that agent to utilize." And it can be by it can be by it can be b-sided meaning that agents can come and say this is what I'm trying to build you know flock will just autogenerate it for them or it can actually if there is agents trying to optimize for it flocks can actually suggest what's the ideal environment and then the agent will actually build off of that based on the user requirements and the user spec. So there's kind of like a dual-sided thing that we're thinking about here and I think that's where we're going to be a few years from now completely and it's going to be fully optimized. I think it's really interesting because it blends into uh into again the thought of like creating an app and understanding that you know you you you have actually a variety of applications. I think today we're not we're not seeing as much. I think if you're building with AI and you're sort of doing VI coding and all that, you don't encounter that problem immediately. probably because whoever it is that is building the platforms probably um they again they created a

44:16 very finite very uh kind of a carefully selected uh set of environments uh and uh and they just deploy in that environment like so we have the the open web you know you might have you know deployed on a specific on netlifi you might have deployed it on uh you know within you know it's like a react application like you're you're so it's a very specific and then they only generate to that confine So, so I think like the problem it it makes sense to me very much in in like a future tense, but I think it's like a pain that people are not yet feeling today because they're still working within narrow confines of uh what can be generated. Right. Exactly. And I think I think this is this is exactly like look at our careers as software engineers, right? It's it's so specialized. It's so niche. come with the experience and there's a reason where job descriptions today require 5 10 years of a specific language experience because you come knowing which packages are the best but you come with that kind of like world view of it and I think we're going to move to a situation where we're going to

45:17 be able to 5x 10x if not 100x the space just by defining you know the best requirements and defining the best you like like these these apps are able to create these minute uh minute apps but in the future they're going to be able to create 100 minute apps and 10year apps and hopefully 100y year apps. So I totally resonate with with how you're looking at it. Right. So yeah, I think uh it it's interesting to think maybe of uh environment as as a bit of you know partly overlooked because of of speed part of the AI generation. So from my my kind of different maybe lens engaging with people building with AI, I think today probably the the the top of mind for people uh when they think about environments is uh is environments as a an enabler for for their agent. So what they want is the to create the code like create the code for me to create the code they need an environment to be able to run uh things inside of it and maybe run some tools, run some tests and so they're that's like focus and passion on

46:19 it. they they maybe they don't think as much about the output piece because they're in a closed garden and they're just generating that. Maybe they don't think as much about the declarative piece because to begin with it's also hard already to generate like specific code that it's actually something they anyway need to do which is narrow the the fold and just like focus the LLM on creating something. Uh and then on top of all of those the the reality is today that uh uh there are there are many many gaps between uh the way v coding and other sort of AI generation uh operates today and any long-term viability of these applications like there's no thinking about maintenance of those uh of those application. So and and and in that process there's no thinking about what happens when something in your environment needs an update. Um like I don't know It's like seven steps down the road from I not to say 70 of the problems that are top of mind for me today and at the same time they feel kind of fundamental when

47:20 you think about how would you build things in software that is that has longevity is that correct I guess kind of representation like if you were to uh guess at I don't know if you have actual telemetry probably for this granularity of division but like when you think about people building environments would you would you say most of them are that like I need environments for my agents to be able to uh test code that they've created versus I want portable environment versus I want declarative uh like a script based kind of a prompt driven environments. I think when we're looking at agents today they're they're optimizing for that minute app. They're optimizing for for as simple as possible low cost as possible. A user asks for something pretty basic. we spit it out with a minimal amount of bugs and that optimization had you know I think obviously I'm overstepping into the folks building agents excuse me but I think from a user perspective and from like a let's say pseudo partner vendor perspective as as the person you know providing flocks and nyx I think that

48:21 optimization makes them care very much about being able to spin up the environment test it so that it's you know that minute app is fully cooked and then and then ship it out right they they're kind of using that environment as just like a transactional piece throughout just putting the stuff out there. Now, what I'm seeing the last few months is a lot of them are thinking about how commoditized those minute apps are starting to become, right? There are so many different products out there that you tell it, hey, I want a voting app that my family can see each other live, blah blah blah, hook up super b Superbase, which is amazing, and all of that. And now I think more and more of them are thinking about, wait a second, where is the money? Where is the ROI?

48:57 The ROI is not in these minute apps. Where's the differentiation as well? I can always and I think that's where they're starting to come in and say, "Oh boy, we need some baseline. We need our users to be able to export this and start working on it super easily just as as if they were sitting on the same team with this agent." And that's what I was talking about earlier where I'm we're moving from like human assist to human nicities to actual human replace in things that allow me to focus on the bigger more innovative tasks at hand because all of a sudden this agent becomes a team member instead of just being that intern that we asked to throw together the lunch, you know, lunch ordering app for the office that we're going to throw away three weeks from now because we'll forget about. Right. Yeah.

49:43 And and I think in that sense that becomes you have to think indeed long term just like you you wouldn't you wouldn't continue hiring you know a junior developer who uh only built applications that were suitable for sort of a three-day lifespan or a three-month lifpan and again there's use cases for it but I think it's to your point the differentiation the the the target market and the market caps are going to be very different for the minute apps and the folks who are able to extend that into into the large large ecosystems. Yeah. Yeah. And and like I I don't I don't think either of us kind of mean to diss the uh the applications today. They they allow us to to tap into the magic. They're amazing. They do feel magical and they they're an iteration like I think you you can never jump to the end. Uh you always have to uh build it. Uh but it's interesting to also think about what are the gaps uh between that and and the future there. I think uh I have one more question on environments and I do want to ask a little bit about that dinner that you uh mentioned in passing because I know you had some great insights from it. Just

MCP is a machete for agents

50:38 one more question on environments. uh you know MCP is all the rage uh uh these days on it. you know, I know you uh you have Flux Hub and it sort of holds a whole bunch of environments that uh people have there that you know, from my kind of layman's perspective, it feels uh oh, cool. That's a thing to sort of slap an MCP front on top of. Just curious like have you thought of that?

6 Highlight · The operational risks of Model Context Protocol

50:57 You know, I guess what's your what's your view there? I guess when I think I was going to say something, I was like, well, shouldn't that be obvious? My my head of marketing, Ross, very creative genius, um he usually says these these like has these things that just stick with me. And when we started looking into MCP, because Flux has obviously been looking into MCP, he told me like MCP, and I love this, is like giving a super sharp machete to a random number generator. You know, it's like giving it's giving uh HAL 9,000 arms and legs.

51:28 So, I think from the MCP front, at the end of the day, I think it's just a more more capable version of what we're doing, right? All of a sudden, this AI has arms and legs. this agent can actually go out there and and I don't know, right, in the real world, potentially hook up to my email, answer my banker for me, you know, review the tip amount that I wasn't scammed at a I don't know, right? Can access my bank. Um, and the way that we think about it is that MCPs will run software. That software has to be provided upfront and reliably just as much as anything else. Um, or it has to be dynamically available for agents to to extend upon. And and from our perspective, that sense of reliability just steps up again a level, right?

52:13 Because if if if I'm going to sell you an agent that is connected to a bunch of real world outside services, if you don't have that AI trust and AI reliability in it, that's just a more dangerous, you know, random number generator with a machete that you're launching out into the world with your

52:31 name on it. So that's a obviously a whimsical point of view from the flock side. Yeah. Yeah. Uh it's interesting. I get it. I think you're you're sort of consistent also in pointing out that the um one of the key challenges is just the the degrees of freedom and just like how many things can change. And yeah, MCP is uh is like you know an API with no structure. You know that may or may not work. Um and I think today by the way it does shine in places in which it is still an attended process uh that uh that runs because then you give it tools but then if you did blunder right and cut off a leg you at least notice it before you say yes uh uh and so that's good but it does feel like also a good way I think people talk a lot about MCP as a tool call uh primarily and uh I actually really like the resources aspect of MCP and it feels like the uh opportunity to make the different LLMs that run uh

53:31 aware and kind of easily access hopefully frequently successfully some environment from from Fox that we can kind of pull down. uh is probably interesting and kind of goes towards that sort of uh declarative and again we've been we've been having immense fun with it like we've been hooking it up to different things and bringing it together and we're we're experimenting with a few things with a few you know with a few partners and and it's you know MCP is is is great in my mind. Yeah. Yeah. Its degrees of freedom are precisely what kind of leaves room for creativity and so I I think you see a lot of people just trying it out. I I would wager that it would become a lot

The sous-chef reliability threshold for AI

54:06 more strict uh or at least have an option to become a lot more strict uh over the coming year. So uh hey just uh before we wrap up here uh I know you recently hosted a a dinner event with some of the top tech leaders from uh I don't know if I want to name names but like some of the top uh uh AI companies both building on AI and building uh the foundations for AI on it. Um, so we're veering a little bit outside maybe of the the kind of a flux or environment lens, but curious what uh what takeaways what what are the most interesting topics you felt came up during that conversation? I think I think one was that, you know, AI's impact on developer productivity. Still still a very hard area, you know, to quantify and to and to make decisions based on. I don't think anyone's surprised by that. I think even pre AAI we had a hard time quantifying developer productivity and actually you know there was like inner

55:07 loop outer loop uh lines of code which was complete So I think that that also made me feel better because I was like you know thinking about that very yeah you're always thinking about it's like are they all like using AI and seeing these huge quantifiable movements and they're strategic about it. I think in general it's like a lot of folks are still working against that and that's interesting. And by the way, another example of the multiplier uh or like AI is the great multiplier that it's it's something we always wanted develop productivity measurements and maybe you know can we now do we have now enough motivation to uh to track that and I wonder when we'll start talking about agent productivity. So I've seen I've actually seen a few start talking about that. Won't disclose that too much but that was one I think I'll just call out the top three that came to my mind. Now

7 Highlight · The reliability threshold for AI as a sous-chef

55:54 the second was definitely that that that glass ceiling that we kind of dripped throughout where how do we focus on generating more innovation on the AI trust side rather than more innovation necessarily on having AI do something more or something better. And again food connotations all the way. This was a dinner. One of the things that was mentioned from my end was like I want AI to be my ultimate sue chef, right? I don't want it to like make a meal and wait for me to finish what I'm doing and then make me check the meal. I don't need it to make intrinsic like Michelin star meals. I kind of wanted to cut up bread very consistently and then go put it on the table right now. I can go focus on other things. And I think the issue that a lot of us are still feeling is that three out of five even four out of five were the best models and providers. They cut up the bread, they put it on the table. On that fifth attempt or the fourth attempt, they place some rocks on the table. They put some, you know, like machine oil instead of olive oil. and that doesn't allow me to fully kind of step away from that area that AI is capable to do and move

56:56 over to do things and spend more time in other places. Can I ask just on that one before you go to the third? Is is is is their sense or your sense that the the part that needs to improve here is the

57:08 AI becoming deterministic or the humans changing how we how we how we work and uh to to be able to deal with probabilistic. So I think that's that's a great question because that was an immediate followup. I think I think one we do want AI to become a little bit more repeatable. I want to know that when I ask it to cut bread and put on the table that like 95 again also humans make mistakes, right? Yesterday I got my chicken with butter and I didn't want it with butter and then they went out to the kitchen. There was no AI involved I believe. So in centro but we wanted a bit more. We want there's a threshold. We haven't defined it yet. It's probably more psychological than not. And I think the other conversation was like, do we need to start just lowering our standards a bit because our standards are are on humans who have 40 years, 30 years of experience doing most of these things at a minimum, right? And obviously they're older humans doing this. Do we just need to say that, you know what, when I'm writing an email response to confirm a time, I don't care if it's missing a period or or you know, it it was super it was superlative in its response

58:10 because it's not human. Uh maybe we just need to give it a you know run by Ron's AI and I'll feel and as a society we'll be like oh it's not Ron saying good sir thank you so much I'm so excited um accepting your formal invite for the 1pm meeting we'll just be like oh that's that's fine right but it just saved time so I think you're on the money that this thing has two aspects it's like our shift of the psychological expectation and AI becoming more appeal yeah yeah and which I think is extra fascinating in the world of software development which uh we're we basically expect software to be deterministic. Uh I guess we know if you're experienced that it's not uh because environments because uh data uh but otherwise like we have a pretty high bar on determinism that the AI systems are not currently meeting probably to to a degree we're going to have to accept that but to agree they need to get there was also an entire conversation that led from it about like you know maybe this minute apps are just the new standard maybe you know 50% of our thing become become a disposable cup

59:12 right that's like evil we don't want to pollute the planet But maybe we do start standardizing around some industries having disposable software where it's like every few months or every few weeks. You ship it out with all the new functionality and no one knows how to reproduce it because that's totally fine. And after a few months you ship it out with all the new features on top of it and you you know that's like a standard question and a human psychology question. Yeah. The third one that stuck with me because I didn't expect it but I I once it was said I was like huh I have been thinking about this for a bit. It's like it's career progression inside of startups, inside of tech companies, right? We're moving away from this. Um, obviously in small companies, very different than like the mega corporates, but we're moving away from it. There's an obvious career path now. We need to kind of change our thinking there. And how do we motivate ourselves? How do we motivate our teams? How do we show them growth? Right? It's moving away from, oh, you'll do more, you'll hire more, you'll be a manager, and then you'll be a manager of managers, and then you'll step up. And that's like a direct correlation to scope and impact to what happens in an AI native role, right? Um

1:00:15 maybe we don't need middle management anymore. Maybe we're able to, you know, have 59600 reports. I don't know. Um so

Fundamentals remain critical for computer science

1:00:22 how do you motivate the individual and how do you show them a path of growth when it's not so obvious anymore? And I think that was that was another big topic. Yeah, that's a big and important question. I guess that uh so so brilliant insights uh Ron thanks for all of the the kind of the the learnings the sharing the perspectives uh both on environments as a service and probably conversation I should have left more time for uh on the takeaways from uh from that dinner maybe just sort of one last question and teeing up a bit on his sort of last comment on career progression. Uh I asked this previous guest and I I find it interesting. Um, if you had a a child uh of 15 years old, would you want them to go study computer science in university right now or would you think that's a good career move for them? Um, I'm again very biased person.

1:01:11 Hell yes. Uh, the the reason for that is other than being biased, I think I think the fundamentals don't change. They've never changed in any wave we've had for the past, I don't know, 50 years of software. Fundamentals have always been there. Yes, they've grown. they've improved. But I think I think the main recommendation today I give and and I really resonate with is T-shaped. Whatever industry you choose, and I'm going to pick on software engineering because that's the thing that you just asked me. Yes, go study software engineering, but make sure you go really deep. You go all the way to the fundamentals. I don't care if if you chose Python because you like snakes or you chose C for more some weird reason.

1:01:51 Go deep all the way to what are the fundamentals of software? Why is it doing it? How is it doing it? You know, and then start going up, right? Because that will always exist. We'll just we're just adding another layer. We're just now moving from higher level languages to now English as a language to writing code. But someone or something is still touching the fundamentals and understanding and knowing them is going to always be something that's needed.

1:02:16 And no matter what the abstraction is, it's going to allow you to always be the most effective person using that abstraction. So obviously yes on software engineering and then regardless of software engineering T-shaped kind of recommendation for it. Cool. Well, thanks super uh super insightful here. Uh Ron, thanks again for coming on uh to share your learnings and uh thanks everyone for tuning in and I hope you join us for the next one. Thank you guy. Awesome being here.