Planificación, razonamiento y ejecución independientes
En esta unidad, aprenderá lo siguiente:
Por qué separar la planificación, la ejecución y la validación mejora la confiabilidad
Descripción de la diferencia entre un plan primero y un plan + flujos de trabajo de ejecución
Cómo aplicar límites de planificación mediante límites de capacidades y control de herramientas
Por qué la separación mejora la confiabilidad
Sistemas de agentes confiables independientes:
Planificación: qué se hará y por qué.
Ejecución: los cambios concretos realizados en el repositorio.
Validación: evidencia de que el resultado cumple los criterios de éxito.
Cuando el planeamiento y la ejecución se mezclan, los revisores solo ven la diferencia final. Pierden la capacidad de validar la intención pronto, detectar malentendidos rápidamente y controlar el ámbito antes del impacto.
Cómo se relaciona la separación con GitHub
GitHub naturalmente admite esta separación:
La planificación aparece en una descripción de PR, un comentario de issue, o un artefacto de Github/pull_request_template.md.
La ejecución aparece como confirmaciones en una rama.
La validación aparece como comprobaciones, análisis, artefactos y resultados de revisión.
Descripción de la diferencia entre un flujo de trabajo basado en planificación y un flujo de trabajo de planificación y ejecución.
Al trabajar con agentes, los equipos deben decidir cuándo un plan se vuelve visible y cuándo se permite que comiencen los cambios de código. En GitHub, el planeamiento y la ejecución pueden comenzar desde distintos puntos de entrada, como un problema de GitHub (por ejemplo, asignar un agente en la nube de Copilot) o a través de la pestaña Agentes donde se genera un plan de forma interactiva.
Estas son formas independientes de interactuar con el agente, pero convergen en el mismo modelo de gobernanza: todo el trabajo se presenta y se revisa en última instancia en un pull request (PR).
Por lo tanto, la opción de diseño clave no es donde se inicia el plan, pero cuando se requiere validación humana con respecto a los cambios de código.
Opción A: Pull request basado en el plan
En este enfoque, el planeamiento se completa y aprueba antes de que se introduzcan cambios en el código.
Cómo funciona en la práctica:
Se genera un plan (por ejemplo, asignando un agente a un problema de GitHub o creandolo en la pestaña Agentes).
El agente abre un pull request que contiene únicamente el plan (aún no hay cambios en el código).
Los revisores discuten, refinan y aprueban el plan directamente en el PR.
Después de la aprobación, el agente continúa implementando el plan en confirmaciones de seguimiento o una nueva solicitud de incorporación de cambios.
Esto crea una separación clara entre la intención (plan) y la ejecución (código).
Opción B: Planear y ejecutar en la misma solicitud de incorporación de cambios
En este enfoque, la planificación y la ejecución se combinan dentro de una única solicitud de incorporación de cambios.
Cómo funciona en la práctica:
El agente abre una solicitud de incorporación de cambios que incluye ambas cosas:
un plan estructurado (en la descripción)
cambios de código iniciales (confirmaciones)
El agente puede seguir actualizando la solicitud de incorporación de cambios a medida que evoluciona el plan.
Las comprobaciones estándar requeridas de GitHub, las revisiones de CODEOWNERS y la protección de ramas impiden la combinación hasta que se cumplan todos los requisitos.
Aquí, el plan sigue siendo visible, pero se presenta junto con los cambios activos en lugar de antes de ellos.
Diferencia clave: Tiempo de validación
Ambas opciones usan los mismos controles GitHub. La diferencia es cuando esos controles se aplican en relación con la ejecución:
Opción A (Plan-first): La validación humana se produce antes de que se escriba cualquier código.
Opción B (Plan + ejecución): El código se genera inmediatamente, pero la validación sigue siendo necesaria antes de la combinación.
Consideraciones de riesgo
Ambos enfoques pueden ser seguros cuando GitHub protecciones están configuradas correctamente. La diferencia radica en cuándo se introduce el riesgo en el sistema:
La opción A reduce la exposición temprana. Puesto que no se genera ningún código antes de la aprobación, los revisores validan primero la intención. Esto minimiza los cambios innecesarios o no seguros y se prefiere en entornos de alto riesgo (por ejemplo, sistemas de producción o áreas sensibles a la seguridad).
La opción B presenta una exposición anterior al cambio. El código aparece en el PR antes de que el plan se haya validado por completo. Aunque este código no se puede combinar sin aprobación, puede:
introducir cambios innecesarios o incorrectos que se deben revisar y rechazar
aumentar el esfuerzo del revisor
crear desalineación temporal entre el plan y la implementación
Importantemente, este riesgo existe durante la fase de propuesta, no después de la combinación. los mecanismos de cumplimiento de GitHub siguen evitando que se implemente código no seguro.
Cuándo usar cada opción
Utilice el flujo de trabajo Plan-first cuando:
los cambios son de alto riesgo o difíciles de revertir
la alineación en la intención es fundamental antes de la ejecución
Desea una separación estricta entre la planeación y la implementación.
Use el flujo de trabajo Plan y Ejecución cuando:
velocidad e iteración son más importantes
los cambios son de bajo riesgo o son fácilmente reversibles
los revisores se sienten cómodos evaluando el plan y el código juntos
Conclusión principal
La cuestión no es si el trabajo se revisa o no; siempre se revisa. La elección surge cuando el sistema permite generar código en relación con la validación por humanos y cuándo desea introducir cambios en el flujo de trabajo lo más temprano posible.
Aplicación de límites de planeamiento mediante límites de capacidad y control de herramientas
- Límite de funcionalidad (los agentes de planeamiento son de solo lectura) Un agente de planeación debe limitarse a las herramientas de solo lectura para que no pueda modificar los archivos durante el planeamiento.
- Transición explícita (o entrega) a un agente de implementación. La ejecución solo debe producirse después de la aprobación del plan, mediante una transferencia deliberada.
- En los orquestadores de orquestaciones automatizadas, se puede controlar la ejecución para forzar que la planificación se ejecute sin herramientas y habilitarlas solo después de aceptar el plan.
- Flujos de trabajo de "modo de plan": algunas interfaces admiten una experiencia de planificación inicial que genera un artefacto de plan y se pausa antes de aplicar los cambios.
Guía de decisión
Use plan-first para el trabajo de alto riesgo (flujos de trabajo, infraestructura, autenticación, producción).
Use plan + ejecución para el trabajo de riesgo medio/bajo, pero mantenga las comprobaciones y revisiones necesarias.
Tratar las "instrucciones para no editar" como guía; tratar las listas de herramientas permitidas y las puertas como aplicación.
Conclusiones clave: La separación crea una oportunidad para revisar la intención antes de aceptar el impacto.
A continuación, aplicará la visibilidad y validación del plan a través de puertas de aprobación de solicitudes de incorporación de cambios.