Vivere di equilibri nell’era dell’agentic coding

Vivere è, in fondo, vivere di equilibri. Baruch Spinoza, nell’Etica, descrive l’esistenza come un continuo essere attraversati da forze contrarie: affezioni che aumentano la nostra potenza di agire e altre che la diminuiscono, senza un punto d’arrivo in cui posarsi. La libertà, per lui, coincide con la capacità di conoscere le cause che ci muovono e di leggere il gioco delle tensioni in cui siamo immersi. È una pratica costante di lettura del contesto, un esercizio che non si chiude mai.  

In questo articolo  assieme ad Alberto Marsanasco, Chief Innovation Officer di adesso.it, portiamo questo sguardo dentro l’agentic coding. La domanda che chi lavora con gli agenti di sviluppo si sente porre di continuo, "qual è il modo giusto di lavorarci?", ha la stessa forma delle domande che Spinoza smontava nell’Etica: cerca una configurazione stabile là dove esistono solo equilibri momentanei da regolare, invoca una libertà come libero arbitrio da esercitare una volta per tutte là dove la libertà, per come la insegnava lui, comincia dal riconoscere le forze in gioco. Prendendo in prestito il polarity management di Barry Johnson, la distinzione tra problemi che ammettono una soluzione definitiva e polarità che vanno abitate, Alberto ci accompagna dentro le tensioni che attraversano oggi il lavoro di sviluppo AI-augmented, dalla collaborazione tra persone e agenti fino alla scelta tra autonomia e controllo. La vera competenza dell’era agentica, forse, si misura sulla capacità di riconoscere il momento in cui muoversi da un polo all’altro, molto prima che sulla ricerca della ricetta buona per sempre. 

Da quando gli agenti di sviluppo sono entrati nel nostro lavoro quotidiano, la domanda che sento più spesso è: "qual è il modo giusto di lavorarci?". Dietro c’è la ricerca di una configurazione stabile che ci metta al riparo dall’incertezza.   

Ogni settimana arriva un nuovo framework che promette di essere quello definitivo.  

Credo che la domanda sia mal posta. Molte delle scelte che ci troviamo davanti hanno la forma di polarità da gestire, più che di problemi da risolvere.  

La distinzione viene dal lavoro di Barry Johnson sul polarity management. Un problema ha una soluzione: una volta trovata, è chiuso. Una polarità invece è una tensione tra due poli entrambi validi e interdipendenti. Ciascuno porta benefici reali, e ciascuno, se spinto troppo, produce effetti negativi che ci riportano verso il polo opposto. Non si sceglie una volta per tutte: ci si muove tra i due, leggendo il contesto e i bisogni del momento.  

L’agentic coding è pieno di polarità. Eccone alcune che vedo ogni giorno. 

Lavoro individuale ↔ Collaborazione  

Una persona con un buon agente oggi può fare in pochi giorni quello che prima richiedeva un team per settimane. La velocità è impressionante, ma funziona bene su progetti di dimensione contenuta. Quando il perimetro cresce, serve collaborazione: e collaborare nell’era degli agenti significa costruire un layer di conoscenza comune (convenzioni, architettura, decisioni, contesto di dominio) su cui agenti diversi, guidati da persone diverse, possano lavorare in modo coerente.  

Troppo individuale, e ci si ritrova con tante isole veloci ma incompatibili, conoscenza chiusa nelle chat di una sola persona. Troppa collaborazione, e si paga un costo di coordinamento che annulla il vantaggio di velocità che gli agenti ci avevano regalato.  

Specificazione ex ante ↔ Discovery iterativa  

Gli agenti amano specifiche chiare. Un’analisi iniziale solida, data in pasto agli agenti di sviluppo, produce rapidamente risultati sorprendentemente buoni. È una specie di ritorno del waterfall, anche se applicabile a rilasci molto più rapidi. Dall’altra parte, gli agenti sono anche straordinari compagni di scoperta: posso costruire un prototipo, guardarlo, capire cosa mi serve davvero, e far emergere i requisiti in corso d’opera insieme a loro.  

