[dead]
Show HN: Broccoli, one shot coding agent on the cloud
31–40 of 57 posts
Re: Show HN: Broccoli, one shot coding agent on the cloud
#32Re: Show HN: Broccoli, one shot coding agent on the cloud
#33[dead]
Re: Show HN: Broccoli, one shot coding agent on the cloud
#34It'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 windo…
We don't have this kind of tooling built up, but we've been using Linear as a source of truth alongside a human written prompt adding context. It's worked really well for both feature development and bug hunting, and helps keep us honest with tickets (good LLM context is still good human context) as well as maintain some level of consistency between LLM passes on the same issue.
Re: Show HN: Broccoli, one shot coding agent on the cloud
#35It'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 windo…
We don't have this kind of tooling built up, but we've been using Linear as a source of truth alongside a human written prompt adding context. It's worked really well for both feature development and bug hunting, and helps keep us honest with tickets (good LLM context is still good human context) as well as maintain some level of consistency between LLM passes on the same issue.
100% on using linear as the source of truth! We went a bit further and just use Linear as the prompt. So there isn't a human written one adding context that lives elsewhere
Re: Show HN: Broccoli, one shot coding agent on the cloud
#36Earlier quoted context omitted.
We don't have this kind of tooling built up, but we've been using Linear as a source of truth alongside a human written prompt adding context. It's worked really well for both feature development and bug hunting, and helps keep us honest with tickets (good LLM context is still good human context) as well as maintain some level of consistency between LLM passes on the same issue.
100% on using linear as the source of truth! We went a bit further and just use Linear as the prompt. So there isn't a human written one adding context that lives elsewhere
This has been great for me too. Every feature starts and completes with /gh-issue .
Every issue is created with /spec and a conversation with a human. Once the spec is materialized as an issue it’s sufficient for an agent to implement.
Everything is documented. It’s amazing.
Re: Show HN: Broccoli, one shot coding agent on the cloud
#37One 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?
Re: Show HN: Broccoli, one shot coding agent on the cloud
#38One 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?
We use firebase which supports the preview environments. It's mainly for front end changes though. Are you looking for a solution for backend changes as well?
Re: Show HN: Broccoli, one shot coding agent on the cloud
#39[dead]
Re: Show HN: Broccoli, one shot coding agent on the cloud
#40Built 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?