Re: the dev box, it works very well for individuals and small sized teams, but starts to become an operational burden past a certain size. Our ideal customer is one who has a ton of engineers and wants great multiplayer/observability, as the case for Hoplite becomes a lot clearer -- "Run through project setup once, then onboard all engineers with one email (and they can bring their entire local setup with one CLI command)".
On the point of microVMs, agreed that it's a very difficult problem to solve. Luckily sandbox providers are continuously improving their APIs to make this slightly easier, but I wouldn't be surprised if we need to migrate over to AWS Lambda MicroVMs and roll a lot of the orchestration logic ourselves. Our goal is to get our P95 project setup time (i.e. connect -> fully running in the sandbox) to around 5 minutes, most of which we imagine being dependency installation. This is one clear point of differentiation where if we nail it, we'd be leagues above the rest of the competition.
The legacy players such as Devin, Cursor, and Factory are certainly well entrenched in their market position, but this space has the unique advantage of completely reworking how it operates every 6 months. These existing tools need to balance keeping up with new user demand for features, while also maintaining the old legacy workflows for their existing customers. We're lucky in that we can now build a product that we believe resembles how the majority of development will work ~1 year from now, meaning we have a lot more flexibility in how we can move forward.
And fundamentally, outside of large enterprise features like on-prem deployment, the key differentiators are 1) UX, 2) cost, and 3) harness performance. We can certainly win at the first, are at parity with the second, and likely struggle at the third (need to do benchmarks/evals -- if those go poorly then we'll transition from the custom harness to using the first party Claude Code/Codex. So quite fixable.)
Thanks for the attempt, but this is really a non-answer, which makes me think you have not worked with the kind of large, well-encumbered codebases / business problems that I seem to be attracted to :D
My take is that some of your architecture decisions are fundamentally incompatible with [what I believe to be the state of] most enterprise codebases.
And that’s fine if you have a very specific client base and are focused on fellow startups.
We're going to be investing pretty heavily in evals/benchmarks over the next couple of weeks, so that should give us a much better understanding of how our custom harness stacks up to the official ones.
In general, we've found that over the past couple of years agent harnesses have gotten much less restrictive, allowing the agent freedom to choose its own way of doing things. It seems like the project agnostic vs. specific harnesses will follow that trend. The pattern will work well for the current gen models, but eventually Fable 7 will be able to intuit how it should approach a specific project very well, at which point the challenge is making sure it has the tools to do so.
And I've made some changes to the coupon, does it work now?
We've observed this pattern as well, and have counteracted it by keeping the tasks very finely scoped. For example, "The test(api) check has failed. Fix it, then immediately commit and push." -- or -- "The following comments have been added by reviewers. Resolve each one, then immediately commit and push."
This specificity helps Sol stay on track (most of the time). It doesn't work as well when the comment questions a complex piece of the architecture though.
Agreed, we're working with a designer and are going to be fixing this very soon. Our main focus has been on making sure the product itself looks and feels very good to use -- probably not the best approach from a marketing POV.
Agreed that at the moment it's a very difficult problem, but one we're looking to solve! I think it becomes a no-brainer for most people if we're able to give each agent a replica of their production stack.
What does your current setup look like? And are you using an open source solution like OpenInspect for your in-house version, or building it from the ground up?
Building from ground up using OpenAI Agents SDK. We already have custom in house Cloud Development Environment, so the effort is just to "agent-ize" though which is not small. That's why I feel any team with any sort of infra support likely won't buy your product, since they already have the tribal knowledge to set this up. Newer teams might. But overall porting people's dev envs into the cloud is a tarpit problem(IMO), I was interested in this space too but decided against it for that reason. Happy to be proven wrong though!
I think for use cases like that, we'd offer on-prem deployments (similar to Factory), potentially coupled with a FDE. Still need to do a lot more research into the enterprise space.
exe.dev works quite well for giving an agent a computer and managing it remotely, but seems to require a fair bit more configuration to achieve parity with what we offer out of the box. Namely automations, PR autofix, visual QA, and general UI/UX polish.
I think it comes down to whether configuration or ease of use is valued more, and Hoplite favours the latter a bit more. (They shouldn't really be mutually exclusive, but we have a long way to go before we're happy claiming that we match/beat self-hosting in that area)
This is still something we're working on making seamless. The current approach is to install our MCP server and ask the local agent to start up a new thread on Hoplite when you want to transition to the cloud, but it doesn't carry over file system changes. (Unless you first push the contents to a remote branch, at which point the Hoplite agent can pull it down.)
gotcha. yea ideally you take a full live snapshot of my current state, untracked files, processes etc, and resume them in the cloud. Congrats on the launch! A mobile app would also be nice
That setup is pretty much what we're trying to offer with Hoplite!
Using us means losing freedom and control with regards to infrastructure, however we think that's a tradeoff people would want to make in exchange for easier onboarding and a more polished experience.
Makes sense. It took me some experimentations with a few open source libraries and docker-compose to arrive at my setup. My setup also requires me to access agents via a terminal app on my phone so it's nice to have a web app like your offering.
Are you offering browser access to the agents in your setup?
If browser access is the actual blocker: OpenCode (open-source coding agent, github.com/anomalyco/opencode) ships its own web UI -- `opencode serve` gets you a browser tab into the agent without needing Hoplite's hosted layer at all, so it slots into a self-hosted docker-compose setup like yours instead of replacing it.
I got tired of re-doing that setup on every new box, so I packaged it as a one-click Railway template -- a cloud dev box that runs OpenCode's web UI with state persisting between sessions, so you can drive it from your phone's browser instead of a terminal app. Full disclosure: I maintain it and get a kickback if you deploy through it: https://railway.com/deploy/opencode-webui-workspace?referral...
It doesn't give you Hoplite's per-thread VMs, PR automation, or QA tooling -- it's just the agent plus a browser, self-hosted. But if that's literally the missing 20%, it's a much smaller lift than what you already built.
Yes, agents have a persistent Chromium session they use via the agent-browser CLI. Typical workflow would involve starting the preview, seeding data, then the agent going through the old and new UX flows for a before + after view. We've also got some optimisations around saving the aforementioned flows in a QA library, so that they can be replayed without needing an agent to run through it all again.
On the point of microVMs, agreed that it's a very difficult problem to solve. Luckily sandbox providers are continuously improving their APIs to make this slightly easier, but I wouldn't be surprised if we need to migrate over to AWS Lambda MicroVMs and roll a lot of the orchestration logic ourselves. Our goal is to get our P95 project setup time (i.e. connect -> fully running in the sandbox) to around 5 minutes, most of which we imagine being dependency installation. This is one clear point of differentiation where if we nail it, we'd be leagues above the rest of the competition.
The legacy players such as Devin, Cursor, and Factory are certainly well entrenched in their market position, but this space has the unique advantage of completely reworking how it operates every 6 months. These existing tools need to balance keeping up with new user demand for features, while also maintaining the old legacy workflows for their existing customers. We're lucky in that we can now build a product that we believe resembles how the majority of development will work ~1 year from now, meaning we have a lot more flexibility in how we can move forward.
And fundamentally, outside of large enterprise features like on-prem deployment, the key differentiators are 1) UX, 2) cost, and 3) harness performance. We can certainly win at the first, are at parity with the second, and likely struggle at the third (need to do benchmarks/evals -- if those go poorly then we'll transition from the custom harness to using the first party Claude Code/Codex. So quite fixable.)