Questo cambia profondamente la discovery. Nel primo caso posso creare loop specifici per l’analisi, e il business si organizza attorno a quel loop: entra all’inizio, definisce, valida. Nel secondo caso devo essere capace di portare il business dentro il flusso agile. E qui c’è la sfida vera: quando lo sviluppo avanza in ore anziché in settimane, una review ogni due settimane non basta più. Il collo di bottiglia si sposta dal codice al feedback.  

Troppo waterfall, e costruiamo velocemente la cosa sbagliata. Troppo agile, e il business non riesce a stare al passo, o gli agenti girano a vuoto su requisiti che potranno cambiare in futuro. 

Orchestrazione di più agenti ↔ Un agente end-to-end  

Posso organizzare più agenti con ruoli precisi (analista, architetto, sviluppatore, tester) che dialogano tramite documenti e partono da una base di conoscenza condivisa. Ottengo specializzazione dei ruoli e ripetibilità del processo. Oppure posso lavorare con un singolo agente che copre tutto il flusso, in dialogo continuo con me: meno struttura, molto più contesto condiviso e adattamento immediato.  

Troppa orchestrazione, e il sistema diventa una burocrazia di documenti in cui il contesto si perde a ogni passaggio. Troppo agente singolo, e tutto dipende dalla persona che lo guida, dalla sua sessione, dalla sua memoria.  

Autonomia ↔ Controllo  

Dare libertà agli agenti significa sfruttarne pienamente il potenziale creativo e muoversi veloci: trovano soluzioni che non avremmo immaginato, senza fermarsi a ogni passo. Il controllo ha due facce. Da un lato guardrail e regole precise, che riducono il non determinismo e rendono il risultato prevedibile. Dall’altro la tracciabilità: sapere chi ha deciso cosa, quale agente ha prodotto quale artefatto, con quale prompt e quale contesto. È ciò che rende possibili governance e audit, e con essi la fiducia. Ma il controllo ha un costo, in tempo, in token, e in parte del vantaggio che ci ha portato a usare gli agenti.  

Troppa autonomia, e ci ritroviamo con output brillanti ma incoerenti, dentro un sistema di cui nessuno sa più spiegare. Troppo controllo, e abbiamo trasformato un collaboratore creativo in un generatore di codice lento e costoso. 

Agente generalista ↔ Agente specializzato  

Come assorbiamo la nostra conoscenza e i nostri standard nel processo di sviluppo agentico?  

Con un agente generalista, tipicamente quello nativo del model provider, la nostra conoscenza vive attorno all'agente: nel contesto che gli diamo, nei workflow in cui lo inseriamo, nell'harness che lo guida. In cambio beneficiamo di un agente che evolve allo stato dell'arte senza bisogno di intervento da parte nostra. Con un agente specializzato, la conoscenza entra dentro l'agente: dai più semplici, poco più che file markdown con istruzioni di ruolo, ai più complessi, con knowledge e tool dedicati. E un agente custom può essere vincolato a un modello preciso, scelto e testato per quel compito: il suo comportamento resta stabile e prevedibile, perché lo decidiamo noi.  

Troppo generalista, e il comportamento dei nostri agenti dipende da scelte che non controlliamo: ogni rilascio del provider può cambiarlo. Troppo specializzato, e quella stabilità diventa immobilità: restiamo legati a un modello che il mercato supera in pochi mesi, e a un'infrastruttura che il prossimo rilascio del provider potrebbe rendere obsoleta.

Se queste sono polarità, allora non esiste la configurazione giusta. Esiste la capacità di riconoscere dove ci troviamo, quali segnali ci dicono che stiamo esagerando da una parte, e quando è il momento di spostarsi.  

Questa capacità non si sviluppa in una persona sola. Il modo migliore per gestire le polarità in un’organizzazione è costruire una learning organization: un luogo dove team diversi possono fare scelte diverse, in contesti diversi, e condividere cosa hanno imparato. Dove “noi qui abbiamo scelto più controllo, ed ecco perché” non è un’eresia rispetto allo standard aziendale, ma un dato prezioso per tutti.  

È così che cresce la maturità: accumulando consapevolezza su come e quando muoversi tra i poli, più che adottando la best practice del momento.