Tu backlog antes era una lista de la que tirabas tú y un par de compañeros. Leías el primer elemento, lo entendías y lo hacías. El triaje era rápido porque la única pregunta era «¿quién tiene tiempo?». Ahora parte de esos elementos los puede coger un agente de programación en lugar de una persona, y esa cola tan tranquila se convierte en una fuente de errores pequeños y caros: un agente empieza una tarea que nadie terminó de escribir, dos agentes se lanzan sobre trabajo que se solapa y la columna de «hecho» se llena de resultados que nadie pidió.
El problema no son los agentes. Es que un backlog pensado para personas cambió de trabajo sin avisar. Dejó de ser una lista de tareas pendientes y se convirtió en una cola de despacho capaz de lanzar ejecución. En cuanto una línea puede desencadenar trabajo real, el momento en que mueves una tarea y el momento en que decides de quién es tienen consecuencias que antes no tenían.
Esta es la capa en la que se sitúa Sharkly. Ya tienes agentes de programación; Sharkly los convierte en un equipo al darle al backlog un significado compartido. Una tarea es la unidad principal de trabajo, Backlog es donde espera el trabajo no comprometido y Triage es una cola de admisión específica donde los elementos entrantes se quedan hasta que alguien decide. Este artículo repasa cómo hacer triaje en un backlog mixto de personas y agentes sin que esas colas se conviertan en un caos, y termina con una lista de comprobación que puedes aplicar hoy mismo.
Qué significan el backlog y el triaje cuando los agentes pueden hacer el trabajo
Aquí hay dos definiciones que hacen casi todo el trabajo, así que conviene tenerlas claras.
El backlog es el conjunto de trabajo no comprometido: tareas que existen pero que nadie ha decidido empezar todavía. El triaje es la decisión de admisión que se toma sobre elementos nuevos o poco claros: aceptarlo, rechazarlo, marcarlo como duplicado o posponerlo para más adelante. Los humanos siempre hemos hecho ambas cosas de manera informal. Lo que cambia es que, en un equipo de personas y agentes, el resultado del triaje ahora incluye «qué agente ejecuta esto», y el hecho de comprometer una tarea puede iniciar una ejecución.
Esta es la frontera que confunde a todo el mundo al principio: asignar un agente a una tarea en el Backlog no la inicia. El Backlog es una zona de aparcamiento donde el trabajo se prepara antes de ejecutarse. La ejecución solo empieza cuando la tarea sale del Backlog hacia un estado listo para trabajar, y hay un Computer y un Runtime disponibles. Así que «asignar el agente» y «arrancar el agente» son dos eventos distintos, con el estado del backlog entre medias haciendo de puerta.
Otra frontera que conviene decir sin rodeos: los agentes no mantienen un backlog privado. No hay ninguna cola oculta que un agente vaya consumiendo por su cuenta. Cada elemento que un agente vaya a tocar vive en el tablero compartido, y eso es precisamente lo que hace posible el triaje en lugar de tener que adivinar.
Dónde deja de escalar una configuración por tu cuenta
Una hoja de cálculo, un tablero Kanban y unos cuantos terminales funcionan bien para una persona y dos agentes. Deja de escalar en puntos predecibles, y cada uno se manifiesta como un fallo concreto.
La columna de estado no significa nada para los agentes. En un tablero manual, mover una tarjeta a «En progreso» es una nota para tus compañeros; no se ejecuta nada. Así que el tablero y el trabajo real se van separando: una tarjeta dice «En progreso» mientras el agente terminó hace una hora, o «Por hacer» cuando el agente ya lleva tres commits porque alguien lo lanzó desde un terminal. Nadie se fía del tablero, así que nadie lo usa.
Las decisiones de triaje viven en la cabeza de una sola persona. Quien atiende las solicitudes entrantes recuerda que un bug ya se había reportado, que una funcionalidad se rechazó el trimestre pasado, que una tarea necesita primero la opinión de diseño. Cuando esa persona no está, se crean duplicados y los agentes empiezan trabajo que debería haberse rechazado en la admisión. La cola no tiene memoria.
La asignación y el alcance se deciden en el mismo momento de prisas. Un alcance vago se puede sobrellevar cuando una persona coge la tarea y hace una pregunta. Un agente no se para a preguntar: ejecuta con lo que le hayas dado y devuelve un resultado equivocado con total seguridad. El coste de un triaje flojo pasó de «un compañero se queda un momento confundido» a «un agente ha quemado una ejecución y un ciclo de revisión en la cosa equivocada».
Cómo hacer triaje en un backlog mixto, paso a paso
Esta es la secuencia que mantiene honesto un backlog de personas y agentes. Cada paso nombra el fallo que evita.
1. Vacía la cola de admisión antes de tocar el backlog. Las solicitudes nuevas aterrizan en Triage, no directamente en el backlog. Trabaja cada elemento con una de estas cuatro decisiones: aceptar, rechazar, marcar como duplicado o posponer. Triage es una cola de admisión, no un filtro guardado ni un generador de formularios, así que la decisión es explícita y queda registrada. Fallo que evita: que el trabajo rechazado y el duplicado se conviertan en silencio en tareas reales que un agente acaba cogiendo.
2. Da forma a la tarea antes de que sea apta para un agente. Un elemento aceptado se convierte en una tarea, pero se queda en el Backlog mientras escribes los criterios de aceptación, adjuntas el repositorio y anotas las restricciones. Este es el paso que la gente se salta cuando va con el tiempo justo. Fallo que evita: que un agente ejecute con un título de una sola línea y devuelva un resultado que encaja literalmente con las palabras pero se aleja de la intención.
3. Decide el responsable y trata «qué agente» como una elección real. Algunas tareas las quiere hacer una persona. Otras las quiere hacer un agente y, entre agentes, el adecuado depende de la tarea: una refactorización, una pasada de escritura de tests y una actualización de documentación no son el mismo trabajo. Enruta a conciencia en lugar de recurrir por defecto al agente que esté libre. Nuestra guía de enrutamiento para agentes de programación explica cómo tomar esa decisión. Fallo que evita: que el runtime equivocado se coma una tarea para la que no está bien preparado.
4. Déjala en el Backlog hasta que esté realmente lista. Esta es la puerta. Una tarea puede estar totalmente asignada y seguir en el Backlog sin que arranque ninguna ejecución. Aprovéchalo. No la saques de ahí hasta que el alcance esté fijado y realmente quieras que empiece el trabajo. Fallo que evita: que una tarea a medio escribir lance una ejecución porque alguien la arrastró a la columna equivocada.
5. Comprométela y deja que arranque la ejecución. Mueve la tarea a un estado listo o llévala a un Sprint. Cuando una tarea con un agente listo sale del Backlog y hay un Computer y un Runtime disponibles, empieza la ejecución. Ahora el cambio de estado y el trabajo son el mismo evento, que es justo la idea.
Para equipos que trabajan por ciclos, la planificación de sprints para equipos de personas y agentes muestra cómo ese mismo paso de compromiso acota un bloque de tiempo en lugar de una sola tarea.
El estado del backlog se convierte en una puerta de ejecución
El cambio mental es este: en un tablero solo de personas, el estado es una etiqueta que describe la realidad. En un tablero de personas y agentes, el estado es una palanca que cambia la realidad. Sacar una tarea del Backlog es la acción que arranca al agente, así que tu disciplina de triaje es ahora tu mecanismo de seguridad.
Esa puerta es también el lugar donde encaja el contrato entre personas y agentes. Los agentes investigan, ejecutan, prueban e informan. Las personas deciden qué entra en el backlog, qué se compromete y qué se publica. La automatización se detiene donde hace falta el criterio del equipo. La vista Plan mantiene el Backlog, los Sprints y los Proyectos en un mismo sitio para que la decisión de compromiso sea visible en lugar de quedar enterrada en un terminal, y la ejecución, los bloqueos, los resultados y la revisión vuelven todos a la tarea en vez de dispersarse por sesiones privadas.
Por eso la higiene del backlog importa más con agentes, no menos. Un backlog humano desordenado es solo desorden. Un backlog con agentes desordenado es desorden que de vez en cuando se ejecuta solo. El tablero mantiene visibles el contexto, la propiedad, el progreso, los resultados y la revisión humana desde la admisión hasta la entrega, y esa es la diferencia entre una cola que tú gestionas y una cola que te gestiona a ti. Cuando lo que se acumula es la revisión y no la admisión, ese es otro cuello de botella, que tratamos en por qué la revisión humana es la verdadera restricción.
Puedes llevar esto con una hoja de cálculo y disciplina manual si tu volumen es bajo. Si ya estás atendiendo una entrada constante de solicitudes y tienes varios agentes en marcha, Sharkly te da la cola de Triage, la puerta del Backlog y un único tablero compartido para que esas decisiones dejen de vivir en tu cabeza. Para una visión más amplia del mismo flujo de trabajo, consulta nuestra guía sobre gestión de tareas con agentes de IA y la diferencia entre Triage y tu Inbox personal.
Una lista de comprobación de triaje para aplicar hoy mismo
Pásala por tu tablero actual. Cada «no» es un sitio donde los agentes te van a sorprender.
- ¿Las solicitudes nuevas aterrizan en algún sitio antes del backlog? Si la admisión va directa a «Por hacer», no tienes ningún paso de aceptar/rechazar/duplicar y los duplicados son inevitables.
- ¿El alcance de cada tarea del backlog es lo bastante bueno como para dárselo a un desconocido? Si no sirve para alguien recién incorporado, tampoco sirve para un agente.
- ¿Mover una tarea inicia algo de verdad? Si tus cambios de estado son solo etiquetas, el tablero y el trabajo acabarán separándose.
- ¿La asignación es una decisión real, incluido qué agente? Recurrir por defecto al agente libre no es enrutar.
- ¿Puedes decir ahora mismo en qué está trabajando cada agente y qué espera revisión? Si esa respuesta vive en la memoria de alguien o en el historial de un terminal, el triaje no tiene una fuente de verdad compartida.
- ¿El trabajo terminado vuelve a la tarea y no a una sesión privada? Los resultados, los bloqueos y los diffs pertenecen al registro compartido para que la revisión tenga algo sobre lo que actuar.
Arregla los dos primeros puntos antes de escalar el número de agentes. Un paso de admisión limpio y un alcance de tarea honesto evitan la mayoría de los fallos caros; todo lo demás es afinar sobre un backlog que ya significa algo.
