Scaling AI Agents From Your Laptop To Across Your Enterprise
In this interview, we sit down with Robert Brennan, CEO and co-founder of OpenHands, an open source platform that is fundamentally reimagining the software development lifecycle through autonomous coding agents. Robert shares his journey from building machine learning systems at Google to leading a massive community of developers who are collectively building the “Lego bricks” of the future engineering workforce. Our discussion explores the evolution of AI from a simple “copy-paste” assistant on a laptop to a sophisticated, enterprise-grade fleet of agents capable of managing entire systems. We focus on the practical realities of scaling these technologies within large organizations, addressing critical concerns like cost optimization, data sovereignty, and the future of human engineering roles.
This topic has become a top priority for technology leaders because enterprises are currently hitting a “productivity wall” where the volume of maintenance and “keep the lights on” work is stifling innovation. While many developers have experimented with AI tools individually, the transition to an integrated, enterprise-wide agentic strategy requires solving complex problems involving security, visibility, and return on investment. In an era of skyrocketing API costs and heightened concerns over intellectual property, the ability to deploy model-agnostic, self-hosted agents has become a strategic necessity for any large-scale software organization.
Watch the full interview here.
Robert Brennan
Co-Founder&CEO at OpenHands
Robert, your background spans machine learning at Google and deep work in the Kubernetes ecosystem. What was the specific technical epiphany that convinced you AI agents were ready for the enterprise “inner loop” of development?
It started very pragmatically with my own daily frustrations as a developer. Like many others in 2023, I was using ChatGPT to write code, but I found myself trapped in a manual, repetitive cycle: I would prompt the model, copy the code into my IDE, run it, hit an error, and then paste that error back into the chat interface. I realized quite quickly that this was a “dumb use of my time” and that I could automate this entire iterative process. I built a CLI tool to handle that loop, essentially a harness that allowed the LLM to see the source code, run a command, and then react to the output.
When the industry saw demos of fully automated agents, it became clear that the “inner loop” of development – writing, running, and debugging, was the future. My co-founder and I realized that this shouldn’t happen inside a proprietary “black box” where companies dictate how engineers work. We wanted to give the community a say in how their jobs would change, which led us to build OpenHands as an open-source platform. For the enterprise, this shift is massive: we are moving from AI as a passive reference tool to an active participant that can navigate the same trial-and-error process as a human.
Large enterprises often struggle with vendor lock-in. Why is an open-source, “Lego brick” approach more effective for a corporate engineering organization than an off-the-shelf proprietary solution?
Building a robust agentic harness is an incredibly difficult research problem that requires a lot of “know-how” and capital. We spend significant resources benchmarking hundreds of different models to understand the trade-offs between accuracy, speed, and cost. If you use a proprietary tool, you are often locked into a single provider’s ecosystem, and if you want to switch models, the performance often degrades because the system wasn’t designed for flexibility.
When scaling from a single laptop to an enterprise with thousands of engineers, how does the nature of the AI agent’s work change?
On a single laptop, an agent is usually “co-piloted” by a human to build new features or solve ad-hoc problems. However, at the enterprise scale, the most significant gains come from automating the “undifferentiated” work, the roughly 30% of engineering effort spent just keeping the lights on. This includes things like managing dependencies, maintaining documentation, and hitting test coverage targets across dozens or even hundreds of teams.
In a large organization, you aren’t just giving every developer an assistant; you are creating fleets of agents that run automatically. These agents aren’t “pair programmed” with an engineer; instead, they are triggered by system events from platforms like GitHub, Slack, or Datadog. This provides an order of magnitude increase in productivity because the agents are handling the rote, repetitive tasks without taking up cognitive space in an engineer’s brain. The human’s role shifts from “piloting” one agent to “supervising” a much larger team of agents that operate across the entire organization.
Corporate leaders are often wary of “bill shock” and the lack of visibility into what autonomous agents are doing. How do you solve for governance and ROI at scale?
This is exactly why we built what we call the Agent Control Plane for our enterprise users. At a certain scale, you need organization-level visibility into what agents are in place, what they are allowed to access, and exactly how much they are costing you. We have seen cases where companies receive massive, unexpected bills from model providers because they didn’t have this visibility.
Our approach allows organizations to track the ROI for each agent. For example, we track our own code-review agent to see how much we spend on each review and how often its comments are accepted and incorporated by the team. If an agent is just generating noise, we can see that in the data and either improve it or shut it down. Furthermore, by being model-agnostic, we allow companies to A/B test different models. You might find that a smaller, open-source model gives you a 90% reduction in cost with only a 10% drop in quality, which is a trade-off that makes perfect sense for internal tasks like dependency updates.
For finance or healthcare companies, “sending code to the cloud” is often a deal-breaker. How can these enterprises use AI agents while maintaining total data sovereignty?
We work with several hedge funds and highly regulated organizations that have a strict policy: their source code is too valuable to ever send over the wire to a third-party provider, regardless of any security guarantees. For these types of customers, the only viable solution is to self-host everything. Because our platform is open source and supports open-source models, these companies can run the entire agentic loop inside their own private cloud or even an air-gapped data center.
If agents are handling the “rote” work traditionally given to junior developers, what happens to the next generation of engineers, and how does the human role evolve?
This is one of the most important “open questions” in our industry. Traditionally, we gave entry-level engineers the easily automatable tasks to help them learn the ropes, but that work is now being fully handled by agents. We have to rethink how we introduce new graduates to the field. I believe we are moving toward a future where we will have ten times as much software, but we will need human engineers to act as systems-level thinkers.
Agents are essentially software themselves, and they can never be held truly accountable. You will always need human beings who are responsible for the very complicated systems being built. The engineer’s role is shifting toward supervising these fleets of agents and making high-level architectural decisions. While a single engineer might soon be able to manage a much larger surface area of code, the demand for human creativity and accountability in building complex systems will only increase as we remove the mechanical bottlenecks of writing and debugging code.
Where do you see the most significant shift in the software development lifecycle (SDLC) occurring over the next year and a half?
I believe the biggest shift will be moving away from the requirement that a human must read every single line of code. Currently, we still perform thorough human code reviews for almost every change, which has become a major “bureaucratic rubber stamp” and a bottleneck for velocity. Within the next 18 months, I expect to see more organizations “blessing” agents to automatically merge low-risk changes directly into the main branch without a human reviewer in the loop.
Once the tests pass and an agent stamps a change as safe, there is no reason for a human to spend time reviewing it. We want to reach full automation of the SDLC, where agents are not just writing code but also shipping it to production and monitoring the logs to ensure their changes are performing as expected. For companies that are still hesitating, my advice is to start now with low-risk, read-only use cases. Deploy agents to scan your logs for insights or perform initial code reviews to surface information for your team. This allows you to “get your hands dirty” and build trust in the technology before moving toward full-scale, autonomous deployment.