Self-Healing Software with Agent Fleets: OpenHands Vulnerability Fixing and Code Review

Summary

Code Verification Priority: Prioritize verification over generation because AI makes code generation trivial; every developer must adopt quality assurance practices to validate agent output.
Isolated Agent Execution: Run autonomous agents inside secure managed sandboxes with least-privilege access to prevent unauthorized system modifications and credential exposure.
Automated Quality Gates: Implement static analysis, type checking, and complexity metrics to block low-quality agent-generated code before it reaches production environments.

Self-Healing Software with Agent Fleets: OpenHands Vulnerability Fixing and Code Review

OpenHands, an open-source coding agent harness, runs a fleet of automations that fix dependency vulnerabilities, triage release errors and review pull requests, with agents isolated in managed sandboxes and humans kept in the loop. This video explains how to run autonomous coding agents safely at scale and why verification, not code generation, becomes the bottleneck.
The OpenHands team describes three automations: a vulnerability fixer, a Datadog log retriever that files tickets or opens PRs after each release, and a code review bot built on a skill file that encodes organizational knowledge. They cover limitations such as tests that passed but did not reflect production, an agent posting to the wrong Slack channel, and a race condition found with the Quint formal verification tool. Guardrails include least privilege, SonarQube quality gates, and cyclomatic complexity and Halstead measures against runaway code. They conclude that fully automated dark factories are impractical for bespoke software and human sign-off remains essential.

Chapters

FAQs

What are the main security risks of deploying autonomous agent fleets?

Autonomous agents can cause runaway code complexity, environment mismatches, and unauthorized system modifications. This video demonstrates how robust isolation, sandboxing, and verification frameworks effectively mitigate these systemic risks.

Why is code verification more important than code generation in agent workflows?

Code generation is now trivial for AI, but verification remains the critical bottleneck. This video emphasizes why developers must prioritize quality assurance and thorough validation of agent output.

How should enterprises implement automated quality gates for agent-generated code?

Use static analysis, type checking, and cyclomatic complexity metrics to block low-quality code before production. This video shows how automated guardrails prevent code bloat and security vulnerabilities.

Can autonomous agents fully replace human developers in software delivery?

No—this video debunks the "dark factory" myth. Humans remain essential for architecture decisions, cross-repository changes, and final deployment approvals despite powerful agent automation.

Full transcript

`00:00` Introduction

My my colleague Sher and I today are gonna just tell you a little bit more about Open Hands and what we do and Sher will show you probably more kind of on the technical side. Uh just a little bit about myself. I'm on the go to market team here at uh Open Hands. I look after the uh uh in industry. So in the market today. Uh if you follow some of you if you're kind of in the academic field and and do a lot of research you you bump into him a lot and and second co-founder former kind of a Google engineering team uh Robert uh Brandon so uh you know is too we have a great uh open source project on the market for community and from an enterprise adoption standpoint we uh are that means fi financial services uh you know high high sensitivity uh semiconductor manufacturings and to have that kind of a sovereign AI story are backed by tier A ventures and ma venture and Madrona obviously Carnegie Melon kind of pitched in at the seed.

`01:09` Enterprise adoption and self-hosted, sovereign AI

