Por Grego
Slack acaba de tocar una pieza sensible del workflow de desarrollo: el momento exacto en que el trabajo de un agente se vuelve visible para el equipo.
Con Slack Code, la empresa propone canales dedicados donde podés invocar agentes como Claude Code, Devin, Vercel Agent o GitHub Copilot, seguir lo que están haciendo, revisar diffs, mirar previews, dejar feedback y aprobar antes de shippear.
Cuando la tarea termina, el canal se archiva.
Y queda como audit log.
Eso parece una integración más entre Slack y herramientas de IA.
No lo es.
La señal importante es otra: el review loop de los agentes está saliendo del PR.
El PR llega tarde a una parte cada vez más importante del trabajo
El pull request sigue siendo excelente para revisar un cambio terminado.
Te muestra el diff.
Corre los checks.
Dispara code owners.
Conserva comentarios.
Permite aprobar o bloquear el merge.
Pero el trabajo con agentes no empieza ahí.
Empieza antes, cuando alguien define una intención:
arreglá este bug
cambiá esta pantalla
prepará una versión inicial
revisá este comportamiento
Después el agente interpreta, planifica, ejecuta, pide aclaraciones, recibe correcciones y ajusta.
Muchas de las decisiones importantes ocurren antes de que exista un PR final.
Y si el equipo solo mira el diff, llega tarde.
Slack Code mueve la revisión hacia el proceso
Lo interesante de Slack Code no es solamente que puedas mencionar a un agente desde Slack.
Lo interesante es que convierte una tarea agéntica en un espacio compartido.
Ahí viven:
- la solicitud original;
- el plan del agente;
- las preguntas;
- las correcciones humanas;
- los cambios;
- los previews;
- los comentarios;
- la aprobación;
- y el registro final de lo que pasó.
Ese formato encaja mejor con agentes que un PR aislado.
Porque el valor no está solo en saber qué cambió.
También está en saber cómo se decidió cambiarlo.
Revisar intención, no solo código
Un agente puede producir un diff técnicamente correcto y aun así haber entendido mal la tarea.
Puede pasar los tests, pero tocar una zona del sistema que nadie quería modificar.
Puede resolver el bug, pero ignorar una restricción de producto que estaba en la conversación inicial.
Por eso el review empieza a moverse hacia arriba en el workflow.
Ya no se trata solo de preguntar:
¿Este código está bien?
También hay que preguntar:
¿Esta era la tarea correcta?
¿El agente entendió el límite?
¿El equipo aprobó el camino?
¿Qué feedback recibió antes del resultado final?
Ese contexto rara vez queda completo en GitHub.
En cambio, vive naturalmente en la conversación.
Slack tiene una ventaja obvia
Slack ya es donde muchos equipos deciden qué vale la pena hacer.
Ahí aparece el bug report informal.
Ahí producto pregunta si algo es urgente.
Ahí soporte pega una captura.
Ahí diseño da contexto.
Ahí ingeniería negocia alcance.
Si el agente trabaja desde ese lugar, el contexto no tiene que ser copiado manualmente hacia otro sistema.
Ya está ahí.
Slack no necesita convertirse en GitHub para que esto importe.
Le alcanza con capturar el momento anterior al PR: el momento donde el trabajo se define, se corrige y se aprueba.
En workflows con agentes, ese momento se volvió muchísimo más valioso.
El audit log se vuelve parte del producto
El detalle de archivar el canal al terminar no es menor.
Para una empresa, saber qué cambió no alcanza.
También importa saber:
- quién pidió el cambio;
- qué agente lo ejecutó;
- qué instrucciones recibió;
- qué opciones descartó;
- quién corrigió el rumbo;
- quién aprobó;
- qué preview se revisó;
- y qué terminó llegando al deploy.
En desarrollo tradicional, muchas de esas conversaciones quedaban repartidas entre Slack, Jira, GitHub, Linear y reuniones.
Con agentes, esa dispersión se vuelve más peligrosa.
Porque el agente puede ejecutar mucho más rápido que el equipo puede reconstruir la historia después.
La auditabilidad deja de ser un detalle de compliance.
Se convierte en la condición para darle más autonomía al sistema.
El mercado está buscando dónde vive el agente
Slack Code no aparece en el vacío.
Cursor está llevando agentes hacia repos, PRs, cloud tasks y ejecución persistente.
Codex separa el harness de las superficies donde se usa.
Cloudflare OS explora workspaces con permisos granulares para agentes.
GitHub intenta que Copilot viva cada vez más cerca del ciclo completo de desarrollo.
Todos están rodeando la misma pregunta:
¿Dónde debería vivir el trabajo de un agente?
Puede ser el IDE.
Puede ser el repo.
Puede ser el browser.
Puede ser Slack.
Puede ser una plataforma nueva.
Pero la dirección es clara: el agente necesita un lugar donde el equipo pueda verlo trabajar, corregirlo, aprobarlo y reconstruir después qué ocurrió.
El PR por sí solo no alcanza para eso.
El PR no desaparece
El pull request sigue siendo necesario.
Es el lugar natural para validar el cambio contra el repositorio:
- diff;
- tests;
- checks;
- code ownership;
- branch protection;
- merge.
Pero puede dejar de ser el lugar principal donde se entiende el trabajo.
En un workflow agéntico, el PR empieza a parecerse más al recibo final.
Importante.
Necesario.
Auditable.
Pero incompleto.
La historia completa vive antes: en la intención, el plan, las iteraciones, el feedback y las aprobaciones humanas que llevaron al agente hasta ese diff.
Slack Code apunta exactamente a ese espacio.
Por eso importa.
No porque Slack haya inventado el coding agent.
Sino porque entendió que el problema ya no es solo generar código.
Es coordinar humanos y agentes alrededor de una tarea compartida sin perder visibilidad.
La próxima gran batalla de los dev tools quizá no sea quién escribe mejor código.
Puede ser quién conserva mejor la historia de cómo ese código llegó a existir.