Retrofit or reimagine? Developer environments for humans and agents | Ona’s Matt Boyle

0:04Today, 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 is 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 talked about this a lot on Dev Interrupted, how agents and agentic engineering is arriving into an internet not built for it yet. But these agentic 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.

0:47So 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 a joke that I loved from when I first talked with Matt is the idea of trying to create an agent jail, the idea of creating a place that contains it so well. So how do you take that solo agent jail experience to the enterprise?

1:26That's what we're going to figure out today. So, Matt, you know, welcome to Dev Interrupted. Thank you. I love that intro. So one thing that really resonated that you said to me there, and I've never really thought about it in that specific terms yet, is agents have arrived into an internet that's not ready for them. And so I think 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 all the things and assumptions we made in the past up to the place we need them to be. So I really like that framing.

1:55Great. I'm excited to dive into more of it 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. 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 pre-existing tech. The brownfield problem in AI right now is really big. So I want to just know a little bit more, Matt, about the pivot from being in a world where you have these ephemeral workspace environments at Gitpod and seeing this opportunity.

2:35And like you said, 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-envision versus versus a pivot because the really interesting thing about what we're doing with owner is 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 and 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 make it so you're always ready to code.

3:15And like that mission is still kind of showing up in the way we're building. But 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 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 you've got to get through setting up the laptop.

3:48And 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 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 agentic journey we're really focused on giving our agent as much context as possible like mcps become really popular in terms of okay there's all this information this wealth of information about our company and 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 um 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 features ideas changes end to end because you really do have the full 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 you know we're going to be we're going to 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 arguably more important than the agent i think the more access you give to to the environment the safer it can be, 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.

6:06And so the environment is still very, very central to everything we do. And just making it so the agent can run there safely in a way that companies and yourself are comfortable with is how we will build a really impressive agentic capability here, I think. And that environment that has to be so finely built for the agent and its needs. Like, I guess the idea of up-leveling Gitpod into being like 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.

6:47And 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 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 right answers and their peers that they can work with in order to arrive at solutions at scale.

7:35In 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. How do you tackle that? Yeah. And this is a really difficult problem that we're spending tons of time thinking about. Effectively, the thing that is very, very powerful about the way we've kind of built 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 works, right?

8:18Like 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 backend service. 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.

8:50because 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 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 at scale because ultimately all these are are machines running inside the network like a lot of these companies have a lot of maturity around 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 because 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 is really really powerful and um in in some of our largest customers we work particularly with um financial firms and pharmaceutical companies like they're able to give our agent access to 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 um called project veto and we can share a blog post to to our launch announcement for this but one thing that's been very clear to us from the beginning here is that security hasn't really it's not ready for the age and age.

10:40And you can see tons of podcasts 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. Anyone who says that they can solve it, they can't. And so we've been really investing in this sort of defense in depth and Project Veto is our first product that we're going to continue to invest in this space where we hired the folks who built Falco, which allows you to do like runtime controls and EBPF layers, so like at the kernel. And we're already seeing some evidence where we've got some data points where we can, let's say you try to run a command where, say you want to block people from curling to an external endpoint.

11:22One 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 the request that way, because they're just so incentivized to achieve the outcome. And some of the things we saw agents do was like rename curl to something else. which bypasses an awful lot of control. So change curl to hurl and then use that instead. And it works in a lot of cases. We've started to really develop the primitives to block that 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 tools.

11:58Like 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 abounded in control. And 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?

12:34But like all of the time when like those 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 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 have all these crazy incentivized ways that it's trying to just achieve its goal.

13:15Because, you know, when we had Jeffrey Huntley on the show and he talked about the Ralph Loop, that's what he emphasized really strongly. It was like, you know, Claude, especially early Claude Sonnet, it's like a trigger happy, like a squirrel. And 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 guardrailed i think is is really powerful 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 of ona yeah so the way the way we're thinking about this today is we're very opinionated about what our environments look like which is also one of our learnings from building Gitpod is it's really important that you own as much of the stack as possible to really have these controls in place.

14:09Flexibility 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 know you've got incredible engineering resources to fine-tune for every single eventuality. So, you know, we're really standardizing on EC2 machines, 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, and we're going to continue to invest 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.

14:50but it becomes yet again like another like thing in this agentic pipeline that you're configuring down to like a very specific level absolutely so the way that veto works today is you can kind of specify some rules that you care about like i don't want people doing these things but i'm comfortable with them doing these things we have our own list of rules like hey here's some 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 Hadool and thought about how we potentially could have been in a really good place to help there.

15:22So we've got rules to kind of help with that immediately. And then kind of, it then becomes like a risk appetite of specific organizations of what they want to allow to happen 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 look to roll this out. And as you're going down and down all the way down to the kernel level, what are the other direction and going up and the things that you expose the the capabilities and the and the gains from ona to more people to it 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 ona yeah i love this question 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.

