Latent Space: The AI Engineer Podcast
Original podcast
Watch the full show on YouTube: https://www.youtube.com/watch?v=qka_pUJz2KY
6,480 words · 3 speakers
Welcome to a Late in Space Lightning Pod. We are excited to work with, I guess, the former GitPod team on Late in Space Pod, on their new products. You guys are, you know, you and I, Chris and Johannes, you and you, we've been sort of familiar over the years, even before this AI wave, with GitPod. When I was trying to show off Temporal, where I used to work, which is like kind of a complex open source distributed system. The only system and platform that was possible, that was able to make it easy to spin up infrastructure of the complexity that Temporal had was GitPod. So thank you for working on it. But now you're working on a new thing.
So you got to know GitPod YAMO.
GitPod YAMO, that was the joy of infrastructure at the time. But no, you guys, you guys worked on really, really good sort of, like, I always think of it as like containers plus plus, right? Like, containers stop at like the single, single sort of node, and you need more networking and like Kubernetes has its own thing. But like, really, I needed something lighter weight and you guys solved a lot of those isolation and networking issues.
Yeah, you also need, like, for dev environments, I see that happen a lot. Like, for dev environments, you also want a little bit more than containers, because container really up to run applications and dev containers aren't your optimal application, right?
Yeah, yeah. So anyway, you guys are co-founders of GitPod, but also now you're sort of renaming the company. Why don't you guys introduce yourself and also what we're announcing today?
Cool, I can start. So my name is Johannes, I'm one of the co-founders and CEO of GitPod and soon ONA. I think we'll talk a lot about why that happened, so it's a bit about our roots, and then are excited to showcase, you also, what we've been building over the last month. So really looking forward to talking today.
So my name is Chris, I'm one of the co-founders and CTO at GitPod and, well, soon ONA, gotta get used to that. But yeah, looking forward to this conversation.
It's three letters, Chris, so easy to remember.
But it's years of ingrained saying GitPod, you know?
That is true.
Yeah, yeah. So what is ONA? What made you start working on it when GitPod already, you know, decently successful, raised a bunch of money and like had some traction, even dumb people like me could use it? Great, so like, why ONA?
Yeah, I think let's take a step back and also go through a couple of phases, I think, that the company did. So when we started GitPod, like more than five years ago, right now, the idea was really to have this one-click experience to be beamed into what we call like a ready-to-code development environment. Initially with a browser-based IDE. So some of your listeners might know, but back in the day, VS Code could actually not run in a browser, right? And it was not yet refactored to support remote development. And because as we started, we really wanted to offer a VS Code-like developer experience.
Our team, specifically back then, Sven and Anton, they created FIA, which was like a cloud IDE framework that is still used heavily by ARM, Arduino, a couple of other people under the Eclipse Foundation. So we created that. And together with that, we also created OpenVSX, which I think now powers all of the extensions that you see running in Cursor and also Windows Surf, which is also open source under the Eclipse Foundation marketplace for VS Code extensions that is not hosted by Microsoft. Together with those, where some of the building blocks, then we had to build all of the orchestration in order to build a ready-to-code experience.
And I think that was until, let's say, end of 2022, I think, the first phase of GitPod, really this one-click web IDE running in your browser, winning hearts and minds also of developers. You scale through open source, have more than 2 million folks on the platform. By now, and I think that's also when we interacted with you, when you were still with Tim Parrow. Since the end of 2022, we really embraced also enterprises. So I think as a company, both culturally and from a product architecture perspective, we really kind of shaped what we call cloud development environments with a strong focus on some of the most regulated companies on the planet. So today, our customers include, you know, the oldest bank in the US, top sovereign wealth funds.
We have like pharma companies, a lot of financial institutions that are running our orchestration system to power those fully configured dev environments that connect on from databases to the registries, secret managers, everything in order for you to write software inside of your VPC and then connect it to desktop IDEs. So what happened is we, as I think Copilot really started to become successful, we realized that if the future of agentic software development is going to happen, we didn't know back then, that was like end of 2022 or so 2023, when that will be the case. But if that is going to happen, we have something that is very valuable,
which is the fully configured environment. And at that point, we made already the decision that when we feel that coding agents have crossed the chasm, so are at a point where they efficiently can actually solve engineering tasks, we are going to fully embrace it. And that was, I think, Chris, when did we start? End of last year, so when 3.5, so Sonar 3.5 came out, it became clear that it will not be very far away. And then we started prototyping and developing our own software engineering agent on top of all of the primitives that we have built over the years. And that turned out to be a very great experience that like internal engineers really used a lot.
And we decided to fully embrace that. And with that, also change then the company name to Ona to go all in into that that future.
Very bold, very bold. I think we can sort of pull it up on screen now. I always like to give people the sort of visual aid as well while we talk. Yeah, I mean, just a quick, you know, while we're putting it on screen, why did you have to rename the company? Like, why can't you just be like Ona by GitPod, right? You know, like, why so drastic?
I mean, so what we understood as we initially also thought about just naming the agent Ona, what we quickly understood is that it's a core part of the experience and it's a core part of the platform. Those two things are not separate, right? And that is, that was ultimately then the driver of the decision to say, hey, let's embrace that. GitPod is also as a name, very technical. So we kind of have outgrown that name to a certain extent. Like with Git and Pod, it's like it's a Kubernetes based architecture. We released a blog post a couple of months ago that was called We Are Leaving Kubernetes. So it just did not really fit.
So generally, you can say our ambition, product architecture, and also the value that we deliver to our customer has outgrown the core, you know, name of GitPod.
Awesome. I think Chris has Ona up, so I'm just gonna let him drive a quick demo, so we know what we're talking about.
Okay, cool. So this is the raw, unfiltered version. This is how I use Ona myself every day. And so that's exactly what you're seeing here. Now, the hello world of Ona is essentially firing off an agent to do something for me. And, you know, something very simple, like what's in this repo? I don't do that every day. I know what's in our repo, but you can then set it off on, you know, some code base that you wanted to work on. You can also start from scratch, of course. But really, the interesting piece here is that organizations typically have,
you know, paved roads and known repositories, known projects, known dev environment setups, really standardized setups that they want to work on. Like typically, it's not a nan agent is gonna figure it out, but there is compliance and platform team requirements around how your dev environment looks like. And so here I select this perfectly set curated setup. Okay, so I'm gonna fire that off. And what happens now is, you know, we spin up a dev environment, which is the, has been the bread and butter of what we do for a very long time. And you see on the side, the agent already engaging in that conversation. And so while that's starting up, let me talk you through a bunch of ways I use Ona every day. And this is literally something that happened in a call earlier today,
where we were wondering if this, you see this inactivity timeout here? And we were wondering if that inactivity timeout is still working well with the agent. And so while we were in that call, you know, I literally asked it a question, hey, it no longer seems to happen, examine if this is true, and if it isn't, why? And it did a fine job. It very quickly gave me a detailed account of how this tracking works and that it's still in place and answered a question for me. And I didn't have to change my, I didn't have to check out a different branch. I didn't have to faff with Git work tree. All I did is I put that in a prompt box and it worked. You know, inquiring things like that is something that you can also do in other ways. You know, connecting MCP server to GitHub API or something like that.
Where it gets really interesting is when you wanna make changes. And you see, there's a bunch of these conversations here that have changes in them. Right? And so if I look at, if I look at one, what I do a lot is I use Ona to prototype stuff. So for example, here I'm looking into showing the, showing the, the numbers. Like showing the, where we add in the to do's, you notice we track to do's as the agent does its work. And I wanted to show them here on the side. And so I ended up building a prototype for this. And that too is entirely conversation driven, you know? I have, as I walk it through and talk to it, and I can do that without, again, needing to change any state.
I can do this in parallel to getting actual work done. And that's how my day to day actually looks like. I typically do one or two prototypes on the side. In a call, we'll run inquiries or ask how things are actually working. And then also work on some light feature stuff alongside, and I can do all that in parallel.
So if we look over here, you can also very easily track the, the state of your changes. And if I need to go deeper and wanna see how these changes look like, I can pop into VS Code right here. You know, it's one click and I'm, I'm right there. And then in VS Code, and you know, this is true VS Code running in the web. If I need to go even deeper than that, I can open this in a, in an actual editor on my desktop. You know, I can pop into Cusso VS Code or any of the other editors that, that we support. So I'm gonna pause there. Like this is the, the, the core of it really is the parallelization. This ability to run so many things at the same time.
Without needing to, you know, maintain any of that state and well knowing that the dev environment is perfectly set up. For how it needs to be and you know for we can worry where the setting it up on setting up the dev environment might not feel like much, but you know, if you're working a bit of Python here and a bit of Go over here and with a typescript over there, it already becomes a handful. If you're working at a any decent sized shop, let alone an enterprise, the way you set up your dev environment is really hard at the heart of all of this. And of course you want your agents to work in exactly the same space that you as a human can operate in. And you want that parallelism and this is what that platform gives you.
Yeah, amazing. What was the hardest part of the, you know, this exploration? Anything that you struggled with like figuring out in terms of putting the agent together?
So I think one of the big ones is is the user experience and a lot of the design decisions around, you know, is there one to one mapping between environment and conversation? Or do you have multiple conversations in an environment and how do people think about that? And this is something that will clearly evolve, but making that accessible, not only to the really plugged in 1% that is listening to this podcast or folks who really know their stuff, but also to maybe the more AI skeptical or the ones who think that TapTap autocomplete as of today is the pinnacle of, you know, AI based writing, writing code.
And making these decisions, sorry, there's a camera popping in here, making these decisions. Making this really accessible, I think, has been one of the challenges.
Yeah, I mean, I think that's always a challenge for all the agent builders I talk to. One thing I realized that may not be super obvious is that, you know, you're showing a demo here that is very front end oriented. I wonder if you had decisions on front end versus back end workload. I kind of see GitPod as obviously more infrastructure, more back endy and obviously you're more capable of back end intensive things. As compared to something like Bolt, we've had on the podcast before where they use web containers. So it is very, very sort of tuned to to front end, right?
Both are capable of front end and back end. It's just like I expected some kind of lean. Oh, you're showing me some Go code base.
I think one thing that is very important to to mention, what Chris showed here is our own product. So the whole product that you're seeing, we are building with ONA. So I think last week, we had seventy five percent of all of our PRs being co-authored by ONA. So we're heavily dog fooding. So all the environments that Chris just has showed are or have the whole platform with its front end, with its back end, the whole orchestration platform and running inside of them. And I think that is, as you as you mentioned, huge difference from from folks like Bolt who use web containers is that everything that runs on Linux runs on ONA.
And our customers, as Chris also alluded to, are oftentimes ninety nine percent of developers. And we have to support a huge spread and variance of different workloads. And everything, again, that runs on Linux runs on the platform. Chris, maybe it's helpful if you show a bit the how the environment automation is set up from the dev container and the automation XAML file, which I think is one of the very, very hard things in order to get this running in production, both as our customers, but in general, is that you create those very reproducible environments.
Let me let me show that. Like, this is also why I went back out of code. Like, you see these services here, you know, I can run our back end right right there. And then most of the work that we do, like I showed some front end stuff, but most of the work we do is is back end fundamentally. It's a lot of infrastructure stuff. You see the Go code. All this is also written obviously within ONA. And at the heart of it is is a dev container, is a dev container JSON that
contains the the version of defines the version of Go. It it comes down to a Docker file at the end.
Okay, don't find, there we go, def container, Docker file, there we go. It comes down to a Docker file at the end. And which, you know, itself isn't a, like, Docker itself isn't a security boundary. You don't want to be relying on that, but for specifying the tools that you need, Docker is a decent way to do in that, or def container is a decent way of doing that. And then on top of that, we built what we call automations. Sorry, GitPod, that's one of the reasons we're renaming, no more GitHub and GitPod conflation. Can't wait for this. There's an automation CML file, which also gives you the services that I showed earlier, right? Like here, there is a, there's a backend that you can run.
And here's the definition of what it takes to actually run that, run that backend. And then also commonly run task. And all of this is of course also available to agents. You know, like this stuff has been very useful for humans because it takes an outdated readme file and makes it into, turns it into something machine executable that it can actually automate. And you see there, there are triggers here also where we, where we trigger things on post def container style, stuff like that. And all of this now becomes also input and context that helps the agent navigate your dev environment.
Yeah.
Yeah, wow. Okay.
How, how good is our LLMs speaking your YAML, by the way? I'm just kind of curious because you, you made the cutoff, right? Like, I think actually right now is kind of a golden age of pre LLM era infrastructure companies, because all your tooling is like inside the training data and like people who started it afterwards is not.
We did make the cutoff. It's, it's really decent. Generating the def container, the automation CML. And then obviously, like, you know, the moment you do that within one of these environments, it can also try it out.
We didn't even have to give it tools. We just told it, here's the CLI, go knock yourself out.
Yeah. Is there anything that it cannot do or you warn people not to do, you know, like what is like within, well within normal capabilities and what is flakier, like in your experience?
So I think we're seeing the very similar problems that a lot of other folks are seeing where some prompting, some input is reasonably naive. So the underspecification problem, we also see a lot with especially people who come to us for the first time. And the second is the decomposition piece, you know, if you give it sort of a vaguely specified, too large task, it's gonna go astray.
Much like it would with any other agent. The advice that we generally people give to people is like, start small and work your way up. Learn how to decompose, learn how to really be excessively specific about what you want. Don't make assumptions necessarily. And that gets folks quite far. So there is a learning curve, we find, you know, it's not, I mean, the audience will also know that, of course, like this isn't some magic fairy dust that you just give some, it can't read your mind, you know, you have to specify what you want. And this is part of the challenge also building this product of how you educate folks who sit in front of that prompt box.
Yeah, totally.
What is other challenges? I guess like people always talk about like memory. Do you talk about like which model you're using? Any discoveries from like using GPT-5 versus Cloud 4, you know, anything like that?
Yeah. So we right now essentially live on top of Sonnet 4 and we've tried a bunch of other models. We found that to work really, really well for us. The, like, one of the trickier parts to get right actually was file edits, surprisingly, like the,
You know, we tried different iterations. We tried to come up with our own. We started very simple and we're like, you know, here produced diff, we're gonna apply diff. That didn't go very far. We tried to tell it use SED to make edits and then had a lot of problems with it getting back slashes wrong and we tried essentially a fork of clients apply edit tool for a long time and at this point we've landed at essentially Anthropic's standard string replace built in tool and that's working decent. But it's obviously model specific and you know, so the moment we like for the other models that we support, we will need to find something else, but file edit.
Then no, but it's really, really hot and it's very much at the heart of it. Like if that fails, your agent's gonna go astray and burn tokens for no good reason very quickly.
Yeah, I mean, I, I think it's a, we've covered this in our podcast a couple of times and I think both Anthropic and OpenAI have open source. They're the way that they do file edits and it's kind of a research topic, but I didn't expect it to be that much of an unsolved issue. I haven't tried to do this myself. But it seems to be like something that's, that's every lab is, is coming to deal with and obviously we'll post train for. The other thing I'll mention here is MorphLM, which apparently is focusing on just file editing, like they do the sort of the fast edit company. Okay, cool.
Especially doing that for larger files is really interesting, you know, like doing that for a hundred lines, no problem, but almost sorry to say like the largest, it's a test file. Actually, the largest GO file we have is about 8K lines. And you know, adding a test case in there is really a challenge.
Yeah. So one thing that always comes up with like all this conversation about like coding agents is pricing model. Obviously you guys are enterprisey business, so in some, in some ways you already have a, you know, a lot of large contracts anyway. How are you thinking about pricing for owner?
Yeah, so I think they're really, you know, on the enterprise side, how we always also have differentiated is that we can deploy inside of the VPC of our customers, which is a requirement. So ONA is powered by a runner-based architecture where we can deploy in various, you know, infrastructure and compute destinations. And so we run inside of the network of our customers, which gives us more flexibility where we can connect also to their like Bedrock and Vertex instances inside of the enterprise. So there we have, we have, we have high pricing flexibility. On the self-serve side, which we are also launching when this podcast is out, you can just go to ona.com and try this for yourself.
In September, you will get $100 in credits if you upgrade to the core tier. So that will be made available for you to try that out. And here we follow a credit model where we blend a bit the compute and token usage. Generally, we are really, we're not in the inference game, right? And I think the value that we provide, which is important. We want to price on the value that our platform provides is really in the sandbox isolation, the connectivity, so that you have access to everything you need in order to write professional software. It's in the parallelization, it's in the autonomy that you get, it's in the editing experience. I think Chris quickly showed that. But having VS Code in the browser, this is a native and full, like fully
working VS Code version that I think gives us a very nice blend where you don't need to access your desktop IDE, but you can get a lot of things done in VS Code in the browser. And if you want to transition, there is a one-click opportunity as well for you to do that, to continue to work in Cursor, in VS Code, in JetBrains, whatever IDE and desktop IDE you prefer. And the mobile experience is also something we have, we have really optimized for. So all of that is ultimately what we will, what we
Yeah, I think that that is reassuring to hear, right? Like that that you're not in sort of the uh the sort of inference subsidy game or whatever. It's a lot of the conversation recently has been like what people have been calling cursor, the cursor problem.
I don't know if it's a problem, they seem to be doing fine, but like at some point you have to make the finances work.
Yeah, I think if you look from a business model perspective on this, I think at least right now we are not planning to build our own models. I think ultimately that's a way out, you know, if you also are building your own models. We're not doing that, we are really betting on the frontier labs who are focused on coding.
Yeah, awesome. And you know, I think this calls back a little bit, you know, the whole VS Code in the browser thing to the end of local host post that I that I wrote that I know you guys saw like. I guess like, will we ever stop using IDEs? You know, like right now you have the, you know, pop out to cursor button, pop out to whatever VS Code. I can kind of tell that you kind of don't want them to do that. It's like, okay, fine, you're so married to your IDE, like, fine, go ahead, but like, really? Do we need it? I don't know. I will still man the argument for why people love the IDEs. We have much more powerful local machines than we have in the cloud. I ran my Linux box from you, like I have only so much memory, I have only so much whatever. And like you, you shut it down, so there's like a cold start and all that.
Uh, I open up my laptop, it's a super powerful machine, it's like M4 Mac or whatever. And it's on, it's always warm because I'm on it. So, you know, like, how does this work? How does, how does, how does the IDE go away? The local IDE.
It's interesting, I think the um the reason, I think there are two main reasons why folks really love their IDE. One, we're all creatures of habit. Like, this has been conditioned for 30 years, we've been writing software like this for decades. You know, there's a long tail in that change for sure, like, just changing the habit alone is gonna take a long time. And it shows in the way, you know, folks have set up their key bindings and really made it their home. The second is, I think the way you work, like the, the way you write code influences the tool you want to use. And so as long as you're writing code in this deep mono-focused work where you're doing one thing at a time, an IDE is a good tool. It is built for that. And we've spent, again, decades optimizing this one particular way of working.
What's changing with agents is as they gain more and more autonomy, we'll be asked to turn this autonomy into productivity. And the only way we can do that is by doing multiple things in parallel, as we've shown. And the moment you do multiple things in parallel, IDEs really aren't the way. They're not built for this. It's cognitive overload. If you try and out-tab between a bunch of cursor windows, good luck to you. You know, you're not going to have a good time. So we will need new interfaces that help make this parallel work not only easy but highly enjoyable. You know, how do you get into flow when you're doing five things in parallel? It's a question that we need to answer. And I think this is actually the thing that's going to drive people, that's going to fundamentally change how we think of an IDE. We might still use the term, but, you know, give it, give it, I know, I don't want to say a time here, but like, give it some time.
I do think we'll, the interfaces will change, not because we move away from compute to a different form of compute so much, but because we move away from a way of working, you know, we'll move away from this mono-focused work to some parallel track working.
And I think one point, what is very important to us when we designed this from also product point of view is that we give people choice. So I would actually disagree that we don't want people to click that button. Over time, more and more, people should not do that because they get value out of it. But we always want to give engineers the choice. And I think as habits change, as workflows change, whatever interface works for you, you should use. If that is a conversational interface that Chris showed, great. If you can get so far with the agent, amazing. If you need this like hybrid, you know, native VS code in the browser interface to make a couple of quick edits or review, great as well. And then if you want to go to focus mode and like work on a specific task where you need
I don't know, cursors, tap, tap, tap, which is like an amazing feature, or your full jetbrains functionality, go do that, right? So I think it really will depend, at least as we are in this like transitionary phase over the next years, what's the task at hand? And for each task at hand, we want to build a platform that gives developers the tools in order to get that task done.
One, one mental model, like we all seem to like car mental models, like we, we spoke about the time between disengagement at some point. And one, one mental model I have in my mind is like, as long as you work with agents, as long as you go the long distance, it's a bit like highway driving. You know, you're making miles and miles and miles, you're getting a lot of stuff done. And then the moment you, you go into the city, you need, you know, your driving changes, you need more, you need to pay more attention to more details, more things happen. And so you, you maybe want to pull in this ID on the side. If you're driving, if you're driving a car race, you know, the moment you go on a racetrack, you need a very specialized tool, you need to be extremely focused. And then you need a race car to do it. And then you're in an ID. Do you go shopping with your race car? Absolutely not.
Do you, do you haul stuff across country apps with a race car? Absolutely not. So that's the right tool for the job. And I think this is also how things are going to shift over time.
Yeah, I, I definitely think so. It's weird, it's a, it's a such a interesting, twisting journey through all this. But I, I think like you guys are definitely at the forefront of like designing that shift up in terms of like the, the, the sort of power tools. I think the other, the other thought I always have with this stuff is that the other direction, which is in going into production.
You know, you have like pseudo production infrastructure anyway. You know, maybe people at the highest scale really need to scale up. But for a lot of people, especially a lot of like vibe coded apps, like development is all you need. Can I run my like, you know, internal apps on like, you know, my own vibe coded app, right? Like maybe, maybe that's enough.
You definitely have the, you have the choice for sure. So there's an SDK available for the entire platform. And if within your domain, you choose to adopt owner this way, you can, you know, you can use it to, to spin up a machine. We're very, we're very def focused. So we're really intensely obsessed about developers doing their thing. And right now are really focused hard to sort of what we say left of the commit. But it doesn't have to, or left of, left of it going to production at this point. But it doesn't have to be this way. Like you, you can use this platform, there's a lot of versatility in it. For our own focus, we're really focused on, on the developer's experience.
Exactly what Chris said, I think like it's professional engineers right now. We really want to build like a professional editing experience here or general agentic experience. And then let's see, I think there will be a lot of change over the next years coming. And we've played around with that idea going more to the right in the past. So let's see, definitely we have the infrastructure in place.
Yeah, I mean, I think like the, I would have normally said that. And then, you know, Ball and Lovable came up and, you know, they're making like 140 million dollars in like in a year. And like, you know, at some point that's real money.
Okay, cool.
We have a 90% margin though, right now on our enterprise offering, so.
That's also real money.
Better than minus whatever margin that those guys have. Okay, cool. Yeah, great. Congrats on your launch. I'm excited to try it out myself and give feedback. And what other, any other calls action that you guys have? I think Johan has already sort of spilled the beans on like self-serve, you know, you get a hundred dollars. But anything else that you want people to try, like what's a good first thing that you encourage people to try?
So go to, when I go through the onboarding, we curated some of the use cases to get you off the ground and really play with it, use it. It's, it's definitely changed the way I work. It also works well on mobile. I don't think we've touched on that enough. Like I'll share that I have a three months old son. And so I spend a lot of nights sitting on a sofa with the sun on one hand and like him sleeping and a phone in the other. And, you know, I'll get a lot of stuff done. The way I said that to my team at some point is, you know, I'm now three times more productive on my phone than I was on my laptop six months ago. It's crazy how much that shifts. And because it's the same environment on my phone as it is on my desktop, you know, I have a seamless transition. I come into this the next morning and my prototype's still there, my change is still there. And it's the exact same environment that I can continue from, and that's incredibly powerful.
Yeah, I agree with that. We've seen a lot of folks using it also with their iPad. Gives you a bit of more estate. And then I think like VS Code in the browser also really, really shines. But try it out, give it a, give it, give it a shot. All of those environments are fully sandboxed because of the, because of our underlying infrastructure. So give them autonomy. I think that would be really our advice. You can run a couple of them in parallel, like let them do their job. You do not need a dangerously skip permission flag here, like that is by default not.
Not, not, not, not existing because it doesn't run on your local machine. So that is totally like, we love, we love, we love what, what folks are doing there. But we have isolated every environment. So you can just give more autonomy to, to, to folks and are by default in Yolo mode, essentially.
Yeah, you just made me realize I can actually run cloud code inside of ONA. So I can have like two agents.
And we can recommend that as well, if you want that.
The other thing is as well as like, it's not dangerous to skip permissions, right? So actually you can just remove dangerous because it's not dangerous. You can throw away environments, which is very.
Mistakes become risk free in a way, you know? So you can throw away, they're, they're ephemeral, those environments.
It's the default that, you know, the, the agent by default is allowed to do anything and everything. And then also as an enterprise customer, you might still not want that. You might have compliance reasons why you don't want that. So there's a deny list. You can say, I don't want you to run X and we're going, we're going deeper and deeper also in the system to make that happen. Because you tell an agent, it can't run a command, it's going to write a script to run the command. And so the, we're going deeper and deeper to also make sure that that deny list is true.
But by default, we're open.
Yeah, great. Uh, well, you know, I've, I've already probably run over time a little bit, but thank you so much for jumping on and sharing and congrats. And everyone should go try it.
Amazing. Love to hear the feedback. Thank you, Sean.
Thank you.
Page updated October 24, 2026 · transcript and summary are machine-generated
