Descomposición de tareas: cadena fija para pasos conocidos y plan dinámico para tareas abiertas

Bienvenidos y bienvenidas a la cápsula seis del Módulo tres. Hoy vemos el task statement uno punto seis: cómo dividir una tarea compleja, con una cadena fija o con un plan que se adapta.

La guía compara dos formas de dividir una tarea grande. La primera es el pipeline secuencial fijo, o prompt chaining, que significa encadenar prompts: los pasos se conocen de antemano y se ejecutan en orden, cada uno con la salida del anterior. El ejemplo de la guía es la revisión de código. Primero se analiza cada archivo por separado, en busca de problemas locales, y después viene una pasada de integración entre archivos.

La segunda forma es la descomposición dinámica, en que el plan se arma según lo que se va descubriendo, y cada paso puede generar subtareas nuevas. El ejemplo es agregar tests completos a un código heredado, es decir, un código antiguo que nadie conoce bien. Primero se mapea la estructura, después se identifican las áreas de alto impacto, y luego se sigue un plan priorizado que se ajusta cuando aparecen dependencias.

La pregunta oficial doce muestra el problema de no dividir. Un pull request, o propuesta de cambio, toca catorce archivos, y la revisión de una sola pasada sale inconsistente. Hay comentarios detallados en unos archivos y superficiales en otros, se escapan bugs obvios, y el mismo patrón se marca en un archivo y se aprueba en otro. La causa es la dilución de atención: al mirar tantos archivos a la vez, la atención se reparte. La corrección es una pasada por archivo, más una pasada de integración.

Los distractores fallan así. Una ventana de contexto más grande no resuelve la atención. Pedir pull requests más chicos le traslada el problema a los desarrolladores. Y exigir que un hallazgo aparezca en dos de tres pasadas esconde bugs reales que se detectan solo a veces.

El artículo Building effective agents, de Anthropic, llama prompt chaining a la cadena fija y orchestrator-workers a la descomposición dinámica, en que un orquestador define las subtareas sobre la marcha. Y recomienda empezar por la solución más simple, y sumar complejidad solo cuando mejora los resultados.

El examen pide elegir según lo predecible del trabajo. Si los aspectos a revisar se conocen de antemano, entonces va la cadena fija. Por su parte, si es una investigación abierta, entonces va un plan que se adapta.

Una pregunta. ¿Qué patrón elegirías para una revisión con criterios fijos, y cuál para una investigación abierta?

Para criterios fijos, la cadena de pasos. Para la investigación abierta, la descomposición dinámica.

Dos preguntas de práctica. Pregunta uno. En una consultora de ingeniería, un agente revisa en una sola pasada un informe con catorce anexos. Unos anexos reciben comentarios detallados y otros, superficiales, y algunos comentarios se contradicen. ¿Cómo conviene reestructurar la revisión? Opción A: usar un modelo con una ventana de contexto más grande. Opción B: pedir que los informes lleguen con menos anexos. Opción C: conservar solo los hallazgos que aparezcan en dos de tres revisiones completas. Opción D: hacer una pasada por anexo y una pasada final de integración entre anexos.

La correcta es D. Ataca la causa, que es la dilución de atención, y la pasada final capta lo que cruza anexos. La A confunde el tamaño de la ventana con la calidad de la atención. La B le traslada la carga a quien entrega el informe. La C suprime hallazgos reales que aparecen de forma intermitente.

Pregunta dos, de respuesta múltiple. Elige dos. Una empresa de arriendo de autos necesita agregar pruebas a un módulo de tarifas heredado, sin documentación y con dependencias que nadie conoce. ¿Qué dos decisiones conviene tomar? Opción A: mapear primero la estructura y las dependencias del módulo. Opción B: definir de antemano un pipeline fijo, con los pasos escritos antes de conocer el código. Opción C: priorizar las áreas de mayor impacto y ajustar el plan a medida que aparecen hallazgos. Opción D: pedir primero toda la documentación a los equipos, antes de tocar el código. Opción E: generar pruebas archivo por archivo, sin plan previo. ¿Cuáles dos?

Las correctas son A y C. La A descubre qué hay antes de decidir, y la C concentra el esfuerzo donde más importa y corrige el rumbo. La B aplica un plan fijo a una tarea que no se puede prever. La D depende de documentación que quizás no exista. La E avanza sin criterio de impacto.

Resumen: los pasos conocidos van en cadena, las tareas abiertas en un plan que se adapta, y una revisión grande se divide por archivo más una integración. Si te sirvió, sigue el podcast, dale cinco estrellas y activa las notificaciones. En la próxima cápsula vemos las sesiones: cuándo reanudar, cuándo bifurcar y cuándo empezar de nuevo. Nos escuchamos en la próxima cápsula de EvoAcademy.