16:13But 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 the right way. I was just listening to Boris's podcast on Lenny's podcast. And he talked about like latent demand, right? And how you sometimes have, you know, your product being used in a way maybe you didn't really expect. And that's certainly been 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 the reason they do that is because they can expose it on their network and share it with people and it's you know they've got a lot of sort of power and control that way and we've seen people really enjoy the fact that we have vs code in the browser because there's like a class of data scientists who they want to write some python but they really don't want to do their python notebooks exactly but but they don't they don't care what ideas 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 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 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 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 a little bit more is i think a little bit more about personas now you know 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 potentially just frame things a little bit differently for you if you are a 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 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.

18:39Like 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 OpenClaw, you know, just hitting like the most starred repo on GitHub ever, 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 maybe are not as obvious to you and I, right?

19:25And in that world too, like a lot of other norms change as well in something like ONA or working in that kind of world. Like anything that can access the internet can become an IDE now. You know, you could code on your phone. This is something that I do all the time. I'm curious, like, what do you think about the idea of how a tool like ONA frees people up even from their laptops and the way that they do with their work? Yeah, so in our company, in our organization, and in our most forward-looking companies that we work with, we do not see much IDE usage anymore at all. It's very, very rare for an engineer in our company to open a fully-fledged IDE.

20:06And this week, we shipped what we just call a review, like in the product. So 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 id might not see it till 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 owner 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 the 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 yeah all these notions we had of how we should work and and the pace that I've delivered that was possible are all thrown out the window.

21:16And if you let go of the IDE as something that you need, actually, it's quite freeing, actually. And you start to realize how much more you can actually get done if you don't need to defend on that interface. Yeah, I completely echo that. 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 can't even go back. I just much prefer to be in the terminal. I just think there's a lot. And actually, how I've thought about it before is it gets you closer to the craft, I think, in a lot of ways.

21:49You'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 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, sometimes that involves like piecing together what you need and working backwards. There's so much context flipping over and exploring.

22:22And 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. What do you think about like the skills that engineers of today and tomorrow need? yeah i mean one thing you started 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 engineering 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 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 find people who who are kind of committed to working this way you know some of the most uh technically challenging things in owner 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 production.

24:00So they're the people I really love working with and we're seeking out more and more of those people who are, they've probably spent their 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 phenomenal. And 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. It's never been, those possibilities have never been more open. And the idea of even working with 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.

24:41I love the idea of like, you know, the designer who can ship and the engineer who can go to customer meetings. 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 ship software that's impactful. 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 aligning and getting a 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 in the agents, I think that becomes like the new challenge for engineers to go after.

25:35Absolutely. I can give you a concrete example of this workflow and how it's showing up for us a little bit, 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 spend most of my time in meetings, honestly, but I have this real 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, today is the day I'm going to build it so 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 i want to pull that back into the platform and i asked it to to make a linear project for me and to split it into uh tickets smallest shippable increments it could come up with 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 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 going to build this this morning to it 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 one to 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 in planning and you 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 knew were good for it to explore.

27:50And 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 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 were in meetings the whole time this thing was even being built, 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. The way that you described it of very cleanly laying everything out, breaking it up into very atomic tasks, parallelizing things as you need, and then assembling at the end.

28:31That's something that we talk about a lot on the show. it sounds crazy to many people, maybe not a lot of that have 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 so I love to hear that story. I have a lot of similar success, especially with bringing other people in to iterate on those outputs, those experiences, especially if 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, 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?

29:19Is this solving the problem? That actually lets you unlock like an iterative speed. So you talk about the Ralph loop, and I know 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. The idea that it's the environment that 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 Yegg's gas town or 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 oh, I actually think that is where this is going.

30:14With things like agentic engineers, 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 Gastown will collide with things like ONA. Yeah, it's a great question. And we spend a lot of time in tension here, I think, because we're a Series A company. we have a lot of flexibility to move around our SDLC process, how we think about things. But we also, because of the customers we have, we also have, you know, we have SOX2 compliance requirements.

30:55Like our customers have even more stringent requirements than we do. And so it's really important that we try and stay as close to the cutting edge as possible. And we think of a lot about like these really long running loops where, you know, you saw Anthropic build a Rust compiler. But like there's all these checkpoints that are built into the SDLC process that, again, the world wasn't built for agents yet. We're not ready for these incredibly long-running processes. And so I spend a lot of time in this tension about how far do we push Owner today in terms of its 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.

31:30And it doesn't mean we can't put a bit of tension on them to encourage them to change things where they need to. But a lot of the things in their SDLC process were wisely put in place for certain reasons. You know, I think if people found out their bank was running huge rough loops to develop a brand new feature, they'd be pretty uncomfortable with that. 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?

32:01And I don't have all the answers yet, but I have some really good ideas about 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 run a route for 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 this splits into two, doesn't it? I think in the medium term, I think humans being in a loop makes tons of sense.

32:37Because when I think about the best engineers in the company today, they're the ones who have the most context, actually, of the things that shipped, the system, 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 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 the planning and the loop process. And 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.

33:12So at least in the midterm, I think humans being in the loop is incredibly important. I would not dare bet against like entirely autonomous 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 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 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 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.

34:24And 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 will 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 ona.com read some of our blogs like 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.