Salesforce ha presentado Slack Code, un espacio dentro de Slack donde un equipo puede trabajar junto a Claude Code y a otros agentes de programación compartiendo contexto, planes, diffs y previews en el propio canal. La idea que vertebra el lanzamiento es explícita: convertir el desarrollo asistido por IA en algo de varios participantes en lugar de una sesión individual frente a un terminal.
Suena a integración más, y no lo es del todo. Lo que se mueve aquí no es dónde se ejecuta el agente, sino quién puede ver lo que está haciendo mientras lo hace. Y esa diferencia cambia bastantes cosas.
El terminal es, por diseño, un sitio de una sola persona
Quien lleva meses trabajando con un agente de programación conoce la sensación: la sesión buena, la que resolvió el problema difícil, se queda en tu máquina. El razonamiento intermedio, las alternativas que el agente propuso y descartó, el plan que acabó funcionando a la tercera — todo eso vive en un buffer de terminal que se cierra al terminar el día.
Lo que llega al resto del equipo es el resultado comprimido: un pull request y, con suerte, una descripción decente. El compañero que revisa ese PR ve el destino pero no el camino, y cuando el camino lo eligió un agente, esa asimetría pesa más que antes. Revisar código escrito por una persona implica una teoría implícita sobre por qué lo escribió así. Revisar código generado por un agente al que no viste trabajar es un ejercicio bastante más ciego.
Ahí es donde encaja la propuesta de Slack Code. Si el plan que el agente se marcó, los diffs que va produciendo y la preview del resultado aparecen en un canal, el equipo puede intervenir durante el trabajo y no solo al final. Corregir el rumbo cuando el agente ha entendido mal el requisito cuesta un comentario; corregirlo cuando ya hay cuatrocientas líneas escritas cuesta una tarde.
Revisar código de un agente al que no viste trabajar es bastante más ciego que revisar el de un compañero.
Slack ya era donde se decidían las cosas
La elección de Slack como sede no es casual ni oportunista. En la mayoría de equipos, la decisión técnica real no se toma en el gestor de tareas ni en el repositorio: se toma en un hilo. Alguien pega un error, otro sugiere un enfoque, se acuerda una solución y el ticket se actualiza después, si alguien se acuerda. Ese hilo es el registro de por qué el software es como es, y lleva años siendo un registro que ninguna herramienta de desarrollo lee.
Meter al agente en ese mismo hilo tiene una consecuencia obvia y una menos obvia. La obvia es la comodidad: no cambias de aplicación para lanzar una tarea. La menos obvia es que el contexto de la conversación y el contexto de ejecución dejan de estar separados. El agente no trabaja a partir de un prompt aislado, sino de un hilo donde ya está la captura del error, la decisión de la semana pasada y la persona que sabe por qué esa tabla se llama así.
⚠️ Lo que hay que mirar antes de activarlo
Un canal donde el agente lee el contexto es también un canal donde el agente lee todo lo que se pega ahí: claves de API, volcados de logs con datos de clientes, credenciales de staging. Antes de abrirlo a un equipo, decide qué canales entran, quién puede lanzar tareas y qué repositorios quedan fuera de alcance. La conveniencia y la superficie de exposición crecen en la misma dirección.
El ruido es el problema que hay que vigilar
Hay una lectura menos entusiasta que conviene tener presente. Todo lo que se traslada a un canal compartido genera notificaciones, y un agente de programación produce mucho más output por minuto que una persona. Un flujo mal calibrado convierte el canal del equipo en un log rodante donde nadie lee nada, que es exactamente el fracaso clásico de las integraciones de CI en Slack: al principio todo el mundo mira los avisos de build, al mes están silenciados.
Que esto funcione o no dependerá de una cosa aburrida: qué se publica y qué se resume. Compartir el plan antes de ejecutar y el diff final tiene valor. Compartir cada paso intermedio no lo tiene, y encima entierra los dos anteriores. Es una decisión de diseño de producto, pero también de configuración del equipo, y merece pensarse antes de enchufarlo a un canal con veinte personas dentro.
Qué se lleva de aquí quien trabaja por su cuenta
Si eres freelance, la lectura inmediata es que esto no va contigo, y en parte es cierto: no hay equipo con el que compartir el canal. Pero hay dos implicaciones que sí aterrizan.
- El cliente como espectador. Un canal compartido con el cliente donde aparezcan el plan y la preview de cada tarea es una forma de visibilidad que hasta ahora costaba trabajo fabricar a mano con capturas y correos de seguimiento. También es una forma de que el cliente vea el trabajo en curso, con todo lo bueno y lo incómodo que eso tiene.
- La normalización del agente como participante. Cuando una empresa del tamaño de Salesforce da a los agentes de programación un asiento en la herramienta donde trabaja todo el mundo, el debate sobre si se usan o no se acaba. La pregunta pasa a ser con qué permisos y bajo qué revisión, que es una conversación mucho más útil.
La implicación práctica para hoy es modesta pero real: si trabajas con equipos que viven en Slack, esta es la vía por la que Claude Code va a entrar en sus procesos, tanto si tú lo propones como si no. Merece la pena llegar a esa conversación con una opinión formada sobre qué canales tienen sentido, qué se publica en ellos y dónde poner el límite de lo que un agente puede tocar sin que lo mire una persona.
