El debate sobre si debería existir la construcción de software totalmente automatizada por IA finalmente ha estallado. El detonante fue
@yetone manteniendo magpie, un proyecto que sus colegas criticaron como "comida rápida" y "demasiado arriesgado para usarlo".
La mayoría coincide en que la construcción de software automatizada por IA es la tendencia. Entonces, ¿cómo lo lleva a la práctica magpie? Cloné el repositorio de magpie, analicé los 2,862 commits de los últimos diez días y usé OpenClaw para comparar.
https://x.com/wquguru/status/2109458639501271530
1204 versiones en 19 días
magpie es un gateway local para LLMs que conecta agentes de programación como Claude Code, Codex y Gemini CLI con cualquier modelo o suscripción. Desde su primer commit el 22 de septiembre hasta hoy, alcanzó 9,474 estrellas en 19 días. De los 2,862 commits, la cuenta de yetone representa el 85 %, fusionando 383 PRs de la comunidad.
La cantidad de tags (equivalente a versiones) llegó a 1,204 en 19 días, un promedio de más de 60 versiones diarias: una frecuencia imposible de mantener manualmente para un humano. En comparación, OpenClaw tuvo 1,423 commits en sus primeros 19 días, el 99 % enviados por el propio Peter Steinberger, con apenas unos 10 tags.
magpie tiene el doble de commits, pero más de cien veces más versiones.
Lo que quería descubrir era una sola cosa: ¿cómo cierra exactamente el ciclo la IA en este proyecto?
Una tabla de enrutamiento y un cuaderno de errores
El archivo CLAUDE.md de magpie solo hace referencia a dos archivos: AGENTS.md y LESSONS.md.
AGENTS.md es una tabla de enrutamiento. No define reglas por sí mismo; simplemente le indica a los agentes qué documentos consultar antes de trabajar: revisar docs/subsystems/ antes de modificar subsistemas, seguir docs/code-standards.md para escribir o revisar código, y consultar docs/contributors.md al evaluar PRs de la comunidad.
La primera frase de LESSONS.md responde a la pregunta inicial:
El código de magpie es escrito, revisado, fusionado y publicado por agentes. (El código de magpie es escrito, revisado, fusionado y publicado por agentes)
Escribir, revisar, fusionar, publicar... todo lo hacen los agentes. Sin supervisión humana, ¿por qué no se viene abajo? La respuesta está en ese archivo. Con 479 líneas, funciona básicamente como un cuaderno de errores, redactado por el agente cada noche.
Cada noche, el agente revisa todos los commits del día, centrándose en tres escenarios:
- ¿Qué correcciones tuvieron que rehacerse?
- ¿Qué no debió haberse fusionado en absoluto?
- ¿Qué verificaciones fueron demasiado descuidadas?
Por cada problema detectado, registra una regla, una razón y adjunta los números de commit e issue como evidencia. Por ejemplo:
Reproduce el caso exacto del usuario que lo reportó, en la interfaz que usa, antes de darlo por solucionado.
El 834 volvió 4 veces (v0.1.920 → .925 → .931 → .938). Cada ronda solo corrigió el agente que aparecía en la captura. Visto 1× (2026-10-05).
El issue 834 se reabrió cuatro veces, y cada vez solo se corrigió el agente que salía en la captura. De ahí la regla: antes de dar algo por arreglado, reproduce el problema exactamente en la interfaz que utiliza quien lo reportó.
La clave está en la última línea: Visto 1×. Si la misma lección aparece en las revisiones de tres días distintos, pasa de LESSONS.md a code-standards.md, convirtiéndose de experiencia empírica a regla inquebrantable. A partir de entonces, toda revisión de PR debe comprobarla punto por punto.
Ocho reglas ya han sido promovidas de esta manera. Algunos ejemplos: corregir bugs similares de forma conjunta (detectado una vez el 5, 6 y 7 de octubre); si los tests fallan en main, es un bug urgente que hay que arreglar de inmediato; y dejar claro qué se probó y sobre qué commit antes de fusionar.
Por supuesto, el cuaderno de errores también registra lo que se hizo bien, marcado como Done right, para que los agentes no solo lean "no hagas esto", sino también "haz esto en su lugar".
El cuaderno de errores se introdujo en la madrugada del 6 de octubre
¿Estaba diseñado este sistema desde el principio? Al revisar el historial de commits de LESSONS.md, la primera versión corresponde al commit 303819c5, creado a las 3:10 AM del 6 de octubre.
Un día antes, el 5 de octubre, magpie lanzó 168 versiones.
La primera versión de LESSONS.md documentó precisamente ese día. Con 220 commits y unas 170 publicaciones, cerca de 40 eran versiones para corregir lo lanzado ese mismo día o el anterior. El CI casi siempre se cancelaba con el siguiente push. Un test que solo fallaba en Linux se mantuvo en rojo desde la v0.1.877 hasta la v0.1.892 sin que nadie lo notara.
294 tags en 51 horas no dejaron terminar ninguna ejecución. (294 tags en 51 horas significaron que ninguna ejecución de CI pudo completarse)
Así que la primera versión añadió una regla: Antes de crear un tag, el CI de ese commit debe terminar y estar en verde. Las ejecuciones canceladas por nuevos pushes no cuentan.
168 publicaciones el primer día, 42 el segundo, 15 el tercero, y luego estabilizándose entre 15 y 26.
No hubo reuniones ni avisos. Las revisiones nocturnas detectaron los problemas, añadieron una regla al cuaderno de errores, los agentes en activo la leyeron y redujeron la frecuencia de publicación.
Por eso, esas veintitantas versiones diarias que recientemente se señalaron como problemáticas eran, en realidad, la velocidad después de pisar el freno.
Criterios de aceptación de PRs
Veamos ahora algunos PRs reales:
code-standards.md enumera seis criterios de aceptación. Todos deben cumplirse antes de fusionar o publicar. Dejando de lado comprobaciones estándar como compilar en tres plataformas o hacer pruebas en sandbox, hay tres que rara vez se ven en proyectos comunes:
- Prueba de regresión: Restaura el código antiguo; los nuevos tests deben fallar de forma explícita, señalando qué comportamiento es incorrecto. Los errores de compilación o los tests omitidos no cuentan.
- Uso real: Si cambias la integración de un proveedor, verifícalo con cuentas, configuraciones y respuestas de API reales. Lo que no se prueba no puede servir de base para otras cosas ni venderse a los usuarios como funcional.
- Las comprobaciones no ejecutadas deben listarse:
Una comprobación que no se ejecutó se lista como no ejecutada, nunca se omite. (Las comprobaciones no realizadas deben listarse como no ejecutadas, nunca omitirse)
Elegí el #1339 al azar para ver el comentario dejado antes de fusionarlo:
Red check significa prueba de regresión, Break check implica romper el código a propósito para ver si los tests lo detectan, y la última línea dice Not run, es decir, que no se probó en hardware real.
El comando de merge incluye --match-head-commit <reviewed sha>. Si alguien sube cambios durante la revisión, el merge falla, garantizando que no entre código no revisado.
Humanos en el circuito
Por supuesto, los humanos siguen participando en algunas tareas, al menos en estas áreas:
- Decisiones de producto: "No reviertas decisiones deliberadas". Cosas como el comportamiento del scroll o los cursores de los botones no pueden cambiarse mediante PRs.
- Controles de seguridad: Si saltan las alertas de riesgo, hay que esperar la aprobación del maintainer.
- Sugerencias de la comunidad: 474 títulos de commits mencionan a usuarios que reportaron problemas en X o Discord, por ejemplo, JonahFu en X o Jeremy.Zhou en Discord.
En resumen, los humanos definen el rumbo y vigilan las puertas; escribir, revisar, fusionar y publicar queda en manos de los agentes.
¿Nos oculta algo yetone?
Llegados a este punto, algunos se preguntarán: ¿nos oculta algo yetone? Yo también sentí curiosidad y escarbé un poco más.
Efectivamente, hay varias cosas que no están en el repositorio:
- No se documenta cómo se disparan las revisiones nocturnas. Ninguno de los 4 workflows está programado.
- Extraje las horas de 7 actualizaciones de LESSONS.md: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Están dispersas, lo que parece menos un cron job y más ejecuciones manuales locales o scripts personalizados.
- Los prompts utilizados para las revisiones nocturnas tampoco están. Qué agente se usa, cuántas sesiones en paralelo... nada de eso está documentado.
De paso, encontré otros dos detalles:
Primero, el método se nutre de las contribuciones de la comunidad. La documentación de subsistemas y las revisiones de cambios semánticos se introdujeron mediante el PR #889 del miembro de la comunidad Junjie Zhou. Las dos tablas al inicio de code-standards.md se acreditan explícitamente en el commit 926bcaa3 a seis reglas de revisión propuestas por Junjie Zhou en Discord.
Segundo, las interacciones de yetone con los agentes quedan preservadas en los commits. 52 títulos de commits incluyen citas textuales de yetone entre paréntesis:
1(el dueño: Esto es demasiado feo)2(el dueño: ¿Por qué esto es un selector nativo en lugar de nuestro ComboBox abstracto?)3(el dueño: ¿Por qué ha vuelto a pasar esto? ¿No dijimos que solo debía aparecer al pasar el ratón? Que aparezca siempre es muy feo)4(dueño: Durante el pr-preview, a veces no hay datos para probar. ¿Puedes ayudarme a crear algunos datos falsos?)
Suelen ser quejas de una sola línea; el agente se encarga de desarrollar el resto, lo que a menudo resulta en cientos de palabras en el cuerpo del commit. La petición de datos falsos terminó convirtiéndose en el conjunto de datos mock utilizado para las grabaciones del CI.
Los humanos señalan qué está mal; los agentes lo transforman en cambios verificables. Estas decenas de títulos de commits explican la metodología mejor que cualquier documento.
Si quieres construir el tuyo
Cualquiera puede escribir una tabla de enrutamiento. Lo que realmente vale la pena copiar es el sistema del cuaderno de errores. Una entrada en LESSONS tiene este aspecto:
1**<Regla de una sola frase>**2- <Qué commit/issue causó el problema y cuál fue la consecuencia>3- <Commit de la corrección>4- Done right: <Ejemplo de cómo hacerlo correctamente>5- Seen N× (AAAA-MM-DD, AAAA-MM-DD).
Haz que un agente revise los commits diarios cada noche, buscando únicamente retrabajos, malas fusiones y verificaciones débiles. Si el mismo problema aparece en tres días distintos, pásalo a los estándares de código. Durante la aceptación, detalla en los cuerpos de los commits y comentarios de los PRs las pruebas de regresión, el uso real y los elementos no ejecutados.
Después de revisar todo el repositorio, lo que más me impresionó fue el umbral de Seen 3×. Los errores se anotan, los agentes los leen al arrancar, y repetir la misma equivocación tres veces la eleva a regla inquebrantable, aplicando a la perfección el dicho de que "no hay dos sin tres" (o más bien, a la tercera va la vencida).
Reflexiones finales...
Hace un año, o incluso hace seis meses, las capacidades de los modelos rara vez alcanzaban una automatización apta para producción. Pero ahora, sobre todo desde la llegada de Opus 5.5, podemos verlo con claridad: el futuro ya está aquí.
Esto me recuerda a Yoyo de @yuanhao, un Agente que lleva más de 200 días iterando sobre sí mismo: https://yoyo-gasp.yolog.dev/, también vale mucho la pena echarle un vistazo.
