Pianificazione, ragionamento ed esecuzione separate

In questa unità si apprenderà quanto segue:

• Perché la separazione della pianificazione, dell'esecuzione e della convalida migliora l'affidabilità

• Comprendere la differenza tra un flusso di lavoro incentrato sulla pianificazione e un flusso di lavoro di pianificazione ed esecuzione.

• Come applicare i limiti di pianificazione usando limiti di funzionalità e controllo degli strumenti

Perché la separazione migliora l'affidabilità

Sistemi agenti affidabili separati:

• Pianificazione: cosa fare e perché.

• Esecuzione: le modifiche concrete apportate al repository.

• Convalida: evidenza che il risultato soddisfa i criteri di esito positivo.

Quando la pianificazione e l'esecuzione vengono mescolate, i revisori vedono solo il differenziale finale. Perdono la possibilità di convalidare le finalità in anticipo, rilevare rapidamente i malintesi e controllare l'ambito prima dell'impatto.

Come la separazione si integra con GitHub

GitHub supporta naturalmente questa separazione:

• La pianificazione appare nella descrizione di una richiesta pull, nel commento su un problema o in un artefatto Github/pull_request_template.md.

• L'esecuzione viene visualizzata come commit in un ramo.

• La validazione si presenta come controlli, analisi, artefatti ed esiti della revisione.

Comprensione della differenza tra un flusso di lavoro orientato alla pianificazione e un flusso di lavoro di pianificazione ed esecuzione

Quando si lavora con gli agenti, i team devono decidere quando un piano diventa visibile e quando le modifiche al codice possono iniziare. In GitHub, la pianificazione e l'esecuzione possono iniziare da punti di ingresso diversi, ad esempio un problema di GitHub (ad esempio, l'assegnazione di un agente cloud Copilot) o tramite la scheda Agenti in cui viene generato un piano in modo interattivo.

Si tratta di modi distinti per interagire con l'agente, ma convergono sullo stesso modello di governance: tutto il lavoro viene infine esposto e esaminato in una pull request (PR)

La scelta di progettazione chiave non è quindi la posizione in cui viene avviato il piano, ma quando la convalida umana è necessaria in relazione alle modifiche al codice.

Opzione A: richiesta pull con piano prioritario

In questo approccio, la pianificazione viene completata e approvata prima dell'introduzione di eventuali modifiche al codice.

Come funziona in pratica:

• Viene generato un piano, ad esempio assegnando un agente a un problema di GitHub o creandolo nella scheda Agenti.

• L'agente apre una richiesta pull che contiene solo il piano (nessuna modifica del codice).

• I revisori discutono, perfezionano e approvano il piano direttamente nella richiesta pull.

• Dopo l'approvazione, l'agente procede all'implementazione del piano nei commit di follow-up o in una nuova richiesta pull.

In questo modo viene creata una netta separazione tra finalità (piano) ed esecuzione (codice).

Opzione B: Pianificare + esecuzione nella stessa richiesta pull

In questo approccio, la pianificazione e l'esecuzione vengono combinate all'interno di un'unica richiesta pull.

Come funziona in pratica:

• L'agente apre una richiesta pull che include:

  • un piano strutturato (nella descrizione)

  • modifiche al codice iniziale (commit)

• L'agente può continuare ad aggiornare il PR man mano che il piano si evolve.

• Controlli standard GitHub obbligatori, verifiche CODEOWNERS e protezione dei rami impediscono l'unione fino a quando non vengono soddisfatti tutti i requisiti.

In questo caso, il piano è ancora visibile, ma viene presentato insieme a modifiche attive anziché prima di esse.

Differenza chiave: intervallo di convalida

Entrambe le opzioni usano gli stessi controlli GitHub. La differenza è quando questi controlli vengono applicati in relazione all'esecuzione:

• Opzione A (Plan-first): La convalida umana viene eseguita prima della scrittura di qualsiasi codice.

• Opzione B (Piano + esecuzione): Il codice viene generato immediatamente, ma la convalida è ancora necessaria prima dell'unione.

Considerazioni sul rischio

Entrambi gli approcci possono essere sicuri quando GitHub protezioni sono configurate correttamente. La differenza risiede nel momento in cui il rischio viene introdotto nel sistema:

• L'opzione A riduce l'esposizione precoce. Poiché non viene generato alcun codice prima dell'approvazione, i revisori convalidano prima la finalità. Ciò riduce al minimo le modifiche non necessarie o non sicure ed è preferibile in ambienti ad alto rischio (ad esempio, sistemi di produzione o aree sensibili alla sicurezza).

• L'opzione B introduce un'esposizione precedente al cambiamento. Il codice appare nella PR prima che il piano venga convalidato interamente. Anche se questo codice non può essere unito senza approvazione, può:

  • introdurre modifiche non necessarie o errate che devono essere esaminate e rifiutate

  • aumentare il lavoro del revisore

  • creare un disallineamento temporaneo tra piano e implementazione

In particolare, questo rischio esiste durante la fase della proposta, non dopo l'unione. i meccanismi di imposizione di GitHub impediscono comunque la distribuzione di codice non sicuro.

Quando usare ogni opzione

• Usare il flusso di lavoro Plan-first quando:

  • le modifiche sono ad alto rischio o difficili da invertire

  • l'allineamento sulla finalità è fondamentale prima dell'esecuzione

  • si vuole una separazione rigorosa tra pianificazione e implementazione

• Usare il flusso di lavoro di pianificazione ed esecuzione quando:

  • velocità e iterazione sono più importanti

  • le modifiche sono a basso rischio o facilmente reversibili

  • i revisori hanno familiarità con la valutazione del piano e del codice insieme

Punto chiave

La scelta non è se il lavoro viene esaminato, perché lo è sempre. La scelta è quando il sistema consente la generazione del codice rispetto alla convalida umana e la tempestività con cui si vuole introdurre modifiche nel flusso di lavoro.

Applicazione dei limiti di pianificazione tramite limiti di funzionalità e controllo degli strumenti

1. Limite di funzionalità (gli agenti di pianificazione sono di sola lettura) Un agente di pianificazione deve essere limitato agli strumenti di sola lettura in modo che non possa modificare i file durante la pianificazione.
2. Transizione esplicita (o handoff) a un agente di implementazione. L'esecuzione deve avvenire solo dopo l'approvazione del piano, utilizzando un passaggio intenzionale.
3. Con il controllo dell'uso degli strumenti in ambito di orchestrazioni automatizzate, è possibile forzare l'esecuzione della pianificazione senza l'esecuzione degli strumenti e consentire gli strumenti solo dopo che il piano è stato accettato.
4. Flussi di lavoro in "Modalità piano": alcune interfacce supportano un'esperienza di pianificazione preliminare che genera un artefatto di pianificazione e si sospende prima dell'applicazione di eventuali modifiche.

Indicazioni per le decisioni

• Usare plan-first per il lavoro ad alto rischio (flussi di lavoro, infrastruttura, autenticazione, produzione).

• Usare plan + execution per il lavoro a medio/basso rischio, ma mantenere obbligatori controlli/revisioni.

• Considerare indicazioni le "istruzioni di non modificare"; considerare l'elenco elementi consentiti degli strumenti e i controlli come imposizione.

Punto chiave: La separazione crea un'opportunità per esaminare l'intento prima di accettare l'impatto.

Successivamente, si applicherà la visibilità e la convalida del piano tramite controlli di approvazione delle richieste pull.