Show HN: Broccoli, one shot coding agent on the cloud
Hi HN — we built Broccoli, an open-source harness for taking coding tasks from Linear, running them in isolated cloud sandboxes, and opening PRs for a human to review. We’re a small team, and our main company supplies voice data. But we kept running into the same problem with coding agents. We’d have a feature request, a refactor, a bug, and some internal tooling work all happening at once, and managing that through local agent sessions meant a lot of context switching, worktree juggling, and laptops left open just so tasks could keep running. So we built Broccoli. Each task gets its own cloud sandbox to be executed end to end independently. Broccoli checks out the repo, uses the context in the ticket, works through an implementation, runs tests and review loops, and opens a PR for someone on the team to inspect. Over the last four weeks, 100% of the PRs from non-developers are shipped via Broccoli, which is a safer and more efficient route. For developers on the team, this share is around 60%. More complicated features require more back and forth design with Codex / Claude Code and get shipped manually using the same set of skills locally. Our implementation uses: 1. Webhook deployment: GCP 2. Sandbox: GCP or Blaxel 3. Project management: Linear 4. Code hosting & CI/CD: Github Repo: https://github.com/besimple-oss/broccoli We believe that if you should invest in your own coding harness if coding is an essential part of your business. That’s why we decided to open-source it as an alternative to all the cloud coding agents out there. Would love to hear your feedback on this!
Discussion Highlights (13 comments)
dbmikus
Like the detailed setup instructions in the readme! Also agree that teams should invest in their own harness (or maybe pedantically, build a system on top of harness likes Claude Code, Codex, Pi, or OpenCode)
Jayakumark
Thanks for making it open source, Jira Support would be good
throwaway7783
Cool! We have a similar setup,connected to JIRA, but it stops at analysis and approach to solution. I'm taking inspiration from this now to take it to the next level!
orliesaurus
I use the Codex integration in Linear, can you tell me more about the differences please?
sinansaka
nice work! I built a similar system at my previous company. It was built on top of github. agent was triggered by the created issue, run in actions, save state in PR as hidden markdown. It worked great but time to first token was slow and multi repo PRs took very long to create (30+ mins) Now im working on my standalone implementation for cloud native agents
ayjze
this is exactly what I was looking for! can't wait to try it out
ppeetteerr
How does this compare to using Claude Web with connectors to build the same feature? On a separate note, READMEs written by AI are unpleasant to read. It would be great if they were written by a human for humans.
Almured
It's interesting that you’re using Linear tickets as the primary context source. From my experience so far, one of the biggest issues with coding agents is context drift. Ticket says one thing, but the codebase has changed since it was written. How did you solve? fresh RAG pass or use something like ctags to map the repo before it starts the implementation, or does it rely entirely on the LLM's provided context window?
dennisy
Fair play for launching this, it looks like a neat project. However I feel it will be an uphill battle competing with OpenAI and Anthropic, I doubt your harness can be better since they see so much traffic through theirs. So this is for those who care about the harness running on their own infra? Not sure why anyone would since the LLM call means you are sending your code to the lab anyway. Sorry I don’t want to sound negative, I am just trying to understand the market for this. Good luck!
xmonkee
One persistent issue I keep having is preview environments for this kind of stuff. I have the full setup, migrations, database seeding, etc. But having it run off a PR is still kind of a mess with spinning up 2 services, databases, redis etc. Do you guys run into this problem?
auszeph
Built similar for internal use at our work. Slack+JIRA though, not Linear. Otherwise GCP-native like this. I didn't want to be on the hook for supporting an open source version though, so never made it public. Good on you for putting it out there. A few differences I can quickly spot, fwiw... I went with Firestore over Postgres for the lower cost, and use Cloud Tasks for "free" deduping of webhooks. Each webhooks is validated, translated, and created as an instant Cloud Task. They get deduped by ID. We see a lot of value in a scheduler. So running a prompt on a schedule - good for things like status reports, or auto log reading/debug. I prefer to put my PEMs in to KMS instead of Secret Manager. You can still sign things but without having to expose the actual private key where it can be snooped on. I run the actual jobs on spot VMs using an image baked by Packer with all the tooling needed. You don't run in to time/resource limits running them as Cloud Run jobs?
jlian
> laptops left open just so tasks could keep running Too real. We’re currently still sticking to local agent workflows which feel more powerful than cloud native ones. Moving that to your own cloud with no third-party control plane feels like the right middle ground. Nice work EDIT: the adversarial two-agent review loop is really clever!
adamwong246
I like everything about this idea but "one-shot". I work _with_ an LLM, but as Wozniak said, "Never trust a computer you can't throw out a window". here's my [similar take]( https://github.com/testeranto-dev/testeranto )