Broccoli: el agente que convierte tickets de Linear en PRs sin que tu código salga de tu cloud
Hay una suposición silenciosa metida en la mayoría de los cloud coding agents que aparecieron este año: que estás cómodo entregándole tu repo, tus tickets y tus API keys al control plane de otro. Asignás una tarea, corre en algún lado, vuelve un PR. Cómodo. Y para muchos equipos que manejan código bajo restricciones de compliance o NDAs, directamente inviable.
Broccoli, que acaba de aparecer en Show HN, apuesta a lo contrario. Mismo resultado —entra un ticket, sale un PR revisable— pero todo el pipeline corre dentro de tu proyecto de Google Cloud, contra tu Postgres, con tus keys. Sin control plane de terceros. Nada sale de tu tenancy.
Esa única decisión de arquitectura es lo que lo hace digno de tu atención.
Cómo funciona el loop
El trigger no es un comando de CLI: es un ticket de Linear. Le asignás un issue al bot de Broccoli, y este lee el contexto del ticket, planifica una implementación, escribe el código, corre review loops, y abre un pull request para que alguien de tu equipo lo inspeccione. El modelo async es el punto: describís el trabajo donde ya describís el trabajo, y el PR aparece mientras estás haciendo otra cosa.
Lo interesante es que Broccoli corre sobre Claude y Codex, y los usa uno contra el otro. En cada PR, ambos modelos leen el diff, dejan comentarios accionables, y pushean fix commits cuando se lo pedís. Es menos “un agente escribe código” y más “un pequeño team de agentes discute sobre el código antes de que un humano lo firme”.
La arquitectura es la tesis
Esto no es un juguete envuelto en una landing page. Por debajo es un servicio FastAPI que recibe webhooks de GitHub y Linear, verifica signatures, dedupea deliveries, y crea job records durables. La ejecución corre como un Cloud Run Job por defecto —o, opcionalmente, dentro de sandboxes de Blaxel si activás EXECUTION_BACKEND=blaxel. Secret Manager guarda la private key del GitHub App, los webhook secrets, las LLM keys y la database URL. El estado de jobs, PRs e issues de Linear se persiste, no se mantiene en memoria.
Cada una de esas elecciones apunta en la misma dirección: esto está construido para vivir en infraestructura de producción que ya operás, no para alquilarse.
Lo que necesitás para correrlo
Broccoli es self-hosted by design, y eso es un requisito, no un caveat. Necesitás una cuenta de Google Cloud que pueda crear un proyecto (o administrar uno existente) con billing asociado. El deploy es un bootstrap script, un archivo de config y dos webhooks —unos 30 minutos desde el clone hasta tenerlo corriendo. También sos dueño de los prompt templates: vienen opinados, y los forkeás, ajustás y versionás junto a tu código.
Dónde encaja (y dónde no)
Si tu workflow ya vive en Linear y GitHub, y tu razón para no haber adoptado un cloud agent hasta ahora era que tu código no puede salir de tu boundary, Broccoli apunta exactamente a vos. También encaja si querés ser dueño y versionar los prompts que manejan tu automatización en lugar de tratarlos como una caja negra de un vendor.
Encaja peor si no corrés sobre GCP, o si querés conveniencia zero-infra y no te importa dónde se ejecuta —para eso hay opciones gestionadas más livianas. Broccoli te pide que seas dueño del stack. Ese es el trade, y para los equipos para los que está construido, es todo el atractivo.
El repo es MIT-licensed y está ganando tracción rápido desde su Show HN. Un solo commit en main hoy, pero los docs de arquitectura (ARCHITECTURE.md, JOB-CONTRACT.md) ya están ahí —una señal de que los autores piensan esto como infraestructura, no como un demo.
La era del “asigná un ticket, recibí un PR” claramente ya llegó. La pregunta abierta que plantea Broccoli es si eso tiene que significar ceder la custodia de tu código. Su respuesta es que no.
¿Vos correrías un agente de código dentro de tu propia cloud, o preferís la conveniencia de un servicio gestionado aunque tu código salga de tu boundary? Te leo abajo.