GitHub y agentes de IA
En GitHub está todo lo que se ha hecho, y nada de eso está escrito para quien pregunta cuándo estará listo. El agente lee el repositorio y lo pasa a frases que puedes decirle a un cliente o a tu dirección: qué ha salido, qué está atascado y por qué te van a preguntar primero.
Qué hace un agente en GitHub
- Reúne lo que ha salido de verdad esta semana: pull requests fusionadas, issues cerradas, etiquetas de versión puestas.
- Saca a la luz las pull requests que llevan sin revisar más tiempo del plazo que tú has fijado.
- Mantiene el hilo entre la pregunta del cliente y la issue que hay detrás: por dónde va y qué ha sido lo último.
- Prepara un borrador de notas de versión a partir de los commits y las etiquetas reales, separando lo que va a notar el usuario de lo que solo nota el equipo.
- Te trae las issues que abre gente de fuera del equipo, en vez de dejarlas ahí sin que nadie las lea.
Procesos que arrancan solos
Un playbook no es un botón: es un proceso con una condición que lo dispara. En GitHub esa condición suele venir del propio repositorio: una pull request sin revisar, una etiqueta de versión puesta, una issue abierta por alguien de fuera.
Una pull request se queda sin revisar
Una pull request lleva abierta más del plazo que has fijado y sigue sin revisión
- Separar la espera real de los borradores y de las que no tienen revisor asignado
- Explicar en un párrafo, sin código, qué cambia y a quién afecta
- Recordárselo al revisor asignado donde de verdad lee los mensajes
- Ponerte delante la que lleva más tiempo frenando la entrega
Una versión, contada con palabras
Se pone una etiqueta de versión en el repositorio
- Reunir los commits y las issues cerradas entre la etiqueta anterior y esta
- Separar lo que va a notar el cliente de lo que solo nota el equipo
- Dejarte el borrador de las notas de versión — la redacción y las promesas siguen siendo tuyas
- Marcar los puntos que necesitan la respuesta de un desarrollador y no una suposición
Llega algo desde fuera
Abre una issue alguien que no está en tu equipo
- Comprobar si repite algo que ya está abierto
- Montar una ficha corta: quién escribe, qué pide, a qué afecta
- Traértela a ti — no asigna responsable ni promete fecha
Dónde se detiene el agente
- No escribe, no revisa ni fusiona código: eso lo decide el equipo técnico y de eso responde él.
- Cuenta lo que muestra el repositorio y no deduce ni calidad ni esfuerzo del número de commits.
- No toca accesos, secretos ni la protección de ramas — nada de eso se configura por conversación.
- Cuándo estará algo listo lo dice quien lo está haciendo, no un agente extrapolando una gráfica de commits.
FAQ
¿Hace falta saber leer código para seguir esto?
No. El agente describe los cambios por su resultado: qué funciona ya, qué se ha arreglado, a quién afecta. El enlace a la pull request o a la issue original se queda al lado, por si quieres ponérselo delante a un desarrollador.
¿El agente va a cambiar algo en el repositorio?
Por defecto solo lee. Si tú se lo permites, puede dejar un comentario o una etiqueta, nunca código, ramas ni historial. Revisar y fusionar sigue siendo cosa del equipo.
¿Esto no acaba siendo vigilar a los desarrolladores?
A propósito no hacemos informes del tipo «quién ha hecho más commits»: ese número no dice nada del trabajo y cualquier equipo aprende a alimentarlo en un mes. El agente enseña el estado del trabajo, no un ranking de personas.
¿Qué hace falta para conectar un repositorio privado?
El acceso de lectura lo da la dueña del repositorio o un administrador de la organización: es su decisión, no la nuestra. A partir de ahí la configuración va por conversación: tú dices qué repositorios y a partir de cuánto tiempo algo cuenta como atascado.
Dónde se ve esto
Casos en los que ver qué está haciendo de verdad la parte técnica forma parte del proceso.