AI Tools for Enterprise - Chris and Matt from Ona
Christian Weichel and Matthew Boyle on why Gitpod's rebrand to Ona wasn't a pivot, why cloud dev environments turn out to be the perfect safe box for AI agents, and why models have become a commodity — the only thing left to differentiate on is the environment.
Gitpod has rebranded to Ona and shifted its focus to building AI tools for enterprise teams. Christian Weichel and Matthew Boyle join to dig into why they made the leap, how they're standing out in a crowded AI space, and what it's been like rethinking developer workflows from the ground up.
We talk about dev environments, differentiating in the AI space, forward-deployed engineers, and how a 60-person org kept moving without a real pivot.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Gitpod had been around five or six years and was doing well. Why rebrand to Ona — was this a pivot?
Not an easy decision, and one that took time to grow into — we didn't just wake up one day and decide to rebrand. Split "Gitpod" down the middle and you get "git" and "pod." We famously left Kubernetes, so the "pod" part became technically inaccurate, and "Git" is limiting when what we do is a lot more than that — it also meant we no longer had to have the conversation about whether to capitalize the P, or get confused with GitHub. But really, the shift in how software is written is fundamental enough, and the trajectory we're seeing Ona take, that it was enough motivation for a new name — not something new, but entering a new era of how software is written. And to be clear on the pivot question: everything Gitpod was doing continues. We still have the same foundational platform for deploying developer workloads into enterprise VPCs, plus a cloud offering, and the agentic layer is a natural extension built right on top, not a rebuild. The more time you spend with AI agents, the warier you get of them — did it just delete a file I wanted gone, did it just make a change I'm not comfortable with. Cloud development environments turn out to be a great primitive to put agents inside — think of it like a little box, almost a prison: it's safe because it's ephemeral, and if you don't like what happened, you just blow it away. That's resonated with customers moving from Gitpod to Ona who wanted an agentic story they didn't think they could have, because they don't have the risk appetite to run something like Claude Code or Cursor directly on a developer's laptop.
For anyone who never used Gitpod, what did it actually do, and what does Ona do now?
Gitpod used to take a developer four to five hours a week to set up and maintain a dev environment — we saw that in studies and our own data — and we cut that down to about ten seconds, by turning a typically outdated README into something machine-executable you can spin up at the click of a button. That decouples compute from automation, so it doesn't have to run on your laptop, it can run in the cloud. That automation piece turns out to be existential for agents: if you run an agent locally, you have to give it permission for everything it might want to do, and you don't want it deciding it needs to reset state and reformatting your hard drive, or running next to your production access or your email. Cloud dev environments give agents a secure space to run in, and because you can spin up many of them, you can run many agents in parallel — which is the real unlock, because as agents get more autonomous, the way you turn that into productivity is doing several things at once rather than babysitting one agent at a time, which just swaps one activity for another when your own attention is the expensive part. One framing Matt always liked: take the best engineer's laptop setup and give it to everybody, so time from a new engineer joining to their first commit can be minutes instead of days, because they're not fighting their own machine to get set up.
How has the shift to Ona actually been received?
There are three groups worth thinking about. Internally at Ona, adoption came quite naturally — we'd had a Cursor mandate, then a Claude Code mandate, and we didn't need to mandate Ona at all, people just naturally moved onto it. For customers and prospects, a lot of them are being asked to have an AI story, and they can clearly see organizations that employ agents becoming more efficient, so they need to keep up or lead. Ona helps there because if you've already got the platform's primitives in place from using it for dev environments, we can now give you an agent that builds right on top of what you were already using.
You're a 60-person company that just went through a big shift in focus. How did you get everyone aligned around that?
Fundamentally, the focus has stayed the same — great developer experience, making developers more effective, giving them better tools. A lot of organizations who buy Ona are replacing a VDI setup — Virtual Desktop Interface, things like Citrix or RDP — and anyone who's coded on one of those knows it's laggy, underspecced, locked down, and not built for development. It's usually about control: large, regulated industries need control over whether development happens, what happens to source code, what libraries someone can pull in, and Ona with Guardrails gives that same control in a much more effective package that doesn't make developers' lives hell in the process. So we're helping the same people, in a very similar way, except now we're also giving them superpowers, multiplying what they can get done in a day — which is really just the same shift that happened when engineers went from not using agents to using them, so the company had to offer that too.
Are you effectively competing with OpenAI and Anthropic here?
We think about it as three waves. The first is decades of essentially handcrafted code, with autocomplete at most. The second, starting two or three years ago with Copilot, then Cursor and Windsurf, is tap-tap autocomplete — it made you faster but didn't change the underlying pattern: close your laptop, work stops. What changed fundamentally with agents is that pattern itself — once an agent isn't running on your laptop, closing the lid doesn't stop the work, because it's the machine producing the code now, not the human directly producing it. Agents themselves are a fairly thin wrapper — swyx has been quoted saying engineers perceive an agent as basically an LLM in a for loop, which is approximately right. The tools and the handling of LLM quirks are commodity — some agents are even open source — and the models themselves are commodity too, a great equalizer everyone has roughly equal access to. So the only thing left to differentiate on is the environment and the integration, which is exactly what we're going after.
Was there ever a moment you thought the model itself was the moat?
There was a long stretch where we all thought models were the thing. Then DeepSeek released, and everyone panicked and paused for a moment — genuinely incredible, meaningfully cheaper, open source. Since then we've been in a kind of war where people flick between Claude Code, OpenAI, DeepSeek, whatever comes next, because switching costs are cheap — most people have subscriptions to several at once, ten dollars here, ten dollars there, happy to try everything, or cancel one Claude subscription this week and pick up an OpenAI one instead. Even if you grant that one lab has the best model, we're already at the point of very marginal gains — the last Opus release was maybe one or two percent better on the SWE benchmark, not the huge jumps we used to see — and if a lab does jump ahead meaningfully, another one tends to match it. Once you peel all of that away, what's left is user experience, the platform, where it runs, and the business, legal, and risk-appetite requirements around it — genuinely standard product management: what does the user need and how do we solve it, with the model as one part of the answer, not the whole thing. That's honestly the reason I joined Ona over everything else going on in the AI space right now.
Dev Twitter makes AI adoption sound universal. What's actually happening inside big enterprises?
What you see on Dev Twitter is probably the top ten percent of people adopting things — genuinely at the forefront. In a lot of our actual conversations, companies are just about getting to grips with Copilot, and there's still a surprising amount of pushback on AI tooling at all — people who don't know how to reason about it yet, or aren't sure what's happening elsewhere applies to them. Part of what we end up doing is education — showing what's possible. There's usually someone inside every company already using bleeding-edge tools at home, and we love it when they exist, because they can help navigate the conversation, help convince their boss it makes sense, and help us marry up enterprise risk appetite with what engineers actually want — which ends up meaning we help companies navigate their own org chart, which is genuinely challenging but rewarding when it works. There's a two-speed pattern that plays out at every scale: Dev Twitter, forward-leaning and sometimes critical, versus most engineers who still think Copilot is the pinnacle of AI tooling. The same split shows up at the top: the moment you get into boardrooms and C-level conversations at large enterprises, the question isn't do we need AI, it's how do we get it in here quicker. They see the opportunity — a small team taking a serious chunk out of a bigger company's business — and they see the risk, while their own engineers and compliance requirements aren't always ready to move that fast. We end up connecting the excitement at the leadership level with the excitement in the forward-leaning engineering group.
You've mentioned forward-deployed engineers a lot. What does that role actually look like?
It makes sense given the moment — OpenAI has reportedly been hiring a lot of them specifically. Once you're deploying agents at scale, you're fundamentally changing how a business works, so there's a lot of controls to put in place and a lot of org-specific advice needed quickly. Nobody buys a dev tool at a large company hoping it fails — part of our role is making sure a customer is actually successful after they sign, not disappearing until the renewal conversation. The role itself is a bit up for grabs depending on the company, but at really large enterprises, it can mean spending four or five days a week embedded with that company as an extension of their own engineering team — scoping and even building out a missing feature, connecting them with other customers for best practices. A lot of what the role needs to do is navigate the organization as much as write code — understanding the needs, desires, and even the fears inside it, getting close enough to be part of the coffee-kitchen conversation, because that's how you actually help a customer through the change that's happening. And yes, we are hiring forward-deployed engineers.
Links & references
This episode is brought to you by WorkOS.