So just uh yeah that's a quick kind of a little background story. Uh with that I will uh hand it over to my colleague. Uh as uh as Cliff pointed out we are an open source uh agent. Um I just want to tell you a little bit about why I love open source. Um and it comes down to why like we all have unique needs. Um so my my daughter was born 3 months ago and uh my back very quickly started feeling the effects of that. Um, and I still wanted to work on all of my personal and work projects.
Um, but I didn't want to like hunch over a laptop so much. So, I bought this like uh Tik Tok scrolling ring, which is as dystopian a device as it sounds. Um, and uh it's a programmable Bluetooth ring with a with a few buttons. And um I was able to turn that into a sort of fully, you know, with using open source tools turn into a uh fully um like voice-based um uh software like development life cycles. At this point, I'm hitting uh a little button on my uh headphones there.
Um not using the ring and just I'm talking and that talking is going to show up as a message to open hands. So it says like, "Okay, then go ahead and make a plan." So this was fun. This is cool. Um but the big thing here is that like I needed this for some time and I couldn't do this with a lot of the closed source tools, right? Um there's a real power to open source and that's what that's what we believe in, right? Right.
Um that's what open hands is about. We have a vision of like software, building software. Um and we live that every day, right? We all like probably everybody in this room started out using coding agents for like small tasks. Uh you know maybe 6 months back or a year back probably feels like a decade back at this point. Um but we see a future where like we you know it's a lot of uh agents orchestrated and there are sort of these folks agentic engineers um who are going to be managing these things right.
We'll see we see a world where 90% of what we call software engineering is like turned into automated effort. Um and the 10% that remains well I mean we can we can get to that in a bit but I guess the question I' on everyone's mind is what is what happens in the rest there. So what did we build? We built a a vulnerability fixer. So there's an automation that goes through if anybody's managed open source dependencies, if anybody's been following the supply chain attacks, knows that it's like pretty important to stay up to date with uh all of your uh security updates.

`03:57` Agent automations: vulnerability fixer and Datadog retriever

So we had a bot that just goes and uh pulls these uh vulnerability lists, publishes um publishes them as uh PRs and some human has to look at them. So we've just been able to churn through so many of these and be assured that our product is more secure. We also built a data dog retriever um which basically goes looks at logs after every single release and says are there new errors in here what exactly is going on traces them and it usually files a ticket but it also could if it feels like the effort is low enough it will actually generate a PR right away and then what end up happening is that all of our engineers were reviewing code all day and I'm sure this is not a strange story to the folks in this room so how do we solve that problem with another automation we built the code review bot.

`04:59` Code review bot built on a skill file

Um, this is also something that you know, uh, the cloud code, there's plenty of cloud code skills for this. Um, and, uh, we just, you know, fought fought bots with bots, I guess. Um, and we were able to reduce feedback speed. Uh, sorry, improve feedback speed. Reduce it. Yes. Um, and we didn't turn it on for all PRs. We turn it on for a certain size and for a certain type of um, PR as long as we know that it's coming from uh, one of our other bots.
The core of the code review bot uh is a skill file um which is just a markdown file um and it contains a lot of like accumulated learnings and like uh it contains the tribal knowledge of our uh organization debates that people have had about what exactly should be in our code versus not. We have um uh a bunch of different repos and having the map the dependency map between repos is super important. But once we actually deployed this uh what we were able to do with open hands is uh track the use of the skill, correlate it with how exactly people interacted with it on GitHub and determine which um comments the agent was making were helpful versus not.
And so we have a research team um that's someone led by Graham and um the research team has been sort of taking those signals improving the skill itself but also um sort of providing post-training feedback so that future models are better at using the skill. Um just a like funny little call out. I don't I don't talk about cost explicitly everywhere else anywhere else in this uh uh presentation but I do think this is um it's not because LMS are cheap uh but because I think the real cost uh remains still engineer time um and really what we were measuring when we were uh building the code review bot is how much engineer time did we save so how do these agents run they run in managed sandboxes um these are you know secure they're not allowed to access the host machine um they have a they can have they have essentially infinite access to do whatever they want on their little guest machine.

`06:45` How agents run safely in managed sandboxes

Um, and changes can't leak out except through git actions. And right, so git is where uh you can kind of monitor what the agents are doing. Um, and um, and then it's also where you can kind of improve uh, their performance in the future by modifying the agents. mmd file um, or anything else. We did some experiments around like having agents directly talk to other agents, what's called like a toa. um it's still a little bit too insecure to just kind of throw that out into the world.
Um and there's still so much going on that you as a human want to see these things. You want to see what they're actually doing. Um so I still think u uh the transparency is super important and like there's so much incremental improvement to still be done on the skills um that a doesn't quite make sense right now. So all these automations that we've built, they can be triggered in different ways. Um, I'm actually going to, uh, you know, take a moment to show you some of our automations.

