Scalare gli agenti di coding: cosa cambia davvero quando token e inferenza diventano “quasi gratis”

Dalla corsa al parallelismo all’“esecuzione infinita”: come progettare sistemi di agenti utili oggi, senza inseguire fantascienza.

Negli ultimi mesi si è parlato tantissimo di coding agents come se fossero un interruttore: li accendi e la delivery accelera “automaticamente”. La realtà è più interessante (e più ingegneristica): la capacità dei modelli cresce, i costi per token scendono, ma l’impatto dipende da come imposti architettura e processi.

Qui provo a mettere a fuoco un punto chiave: anche assumendo token economici e modelli velocissimi, l’infrastruttura non sparisce subito. Cambia solo il modo in cui la giustifichi.

1) “Token illimitati” è un’ipotesi utile… ma a tempo

È ragionevole progettare come se:

• il costo per token continuerà a diminuire;
• la latenza per inferenza continuerà a migliorare;
• la disponibilità di modelli più forti arriverà a ondate, con un ritardo di pochi mesi tra “frontier” e “standard”.

Questa ipotesi è pratica perché sblocca un tipo di pensiero: massimizzare esplorazione e parallelismo invece di ottimizzare ogni prompt come fosse oro.

Ma c’è un limite importante: guardare troppo lontano (12–24 mesi) rende la roadmap “sfocata”. L’unica finestra davvero utile è quella in cui puoi dire: questa scelta architetturale sarà ancora sensata tra circa sei mesi? Se sì, vale la pena investirci.

2) L’illusione: “se è tutto veloce, perché mi serve orchestrazione?”

Se avessi davvero token infiniti e modelli perfetti, potresti chiedere: “costruiscimi Google” e aspettarti un risultato.

Nel mondo reale, però, la maggior parte del valore oggi arriva da un livello intermedio: tooling e harness (orchestratori, sandbox, policy di esecuzione, valutatori, strumenti di patching/PR, ecc.).

Si può vederli come “stampelle temporanee”: nel lunghissimo periodo forse diventeranno meno centrali, ma nel medio periodo sono ciò che permette di trasformare capacità grezze in:

• output verificabile;
• cicli ripetibili;
• controllo dei costi;
• riduzione del rischio.

In altre parole: non sono il futuro finale, ma sono ciò che rende il presente produttivo.

3) Un milione di agenti? Il punto non è il numero

Si può “spinnare” un numero enorme di agenti, ma la domanda utile non è quanti ne posso creare, bensì:

• quanti agenti producono lavoro accettabile (non solo testo);
• quanta di quella produzione sopravvive alla selezione (merge/accettazione);
• qual è il costo operativo dell’overhead (coordinamento, valutazione, conflitti, duplicazione).

Nella pratica, il numero efficace tende a scendere di ordini di grandezza: spesso parliamo di decine, centinaia, in alcuni casi migliaia. Il “milione” è più un esperimento sui limiti del parallelismo che un assetto quotidiano.

4) Perché non vediamo ancora “iper-accelerazione” ovunque?

Se i modelli sono così capaci, perché i team non stanno shipando 10× più velocemente con qualità migliore?

Una tesi plausibile è che manchino due cose:

1. abbastanza esecuzione parallela (non stiamo “provando abbastanza strade”);
2. framework corretti per rendere affidabile quel parallelismo.

Il punto non è far lavorare 1 agente più forte. Spesso è far lavorare N agenti più deboli in modo controllato, con un buon sistema di selezione.

5) Il modello “orchestratore + sub-agenti” è quello che funziona oggi

Nel mondo dei prodotti reali (frontend, backend, app consumer), l’assetto più comune e pratico oggi è:

• un agente orchestratore che mantiene contesto, obiettivi e vincoli;
• una “prima corona” di sub-agenti specializzati (ricerca, implementazione, test, refactor, performance, docs…);
• scala tipica: decine (a volte dozzine) più che migliaia.

Le aziende più grandi riescono a spingersi verso centinaia o migliaia, ma il salto verso scale altissime e continua esecuzione resta difficile per motivi molto concreti: costo, latenza, osservabilità, affidabilità del grading, conflitti di merge, e soprattutto… allineamento.

