Un cliente reporta en Slack que no recibió su confirmación de compra. El equipo discute durante veinte mensajes si falló el correo, la cola o el evento de pago. Alguien pide «que la IA lo arregle». Si el agente toma todo el hilo como instrucción, puede convertir hipótesis y comentarios casuales en cambios de código. La noticia útil de GitHub es que ahora puedes llevar esa conversación a una investigación y una PR desde Slack o Teams; la decisión importante es qué parte de la conversación debe convertirse en trabajo verificable.

GitHub anunció el 6 de noviembre de 2026 la disponibilidad general de @GitHub en Slack y Teams. La integración permite investigar bugs, crear issues, pedir cambios y abrir pull requests sin salir de la conversación. En Teams, Canvas permite revisar planes, cambios y previews junto al debate. El agente ahora puede inferir mejor el repositorio mencionado y las issues o PR creadas incluyen una atribución al hilo de Slack o Teams y al usuario que inició el trabajo.

Qué cambia para un fundador o vibecoder

La ventaja no es que un chat sustituya al editor. Es que el contexto de producto —el reporte, las preguntas y la decisión del equipo— puede acompañar a una investigación técnica. La documentación de GitHub para Slack explica que Copilot puede usar el hilo completo, trabajar de forma asíncrona en un sandbox y dejar la PR para revisarla en GitHub. También permite trabajar con varios repositorios cuando corresponde.

Esa misma capacidad crea un límite: el hilo completo pasa a ser contexto del agente y puede quedar reflejado en los artefactos que genera. Si hay datos de clientes, secretos o conjeturas que no deberían acompañar el trabajo, crea un hilo limpio o usa un mensaje directo con un resumen depurado. No pegues credenciales ni datos personales para ahorrar un clic.

Una prueba pequeña, con una instrucción copiable

1. Instala la integración oficial de GitHub para Slack en un workspace de prueba, vincula tu cuenta e invita la app al canal si hace falta. La guía de Copilot en Slack indica que se requiere un plan Copilot de pago y acceso de escritura al repositorio para iniciar o dirigir cambios.
2. Elige un bug reproducible sin datos sensibles. En el hilo, separa hechos de hipótesis: «Hecho: una confirmación no aparece tras una compra de prueba. Hipótesis: falló la cola. No sabemos la causa». Adjunta el enlace a la issue si existe.
3. Envía: @GitHub Investiga por qué una compra de prueba no genera correo de confirmación en OWNER/REPO. Primero explica la causa con evidencia. Si hay una corrección acotada, abre una PR con una prueba de regresión. No fusionas la PR ni cambies la lógica de pagos sin aprobación humana. Sustituye OWNER/REPO y ajusta el caso a tu app.
4. Revisa la sesión y la PR fuera del chat: repositorio correcto, archivos cambiados, pruebas ejecutadas y datos incluidos en la descripción. Reproduce el bug y la corrección. Si trabajas en un canal compartido, verifica quién puede aportar contexto y quién puede dirigir al agente.

GitHub explica que, en un mensaje directo, el agente actúa con los permisos de tu cuenta vinculada. En un hilo o canal compartido, los artefactos se crean bajo la identidad de la app; los participantes pueden añadir contexto, pero solo quien tenga escritura en todos los repositorios seleccionados puede iniciar o dirigir el trabajo. Si hay una regla de aprobación de PR, los cambios creados en contexto compartido pueden exigir una aprobación humana adicional. Esto es parte del diseño de permisos, no un fallo del agente.

Qué no ha sido probado aquí

El flujo anterior es una prueba propuesta por SoyJB; no afirmamos haber conectado un workspace ni ejecutado una PR. Antes de usarlo con clientes, confirma la política de Copilot cloud agent y los permisos de la app en tu organización. Usa la integración para convertir decisiones claras en trabajo trazable; una conversación ambigua o sensible sigue necesitando edición humana antes de delegarse.

Fuentes: anuncio de GitHub, 6 nov 2026; guía de Copilot cloud agent en Slack; instalación oficial. Revisadas el 7 nov 2026.