`07:46` Managing and evaluating a fleet of automations

Uh, so this is, uh, this is an instance that one of our teams uses. Um, so there's 15 automations here. As you can see, one of them is a PR reviewer. Uh, one of them is a Slack channel monitor that kicks off and does various things. Um, and here you can see the, you know, uh, look at that that run failed. We know what happened there. can click in um and we can see what exactly happened. So we can look through the error and and you know over time this is what this is like what many members of our team do right now but over time this is what um we think a lot of engineering is is going to look like and we noticed that you know we were building a lot of these automations but we didn't have a clear idea of um at the end of the week what was working wasn't.
So naturally we built an automation to evaluate our automations and describe how they can be improved. Um this still just creates a report that a human being sits down with and actually usually a couple of human beings sit down with um and then they uh they go and uh uh sort of distill lessons from that and turn it into extensions um and or which are again usually skills or plugins or um just we should integrate this other service.
And so we have this publicly available extensions repository uh that you can go and you can grab skills. There's a bunch of interesting things in here. Um this is not something that's like openhand specific. You could uh I think people in open hands do use other uh agents as well on occasion and you know the like you can use these as well. So with all of that we're now writing perfect code right. Um I I joined open hands uh like uh with with a lot of excitement that agents can finally systematically address tech debt, they can you know uh improve performance, they can just do so much, right?

`09:42` Limitations: passing tests do not mean working code

Um and the reality is while automation definitely churns through a bunch of uh problems um we're not writing perfect code. Perfect means something different now. Um, and there's still so much like logic and architecture that is tough for agents to reason about. And I'll talk a little bit about that. So, what are the limitations? We've done this for a while now. What exactly goes wrong? Uh, I want to share this uh this issue from I think it was actually from two weeks ago.
Um, this was me. I submitted some code and I didn't notice that a commit statement was missing at the end of uh a database transaction. But the tests were passing. And why was that? And it's because the tests were written um to specifically test for what is sent into the database connector um in some cases and in other cases it was uh testing using SQLite and not Postgress. Um and so everything looked fine uh except that it didn't actually work in production.
Um and that was a humbling lesson. So how do you fix this? How do you avoid this type of thing? It's the age-old uh tension in software engineering which is does your production environment look like your test environment? Um or vice versa. Does your test environment look like your production environment? Uh we had an issue the other day that was comparatively small but it you know it feels like foreshadowing for for something else which is um we had an automation running.
It had access to both our public slack and our private slack. uh I asked it to post something on the private Slack and since we don't actually name our public Slack and private Slack public and private uh it posted it to the public one. Um ended up being not too big of a deal but that was a little bit of a a concern. So when it comes to secrets like you have to think a lot there's sort of good software engineering principles here as well which is the principle of lease privilege.

`11:25` Agent mistakes and the principle of least privilege

Don't don't give the keys to the kingdom to every automation that you have. We also have a lot of repos. Um, and I'm going to go out on a limb here and start with the solution first, which is I I sometimes wonder if a monor repo and a monolith are much easier for agents to reason about than a microservices uh architecture with tons of repos. Um, there there's been times where an agent will go and build something um very confidently say it's done, but it's only done in one repo. um and you actually need to touch the you know the UI in this other place and uh this can be hard to get across.

`12:27` Formal verification with Quint to find a race condition

