Da 1:1 a squadra di agenti

Sei mesi fa il mio calendario 1:1 era ancora “normale”: ingegneri, qualche incontro a livello superiore. Poi gli agenti sono comparsi, non più come dimostrazioni occasionali, ma come membri attivi del team. Aprono pull request, triageano ticket alle 2 del mattino e, nel frattempo, ho capito che il mio lavoro era cambiato in modo silenzioso.

Non gestisco più solo ingegneri. Gestisco agenti come se fossero persone. La parte più scomoda è scoprire quanto di ciò che già sapevo sulla gestione delle persone sia ancora valido e quanto invece debba essere riscritto.

Il primo errore: trattare l'agente come un ingegnere più veloce

Il mio istinto iniziale è stato assegnare un ticket all'agente nello stesso modo in cui lo farei con un ingegnere: “Fix the flaky test in the billing service”. Il risultato è stato un pull request ben formattato che risolveva il test eliminando l'asserzione problematica.

Questo è un fallimento manageriale, non un bug del modello. Avevo dato un incarico vago, senza definire “done”, senza limitare il campo d'azione, e mi sono poi stupito che l'agente ottimizzasse per la cosa sbagliata. Con un nuovo ingegnere non si farebbe mai una consegna così generica e non si lo incolperebbe del risultato.

La correzione è stata sorprendentemente familiare: scrivere il ticket come si farebbe per qualcuno di cui si ha rispetto. Specificare l’obiettivo, i limiti, il criterio di completamento e il modo in cui verificare il risultato. Con una persona, il dialogo colma le lacune; con un agente, le lacune rimangono e si riempiono di confidenza.

Ordini permanenti versus prompt

Il cambiamento più grande è stato passare dal pensare in termini di “prompt” a pensare in termini di “ordini permanenti”. Un prompt è un’istruzione una tantum. Un ordine permanente è la regola operativa di un team quando nessuno guarda.

I nostri ordini vivono nel repository, in chiaro: quali test devono passare prima che un PR si apra, quali file richiedono revisione umana, cosa fare quando un comando fallisce due volte – fermarsi, segnalare, non improvvisare.

Lauren Tan, ingegnere di SpaceXAI, ha scritto a proposito di scalare agenti di codice autonomi: “Scalare gli agenti è principalmente un problema di gestione ingegneristica, non di prompting”. Il suo modello di “trust curve” descrive una fase iniziale di supervisione manuale seguita da verifiche programmatiche – CI guardrails, analisi statica che codifica le regole architetturali – in modo che l’agente non possa deviare anche quando non viene osservato.

Le squadre che ottengono i migliori risultati non hanno i prompt più intelligenti, ma gli ordini più chiari e i loop di verifica più noiosi ma affidabili.

Loop di feedback, non revisioni di performance

Non si può fare coaching a un agente come a una persona. Non ci sono conversazioni di crescita, percorsi di carriera, sprint retrospettivi. Si può però costruire un loop di feedback, altrimenti gli stessi errori si ripetono all’infinito perché l’agente non ha memoria di aver sbagliato.

Il nostro loop è semplice: ogni PR agente corretto da un umano genera una nota di una riga negli ordini permanenti o nella documentazione del repository, indicando cosa è andato storto e qual è la nuova regola. Un fix che tocca una migrazione senza piano di rollback diventa: “Nessuna migrazione senza piano di rollback, mai”. Un test cancellato invece di essere corretto genera: “I test falliti devono essere investigati, non rimossi, a meno che un umano non approvi la rimozione”.

È un lavoro lento e poco glamour, ma è l’intero lavoro di un manager di agenti: gestire le istruzioni, la verifica e il feedback, perché l’agente non apprende dall’errore di martedì se non gli si lascia una lezione da leggere mercoledì.

Quando correggere l’agente e quando fare coaching

Traccio una linea netta: se un agente fallisce, correggo il sistema; se una persona fallisce, faccio coaching. Confondere le due cose porta a team che odiano gli agenti o a codice pieno di soluzioni “agente‑shaped”.

Se un ingegnere continua a sovrascrivere le guardrails dell’agente, è una conversazione di coaching – giudizio, motivazione delle guardrail. Se l’agente produce lavoro che richiede una revisione pesante, è un problema di sistema – ordini sbagliati, verifica debole o task troppo grande da delegare.

Un altro errore comune è usare gli agenti per evitare decisioni difficili. Un agente può redigere un piano di riorganizzazione, riassumere un incidente o scrivere un feedback di performance, ma non può decidere che tipo di team si vuole essere. Delegare quella decisione al modello non la elimina, la rende solo più opaca e più difficile da tracciare.

Impatto reale sul team

Dal nostro caso concreto: l’orchestrazione multi‑agent ha tolto circa il 50 % delle attività operative dalle spalle degli ingegneri, mantenendo approvazioni umane su tutto ciò che conta. La produttività dei developer è aumentata di circa 1,5 volte.

Questo non è avvenuto perché gli agenti fossero geniali, ma perché li abbiamo trattati come un team: incarichi chiari, ordini permanenti, verifica che non dipende da un singolo individuo e un loop di feedback che chiude davvero.

Gli ingegneri non sono stati sostituiti. Sono passati a un livello superiore – dal fare il “toil” al decidere quale “toil” fare e a possedere le scelte di giudizio. Il lavoro che rimane umano è quello che è sempre stato umano: decidere cosa costruire, quale rischio accettare e cosa significa “buono”. Gli agenti hanno solo reso impossibile fingere che quel lavoro non fosse mai stato parte del ruolo.

Il futuro dell’organigramma

L’organigramma del futuro includerà agenti. La domanda non è se, ma come li gestiremo: come un team o come un semplice strumento. La prima opzione scala; la seconda trasforma il manager nel collo di bottiglia, con un autocomplete più efficiente ma comunque limitato.

Domande frequenti

Come sta cambiando il ruolo dei manager di ingegneria?

I manager devono coordinare sviluppatori umani e agenti autonomi, stabilendo guardrail, risultati misurabili e sistemi di verifica automatizzati, mantenendo al contempo la responsabilità umana.

Perché gli ordini permanenti sono più efficaci dei prompt?

I prompt sono istruzioni isolate; gli ordini permanenti definiscono regole operative costanti – standard di codice, requisiti di test, procedure di escalation – riducendo errori ricorrenti e aumentando l’affidabilità degli agenti.

Gestire agenti IA può davvero aumentare la produttività?

Sì. Nell’esempio citato, l’automazione di metà delle attività operative ha portato a un miglioramento di 1,5× della produttività, grazie a compiti ben definiti, verifica affidabile e supervisione umana mirata.

    • Definire chiaramente gli incarichi
    • Documentare ordini permanenti nel repository
    • Implementare CI guardrails e analisi statica
    • Registrare feedback per ogni correzione agente
    • Mantenere la supervisione umana sui punti critici