El debate sobre si debería existir la construcción de software totalmente automatizada por IA finalmente estalló. El detonante fue
@yetone manteniendo magpie, algo que otros desarrolladores criticaron como "servicio de comida rápida" y "demasiado riesgoso 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 código como Claude Code, Codex y Gemini CLI con cualquier modelo o suscripción. Desde su primer commit el 22 de septiembre hasta hoy, acumuló 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 contraste, OpenClaw tuvo 1,423 commits en sus primeros 19 días, el 99 % enviados por el propio Peter Steinberger, con unos 10 tags.
magpie tiene el doble de commits, pero más de cien veces más versiones.
Lo que quería entender era una sola cosa: ¿cómo cierra exactamente el ciclo la IA en este proyecto?
Una tabla de ruteo 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 ruteo. 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 mirar 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 lo escriben, revisan, fusionan y publican los agentes. (El código de magpie lo escriben, revisan, fusionan y publican los agentes)
Escribir, revisar, fusionar, publicar... todo lo hacen los agentes. Sin supervisión humana, ¿por qué no colapsa? La respuesta está en ese archivo. Con 479 líneas, funciona básicamente como un cuaderno de errores que el agente redacta cada noche.
Todas las noches, el agente revisa todos los commits del día y se enfoca en tres escenarios:
- ¿Qué correcciones tuvieron que rehacerse?
- ¿Qué no debió haberse fusionado nunca?
- ¿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 reportó el error, 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 retrabajó cuatro veces, y cada vez solo se corrigió el agente que mostraba la captura. Así que la regla es: antes de darlo por arreglado, reproduce el problema exactamente en la interfaz que usa 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 y se convierte en una regla inquebrantable nacida de la experiencia. A partir de ahí, toda revisión de PR debe verificarse punto por punto contra esas reglas.
Ocho reglas ya fueron promovidas de esta manera. Algunos ejemplos: corregir bugs similares en conjunto (detectado una vez el 5, 6 y 7 de octubre); si los tests fallan en main, es un bug urgente por resolver; y declarar claramente qué se probó y en 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 "mejor haz esto otro".
El cuaderno de errores se implementó en la madrugada del 6 de octubre
¿Este sistema estaba diseñado desde el principio? Al revisar el historial de commits de LESSONS.md, la primera versión fue el commit 303819c5, creado a las 3:10 AM del 6 de octubre.
Un día antes, el 5 de octubre, magpie había lanzado 168 versiones.
La primera versión de LESSONS.md documentó precisamente ese día. Con 220 commits y unas 170 releases, cerca de 40 eran parches para versiones publicadas 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 impidieron que alguna ejecución terminara. (294 tags en 51 horas significaron que ninguna ejecución de CI pudo completarse)
Por eso, la primera versión agregó 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 releases 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, agregaron una regla al cuaderno de errores, los agentes en producción la leyeron y redujeron la frecuencia de publicación.
Así que 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
Ahora veamos algunos PRs reales:
code-standards.md enumera seis criterios de aceptación. Todos deben cumplirse antes de fusionar o publicar. Dejando de lado las validaciones estándar como compilar en tres plataformas y pruebas en sandbox, hay tres que son raros en proyectos comunes:
- Prueba de regresión: vuelve a poner el código antiguo; los tests nuevos 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, verifica con cuentas, configuraciones y respuestas de API reales. Las funciones que no se prueban no pueden servir de base para otras ni anunciarse como funcionales a los usuarios.
- Las verificaciones no ejecutadas deben listarse:
Una verificació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í al azar el #1339 para ver el comentario dejado antes de fusionar:
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 código durante la revisión, el merge falla, garantizando que no entre código sin revisar.
El humano 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 se activan 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 algo en X o Discord, por ejemplo, JonahFu en X o Jeremy.Zhou en Discord.
En resumen, los humanos definen el rumbo y cuidan las puertas; escribir, revisar, fusionar y publicar queda en manos de los agentes.
¿Yetone oculta algo?
Llegados a este punto, algunos podrían preguntarse: ¿yetone oculta algo? Yo también sentí curiosidad e investigué más a fondo.
Efectivamente, hay varias cosas que no están en el repo:
- Cómo se disparan las revisiones nocturnas no está documentado. Ninguno de los 4 workflows está programado.
- Extraje los horarios de 7 actualizaciones de LESSONS.md: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Están dispersos, parecen menos trabajos cron y más ejecuciones manuales locales o scripts personalizados.
- Los prompts usados para las revisiones nocturnas tampoco están. Qué agente se usa, cuántas sesiones en paralelo... nada de eso está documentado.
De paso, encontré dos detalles adicionales:
Primero, el método incorpora contribuciones de la comunidad. La documentación de subsistemas y las revisiones de cambios semánticos llegaron a través del 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 guardadas 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é volvió a aparecer esto? ¿No habíamos dicho que solo debía mostrarse al pasar el mouse? 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 resto lo completa el agente, lo que muchas veces resulta en cientos de palabras en el cuerpo del commit. La petición de datos falsos terminó convirtiéndose en el set de datos mock que se usa 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 armar el tuyo
Cualquiera puede escribir una tabla de ruteo. Lo que realmente vale la pena copiar es el sistema del cuaderno de errores. Una entrada de LESSONS se ve así:
1**<Regla en una oración>**2- <Qué commit/issue causó el problema y cuál fue la consecuencia>3- <Commit de 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 todas las noches, 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 repo, lo que más me impresionó fue el umbral de Seen 3×. Los errores se anotan, los agentes los leen al iniciar, y repetir la misma falla tres veces lo eleva a regla inquebrantable, encarnando a la perfección el dicho "a la tercera va la vencida" (o más bien, tres strikes y estás fuera).
Reflexiones finales...
Hace un año, o incluso hace seis meses, las capacidades de los modelos rara vez alcanzaban una automatización lista 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 Agent que lleva más de 200 días iterando sobre sí mismo: https://yoyo-gasp.yolog.dev/, también vale la pena echarle un vistazo.
