Slack ha lanzado Slack Code y, como era de esperar, la narrativa es la de siempre: sacar la programación con IA del terminal solitario y llevarla al chat de equipo, donde cualquiera puede pedirle a un agente que arregle un bug, monte una landing o revise un diff mientras el resto mira. Suena bien. Suena incluso justo. Pero cuando lo lees con calma —y cuando llevas años viendo cómo las herramientas de productividad se convierten en otro canal más donde el ruido mata el foco— empiezas a tener dudas serias.
La idea, según Slack, es sencilla: mencionas a un agente compatible (Claude Code, Devin, GitHub Copilot o Vercel) en un canal y se crea automáticamente un «code channel» con diffs, documentos y previews HTML en vivo. El trabajo queda archivado como registro auditable. Cuando termina, el canal se archiva. Todo muy ordenado, en papel.
Lo que me choca es que Salesforce vende esto como una revolución del flujo de trabajo. En InfoWorld lo explican como una alternativa al modelo tradicional: alguien reporta un fallo en Slack, abre ticket en Jira, llega el desarrollador y se encierra con su agente en el IDE. Slack Code elimina esos saltos. Sí, elimina saltos. También elimina la puerta cerrada donde el desarrollador pensaba antes de tocar producción.
Y aquí está el primer problema que casi nadie menciona en los comunicados: ¿quién es responsable del código que sale de un code channel? Slack dice que los agentes operan dentro de sus permisos y controles de administración existentes. Vale. Pero permisos de Slack no son permisos de Git. Un comercial con buena intención que le pide a Copilot «arregla el botón del checkout» no está haciendo pair programming; está delegando una modificación en un sistema que probablemente no entiende. El diff quedará bonito en el canal. La pregunta de si ese diff debería existir, no.
El segundo problema es económico y es el que más me irrita porque lo disfrazan de inclusión. Slack Code no tiene coste extra: viene en cualquier plan de Slack. Genial. Pero los agentes no. Necesitas tu propia suscripción a Claude Code, Devin, Copilot o lo que toque. Es decir: democratizas la interfaz del desarrollo con IA, no el acceso real. El becario puede ver cómo se programa en el canal; la factura la sigue pagando la empresa en cuatro licencias distintas repartidas por departamentos. He visto esta película con las integraciones de Slack y los bots de moda: la plataforma es gratis, el ecosistema no.
Tampoco me convence el argumento de la «experiencia multijugador». Computerworld lo resume bien: varios compañeros pueden seguir el progreso del agente, revisar cambios y ver prototipos HTML en directo. En teoría, un PM corrige el rumbo antes de que el agente se vaya por las ramas. En la práctica —y lo digo con la cicatriz de cientos de hilos de Slack— lo más probable es que aparezcan diez mensajes paralelos, tres interpretaciones distintas del bug y alguien que escribe «¿ya está?» cada cuarto de hora. El agente no sufre interrupciones; el contexto sí se degrada.
Los defensores dirán que esto es mejor que el silo del terminal. Que un fix pequeño no debería requerir un sprint entero. De acuerdo parcial. Pero confundir accesibilidad con calidad es un error clásico en empresas que quieren mover más rápido sin mover mejor. Hay tareas que encajan en un code channel: copy de una landing, ajuste CSS menor, script de informe interno. Hay otras que no deberían acercarse a un chat ni con un palo: cambios en autenticación, lógica de pagos, migraciones de base de datos. Slack no distingue entre ellas en su marketing; distingue en la práctica solo si tu equipo ya tenía criterio antes de instalar la herramienta.
Me llama la atención que Vercel esté en el lanzamiento con previews automáticos cuando hace apenas unos días en ticweb ya comentábamos el discurso agresivo de Vercel sobre agentes y deploys. No es casualidad: Slack Code convierte a Slack en escaparate de quien ya tiene infraestructura lista para enseñar resultado visual rápido. El que usa agentes en un repo legacy sin preview bonito queda un peldaño por debajo en la demo interna. La herramienta no es neutral; favorece el stack que produce pantallazos.
Tampoco veo claro el tema del archivo como auditoría. Que el canal quede archivado suena a compliance, pero un hilo de Slack no es un ADR, no es un changelog y no es un registro de decisiones técnicas. Es conversación. Si dentro de seis meses alguien pregunta por qué se cambió la lógica de descuentos, encontrarás emojis, un diff y un «parece que ya funciona». Para equipos pequeños puede valer; para cualquier empresa con requisitos mínimos de trazabilidad, es insuficiente.
No digo que Slack Code sea inútil. Digo que llega en el peor momento posible del hype de agentes: cuando muchas pymes ya están probando Copilot o Claude porque «todos lo usan», sin política de uso, sin formación y —ironías del destino— con el AI Act exigiendo trazabilidad en formación desde febrero. Meter la generación de código en el chat corporativo amplifica el alcance del problema sin ofrecer por sí solo ningún mecanismo nuevo de control.
Mi apuesta: veremos equipos enteros celebrando que «ahora cualquiera puede pedir un fix», y veremos incidentes de producción originados en code channels que nadie quiso revisar porque el diff parecía pequeño. Los buenos equipos usarán Slack Code como capa de visibilidad sobre trabajo que ya estaba gobernado. Los demás usarán otro canal donde la IA opere sin supervisión real, pero esta vez con audiencia.
Si mañana tu jefe te propone activar Slack Code para «democratizar el desarrollo», la pregunta no es si la herramienta funciona. La pregunta es si tu empresa tiene ya definido qué puede tocar un agente, quién aprueba el merge y qué pasa cuando el comercial de turno pide en un canal que se cambie la pasarela de pago porque «el botón no se ve bien en su móvil». Porque Slack Code no resuelve eso: lo pone en un hilo con preview HTML y te invita a aplaudir.
¿Aceptarías que cualquier compañero de tu empresa pudiera lanzar un agente de codificación sobre tu repositorio principal siempre que el cambio quedara visible en un canal de Slack, o prefieres seguir pagando el cuello de botella del desarrollador a cambio de saber quién firmó cada línea?