Broccoli: o agente que converte tickets de Linear em PRs sem que seu código saia da sua cloud
Existe uma suposição silenciosa embutida na maioria dos cloud coding agents que surgiram este ano: que você está confortável entregando seu repo, seus tickets e suas API keys para o control plane de outro. Você atribui uma tarefa, ela roda em algum lugar, volta um PR. Confortável. E para muitos times que lidam com código sob restrições de compliance ou NDAs, simplesmente inviável.
Broccoli, que acaba de aparecer em Show HN, aposta no oposto. Mesmo resultado — entra um ticket, sai um PR revisável — mas todo o pipeline roda dentro do seu projeto do Google Cloud, contra seu Postgres, com suas keys. Sem control plane de terceiros. Nada sai do seu tenancy.
Essa única decisão de arquitetura é o que a torna digna de sua atenção.
Como funciona o loop
O trigger não é um comando de CLI: é um ticket de Linear. Você atribui uma issue ao bot do Broccoli, e este lê o contexto do ticket, planeja uma implementação, escreve o código, roda loops de review, e abre um pull request para que alguém do seu time inspecione. O modelo async é o ponto: você descreve o trabalho onde já descreve o trabalho, e o PR aparece enquanto você está fazendo outra coisa.
O interessante é que Broccoli roda sobre Claude e Codex, e os usa um contra o outro. Em cada PR, ambos os modelos leem o diff, deixam comentários acionáveis, e fazem push de fix commits quando você pede. É menos “um agente escreve código” e mais “um pequeno time de agentes discute sobre o código antes que um humano o aprove”.
A arquitetura é a tese
Isso não é um brinquedo embrulhado em uma landing page. Por baixo é um serviço FastAPI que recebe webhooks do GitHub e Linear, verifica assinaturas, desduplica entregas, e cria registros de job duráveis. A execução roda como um Cloud Run Job por padrão — ou, opcionalmente, dentro de sandboxes do Blaxel se você ativar EXECUTION_BACKEND=blaxel. Secret Manager guarda a chave privada do GitHub App, os webhook secrets, as LLM keys e a database URL. O estado de jobs, PRs e issues do Linear persiste, não é mantido na memória.
Cada uma dessas escolhas aponta na mesma direção: isto foi construído para viver em infraestrutura de produção que você já opera, não para ser alugado.
O que você precisa para rodá-lo
Broccoli é self-hosted por design, e isso é um requisito, não uma ressalva. Você precisa de uma conta do Google Cloud que possa criar um projeto (ou administrar um existente) com billing associado. O deploy é um script de bootstrap, um arquivo de config e dois webhooks — uns 30 minutos desde o clone até tê-lo rodando. Você também é dono dos prompt templates: vêm com opiniões, e você os copia, ajusta e versioná junto com seu código.
Onde se encaixa (e onde não)
Se seu workflow já vive em Linear e GitHub, e sua razão para não ter adotado um cloud agent até agora era que seu código não pode sair do seu boundary, Broccoli aponta exatamente para você. Também se encaixa se você quer ser dono e versionar os prompts que controlam sua automação em vez de tratá-los como uma caixa preta de um vendor.
Se encaixa pior se você não roda sobre GCP, ou se quer conveniência zero-infra e não se importa onde executa — para isso há opções gerenciadas mais leves. Broccoli pede que você seja dono da stack. Esse é o trade-off, e para os times para os quais foi construído, é todo o atrativo.
O repo é MIT-licensed e está ganhando tração rápido desde seu Show HN. Um único commit em main hoje, mas os docs de arquitetura (ARCHITECTURE.md, JOB-CONTRACT.md) já estão lá — um sinal de que os autores pensam nisto como infraestrutura, não como um demo.
A era do “atribua um ticket, receba um PR” claramente já chegou. A questão aberta que Broccoli coloca é se isso tem que significar ceder a custódia do seu código. Sua resposta é que não.
Você rodaria um agente de código dentro de sua própria cloud, ou prefere a conveniência de um serviço gerenciado mesmo que seu código saia do seu boundary? Fico no aguardo abaixo.