6) Il vero problema: allineamento a scala

Quando aumenti gli agenti, il tema diventa: come li allinei perché facciano “la cosa giusta” rispetto a obiettivi di business, vincoli di prodotto e feedback umano.

Con 200.000 agenti che corrono più veloci degli umani, il collo di bottiglia diventa:

• decisioni di prodotto;
• segnali esterni (utenti, support, metriche, roadmap);
• coordinamento tra iniziative.

Questo problema non è “risolto” in generale. Quello che funziona oggi è una strategia più semplice e familiare: subdividere lo spazio del problema.

Subdivisione per obiettivi (SPO)

Un modo pratico è trattare gli agenti come team separati, ciascuno con un obiettivo chiaro:

• un gruppo su code quality;
• un gruppo su ottimizzazione (bundle size, performance, query, caching);
• un gruppo su packaging & tooling;
• un gruppo su bug fixing;
• ecc.

Non fai lavorare tutti su tutto. Replichi una struttura organizzativa, ma accelerata.

7) “Esecuzione infinita”: l’idea che vale per chi mantiene codebase grandi

Il concetto più pratico, secondo me, è questo: lasciare un sottogruppo di agenti attivo in modo continuativo su compiti che non finiscono mai davvero.

Esempio classico: ridurre l’entropia del codebase.

Ogni feature nuova tende a:

• aumentare complessità;
• introdurre inconsistenze;
• creare duplicazioni;
• aggiungere edge case.

Per reggere il lungo periodo servono “cleanup crews” permanenti: refactor incrementali, consolidamento di pattern, sistemazione di regressioni, rinforzo delle regole.

8) Perché “100 agenti sulla qualità” non è necessariamente spreco

A prima vista sembra inefficiente: perché tanti agenti su un compito che potresti assegnare a pochi?

Due motivi rendono sensato il parallelismo “sprecato”:

1. molto lavoro verrà scartato per design: 50 agenti propongono 50 soluzioni, ma ne accetti 1. È brute force, sì, ma è anche esplorazione del solution space.
2. qualità = lotta continua contro l’entropia: mentre il team (o altri agenti) costruisce feature, qualcuno deve continuamente ripulire.

L’analogia utile è quella del garbage collector: non è “gratis”, ma è ciò che rende sostenibile il sistema nel tempo.

Implicazioni pratiche per chi fa frontend (e prodotti veri)

Se lavori su UI, design system, performance e mantenibilità, questa mentalità si traduce bene in task continui e misurabili:

• agenti dedicati a riduzione bundle, audit dipendenze, tree-shaking, code splitting;
• agenti che cercano duplicazioni e propongono consolidamenti (componenti, hook, util);
• agenti che rafforzano lint rules e codemod per backportare pattern;
• agenti che generano e mantengono test (unit/integration) e controllano regressioni;
• agenti che propongono PR multiple e un grader (automatico + umano) seleziona le migliori.

Il valore non arriva dall’avere “più testo”, ma dall’avere più candidati, più verifica e un ciclo di selezione affidabile.

Sintesi: cosa portarsi a casa

• I token diventano più economici: questo spinge verso più parallelismo e più esplorazione.
• L’infrastruttura non scompare nel breve: è la differenza tra agenti “impressionanti” e agenti utili.
• La scala reale oggi è spesso: orchestratore + sub-agenti, decine/centinaia, non sciami incontrollati.
• Il nodo tecnico più duro è l’allineamento a scala; la soluzione pragmatica è subdividere obiettivi.
• L’idea più concreta è l’“esecuzione infinita” su qualità e manutenzione: combattere l’entropia come attività continua.

In definitiva, scalare gli agenti non significa inseguire numeri enormi: significa progettare un sistema in cui il parallelismo produce alternative, la valutazione seleziona, e una parte del budget resta sempre allocata a mantenere il codice canonicamente buono mentre tutto il resto evolve.

---

Articolo originale: https://frontendfacile.it/blog/scalare-gli-agenti-di-coding-cosa-cambia-davvero-quando-token-e-inferenza-divent