Slack Code: los coding agents acaban de mudarse al canal del equipo

Lo más importante de un coding agent ya no es lo bien que escribe código. Es quién puede ver lo que hace. Hasta este mes, la respuesta honesta para la mayoría de equipos era: un developer, en terminal privado o browser tab, esperando recordar después qué hizo realmente el agent. Slack Code, lanzado el 20 de agosto, es el mayor intento hasta ahora de cambiar esa respuesta a "todos los del proyecto, por defecto".

He leído el anuncio de lanzamiento, el post de seguimiento de Slack y la coverage. El model debajo es el mismo Claude Code, Devin o Copilot que ya conoces. Lo que cambia es la habitación donde ocurre el trabajo, y resulta que eso importa más de lo que sugiere gran parte de la coverage.

Conclusiones clave - Slack Code añade "code channels": espacios de proyecto compartidos donde un coding agent etiquetado, Claude Code, Devin, GitHub Copilot, Vercel, con ChatGPT próximamente, hace su trabajo abiertamente, con diffs, live previews y human approval antes de shipping. - Funciona en cualquier plan de Slack desde day one, aunque access a cada agent se compra por separado. Los channels auto-archive al terminar y conservan audit log. - El cambio real es de supervisión: agent work pasa de una private session observada por una persona a un shared artefact observado por un equipo. Corrige gaps de attribution y review, y crea otros, bystander apathy, approval theatre, channel context como attack surface. - También es un movimiento de distribución. Slack pasó un año construyendo agent plumbing, MCP server, real-time search, Slackbot MCP client, y code channels son la surface que lo hace visible. - Trata "una persona aprueba el trabajo antes de que salga" como design goal, no garantía. Tu review process todavía tiene que ser real.

Qué ocurrió

El 20 de agosto, Slack lanzó Slack Code en todos sus planes, incluidos free workspaces. La mecánica, según la coverage del launch y el artículo de TechRepublic:

• Etiquetas un coding agent en cualquier conversación de Slack. El agent levanta un code channel dedicado a la task, ya sea arreglar bug, actualizar página o construir feature.

• Todos en el channel ven la misma conversación desde la que trabaja el agent, revisan code diffs según se proponen, comprueban live HTML previews, dejan feedback que incorpora el agent y aprueban el trabajo acabado. Nada se envía sin human sign-off.

• Cuando termina el trabajo, el channel se archiva automáticamente y conserva audit log.

• Los partners de lanzamiento son Claude de Anthropic, Devin de Cognition, GitHub Copilot y Vercel, con ChatGPT de OpenAI anunciado como próxima integración. Slack planea abrir las code channel APIs a la developer community para que cualquier custom agent pueda entrar.

Quién termina dentro del channel es configurable. Katie Steigman, VP of Product de Slack, dijo a Reworked: "You could have the agent just bring in the user who tagged the agent to make the code channel or you could configure the agent to make inferences on its own as to who should be in the channel based on the context it has." Rob Seaman, EVP y general manager de Slack, resumió la intención: "AI only creates value when it's part of how a team actually works."

Slack Code, lanzado el 20 de agosto de 2026 en todos los planes de Slack, mete partner coding agents, Claude, Devin, Copilot, Vercel, ChatGPT anunciado, en "code channels" compartidos donde todo el equipo ve conversation, diffs y live previews del agent, aprueba el trabajo antes de shipping y hereda audit log cuando el channel se auto-archiva, según el anuncio de Slack.

La supervisión sale de la sesión privada

Aquí está lo que oculta la feature list. La mayor parte de agent supervision actual es ficción sostenida por una persona cansada. El agent corre en el IDE de alguien o en cloud sandbox, el diff llega como pull request y el "review" es lo que ese developer tenía ganas de hacer a las 5pm. El reasoning, dead ends, los tres intentos antes del que funcionó: todo desaparece. He revisado suficiente agent output para saber que el diff es la parte menos informativa del proceso.

