# ONA: Infrastructure for Secure Agentic AI and Enterprise Engineering

**Podcast:** Dev Interrupted
**Published:** 2026-03-31

## Transcript

Today we're talking to Matt Boyle, the head of product design and engineering for ONA, a company you may formerly know as Gitpod.
And today we're talking about how agentic AI is only as good as its workspace and how ONA's taking that workspace to the enterprise as an entire platform and what that entails.
Because cloud environments, you know, they're built for human devs.
We talk about this a lot on Dev Interrupted, how agents and agentic engineering is arriving into an internet not built for it yet.
But these agenc environments, they need to be ephemeral, secure, and pre-configured.
And all of that becomes the new stakes for building a platform for AI engineering.
So today we're diving in with Matt about how you scope that, how you design it, and what the implications are of having that kind of safe, disposable, and configurable work environment for your AI at scale.
How do you share the distribution of the gains of your 10x and 100x agentically enabled engineers to everybody else?
I think that's the challenge at hand.
And what's most interesting to reflect on, and and a joke that I loved from when I first talked with Matt is the idea of trying to create an agent jail.
Um, the idea of creating a place that contains it so well.
Uh so how do you take that solo agent jet jail experience to the enterprise?
That's what we're gonna figure out today.
So, Matt, you know, welcome to Dev Interrupted.
Thank you.
I love that intro.
One thing that really resonated that you said to me there, and I've never really thought about it in in that specific terms yet, is you know, agents have arrived into uh into an internet that's not ready for them.
And so I think we're, you know, for the very first time in a long time, we're building something's already happened and we're building behind it a little bit, right?
To try and get get all the things that and assumptions we made in the past up to us up to the place we need them to be.
So I really like that framing.
Oh, great.
I'm I'm excited to dive into Moravin and kind of see what you think about some of the other ideas we've been talking about on the show too, because y'all have a big mission ahead.
Um, the idea of an agentic platform, a place where you can run agents off of your laptop in scalable, auditable, configurable, and secure ways.
That's like the real next big challenge, I think, for enterprises and especially larger companies that are trying to integrate it into their preexisting tech.
The brown field problem in AI right now is really big.
So I I'm I want to just know a little bit more, Matt, about the pivot from being in a world where you're you're you have these ephemeral workspace environments at Gitpod and seeing this opportunity.
And like you said, like, you know, th that was built for an internet that agents didn't exist in.
So what were the first steps you all thought of like, oh, how can we re envision this for this new world we're all stepping into?
Yeah.
I actually really I like the word re re envisioned versus versus a pivot.
Because the really interesting thing about what we're doing with Owner is we we we are building on top of Gitpod.
Like we we haven't kind of changed the product fundamentally, we're actually just taking it further than it was before.
Like the way I think about this is and why we kind of felt the need to rebrand and and to kind of come out with with Owner is if you think about um Gitpod's mission to start with was to to make it so you're always ready to code.
And like that mission is still kind of showing up in the way we're building, but the the ultimate goal was to make humans more productive by creating environments where you hit play and the tests run and the code's always ready.
Really focused on getting people to have a really fast time to first commit.
And you know, in large organizations where you have uh real diversity in languages, code bases, make it incredibly easy to be productive.
You know, some of our larger customers before joining before adopting Owner, their time to first commit might be somewhere in the 30 to 40 days just because of all the bureaucracy they've got to get through setting up their laptop.
And we can distill that down to hitting a button, which is create environment and everything else happens.
You get to use the get the best engineer in the company to set up their laptop in the cloud, then everyone gets to benefit from it.
And I love that zoom in on the idea there that you said of time to first commit because it's like a developer experience metric of trying to make it easy for them.
So again, the idea of it being designed for the humans using the internet, right.
That's it.
But then as you take this one step further, everything that the I guess the real sort of realization for me was everything that you've done or can do to make a um a human more productive actually makes an agent more productive too.
Because you know if you think about what we're doing as we go down this gentic journey, we're really focused on giving our agent as much context as possible.
Like MCP has become really popular in terms of okay, there's all this information, this wealth of information about our company in clo confluence or notion.
Let's give our agent access to it.
This it was just kind of implied in the past that human would have that context and they bring it into their coding sessions.
And now we're really starting to think about how to make that programmable.
But one of the really big unlocks for us that we realized is the most important thing actually to to make programming really productive for agents is the run loop.
Having the ability to run the tests repeatedly and say, okay, that passed, that failed, why fix it, take that as an input into the next round, is how you go from generating code or reviewing code in a way that it is useful, but then a human has to come in to finish it off to really get into a place where if you've got great tests and documentation and you can give the agent context, you can actually start to run some really, really impressive uh uh features, ideas, uh changes end to end, because uh you really do have the full uh input validation output available to the agent.
And so kind of dropping that agent inside these cloud development environments that we spent the last four years developing immediately provided so much value that it made sense to really drive down this path.
And um, you know, we're gonna be we're gonna be spending way more time in in this.
But one thing I also want to be really clear on, which might be somewhat surprising, is like we are going to continue to invest heavily in environments.
Like the environments are really, really important, uh, arguably more important than the agent.
I think the more access you give to to the environment, the safer it can be, uh, the more comfortable you can plug in private context that you don't want to egress outside your company, the more successful agents will be.
And so uh the environment is still very, very central to everything we do.
Um, and just making it so the agent can run there safely in a way that companies and yourself are comfortable with is is how we will build a really impressive agentic uh capability here, I think.
In that environment that has to be so finely built for the agent and its needs.
Like, I guess the idea of uploading Git Pod into being like this this home, this like housing, this container for an agent, then lets you, like you said, feed into a loop because you're solving a critical part of how do you evaluate things maybe off my machine or when I'm not at it or otherwise.
And so it actually lets you solve the idea of I can configure this perfect environment where an agent can figure it out.
This makes me think of something that I experienced a lot when I used to be used to be a classroom teacher.
Of the idea is you create the environment that has all of the tools and resources and methods of learning and figuring out the answer and self-correcting when you're wrong and teaming up with other people and cross-comparing, just creating that environment and then getting out of the way so the learning can happen.
That same thing translates to agents and taking them to scale.
So, like you said, you have to create the environment that has all of the right tools, all of the right resources, all the right answers, and their peers that they can work with in order to arrive at yeah, at solutions at scale.
In that world, like, how do you create effectively that container for them?
What more does it really need than what Gitpod already had?
Because I think the challenge I see is like like even the networking around that is not built for agents.
Like, how do you tackle that?
Yeah.
And this is this is a really difficult problem that we're spending tons of time thinking about.
The effectively the the thing that is um very very powerful about the way we've kind of built out our primitives is there's actually no reason why a single, let's call it a prompt box couldn't drive changes across 10 repositories at once.
And this is actually more representative of how enterprise uh works, right?
Like if you want to make a change to the front end of a dashboard, it might be you need to make a PR to the front end and then to the API gateway to expose a root and then to a um back-end service.
Uh and maybe you have to make a configuration change in Terraform to make all these things happen.
And so previously, like a human would orchestrate those three or four changes, make sure the sequence make sure the land.
We're really well placed to do that, actually, like incredibly well placed to orchestrate the whole thing.
So one person can kind of just give the desire and then we can work towards the end state together.
Because we run inside our customers' VPCs typically, that gives us like a unique position to be able to kind of do security and networking at like a few different layers.
So ultimately we have to kind of um adapt ourselves a little bit to align with whatever our customers' sort of network requirements and policies are.
So there's definitely a lot of sort of individual fine-tuning we do with our customers.
But once we've got those things in place, we have quite a lot of success in being able to drive this out uh at scale because ultimately all these are are uh machines running in inside the network.
Like a lot of these companies have a lot of maturity around running them and thinking about them this way.
So there's quite a natural um ability to adopt here because even though it feels unique for a developer to say, oh, my environment now runs in the cloud, actually, these companies have been running workloads that look an awful lot like this for a long time.
They just got to think about them a tiny bit differently.
And then the real changes we had to make in terms of is like thinking about integrations that we want now that maybe before weren't so important, you know, have it giving the agent access to MCP servers for Jira, for Slack, for Notion, for Confluence, uh giving people the ability to plug in uh to private repositories that they have that they've never exposed to the internet before in a way that they're comfortable with is really, really powerful.
And um in in some of our largest customers, um, we we work particularly with um financial firms and pharmaceutical companies.
Like they're able to give our agent access to uh data they consider quite classified.
They would never send this to like an open source model or something outside of their network, but they're comfortable of doing it through owner because of the perimeter that we can put in place.
The final thing on this is yesterday we launched something really cool called Project Vito, and we can share a blog post to to our launch announcement for this.
But one thing that's been very clear to us uh from the beginning here is that security hasn't really it's not ready for the agent age.
And you can you can see tons of podcasts and and discussion about this.
I really enjoyed Lenny's podcast on this, where it talks a little bit about the lethal trifecta and how it's just kind of not solvable right now.
Uh anyone who says that they can solve it, that that they can't.
And so we've been really investing in this sort of defense in depth.
And Project Vito is our first um product that we're gonna continue to invest in this space where um we hired the the folks who built Falco, which allows you to do like runtime controls and uh eBPF layer, so like at the kernel.
And we're already seeing some evidence where we uh we've got some some data points where we can let's say you try to run a command um where say you want to block people from curling to a um to an external endpoint.
One thing that agents do is because they have such a strong reward function is they'll try and use curl, it will fail, and then they'll write a Python script which reimagines curl and makes a request that way because they're just so incentivized to achieve the outcome.
And um some of the things we saw agents do was like rename curl to something else, uh, which bypasses an awful lot of controls.
So change curl to hurl and then use that instead.
And it works in a lot of cases.
We've started to re really develop the primitives to block that, um, where we can stop certain classes of this straight away.
So agents renaming things, moving things around, trying to get clever about moving around the the tools.
Like we can block those two, three, four, five levels deep.
And you can expect to see us continue to invest in this space where we really can keep the agent uh bounded in control.
And this is this is one of the biggest asks from our customers and for large enterprises is you know, just make me feel really good about running an agent in a way that if it tries to do something it shouldn't, like we see it and we can stop it.
I'm really fascinated by that solution because I've oftentimes found myself as someone who runs agents all the time but in the cloud.
Like I I don't do it on my laptop anymore for all the reasons that you know Ona exists because it doesn't scale and I need it running all the time and all those answers, right?
But like all of the time when like those uh agents are working in that way, I've constantly been thinking like it's almost as if the machine they're sitting on itself isn't like really well designed for them.
So the idea of you like even changing out like the kernel level or the system level of what's available and how they can operate is I think the a really powerful idea.
I've thought about the idea of you know, we have this like containerization and virtualization of almost like how do you enrobe the agent's experience inside of something where it can't like break the kernel, right?
It can't modify or rename curl or or have all these crazy incentivized ways that it's trying to just achieve its its goal.
Because you know, when we had Jeffrey Huntley on the show and he talked about the Ralph Loop as what he emphasized really strongly was like, you know, claw uh clawed, especially early Claude Sonnet, it's like a trigger happy like a squirrel.
If you leave it alone, it'll just like press every single button inside your code base and just like break everything.
And it will always, always try to achieve its goal.
So the idea of like modifying at the kernel level to be have guardrails, I think is is really powerful.
Did do you see that as becoming like a whole virtualized machine or a whole new like operating system almost level that they're they're working on that lives inside of ONA?
Yeah.
So the way the way we're thinking about this today is uh we're very opinionated about what our environments look like.
Uh, which is also one of our our learnings from building building um Git Pods really important that you own as much of the stack as possible to really have these controls in place.
Flexibility seems nice and it can be powerful, but every time you give flexibility, you lose a little bit of control to be able to do this, unless you, you know, you've got incredible engineering resources to fine-tune for every single eventuality.
So, you know, we're really standardizing on uh EC2 machines, uh providing our own image, providing our own virtual machine on that, and then we can guarantee the kernel.
And so as long as we can guarantee that code runs in that, we will be able to have a lot more control over the security perimeter.
Um, and we're going to continue to invest in in it from that angle.
So the idea here is that it becomes another primitive that people are modifying and customizing as they need for their specific workflow for their specific security needs.
Um, but it becomes yet again like another like thing in this pipe this agentic pipeline that you're configuring down to like a very specific level.
Absolutely.
So the way the veto works today is uh you can kind of specify some rules that you care about.
Like, I don't want people doing these things, but I I'm comfortable with them doing these things.
We have our own list of rules, like, hey, here's something we recommend.
For example, um, one of the things that really sort of gave us a lot of confidence this was a good approach is when we looked at like Shah Hadul and thought about how we potentially could have been in a really good place to to help there.
So we've got rules to kind of help with that immediately, and then kind of it then becomes like a um risk appetite of specific organizations of of what they want to allow to happen within within their enterprise.
So there's definitely a configuration piece to this, but there will be some general rules that probably can apply to all agents as we as we look to roll this out.
And as you're going down and down all the way down to the kernel level, what about the other direction and going up in the things that you expose the the capabilities and the and the gains from ONA to more people to within an organization, maybe even the non-technical folks who are definitely having their renaissance moment and being able to access and build technology.
How do we bring them to Owner?
Yeah.
I I love this question.
So there's a there's a few things here because obviously having defense in depth is really important.
And right now we're talking about um, I guess like quite a mature class of attack where we want to defend against that.
But the other side of this is exactly that is how do you get comfort that you can let anyone show up to your platform and they can use it safely because the product guides them in in the right way.
I was just listening to the um Boris's podcast on Lenny's podcast.
Um he talked about like latent demand, right?
And how you sometimes have, you know, piece your product being used in a way maybe you didn't really expect.
And that's certainly been um one of the learnings I've got from Owner over the past um few months that I've been here is we're seeing quite a lot of adoption actually with what we kind of um what we would call citizen developers, right?
Like it's not the hardcore engineers, but it's kind of like the engineer adjacent.
So, for example, I've seen business people use Owner to generate slide decks, and because and the reason they do that is because they can expose it on their network and share it with people.
Uh and it's you know, they got they've got a lot of sort of power and control that way.
Um we've seen people really enjoy the fact that we have VS Code in a browser because there's like a class of data scientists who they want to write some Python, but they really don't need to be able to do that.
Exactly.
But but they don't they don't care what IDEs they use, and they don't want to spend any time investing in in like making it work on their machine.
They just want it to work.
And so it's been really interesting to see that like latent demand show up for us.
And to your point, sometimes they're the people you need to kind of have the best.
I don't I don't necessarily think about it security, but just like making sure the product guides them in the right direction.
And so we've got all the things you'd expect.
Like we've got really basic RBAC.
Uh, we have network level controls, we have the ability to share things and um and even control permissions to kind of push pull from Git from within the platform.
But I think one thing I'd like to see is double down on a little bit more is I I think a little bit more about personas now.
You know, and it's it's not just about permissions, it's like why do you show up to our platform?
Like what are you trying to get done?
And is there an experience we can tune towards where we can uh potentially just frame things a little bit differently for you.
If you are a uh you know, a a back end developer who's very comfortable with certain terminology versus someone who just wants to um you know run something inside VS Code, we can probably shape the platform a little bit easier for you.
Um have the guardrails in place, um security-wise, but also just make sure we make a really pleasant experience and hide some of the complexity that you don't need to see right now.
Yeah, that's a really wise observation because obviously AI being here on the scene allows you to chat throw away those preconceptions or those norms we had before about how we made and shipped products, how we packaged them and made them available to people, because now you really can personalize this so it meets everyone on their level.
Like when computers were first invented and people were using computers in science labs, no one was thinking about how do we make this safe for people to use in their living rooms.
Like that takes time to evolve there.
But like as we're learning with things like open claw, you know, just hitting like the most starred repo on GitHub ever, um, like the massive adoption of like agentic assistance and the ways of working with these tools is it's living and expanding outside of a tech focused world.
So I think anything that we can do to bring this technology to them at their level and make it safe, because just as they have the capability now to take advantage of it, we have the capability now to make an improved experience that protects them from the things that that maybe are not as obvious to you and I, right?
And in that world too, like a lot of other norms change as well in something like ONO or or working in that kind of world, like anything can that can access the internet can become an IDE now.
You know, you could code on your phone.
Um, this is something that I I do all the time.
I'm curious, like, what do you think about um the idea of how a tool like ONA frees people up, even from their laptops and and the way that they do with their work.
Yeah.
So in in our in our company, in our organization and in our most forward-looking companies that we work with, we we do not see much IDE usage anymore at all.
Um it's very, very rare for an engineer in our company to open a fully fledged IDE.
And we this week we shipped um uh what we could call review, like in the product.
So you can owner will generate code for you, and then it will show you the changes and you can comment on them like it's a GitHub pull request, exactly the same experience, but without leaving our product.
And then you press one button, you send it back to the agent, the agent fixes it based on your review and you're ready to actually merge.
More and more I am convinced that the the IDE might not see it until the end of this year.
I think um people who are not willing to let go of habits they have today, I think will continue to use it.
And you know, you can see IDEs even trying to shift into this.
If you use the latest version of Cursor, it looks an awful lot like ONA, where they're trying to step away from the VS Code uh browser a little bit into more of this like conversation, uh orchestration on the left-hand side and then maybe some sort of review panel.
Um so yeah, I do more and more of my development on phone on my phone now.
Like I raise pull requests instead of tickets now, because it's easy.
Like it's so cheap to show instead of telling now that actually throwing up the PR is actually much faster than than writing the ticket at times.
And you can even work backwards from that into a ticket if you want to.
But yeah, all these notions we had of how we should work and and um the pace that of delivery that was possible are all thrown out the window.
And if you let go of the IDE is something that you need, actually it's quite freeing, actually.
And you start to realize like how much more you can actually get done if you don't need to defend on on that interface.
Yeah, I I completely echo that.
Um abandoning the IDE and moving into the terminal was one of the best moves that I made for just my speed.
And it's something now where, you know, I was a diehard IDE user, but like now I I can't even go back.
Like I just I much prefer to be in the terminal.
Um I just think there's a lot of it actually what how I've thought about it before is it gets you closer to the craft, I think, in a lot of ways.
It you're kind of getting rid of complexity and the layers that you needed before to kind of work with it that way.
But like you said, those experiences, those IDEs are also now very so conversation driven.
Like the chat window takes up most of the screen.
Tools like cursor, like they opt you into an experience where you have multiple chats and you're they're trying to not even really show you the code anymore, right?
So it's like everyone's evolving into that new way of working.
And like you said, it sometimes that involves like piecing together what you need and working backwards.
There's so much context flipping over and and exploring.
And honestly, I spend most of my time just gathering all of the context and lining it all up and before I would even start to execute it, which is like speaks to a fundamentally different skill set that I think engineers have to be building and adapting.
Uh, what do you think about like the skills that engineers of today and tomorrow need?
Yeah.
I mean, one thing you started uh this podcast, you introduced me as the head of product design and engineering.
And it might seem quite unusual, I guess, to group all of those so closely, but I think the it actually represents how we think about the future of of of engineering and and product and design.
Is we hire people who are very T-shaped now and like really, really look for people who have depth in one area, but can branch out in both directions.
So, you know, we have a designer who can ship.
We have a um very product-minded engineers who will can go and speak to our customers, represent great empathy and move it all the way through to to production too.
And I think this is the way I think about uh the skill set of engineers of the future is like in the 2010s, we used to talk about like full stack engineer.
And I think about that again, but full stack means something a little bit different to me now.
It means full stack product, it means thinking about design and it means being able to kind of execute on that too.
And if you really embrace this um and and find people who who are kind of committed to to working this way, you know, some of the most uh technically challenging things in Olna have been built by like teams of two people because they're just so empowered and capable of driving things from idea, you know, maybe it's very unclear too, and they can drive clarity around the idea, they can plan it, they can execute it all the way through to to production.
Um so they're the people I really love working with, and you know, we're we're seeking out more and more of those people who are they've probably spent the career going deep on one of them and are now starting to explore the other two parts of the craft now that the barrier to entry is a little bit lower.
And the rate to which we can see people grow in those areas is is phenomenal.
And I I'm sure you've seen this too as well.
The ability now for engineers to spread out into that wider fan shape of being able to do things has never been those possibilities, have never been more open.
Um the idea of even working with um agentic tools to grab the understanding that you don't have to have a sparring partner as you're learning and to expand into those areas, I think is really critical.
Um I love the idea of like, you know, the designer who can ship and the engineer who can go to customer meetings.
Uh we actually talk a lot about the importance of that cross-interdisciplinary like access to customers and problems that engineers that they really need to uh ship software that's impactful.
In in this world too, I'm sure you're envisioning a lot of the time that engineers spend isn't now, you know, in a clawed code session necessarily, because a lot of it is spent uh aligning and getting the decision on what needs to happen, but then also becoming like the context guardian, like having the really great Jira ticket that has all of the excellent context in it.
And then being able to like engineer this like shared layer between the humans and the agents, I think that becomes like the new challenge for engineers to go after.
Absolutely.
I can give you I can give you a concrete example of um this workflow and how it's showing showing up for us a little bit, which is which is fun and it might seem wild to some people listening to this, depending where they are on the journey.
But like, yes, so I I spend most of my time in in meetings, honestly.
But there's I have this real uh desire to have a Slack integration.
It's something we've been talking about for a little while.
And I'm just like, you know what, this today is the day I'm gonna build it.
So uh owner has this plan mode, and so I gave it the Slack docs, I gave access to um another integration we built recently, which is the linear one.
And so I asked it to explore our code base, uh, figure out how we should build this, and then from that, I used our notion integration to push that design doc to to Notion.
I then uh while just before I attended a meeting, I sent it to some of the most senior engineers in my team and asked them to review it, leave comments and feedback.
Um I read it, digested where I think it could be improved, and approved their comments, changed it a little bit, and told Owner to pull that back in.
Owner pulled that back into the platform, um, and I asked it to s to make a linear project for me and to split it into uh tickets, smallest shippable increments it could come up with, uh, and to map the dependency between those tickets too.
And so it pushes all that to linear, and linear shows me which tickets are blocked by which and and which ones uh can be done in parallel effectively.
Um I then used linear for agents, which is another integration we built, to assign the ones that didn't have dependencies to to agents.
Owner went off and built them.
I carried on with my meetings and at lunchtime there was four PRs ready for me to review, um, which I shared with the colleagues to make sure we were aligned and happy and and off we went.
Anyway, this goes on, you can see how this is playing out.
But by the end of the day, I went from I'm gonna build this this morning to it's shipped in the evening.
And then today we're just doing the configuration pieces to be able to do it.
I feel like this would have been a once two week project in the past for me to be able to go from okay, I want this, like I need to figure out how to do it, I need to explore our code base, I need to understand it.
So to be able to do this in in a day is just mind-boggling to me when I reflect.
But all this is just about bringing humans into the loop at the right points, like really spending that time and planning and you know, giving it to your point, like the great context and encouraging the agent to explore specific parts of the code base that I I knew were good for it to explore.
And then from that, you can accelerate development so so quickly.
I love that you brought us here to the story of how you use loops and how you are using engineering, agentic engineering tools um in the background to enable yourself and do things.
You called it like a two to four week project in the past, you know, but like you you were in meetings the whole time this thing was even being built, right?
That's actually the real benefit is that you didn't really spend any time aside from understanding really clearly what you wanted and arranging the resources that were needed.
Um the way that you described it of um very cleanly laying everything out, breaking it up into a very atomic tasks, power or parallelizing things as you need and then assembling at the end, you know.
That's something that we talk about a lot on the show.
It sounds crazy to many people, maybe not a lot of the dev interrupted listeners, because we have some amazing cutting-edge folks on here every week that are echoing the same stuff.
You are, Matt, about how that's what makes for a successful engineering output now.
And um, and so I I love to hear that story.
I I have a lot of similar success, especially with bringing other people in to iterate on those outputs, those experiences, especially if for this is a call to action, I think, for product managers, engineering managers, folks who are in a like a team lead position and have an opportunity to be doing projects like this, uh, like between or during meetings, and then sharing having a system where you can share the outputs back to your engineers and your team and quickly get a register and a read on like is this useful?
Is this solving the problem?
That actually lets you unlock like an iterative speed.
So you you talk about the Ralph Loop.
And I know uh that on ONA, y'all had this amazing blog post about the Ralph Loop.
And Ona, I think is critical to what makes the Ralph Loop successful.
Um, the idea that it's the environment that um allows that loop to run over and over again and get that output eventually, and you can just rely on that environment being configured exactly as you expected.
But I'm wondering about like, how do we take that further?
So, like the ONA world and the Ralph world, I think that like I also compare this to the ideas like Steve Yage's gas town, where the idea of you scale that up into almost like a software factory and that lives somewhere.
And I made a joke like on here a few months ago or a week ago where I was like, you know, oh, what's what's gonna happen?
Is my gas town gonna call your gas town?
Like, I don't think that's where this is going.
But now I actually think that is where this is going with things like agent engineers, uh, engineering platforms like ONA, like you could have those systems and those factories, and then you almost have to now think about how do you wire them up between each other.
I'm just curious to pick your brain on how you think it's like the evolution of engineering, like things like Gas Town will collide with things like ONA.
Yeah, it's uh it's a great question.
And we spend a lot of time intention here, I think, because we we're we're you know, we're a Series A company, we have a lot of flexibility to move around our R SDLC process, how we think about things.
Um but we also, because of the customers we have, we also have um, you know, we have SOX2 compliance requirements.
Like our customers have even more stringent requirements than we do.
And so it it's really important that we try and stay as close to the cutting edge as possible.
And we think a lot about like these really long running loops where you know you saw anthropic builder, rust compiler.
But like there's there's all these checkpoints that are built into the STLC process that again the the the world wasn't built for agents yet.
We're not ready for these incredibly long running processes.
And so I spent a lot of time in this tension about how far do we push ONA today in terms of its like long-running capabilities versus how do we make sure that we're actually serving what our customers need today, which is it has to map to their SDLC process.
And it doesn't mean we can't put a bit of tension on them to encourage them to change things uh, you know, where they need to.
But a lot of the things in their SDLC process were wisely put in place for for certain reasons.
You know, um uh I I think if people found out the bank was what running huge Ralph loops to develop a brand new feature, they'd be pretty uncomfortable with that.
Um, so I spent a lot of time on this particular problem with our customers, trying to reimagine not just what SDLC looks like for those who can move incredibly fast, but how does it look for those who you know have these really intense compliance obligations?
And um I don't have all the answers yet, but I have some really good ideas about uh things we can start to explore here to speed up various points, and then we can look to work together to maybe really start to reimagine SDLC for scale, not just for the smaller companies where they can just you know run a Ralph loop forever.
Do you think the SDLC stays a human and agent collaborative place, or do you think it moves fully into the domain of the agent in that world?
For me, this is such a good question.
I feel I feel this splits into into two, doesn't it?
I think in the in in the medium term, I think humans being in a loop makes tons of sense.
Because I think when I think about the best engineers in the company uh today, they're the ones who have the most context actually of the things that shipped, the system, uh architecture.
And if you give a really senior engineer access to AI tools, they fly.
Whereas we still have the same problem where we need to give guidance to to uh more junior engineers who they have access to the same tools, but they don't achieve the same outcomes.
And so why is that?
It's because humans are still very, very important to to the planning in the loop process.
And if you ask um if you ask an agent like, what should we build next?
It still doesn't give you a great answer, even if you give it all the context in the world.
So at least in the the midterm, I think humans being in the loop is incredibly important.
I would not dare bet against like entirely autonomous uh features, teams existing in the future.
And when I say the future, it could be next year with the rate of development we're working on.
And so I uh I'm I guess cautiously um pessimistic I guess for this year.
But like we the the the framing I was trying to keep in my mind is like build for the models that are going to exist in six months and 12 months.
And like when I approach our product with that lens, like I really do think the software factory that you talked about is a really interesting one.
And whether the person who puts that thing on the conveyor belt at the front is that a human or an agent and it's probably likely going to be a bit of both I think.
The idea of the autonomous software factory running by the end of the year or maybe early next year it's definitely something to consider right and and I think when that happens like we'll have to we'll have to have you back to talk about how like the idea of that living on something like ONA is a reality because it if anything I think that that would come into existence on a platform like ONA.
Because like we said at the beginning agents have arrived into an internet that's not built for them yet and challenges upon us now to construct that internet and ONA is tackling this I think in a lot of fascinating ways that appeals to you know really strict and compliant enterprises, but also like lightning fast teams, and you don't get a lot of product coverage in tools that are that relevant and that important right now.
So I think it's a really exciting story to follow.
You know, we've been covering ONA here on Dev Interrupted for a while and we'll continue to, but it's been a blast having you on the show to talk about like the vision behind it.
I'm curious, like, do you have any final notes you want to end on for our audience where maybe they can go learn more about ONA and what you're working on.
Yeah.
Um, so head over to Owner.com, read some of our blogs.
Like we're we're trying to get uh way more um involved in posting how we're thinking about where things are going and how we're thinking about the space.
So we'd love for you to read all those and uh message me on LinkedIn or Twitter if you're like, hey, I I I have an interesting take on something you said or I disagree with you.
I'd love to hear from you.
Um we recently, in the last few months, we launched a um uh cloud offering where you don't have to have, you know, you don't have to deploy this into an enterprise or have an enterprise account with us.
You can sign up and pay like 10, 20 a month and start experiencing ONA.
So if anything I said sounds interesting, please give it a try.
Again, send me your feedback directly.
I respond to everybody.
I love hearing it.
So if you're interested in agent security, runtime security, especially, like really want to hear from you.
Awesome.
Well, we're gonna include all those links in the show notes.
I love the call to action for people to come and find us on LinkedIn, continue the conversation.
I've really enjoyed having uh these conversations continue beyond the podcast here.
So please come find us, share what you think about these tools and where all of this is going.
We definitely want to hear from you.
So thanks for listening for to Dev Interrupted, and we'll see you next time.
And Matt, thanks again for coming on the show.
Thank you.
It's a pleasure.
AI is everywhere in software engineering, but most teams still can't prove its impact.
That's where the Apex framework comes in.
Apex is a new operating model for engineering productivity, designed to measure AI where it actually matters.
At the pull request level.
It connects AI activity to delivery outcomes, not just tool usage.
Apex is built on four pillars with AI leverage, predictability, efficiency, and developer experience.
Apex helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos, and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, Linear B and Apex gives you the system and the cadence to do it.
Download the guide and start measuring what matters.