¿CON QUÉ IA?
Lo contó A quién le sirve. Equipos pequeños de desarrollo y programadores que mantienen un proyecto y quieren recibir los cambios ya probados y revisados, listos para aprobar.
Qué hicieron
El autor encadenó seis bots Grok. El primero lee la incidencia y localiza en el repositorio los archivos y cambios anteriores relevantes. El segundo clasifica la tarea y su riesgo. El tercero escribe el cambio más pequeño posible. El cuarto ejecuta pruebas, análisis de estilo y compilación y devuelve los fallos al constructor. Un quinto revisa el cambio buscando errores nuevos o pruebas que faltan, y el sexto comprueba secretos, accesos y dependencias antes de abrir un borrador de pull request, la propuesta de cambio que revisa una persona.
Cómo salió
El autor dice haber llegado a más de 1.000 pull requests con este sistema.
Conviene saber
Todo termina en borrador para que una persona lo revise. No hace falta ser programador para entenderlo, pero sí para juzgar si cada cambio es bueno.
Qué necesitas
- Una cuenta de Grok donde puedas crear bots (Grok Bot)
- Un repositorio en GitHub o similar, que es el sitio donde se guarda el código del proyecto, con pruebas automáticas ya escritas
- Una lista de incidencias, que son las tareas y errores pendientes del proyecto
- Permisos para que los bots lean el código y propongan cambios, pero nunca los fusionen
- Alguien que sepa programar para revisar cada borrador
Cómo hacerlo tú, paso a paso
- Elige un proyecto de prueba que tenga pruebas automáticas y una incidencia pequeña y de poco riesgo.
- Crea los bots uno por función: el que localiza el código relevante, el que clasifica la tarea, el que hace el cambio mínimo, el que prueba, el que revisa y el que comprueba la seguridad.
- Da a cada bot solo el acceso que necesita. Ninguno debe poder subir cambios a la rama principal del proyecto.
- Conéctalos en orden, de forma que lo que produce uno lo recibe el siguiente. Si la herramienta no lo permite directamente, un programador puede unirlos con un script.
- Haz que los fallos de las pruebas vuelvan al bot que escribe el cambio, para que los corrija antes de seguir.
- Lanza la incidencia de prueba y revisa el borrador de pull request, que es la propuesta de cambio que aprueba una persona.
- Ajusta las instrucciones de cada bot según los errores que veas y prueba con otra incidencia.
Monta un equipo de bots para mi repositorio [URL del repositorio]: uno que mapee el código, otro que clasifique la tarea a partir de [gestor de incidencias o etiqueta], otro que haga un cambio mínimo, otro que ejecute pruebas, otro que revise y otro que compruebe la seguridad. Cada tarea debe acabar en un borrador de pull request con un resumen de lo cambiado y el resultado de las pruebas. Nunca fusiones ni subas nada a la rama principal. Habrás terminado cuando una tarea de prueba termine en un borrador revisable.
Consejos
- Empieza con tres bots, uno que escriba el cambio, otro que lo pruebe y otro que lo revise. Añade los demás cuando esos funcionen.
- Deja que todo acabe en borrador y que lo apruebe una persona. Sin esa revisión humana, un fallo llega a producción.
- Apunta qué bot hizo cada cosa. Si algo sale mal, sabrás a quién corregir.
Preguntas frecuentes
¿Qué pasa si un bot estropea algo?
El cambio queda en un borrador en una rama aparte y no llega a la versión principal hasta que alguien lo aprueba. Aun así, comprueba que las pruebas pasan de verdad.
¿Necesito seis bots desde el principio?
No. El caso usa seis, pero puedes ir añadiendo funciones a medida que veas que hacen falta.
Fuentes
En el directorio desde el 10 de octubre de 2026.
patrickaltman en Substack
r/AI_Agents en Reddit