Si una falla aparece en un canal de Slack, ya no tendría que perderse entre mensajes ni esperar a que alguien la copie al backlog. Slack Code, anunciado públicamente durante la ventana del 20 al 21 de agosto de 2026, lleva agentes de programación a canales específicos para que el equipo vea, oriente y revise su trabajo. Antes de probarlo, conviene entender qué resuelve y qué riesgo deja intacto. La cobertura del lanzamiento describe el producto y sus socios iniciales.
La idea central es sencilla: el desarrollo asistido por IA deja de ocurrir entre una sola persona y una terminal, y pasa a un espacio compartido. Para ti, eso puede significar que una persona de ventas reporte un error, un diseñador aporte un archivo de Figma y una ingeniera revise el cambio sin perseguir tres conversaciones distintas. El beneficio depende de una condición poco glamorosa, pero decisiva: la aprobación humana debe seguir siendo obligatoria.
1. El canal compartido convierte una tarea invisible en un trabajo revisable
Un agente de programación es un software que recibe una instrucción, consulta archivos de un proyecto y propone cambios. Hasta ahora, buena parte de ese trabajo ocurría en la computadora de una persona. El resto del equipo veía el resultado final, pero no necesariamente el razonamiento, los intentos fallidos o las pruebas intermedias.
Slack Code cambia el lugar donde ocurre la colaboración. Cuando alguien menciona un agente desde una conversación, el sistema abre un canal dedicado al proyecto. Ahí el agente trabaja frente al equipo y muestra tres piezas que suelen quedar escondidas:
- Claude Code, de Anthropic, es uno de los agentes integrados desde el lanzamiento.
- Devin, de Cognition, puede investigar una falla y abrir una solicitud de cambios. En GitHub, una solicitud de cambios es una propuesta que otras personas revisan antes de incorporarla al proyecto.
- GitHub Copilot y el agente de Vercel también figuran entre los socios nombrados por Slack.
- Los cambios de código, las vistas previas en vivo y el plan de trabajo aparecen en pestañas del canal.
La analogía útil es una cocina con la ventana abierta. El agente prepara el platillo, pero el equipo puede ver los ingredientes, señalar un error y decidir si sale del local. El canal terminado se archiva y conserva un registro de auditoría consultable. Eso importa cuando alguien necesita saber quién pidió un cambio, qué archivos tocó el agente y qué revisión ocurrió antes de integrarlo.
El flujo también admite a personas que no escriben código. En una demostración descrita por Cognition, una persona reportó una función rota. Devin investigó, probó el comportamiento en Chrome y DevTools, abrió una solicitud de cambios y publicó capturas junto con una demostración grabada. Un diseñador incorporó un archivo de Figma durante la tarea. La utilidad no está en que todos se vuelvan programadores de la noche a la mañana. Está en que reportar un problema deje de exigir conocer el camino técnico completo.
2. La velocidad mejora cuando la intención queda a la vista
La colaboración abierta resuelve un problema cotidiano: dos personas pueden pedirle a un agente la misma reparación sin saberlo. Un canal por proyecto muestra qué se está intentando, quién participa y en qué punto quedó la tarea. Para un equipo distribuido en México o entre varios husos horarios, esa memoria reduce la necesidad de repetir el contexto en cada reunión.
Cognition reportó que su conteo interno de solicitudes de cambios fusionadas aumentó 10 veces en los últimos meses, mientras su plantilla creció 40 por ciento en el mismo periodo. Son cifras internas de Cognition, no una medición independiente de Slack Code ni una garantía de productividad para tu empresa. Sirven para entender la apuesta: una persona puede lanzar tareas, cambiar de contexto y supervisar varios agentes, pero el volumen de cambios también eleva la cantidad de decisiones que alguien debe revisar.
«Una de las cosas que me gustan es que el código ya no es el cuello de botella».
Rob Seaman, director ejecutivo interino de Slack, resumió la tesis en una sesión informativa. Según explicó, el criterio humano pasa al frente. La frase suena convincente, aunque esconde un intercambio. Si producir código cuesta menos, decidir qué merece producirse se vuelve más importante.
La interfaz de Slack amplía esa apuesta con mensajes directos para agentes, una pestaña llamada «Agents» que concentra las sesiones y muestra su estado, además de un botón para detenerlas. También ofrece un flujo llamado «Add to Slack» para conectar agentes de Lovable, n8n, OpenAI, LangChain y Airtable mediante OAuth. OAuth es un sistema de autorización que permite conectar servicios sin entregar directamente la contraseña. Para un lector no técnico, la traducción práctica es esta: la instalación resulta más sencilla, pero cada conexión agrega una decisión sobre qué información puede consultar el agente.
Jeff Wang, presidente del área New Enterprise de Cognition, explicó que los reportes de errores también llegan del equipo de ventas. Esa ruta es valiosa porque acerca los problemas reales del cliente a quienes pueden corregirlos. El atajo útil: reportar sin duplicar trabajo. Aun así, una empresa debe conservar un lugar para priorizar, probar y documentar cada solicitud. Un canal visible no reemplaza un proceso de producto.
3. La visibilidad reduce el «AI slop», pero no lo elimina
«AI slop» describe contenido generado rápidamente por una IA que parece correcto, pero resuelve mal el problema o agrega mantenimiento innecesario. En software, puede ser una función que funciona en una pantalla y falla en otra, una prueba superficial o un cambio que ignora reglas del negocio. El riesgo crece cuando más personas pueden pedir código sin entender sus consecuencias.
Katie Steigman, vicepresidenta de producto de Slack, sostiene que el modelo compartido funciona como una barrera: el equipo puede ver la intención, comentar y corregir el trabajo antes de aprobarlo. Esa lógica tiene sentido porque hace visibles los cambios y permite que una persona técnica ajuste una solicitud hecha por alguien de producto. El canal, sin embargo, solo crea la oportunidad de revisar. No demuestra que la revisión haya ocurrido.
Los datos de mercado muestran por qué conviene moderar el entusiasmo. Gartner predijo que más del 40 por ciento de los proyectos de IA agéntica serían cancelados para finales de 2027, debido al aumento de costos y a un valor empresarial poco claro. En la encuesta más reciente de McKinsey citada por la fuente, el 62 por ciento de las organizaciones experimentaba con agentes de IA, cerca de un tercio había empezado a escalarlos y el 39 por ciento reportaba algún impacto en sus resultados. Las cifras no miden Slack Code directamente. Sí muestran la distancia entre probar agentes y obtener valor sostenido.
Para tu equipo, la prueba de calidad debe ocurrir antes de fusionar el cambio. Una solicitud de cambios en GitHub es una propuesta de modificación que otras personas pueden revisar. Mantén las puertas de lanzamiento existentes y exige evidencia que se pueda volver a comprobar:
- Reproduce el error antes de pedir la reparación y confirma que desapareció después.
- Revisa el cambio con una persona que conozca el código y las reglas del producto.
- Prueba los casos vecinos, no únicamente el ejemplo que motivó la tarea.
- Registra la aprobación antes de integrar o publicar cualquier modificación.
Si una organización no puede cumplir esos cuatro pasos, el problema no es que Slack Code sea demasiado abierto. El problema es que el equipo todavía no tiene una puerta clara entre «el agente propuso» y «la empresa aceptó». Visible no significa aprobado.
4. Los permisos heredados limitan el alcance, no el impacto
La seguridad de Slack Code parte de una regla comprensible: los agentes heredan los permisos de la persona que los invoca y nada más. Un permiso es la autorización para leer, modificar o ejecutar algo. En este caso, Slack afirma que el agente actúa con las listas de acceso de esa persona tanto dentro de Slack como en los sistemas conectados.
La regla evita crear una identidad automática con acceso total. Si tu cuenta no puede ver un canal financiero, el agente no debería verlo por su cuenta. Cuando Slack Code abre un canal de código, Slack indicó que el agente recibe únicamente el contexto de la conversación que lo activó. No obtiene un pase general para toda la empresa.
El límite también depende del sistema externo. Cognition dijo que Devin funciona en espacios aislados, llamados sandboxes, donde el agente ejecuta tareas separado de otros entornos. Su configuración usa acceso mínimo necesario para completar el trabajo y ofrece un modo opcional sin conexión a internet. Sin conexión, el agente pierde una vía para consultar servicios externos, pero también puede perder información necesaria para ciertas pruebas.
Piensa en los permisos como las llaves de un cibercafé. Que una persona tenga llave de una sala no le da acceso a todas las máquinas. Pero si esa persona puede entrar a una computadora con datos sensibles, el riesgo sigue existiendo. La seguridad no termina en la puerta de Slack: incluye el repositorio, los secretos, las herramientas de prueba y el sistema que publica el cambio.
La arquitectura tiene una ventaja práctica para los equipos de TI. Los agentes producen solicitudes de cambios estándar en GitHub, por lo que las reglas de revisión y lanzamiento que ya existen pueden seguir aplicándose. Antes de activar una integración, comprueba quién puede invocarla, qué repositorios puede leer, si puede escribir cambios, qué ocurre cuando falla una tarea y quién puede detenerla.
Revisa primero los permisos. Después observa si el registro de auditoría conserva suficiente contexto para investigar una decisión. Un archivo puede mostrar qué cambió; el canal puede mostrar por qué se pidió. Necesitas ambos para corregir un problema sin jugar a las adivinanzas.
La decisión práctica: prueba el flujo, no la promesa
Slack Code estaba disponible en cualquier plan de Slack al momento del lanzamiento, pero cada cliente debía contar con su propio acceso a los agentes asociados. Eso significa que «disponible» no equivale a «incluido»: tu empresa todavía necesita revisar contratos, permisos y costos de Claude Code, Devin, GitHub Copilot o el agente de Vercel, según la combinación que use.
La evaluación más sensata empieza con un proyecto pequeño y reversible. Elige un error de bajo impacto, define qué archivos puede tocar el agente y conserva la aprobación humana antes de fusionar. Mide si el canal permitió que una persona no técnica reportara mejor el problema, si una experta pudo orientar la solución y si el equipo evitó repetir la misma tarea.
Prueba Slack Code solo si mantienes las puertas de revisión de GitHub y los controles de permisos. Si tu equipo ya trabaja con canales claros, revisiones registradas y responsables definidos, la función puede quitar fricción sin borrar el criterio profesional. Si todavía no sabe quién aprueba un cambio, conviene ordenar ese proceso antes de sumar agentes. La IA puede hacer visible el trabajo. Tu equipo debe decidir qué trabajo merece llegar a producción.