Then we had this really interesting incident. We kept seeing on call a bunch of pages. Um and it was because of our our sandbox environments. Uh they kept spinning up and then dying. We couldn't figure out why. Um the agents couldn't figure out why either. And eventually we uh reached for Quint which is a formal verification tool. Um, and we were able to use Quint with an LLM to reason about what exactly was going on in our uh, distributed system service, right?
And what we found was that there was a race condition that was kind of embedded deep in there. Like I think it would have taken us multiple engineer months to find it and that was the issue. We solved that and then we stopped getting paid all the time. So there's definitely a there there for formal verification but it was difficult. Um, it's difficult to understand and reason about and it's not a good fix for every problem.
Uh I'm a huge fan of someone named Hell Wayne. Uh H Wayne's writing on the topic. He's been working on formal verification for most of his career. Um he works with something called TLA Plus. Um and he says, "Look, with LLMs, formal verification is going to increase so much in the market. It's going to go from 02% of companies caring about it to 3%. Huge 50% increase, right? But that's still like so tiny for most of our like we're not going to care about this.
But there are tools adjacent to formal verification like property based testing that are still super useful. And when I think about what exactly formal verification is and the fact that we you know push the system out there and then we push the system out there that we built with LLMs and then we formally verified it. I I think are we building compilers inside out? So when you look at a compiler, you know, it does this.
It takes source code in and it takes puts executable code out. Um, and LLM is kind of a version of this, right? You write a prompt and then you generate some code on the other side of that. Um, I think that what we're essentially doing is taking this code that the uh, LLMs give us and then we're putting guards on it, right? We're taking all this like formal verification that would happen inside of a compiler, but we're putting it but because we can't exactly put it into LLMs themselves.
Uh we do the next best thing which is that after they've generated the code, after they've made the PR, we tell them it's not good enough. You have to go back and do it again. So there are solutions to the runaway nature of uh LLMs. Um the way we've done it is we use something called sonar cube uh which measures a lot of these uh a lot of these um like static code quality issues and then it um it stops the PR and says you can't can't put this in.

`14:46` Quality gates: SonarQube and code complexity metrics

Um and this helps a lot with Python in particular because uh because of the typing situation. Another issue is agents love to generate code like the more there is the better right? Uh my latest pet peeve is that there are like 600 instances of accept exception in our codebase and I find that completely useless. It doesn't help me understand what the call site is doing, what the receiver expects. Um and every agent builds on the precedent of whatever was there before and that also often means like introducing more complexity.
Um so how do we combat this? So we started measuring our code again using stuff that like you know um and not to date myself but like that 20 years ago in undergrad like we were talking about as like really useful like cyclomatic complexity uh holstead measures um these are really useful measures for understanding how bad your code is essentially um and I haven't used them before in my software engineering uh life but now that we're generating code in these crazy new ways.
There's a really good place for these things. Um, I'm actually very optimistic. This slide doesn't uh convey my true optimism. This could be the time of like real progress in software engineering because we're able to use all these kind of old tools. So, before I worked on software factories, I worked in a real factory. Um, we used to assemble batteries. Uh, these sort of like room size grid grid scale batteries. Um, and the dream was to build those things in a dark factory.

`16:27` Human in the loop: why dark factories fail

Um, in manufacturing, dark factories are uh they're for a very particular type of thing. If you know you're going to build a billion phones and that a billion people are going to buy them, that's when you build a dark factory. You know exactly what you want to make and you know you need to make a lot of it. Um, but the dirty truth in our world es like in life or especially in software is that a lot of things are much more bespoke than that.
Um, and even if you do manage to do that, you know, you're Huawei or something and you get uh all the money to like build a dark factory that builds a billion phones, you still need engineers to go in and like fix the robots every so often. So, all this to say, human in the loop is essential. It's still a very important thing. It just looks so different from before. So, how do you deal with this? First, you create technical foundations for all these agents for dealing with them. isolation principle of lease privilege.
Don't give them the keys to the kingdom. Observe what they do in a place that humans hang out, right? Like GitHub, um or whatever git hosting you have. Um put gates around them, put guard rails around the code that they actually put in. Make sure that the quality improves as with every PR. And lastly, make sure a human's always in the loop. There's a slight mindset shift. And like if you've kind of zoned out for everything before this slide and this slide is the only one you pay attention to, this is what I want you to take away.
Verification is the hard part. Now, everyone in your company, everyone in your team is doing QA. Um, so figure out a way to make it fun. Uh, know the gaps between where the agent runs and reality. Test is not production. Agents aren't omnisient. They don't know everything. and build safety into your developer life cycle. And what what I mean by that is just make sure that every piece of code that gets in is just improving your codebase a little bit more, is doing something safe.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.