Progreso de tareas largas de IA: cómo mostrar que avanza sin inventar porcentajes

Cómo mostrar el progreso de un agente de IA que trabaja minutos u horas: pasos reales, estados verificables, decisiones pendientes y barra solo si se mide.

info Definición Rápida
El progreso de una tarea larga de IA es la forma en que la interfaz muestra qué ha hecho el agente, qué hace ahora y qué falta, durante un trabajo que puede durar minutos u horas. Debe reflejar pasos reales y estados verificables; un porcentaje inventado es peor que no mostrar nada.

¿Por qué las tareas largas son un problema de diseño?

Una respuesta de chat dura segundos. Un agente que refactoriza un proyecto, investiga diez fuentes o prepara una campaña puede trabajar durante horas, pasando por decenas de herramientas. Durante ese tiempo la persona no ve nada, o ve un indicador que no dice nada. Entonces se pregunta si sigue trabajando, si se atascó o si hizo algo que no debía.

Sin una señal clara, la persona no puede decidir si deja el trabajo en manos del agente o lo interrumpe. Por eso el progreso no es decoración: es la información con la que se decide esperar, intervenir o cancelar.

La investigación de usabilidad lleva décadas diciendo algo parecido. Según Jakob Nielsen, pasados unos 10 segundos la atención del usuario se dispersa y conviene mostrar cuándo terminará el trabajo (NN/g, Response Times). Katie Sherwin añade que un indicador sin fin definido deja a la persona sin saber si el sistema sigue trabajando o se detuvo (NN/g, Progress Indicators). Esas reglas nacieron para esperas de segundos; con un agente que trabaja horas el problema solo se agrava.

Anthropic describe un caso cercano en agentes que cruzan varias ventanas de contexto: cada sesión nueva empieza sin memoria de las anteriores, y el agente tendía a dar el proyecto por terminado demasiado pronto. Su respuesta fue un archivo de progreso (claude-progress.txt) y una lista de funcionalidades que el agente solo puede marcar como «passing» tras probarlas (Anthropic Engineering, noviembre de 2025). Visto desde el diseño, esa lista funciona como una vista de progreso que cualquiera puede revisar.

¿Qué progreso se puede medir de verdad?

Antes de diseñar la barra, conviene preguntar qué se puede medir. Hay tres tipos de avance:

  1. Avance contado. Archivos procesados de un total conocido, tests que pasan de cincuenta, filas revisadas de un lote. Aquí una barra es honesta.
  2. Avance por pasos. Una lista con las etapas del plan: leer, planear, editar, probar, cerrar. Sirve cuando el número de pasos es estable.
  3. Avance indefinido. Investigación abierta, donde no se sabe cuántas fuentes faltan. Aquí no hay porcentaje posible; hay que mostrar pasos y hallazgos.

La regla clásica de NN/g dice que los indicadores de porcentaje se usan para operaciones de más de unos 10 segundos, y que, si se procesa una serie de registros, conviene acompañar la barra con un texto como «Actualizando dirección 3 de 50». Esa regla supone que se puede medir cuánto falta. En un agente a menudo no se puede: el número de pasos cambia a mitad de camino. Si no sabes qué tipo de avance tienes, no uses barra. Una lista de pasos reales es casi siempre suficiente y no miente.

Para esperas de pocos segundos, los estados de carga son la herramienta adecuada; la vista de progreso es para trabajos de minutos u horas.

¿Cómo diseñar la vista de progreso?

Una buena vista de progreso responde cuatro preguntas sin que la persona tenga que abrir nada:

  • ¿Qué se hizo? Pasos terminados, con su resultado breve: “Leí 14 archivos, 3 relevantes”.
  • ¿Qué hace ahora? El paso en curso, en palabras concretas, no “procesando”.
  • ¿Qué falta? Los pasos pendientes, o una estimación marcada como tal.
  • ¿Hay algo que decidir? Si el agente necesita una respuesta, eso va al frente, separado del resto.

Esa última pregunta es la más importante. Un agente que espera una decisión y lo muestra como “en curso” hace perder horas. La interfaz debe distinguir “trabajando” de “esperando a una persona”.

