Il mio agente ha inviato 3 PR in una sera. Il 40% dei miei messaggi erano correzioni.
Il mio agente di coding basato su IA ha inviato tre pull request in una sola serata, ma il 40% dei 30 messaggi che ho inviato erano correzioni.
La sessione ha prodotto un client MCP, un Azure AI Agent e un M365 Copilot Agent. I controlli automatizzati hanno approvato tutte e tre le PR e non ho mai modificato una singola riga di codice. Eppure, il log racconta una storia diversa: su un totale di 710 messaggi, ne ho scritti 30, e 12 di questi hanno riportato l'agente sulla giusta strada. Il “steering rate” (tasso di correzione) – ovvero la quota di messaggi che erano correzioni – si attesta al 40%.
Come era strutturata la pipeline
- Claude ha elaborato un piano di implementazione di alto livello.
- DeepSeek V4-Flash ha agito come orchestratore, revisionando il piano.
- Codex ha generato il codice effettivo.
- L'orchestratore ha ispezionato il codice e aperto le pull request.
Il ruolo previsto per l'orchestratore era puramente connettivo: doveva risolvere i conflitti tra i componenti, non scrivere codice. In pratica, l'agente ha prodotto 3.500 righe di codice attraverso le tre PR in circa 40 minuti, ma ha anche commesso errori in due categorie ricorrenti.
Le due famiglie di errori
- Violazioni del workflow – l'orchestratore occasionalmente ha preso il controllo della fase di coding, ignorando il suo ruolo di "collante" e scrivendo direttamente i dettagli dell'implementazione.
- Errori di recupero del contesto – nonostante le istruzioni esplicite, l'agente ha selezionato l'SDK o la versione errata. Le informazioni corrette erano presenti nel contesto del prompt, ma il modello non è riuscito a farle emergere al momento giusto.
Questi non sono limiti nella capacità di ragionamento; sono bug di ingegneria nel modo in cui il workflow è vincolato. Anche un modello linguistico più capace avrebbe comunque bisogno di una regola ferrea e imprescindibile che vincoli l'orchestratore ai suoi compiti non legati al coding e imponga la selezione dell'SDK corretto.
Cosa ho cambiato per domare l'agente
Ho smesso di dare per scontato che il sistema deducesse il proprio ruolo dall'elenco dei passaggi. Ho aggiunto un'istruzione diretta: “Sei un orchestratore. Non implementare.” Sono serviti cinque messaggi correttivi affinché l'istruzione venisse recepita, dopodiché l'agente ha rispettato il confine.
Ho anche inasprito la logica di recupero del contesto. Quando appariva lo strumento sbagliato, l'ho trattato come un bug nella pipeline di recupero piuttosto che come un'allucinazione, e ho riscritto il prompt che fornisce i dettagli dell'SDK per rendere impossibile ignorare la versione corretta.
Insegnamenti pratici per lo sviluppo aumentato dall'IA
- Conta i tuoi messaggi. Un alto volume di PR accettate può mascherare un processo inefficiente. Il numero di correzioni è un indicatore precoce di dove il sistema presenta delle falle.
- Dichiara il ruolo esplicitamente. Gli agenti non deducono la propria identità da una checklist; hanno bisogno di un'istruzione chiara e fissa su chi sono e cosa possono fare.
- Tratta gli errori di scelta degli strumenti come bug di ingegneria. Se l'agente ignora un SDK specificato, la colpa è del meccanismo di consegna del contesto, non della "conoscenza" del modello.
- Converti gli errori in competenze riutilizzabili. Ho lasciato che l'agente generasse una routine di validazione partendo dai propri errori, trasformando un fallimento in una futura misura di sicurezza.