Main Branch

Fundamentals first, always

Edición #29

🚢 El Que Hizo Más Honesto el Momento de Shippear

Por Andrea Griffiths Read in English 阅读中文版
code-coverage npm staged-publishing multi-agent-systems microsoft-build newsletter
Escuchar artículo

Hola mi gente linda,

Voy camino a San Francisco, así que este va rapidito. Dos features de GitHub hicieron que el momento antes de shippear código sea menos a ojo: coverage en PRs y staged publishing de npm. También hay un paper que me lleva dando vueltas en la cabeza, y un experimento pequeño para respaldarlo. Si estás en Microsoft Build, baja hasta el final para encontrarme.

🚢 Lo Que Se Lanzó

Code coverage en pull requests ya está en public preview

Coverage por fin vive donde debe vivir: en el PR mismo. GitHub Code Quality ahora muestra un porcentaje agregado de código cubierto directamente en el pull request, para que quienes revisan puedan ver qué tan completa está la cobertura de tests sin saltar a una tercera herramienta. Sube un reporte Cobertura desde tu workflow de CI actual usando la action actions/upload-code-coverage. GitHub Apps y workflows de Actions necesitan el nuevo permiso granular code-quality:write para subir reportes. Disponible hoy en github.com para Enterprise Cloud y Team, gratis durante el preview. Enterprise Server todavía no está incluido.

Staged publishing y nuevos controles en install-time para npm

Dos updates que vale la pena conocer en npm CLI 11.15.0. Staged publishing ya está generally available: en vez de que un npm publish directo salga en vivo, el tarball queda en una cola de staging hasta que una persona mantenedora lo aprueba con un challenge de 2FA. Combínalo con trusted publishing (OIDC) y bloquea tus workflows de CI para que solo puedan hacer stage, así los publishes no interactivos nunca se liberan automáticamente. Tres flags nuevos de install (--allow-file, --allow-remote, --allow-directory) se suman a --allow-git, y cada uno acepta all o none. Heads-up: el default de --allow-git cambia a none en npm CLI v12.

📖 Lo Que Estoy Leyendo

“Long Live the Librarian!” de Cho, Choi, Heo, Choi, Moon, Park y Kim (arxiv.org/abs/2605.27787)

Los sistemas SWE multi-agent desperdician demasiados output tokens reexplorando los mismos archivos. El paper lo mide (los output tokens cuestan entre 30 y 1,000 veces más energía que los input tokens o los tokens cacheados) y propone un sub-agent persistente de búsqueda que trackea el historial de búsquedas en el repo y devuelve referencias cortas en vez de excerpts completos de archivos. En SWE-Bench Verified, eso reduce la energía de GPU por episodio hasta un 25% sin perder performance en la tarea.

Vale tu tiempo si: shippeas algo con más de un agent adentro y quieres saber dónde vive el desperdicio.

🔧 Lo Que Estoy Usando

Leí el paper de Librarian y quería números en dólares, así que construí github.com/AndreaGriffiths11/librarian-demo: un harness que corre 5 reviewer agents sobre un PR de 16K tokens en Claude Opus 4.6 a través del GitHub Copilot proxy. Medí token counts en tres modos: naive $1.32, prompt cache $0.45 warm, digest con patrón Librarian $0.49 cold-every-call. Cache gana en series warm; Librarian gana cuando tu bot atiende PRs de muchos devs en muchos repos.

✨ Esta Semana

Estoy en Microsoft Build toda la semana, demoing la GitHub app en el GitHub Commons pavilion. Si estás en el venue, ven a buscarme. ¿No estás en la ciudad? Regístrate virtualmente en gh.io/microsoft-build y síguelo desde ahí. Después de Build me uno al content committee de GitHub Universe para ayudar a escoger los speakers de este año. Respóndeme y cuéntame si postulaste una charla.

Nos vemos la próxima semana.

Con gratitud,
Andrea