Un ejemplo real de lista de pasos está en Claude Code: el agente crea una lista de tareas para planear trabajo de varios pasos, con indicadores de pendiente, en curso o completada, que se muestra u oculta con Ctrl+T y enseña hasta cinco tareas a la vez. Esa lista es distinta de la vista /tasks, que muestra los procesos y subagentes en ejecución (Claude Code, Interactive mode). Son dos preguntas distintas, «qué plan sigue» y «qué está corriendo ahora», y conviene no mezclarlas en una sola barra.

¿Qué pasa cuando la tarea dura horas?

Para tareas largas, tres prácticas evitan que la persona tenga que vigilar:

  1. Registro consultable. El avance se guarda en un lugar que la persona puede abrir cuando quiera: un archivo de progreso, un historial de commits, un panel. No depende de tener la pestaña abierta.
  2. Puntos de control verificables. Cada etapa termina con una comprobación, por ejemplo tests que pasan, y solo entonces se marca como hecha. Así el progreso refleja calidad, no solo tiempo.
  3. Notificación solo por eventos importantes. Avisar cuando hay un resultado, un error o una decisión pendiente. Notificar cada paso convierte la herramienta en ruido. Claude Code, por ejemplo, permite ejecutar un script cuando envía una notificación y distingue tipos como permission_prompt, idle_prompt, agent_needs_input y agent_completed, de modo que se puede avisar solo de lo que importa (Claude Code, Hooks).

Un agente que trabaja en segundo plano necesita, además, una forma de volver a su estado. La página sobre agentes en segundo plano describe ese modelo, y las notificaciones que lo acompañan están en notificaciones de agentes.

¿Qué no debe hacer la barra?

  • Avanzar con el tiempo. Una barra que sube por minutos transcurridos no mide nada.
  • Llegar al 100 % antes de terminar. Si el trabajo no ha terminado, la barra no debe decirlo.
  • Retroceder sin explicación. Si el total cambió porque el agente descubrió más trabajo, hay que decirlo: “Ahora son 40 archivos, antes eran 30”.
  • Quedarse en “procesando”. Un estado sin detalle hace que la persona interrumpa o cierre la tarea.
  • Trabarse en el último porcentaje. NN/g advierte que, si la barra avanza rápido y se queda colgada en el último tramo, la persona se frustra. Con un agente es más probable aún, porque el trabajo final (probar, corregir) suele ser el más lento.

Ejemplo

Ejemplo ilustrativo: un agente migra 120 componentes de una interfaz a una librería nueva. La primera versión muestra una barra que llega al 100 % en cuarenta minutos, pero el agente sigue corrigiendo errores por otros veinte. La barra mentía desde el principio.

El equipo cambia la vista a dos partes. Arriba, un contador real: “78 de 120 componentes migrados, 6 con tests fallidos”. Abajo, la lista de pasos del lote en curso: “Migrando el grupo de formularios, paso 3 de 4: pruebas”. Cuando el agente encuentra un componente que no sabe migrar, la vista lo marca en amarillo con la pregunta. La persona responde en dos minutos y el trabajo sigue.

¿Cuándo NO conviene una vista de progreso detallada?

Cuando la tarea es corta, de unos segundos, un indicador simple basta. Y cuando la persona no va a mirar el progreso porque la tarea puede terminar sin ella, mejor una notificación al final con el resultado y un enlace a lo que se hizo.

Errores comunes

  • Usar un porcentaje que no corresponde a trabajo medido.
  • Mostrar “procesando” durante minutos sin detalle.
  • Mezclar “trabajando” con “esperando a una persona”.
  • Notificar cada paso, lo que termina en ruido.
  • No guardar el avance, y perderlo si la sesión se corta.

Fuentes

Preguntas frecuentes

¿Cómo se muestra el progreso de una tarea larga de IA?
Con una lista de pasos reales y su estado: pendiente, en curso, terminado o fallido. Cuando hay una medida fiable de avance, se muestra; si no la hay, no se inventa un porcentaje.
¿Una barra de progreso sirve para un agente?
Solo si refleja trabajo medible, como archivos procesados de un total conocido. Una barra que avanza con el tiempo sin relación con el trabajo es engañosa.
¿Qué debe mostrar un agente mientras espera a la persona?
Que está esperando, qué necesita exactamente y desde cuándo. Un estado de espera sin explicación parece un error y hace que la persona cierre la tarea.
¿Cómo se maneja una tarea que dura horas?
Guardando el avance en un registro que la persona pueda consultar, con puntos de control verificables, y avisando solo cuando hay un resultado o una decisión pendiente.