La propuesta real de Slack Code es hacer del proceso el artefacto. El channel conserva conversation desde la que trabajó el agent, intermediate steps, feedback que recibió y approvals, y luego archiva todo como searchable record. Es un supervision model genuinamente distinto y está más cerca de cómo buenos equipos revisan junior engineers que de cómo revisan agents hoy: mirar el trabajo, no solo output.

También cambia quién supervisa. El pitch explícito es que PMs, designers y compañeros no técnicos puedan seguir. Estoy cautelosamente a favor, con una reserva: una habitación llena de observadores no equivale a un reviewer. La diff literacy no llega por ósmosis, y "el equipo puede verlo" puede convertirse silenciosamente en "nadie lo comprobó." Las governance questions que esto plantea, quién es accountable cuando diez personas vieron y nadie owned el approval, son precisamente las que trabajo en el framework de agent governance, y Slack Code no las responde por ti. Las hace visibles, que es el primer paso honesto.

Slack Code mueve agent supervision desde private session a un shared, archived channel record: conversation, intermediate steps, feedback y approvals persisten como searchable artefact, según el product post de Slack. La pregunta de accountability, quién owns el approval en una sala de observadores, sigue siendo responsabilidad del customer.

El contexto compartido corta en ambas direcciones

La segunda gran afirmación es sobre context. El argumento de Slack es que el contexto de una task ya vive en channels, bug report, spec discussion, customer complaint, así que el agent debería trabajar donde está el context en vez de copiarlo a private prompt. Correcto, y se apoya en plumbing que Slack ha shipped todo el año: su MCP server y real-time search API llegaron a generally available en febrero, dando a agents governed access a workspace messages y files, y Slackbot MCP client siguió en junio. He cubierto por qué MCP access a team tools es la mitad útil de agent context en el roundup de MCP servers; el channel model lleva esa idea a su conclusión.

Pero shared context también es shared exposure. Un agent que lee un channel lee todo, incluido el message donde alguien pegó un credential "solo un minuto" y external content reenviado desde un customer. Todo security researcher que conozco dirá lo mismo: content que un agent puede leer es content que puede instruirlo. Un shared channel es una prompt-injection surface mayor que una private session, punto. Antes de apuntar un agent con write access a un busy channel, conviene decidir deliberadamente qué channels lee y qué tools puede tocar. Eso es architecture work, no settings work, el mismo trade-off que describo en agentic architecture: capability y blast radius crecen juntos.

La ventaja de context de Slack Code, el agent trabaja donde ya vive el task context, descansa en MCP-based workspace access que Slack hizo generally available en febrero de 2026, según Unite.AI. El mismo shared context ensancha la prompt-injection y credential-exposure surface, un trade-off que los materiales de launch no abordan.

Attribution y review, las victorias sin glamour

Las partes menos flashy del launch son las que realmente compraría. Primero attribution: en code channel, cada agent action queda bajo la identidad del agent, en workspace que ya sabe quién es cada uno, con audit log que sobrevive al project. Suena basic. Lo es. También es más attribution infrastructure de la que muchos equipos tienen hoy para agent work, donde "lo hizo el agent" y "lo hice yo" se mezclan en la misma git history. Las regulated industries llevan un año pidiendo exactamente esto tan aburrido.

Segundo review. Diffs y live previews en channel, feedback que el agent incorpora y hard approval gate antes de shipping. Pero mira lo que falta: los materiales de Slack describen una persona aprobando el trabajo, pero nada que haya visto especifica quién debe ser, qué se le muestra o qué ocurre cuando el reviewer configurado está de vacaciones. Approval como checkbox es cómo se consigue approval theatre: green button que todos aprenden a pulsar. Los equipos que obtengan valor serán los que conecten approval a un code owner real con diff review real, y mantengan channel output del agent como evidence, no como review.

También importa el competitive context. Microsoft metió Copilot coding agent en Teams threads en septiembre de 2025, y Block lanzó su open-source Buzz en julio, como señala Reworked. La chat window se está convirtiendo en contested surface para agent work, y la ventaja de Slack es nada glamourosa: ahí ya está el team. Distribution vence cleverness en collaboration software, siempre.

