# 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.

*Tags: ia, agentes, ux, estados*

---


> [!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](https://www.nngroup.com/articles/response-times-3-important-limits/)). 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](https://www.nngroup.com/articles/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](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)). 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-en-ia|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](https://code.claude.com/docs/en/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](https://code.claude.com/docs/en/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|agentes en segundo plano]] describe ese modelo, y las notificaciones que lo acompañan están en [[notificaciones-de-agentes|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

- Justin Young, "Effective harnesses for long-running agents" (Anthropic Engineering): [https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
- Jakob Nielsen, "Response Times: The 3 Important Limits" (NN/g): [https://www.nngroup.com/articles/response-times-3-important-limits/](https://www.nngroup.com/articles/response-times-3-important-limits/)
- Katie Sherwin, "Progress Indicators Make a Slow System Less Insufferable" (NN/g, 2014): [https://www.nngroup.com/articles/progress-indicators/](https://www.nngroup.com/articles/progress-indicators/)
- Claude Code, documentación de hooks (evento Notification y sus tipos): [https://code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks)
- Claude Code, documentación de Interactive mode (lista de tareas y vista /tasks): [https://code.claude.com/docs/en/interactive-mode](https://code.claude.com/docs/en/interactive-mode)


---

Source: https://www.fernandoux.com/es/wiki/ia/progreso-de-tareas-largas/