La mayor parte del trabajo de código todavía empieza con una frase en un chat de grupo. «La exportación a CSV pierde la última fila». «¿Podemos añadir SSO antes de la demo?». «Producción vuelve a lanzar errores 500 en el checkout». Alguien reacciona con un pulgar arriba, quizá se le asigna a un agente de programación, y tres días después nadie puede decir si se desplegó, quién lo revisó ni qué commit lo arregló. El mensaje se pierde al hacer scroll. El trabajo se convierte en folclore.
Esa brecha es un problema de estructura, no de disciplina. Un mensaje de chat no tiene responsable, ni estado, ni prueba de aceptación, ni enlace al diff que lo resuelve. Apunta a un agente de programación a ese mensaje y habrás creado trabajo que no se puede rastrear. Empeora cuando ejecutas más de un agente, porque entonces tampoco puedes decir qué agente lo tocó.
Este artículo explica cómo convertir un mensaje de chat en una tarea de código rastreable: qué te aporta una configuración casera básica, dónde deja de escalar y qué añade una capa de tareas compartida. Sharkly es el espacio de trabajo para la versión rastreable, porque se sitúa por encima de tus agentes de programación y mantiene el objetivo, la ejecución, los bloqueos, el diff y la revisión humana en un único registro. Ya tienes agentes de programación. La tarea es convertir su trabajo en algo que un equipo pueda seguir.
Por qué el chat es donde mueren las tareas de código
Un chat de grupo optimiza la velocidad de conversación, justo lo contrario de lo que necesita una tarea de código. Una tarea real lleva un objetivo declarado, un responsable, criterios de aceptación, un estado que puedes consultar y un enlace de vuelta al cambio que la cerró. Un mensaje de chat no lleva nada de eso. Lleva una marca de tiempo y una reacción.
El modo de fallo es concreto. Llega una petición, se acepta informalmente en el hilo y el hilo sigue avanzando. Dos días después alguien pregunta «¿alguna vez arreglamos el bug de la exportación?» y la respuesta exige buscar en Slack, conjeturas y hacer scroll por un canal donde la misma frase aparece nueve veces. Aunque encuentres el mensaje, no te dice si la corrección se fusionó. La conversación y el código viven en sistemas separados que nunca se aprendieron el nombre del otro.
Apunta un agente de programación autónomo a ese mensaje y el rastro se acorta. El agente lee una línea de Slack, se ejecuta en un terminal del portátil de alguien, edita archivos y responde en el mismo hilo que se mueve rápido y que se tragó la petición. Ahora tienes un registro de ejecución que nadie guardó, un cambio que nadie enlazó y una decisión que nadie documentó.
El pipeline casero y dónde deja de escalar
No necesitas un producto para empezar. Un pipeline casero viable: copia el mensaje de chat, pégalo en tu agente de programación como prompt, deja que trabaje en un árbol de trabajo de Git aislado para que no colisione con tu checkout principal, y abre una pull request que enlace de vuelta a un issue de seguimiento con una línea Closes #123. Eso es trazabilidad real y, para un desarrollador en solitario que gestiona una petición a la vez, suele ser suficiente.
Aquí está el par de decisión honesto. Si eres una sola persona, ejecutando un solo agente, cerrando una tarea antes de la siguiente, el bucle de copiar y pegar al árbol de trabajo funciona y no deberías añadirle herramientas. El coste de un sistema compartido sería mayor que lo que devuelve.
La configuración deja de escalar en el momento en que dos cosas son ciertas a la vez: dos agentes en ejecución, o dos personas enrutando trabajo, o dos repositorios en juego. Entonces el pipeline manual desarrolla agujeros:
| Qué se rompe | Por qué el bucle casero no puede cubrirlo |
|---|---|
| «¿Qué agente tiene el bug de la exportación?» | La asignación vivía en tu cabeza, no en un registro |
| «¿Esto está hecho o sigue en ejecución?» | El estado es un terminal que cerraste, no un campo consultable |
| «¿Quién aprobó el cambio de autenticación?» | La aprobación fue un pulgar arriba, ahora perdido al hacer scroll |
| «¿Dónde está el diff de esa petición de Slack?» | La PR enlaza a un issue, pero el issue nunca enlaza a la petición |
| «¿Qué cambió realmente el agente?» | El registro de ejecución vivía en una sesión que terminó |
Cada agujero es un punto donde la tarea vuelve a ser no rastreable. Puedes parchearlos a mano con más issues, convenciones de nombres y disciplina. Eso funciona hasta que deja de hacerlo, y falla en silencio, que es la peor forma en que puede fallar un proceso.
Qué significa «rastreable» cuando la tarea es compartida
Rastreable no es una sensación. Cada pregunta sobre una pieza de trabajo tiene una respuesta que vive en un solo lugar y sobrevive a las personas que estaban conectadas cuando empezó. Una tarea rastreable mantiene el contexto, la asignación, el progreso, los bloqueos, los resultados y la revisión humana visibles desde la petición hasta el lanzamiento.
Sharkly modela esto como una Task, la unidad principal de trabajo del sistema. Una Task no es un mensaje de chat ni una sesión de terminal. Es el registro compartido en el que se convierte un mensaje de chat cuando decides actuar sobre él. El objetivo va en la descripción. Un Agent o una persona se convierte en el Assignee. La ejecución del Agent, sus bloqueos, sus resultados y la discusión de seguimiento vuelven todos a la línea temporal de la Task en lugar de desaparecer en un terminal privado. Cuando el cambio se despliega, la pull request se enlaza por ID, de modo que la petición y el diff por fin se conocen.
Un límite importa, porque un lector podría asumir lo incorrecto. Sharkly no sustituye a Claude Code, Codex ni a tus otros agentes de programación. Esas herramientas realizan la ejecución. Sharkly añade la capa compartida de tareas, contexto y revisión a su alrededor. El Agent sigue escribiendo el código. Sharkly hace que el trabajo sea asignable y rastreable.
Convertir un mensaje de chat en una tarea rastreable con Sharkly
El flujo de trabajo es lo bastante corto como para retenerlo. Empieza con un mensaje real, digamos el bug de la exportación a CSV, y sácalo del canal:
- Captura el mensaje como una Task. Crea una Task con la petición como objetivo. Si tu chat está en Slack, un bot de Slack para agentes de programación convierte la mención en una Task sin salir del hilo.
- Dale forma para que un Agent pueda ejecutarla. Un informe de bug de una línea no es una especificación ejecutable. Añade la reproducción, el comportamiento esperado y una prueba de aceptación. La misma disciplina que en la gestión de tareas de agentes de IA: una Task que un Agent pueda cerrar necesita una descripción sobre la que un Agent pueda actuar.
- Asígnala y deja que el Agent se ejecute. El Agent reclama la Task, trabaja en un árbol de trabajo aislado para que el trabajo paralelo no colisione, y transmite su progreso de vuelta a la Task. Estás observando un registro, no un terminal.
- Revisa y acepta. El Agent adjunta su resumen de cambios, los resultados de las pruebas y los límites conocidos. Una persona acepta, solicita cambios o toma la decisión de fusionar.
Ese último paso es el contrato que merece la pena enunciar con claridad: los Agents investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo. Una tarea rastreable hace posible ese traspaso, porque la persona que revisa el cambio ve todo el camino desde la petición hasta el diff. Cuando el trabajo está hecho, puedes rastrear lo que completó el agente sin reconstruirlo de memoria. Es la misma columna vertebral que un flujo de trabajo rastreable de requisitos a código, solo que partiendo de un retazo de chat en lugar de un ticket formal.
Puedes construir una versión de esto a mano con issues y árboles de trabajo, o usar Sharkly para gestionar el flujo de trabajo de modo que el rastro se mantenga cuando suba el volumen.
La lista de comprobación que puedes ejecutar hoy
Pásala por tu configuración actual. Cada casilla sin marcar es un punto donde una tarea nacida del chat puede quedar sin rastrear:
- [ ] Cada petición de chat accionada se convierte en una Task con un responsable, no en un emoji de reacción.
- [ ] Cada Task tiene una descripción que un Agent puede ejecutar: reproducción, comportamiento esperado, prueba de aceptación.
- [ ] Cada Agent en ejecución trabaja en un árbol de trabajo aislado, de modo que dos tareas nunca toquen los mismos archivos.
- [ ] El registro de ejecución del Agent, sus bloqueos y sus resultados vuelven a la Task, no a un terminal que se cierra.
- [ ] La pull request está enlazada a la Task por ID, de modo que la petición y el diff están a un clic de distancia.
- [ ] Una persona acepta o rechaza el resultado, y esa decisión queda registrada en la Task.
- [ ] Puedes responder «¿esto está hecho, quién lo hizo y dónde está el diff?» sin buscar en el chat.
Gestionando una petición a la vez, el bucle manual cumple la mayoría de estos puntos por sí solo. Ejecutando varios agentes en un equipo, Sharkly te da un único lugar donde gestionar sus tareas y resultados. Descarga Sharkly y mueve una petición de chat real a una Task antes de comprometer todo el canal.
Preguntas frecuentes
¿Necesito Sharkly para que las tareas nacidas del chat sean rastreables? No. Un desarrollador en solitario que ejecuta un solo agente obtiene trazabilidad real con un árbol de trabajo más una pull request que enlaza a un issue. El patrón de bandeja de entrada de agentes de IA se gana su lugar cuando tienes varios agentes o personas y los enlaces manuales empiezan a fallar.
¿Qué hace que un mensaje de chat sea difícil de ejecutar para un agente de programación? Normalmente le falta una reproducción, un resultado esperado y una prueba de aceptación. Convierte «la exportación está rota» en «la exportación a CSV pierde la última fila; se esperaban N filas, se obtuvieron N-1; arreglado cuando el recuento coincide». Ahora el Agent tiene algo contra lo que cerrar.
¿En qué se diferencia esto de un sistema de tickets normal? Un ticket rastrea el trabajo que hará una persona. Una tarea de código rastreable también lleva el registro de ejecución del Agent, su ejecución aislada y el diff enlazado, de modo que el registro cubre la decisión y el cambio. Consulta agentes de programación con humano en el bucle para saber dónde se mantiene la persona en el circuito.
¿Puede Sharkly leer mi canal de Slack directamente? Conectas un Agent de Sharkly a Slack para que una mención se convierta en una Task. La conversación se queda en Slack; el registro de trabajo rastreable vive en Sharkly.
