Sesión 5: Introducción al patrón de planeación

Trabajaremos el patrón Planning partiendo de un código inicial. Compararemos una respuesta directa, o one-shot, con un plan explícito que guíe acciones paso por paso.

El recorrido incluye decidir cuándo conviene planear, reconocer límites de una petición única, construir un plan claro y accionable y ejecutar sus acciones de forma incremental.

Entre etapas sintetizaremos el contexto: las reglas vigentes, los resultados comprobados y lo que falta por resolver. Ese resumen ayuda a conservar el hilo sin repetir todo el historial, pero debemos contrastarlo con los datos originales.

Esta introducción presenta el recorrido. Las siguientes clases de la sección incluyen el código inicial, los datos de héroes y villanos, el Excel y las tres fases del laboratorio.

Comenzamos la sección 5 con el patrón de planeación. En lugar de pedir que una tarea se resuelva de una vez, prepararemos un flujo que la descomponga en acciones ordenadas.

El objetivo del curso es construir ese flujo mediante código, conservando el proveedor configurado. No depende de activar un modo de planeación en un editor o en una aplicación de chat.

El plan debe ser un resultado visible que podamos revisar: acciones, responsables, orden y condiciones. No necesitamos acceder al razonamiento interno del modelo para comprobarlo.

La ejecución incremental aborda una acción, comprueba su resultado y actualiza el estado antes de continuar. La síntesis debe conservar restricciones, decisiones justificadas y trabajo pendiente; no debe convertir una suposición en un hecho ni borrar un error todavía sin resolver.

El ejercicio tendrá héroes y villanos. Cada villano presenta una debilidad que debe cubrir la capacidad de algún héroe; además, cada héroe tiene un límite de horas de trabajo.

Las capturas también tienen prioridades. Un plan debe asignar héroes compatibles, respetar sus jornadas y justificar el orden; una lista convincente no demuestra que cumpla estas reglas.

Los nombres, capacidades y jornadas están en el código inicial; la hoja de Excel se ofrece en las referencias de la sección. La próxima clase recorre esos datos y distingue las fórmulas de horas de la revisión del plan.

Uno de los villanos puede liberar a los demás. Según las reglas de este ejercicio, debe capturarse primero aunque no sea el de mayor prioridad.

Esto introduce una dependencia: las otras capturas no son válidas si ese villano sigue libre. Ordenar únicamente por gravedad puede producir un plan que parezca razonable y fracase al ejecutarse.

Conserva esa condición de precedencia al revisar el plan. Cuando el material completo precise las prioridades restantes, comprobaremos también cómo se ordenan las demás capturas.

El material anuncia dos variantes de la prueba: sin Superman el plan debe resultar inviable; con Superman debe existir una solución. Es el resultado esperado para ese conjunto de datos, no una regla general de todos los problemas de planeación.

Para justificarlo necesitamos el catálogo de capacidades, tiempos y restricciones. No basta con responder “viable” ni con mencionar a Superman: cada captura debe tener una asignación compatible y una carga de horas permitida.

Si un plan no cumple una restricción, señala cuál falló. Si no encuentras una solución, distingue un intento fallido de una demostración de imposibilidad. Los datos y la hoja permiten contrastar las asignaciones en las próximas clases.

Primero evaluaremos una respuesta directa, o one-shot, con el código inicial y las reglas completas. Después probaremos un flujo que construya un plan, lo ejecute por etapas y sintetice el contexto entre ellas. Mantendremos el mismo problema y criterios de evaluación.

Un modelo puede resolver el problema en una sola llamada; otro puede beneficiarse de una descomposición. Planificar puede ordenar mejor la respuesta, pero no garantiza el cumplimiento de las reglas. Esa conclusión requiere comprobar el resultado.

Si el flujo añade llamadas, puede aumentar el tiempo y el consumo de tokens. Mide los valores reales y la calidad del plan; no supongas un coste fijo ni una mejora automática por tener más iteraciones.

El material propone comenzar por la solución más sencilla y añadir complejidad cuando la evaluación lo justifique. Las siguientes clases implementan las tres fases y comparan sus resultados con los datos del ejercicio.