Good name, with The Odyssey out, and all. I guess that you could think of the agents as "footsoldiers," and whatnot. Good luck!
We use 'phalanx' internally!
Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
51–60 of 73 posts
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#52Earlier quoted context omitted.
For one, it's interesting to me because I've already known Hoplite for years as nothing to do with AI. For two, I'm not sure how sharing that is so egregious it should be against the rules? Is there an interpretation I'm missing of my original comment? Does pointing out another Hoplite get interpreted as disparaging or accusatory in some way? Does it go against intellectual curiosity?
The term "conflict" implies "there is a problem here". I would say it's very lightly disparaging, because it implies the author didn't even do basic research on other things that are also named the thing they decided to call it. I actually checked HN rules and just saw this: > Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too commo…
you are complaining about yourself
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#53The bet that devs shift from reviewing code to reviewing product output is the most interesting part of this. Most teams haven't really internalised that yet — they're still doing line-by-line code review on agent-generated PRs, which doesn't scale and arguably misses the point. If the output works correctly and the tests pass, the code style of an agent matters a lot less than people think.
The hard part is defining what "works correctly" means in a way that's automatable. Visual diffing helps but it's brittle for anything beyond static layouts. Curious how you're handling cases where the correct behaviour is contextual rather than pixel-perfect.
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#54The bet that devs shift from reviewing code to reviewing product output is the most interesting part of this. Most teams haven't really internalised that yet — they're still doing line-by-line code review on agent-generated PRs, which doesn't scale and arguably misses the point. If the output works correctly and the tests pass, the code style of an agent matters a lot less than people think. The hard part is defining…
I use syns.dev. The agents share one plan up front, so there is less to reconcile at review.
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#55At the risk of replicating the classic Dropbox post (why would you need this when you could just use rsync?)…
I have a dev box with 96 GB of RAM, 2x4 TB NVMe drives, and an unbelievably beefy AMD CPU. This box costs me less than $150 per month and is so hyperlocal that I can log into it and use it as a remote desktop, while also using it as an always-on server that I can use to run T3 code and tmux and so forth. I can then connect to it from my laptop or my phone using Tailscale and prompt using the T3 Code or Remux mobile apps. Voilà — I have my own outsourced development center.
In this setup, my agent can handle everything: previews with a NixOS environment, unlimited threading, “autofixing” (which is just a loop between my agent and Copilot review comments), etc.
But it requires a LOT of custom setup/tooling so that my local environment works with my agent.
Why am I telling you this? Well, I've tried a number of serverless or ephemeral VM-type solutions, and it turns out that once you're working on "real code," you can't use ephemeral micro VMs reliably because your code starts interacting with too many different dependent services. You have to run migrations, so that your tests run properly, and to do that, you need to pull five different Docker images, and it goes on indefinitely. Eventually, the overhead of making little micro VMs is so high that it makes much more sense to take a monolithic approach to development and have a persistent workstation. You can still use things like worktrees, which allow you to massively parallelize your work, but you're building off of a shared local drive and cache.
So I believe there's a place for something like Hoplite with simpler software, but the problem is that the minute you get beyond toy software, it becomes really hard to test, scale, and deploy everything in micro VMs. There are also other companies that have tried this approach (like https://shipyard.build, although I think they had a slightly different philosophy from what you're doing) and I don't know that they've been massively successful.
What is it that you're doing differently that will allow Hoplite to succeed? How do you think that you'll compete against the legacy players in this space and the more full-spectrum players like Devin, et al.?
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#56The bet that devs shift from reviewing code to reviewing product output is the most interesting part of this. Most teams haven't really internalised that yet — they're still doing line-by-line code review on agent-generated PRs, which doesn't scale and arguably misses the point. If the output works correctly and the tests pass, the code style of an agent matters a lot less than people think. The hard part is defining…
Yikes. Hello, Claudebot.
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#57Your website text reads like Claude slop
So do half the comments on this launch post!
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#58The custom harness bet is the interesting one
not using Codex/Claude Code trades a lot of free improvement for control you may not need yet, so I'd watch whether that pays off before the underlying models plateau
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#59The custom harness bet is the interesting one not using Codex/Claude Code trades a lot of free improvement for control you may not need yet, so I'd watch whether that pays off before the underlying models plateau
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.
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#60At the risk of replicating the classic Dropbox post (why would you need this when you could just use rsync?)… I have a dev box with 96 GB of RAM, 2x4 TB NVMe drives, and an unbelievably beefy AMD CPU. This box costs me less than $150 per month and is so hyperlocal that I can log into it and use it as a remote desktop, while also using it as an always-on server that I can use to run T3 code and tmux and so forth. I ca…
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.)