Slack Code da a cada agent identidad propia en channels y conserva audit log por archived project, según TechRepublic, pero su approval gate, "a person approves the work before it ships", no especifica reviewer identity ni review standards. Teams Copilot agent de Microsoft, septiembre de 2025, y Buzz open source de Block, julio de 2026, son comparables directos, según Reworked.

Qué hacer ahora

Si tu equipo usa Slack y coding agents, tres pasos.

1. Esta semana: elige una task low-stakes y bien especificada, un copy change o bug pequeño con reproducción clara, y ejecútala en code channel con dos o tres personas mirando. No estás probando al agent; estás probando el review behaviour del team. Observa si alguien realmente lee el diff.

2. Antes de que salga algo real: decide por escrito quién es approver del agent work en cada repo y qué debe revisar. Si la respuesta es "quien esté en el channel", no tienes review process, tienes un button.

3. Antes de broad rollout: scopea qué channels puede leer el agent y qué credentials contiene su environment. Channel history es context, y context es attack surface. Empieza estrecho y amplía con evidence.

FAQ

¿Qué es Slack Code?

Una feature de Slack, lanzada el 20 de agosto de 2026, que permite etiquetar partner coding agents, Claude Code, Devin, GitHub Copilot, Vercel, con ChatGPT próximo, en una conversación. El agent abre un "code channel" dedicado para la task, donde el equipo observa trabajo, revisa diffs y previews y aprueba el resultado antes de shipping. El channel se archiva automáticamente al terminar.

¿Necesito un plan de Slack de pago?

No. Slack Code está disponible en todos los planes, incluidos free workspaces. Pero access a cada coding agent se compra por separado al vendor correspondiente, así que coste práctico depende de qué agents ya pagas.

¿Slack Code reemplaza code review?

No, y tratarlo así es el riesgo principal. Reubica review en shared archived channel y añade approval gate, pero la calidad del review sigue dependiendo de un human nombrado leyendo el diff. Un proceso visible sin owner es peor que uno privado con reviewer concienzudo, porque parece supervised.

¿Es seguro dejar que un agent lea un channel entero?

Depende de qué haya dentro. Todo lo que puede leer el agent puede influirlo, incluyendo pasted credentials y forwarded external content. Scopea read access estrechamente, mantén agent credentials least-privilege y trata channel content como untrusted input, porque desde la perspectiva del agent lo es.

En resumen

Slack Code no hará que los agents escriban mejor código. No es para eso. Hace agent work visible, attributable y reviewable by default, en el lugar donde ya vive el team, y esas son las tres cosas que faltan silenciosamente en muchos agent deployments. El problema es que visibility no es supervision. El channel da record y gate; que alguien realmente esté mirando sigue siendo tu problema. Mira cómo configuran los teams al approver, no al agent. Ahí esto funciona o se convierte en theatre.

Si estás resolviendo cómo poner agents dentro de team workflows sin perder control del review, es una conversación que tengo regularmente con clientes. Ponte en contacto.

Fuentes

• Salesforce, "Introducing Slack Code: Agentic Coding for Teams": https://www.salesforce.com/introducing-slack-code/ (publicado 2026-08-19, consultado 2026-08-29)

• Slack, "Slack Code: Where Your Team and Agents Build Together": https://slack.com/blog/news/slack-code-channels-for-agents (publicado 2026-08-28, consultado 2026-08-29)

• Unite.AI, "Slack Code Puts AI Coding Agents in Dedicated Project Channels": https://www.unite.ai/slack-code-puts-ai-coding-agents-in-dedicated-project-channels/ (publicado 2026-08-20, consultado 2026-08-29)

• TechRepublic, "Slack Code: AI Coding Agents Get Shared Channels for Review and Oversight": https://www.techrepublic.com/article/news-slack-code-ai-coding-agents/ (publicado 2026-08-21, consultado 2026-08-29)

• Reworked, "Slack Code Puts AI Coding Agents in Shared Channels": https://www.reworked.co/collaboration-productivity/slack-code-brings-collaborative-ai-coding-into-channels/ (publicado 2026-08-20, consultado 2026-08-29)