Stai inseguendo i tool. La competenza sta sotto.

Quasi tutti i giorni scrivo codice con due modelli diversi, e passo dall'uno all'altro senza troppe cerimonie. Uno è veloce, e lo prendo quando il lavoro è meccanico e voglio che il loop sembri un'estensione delle mie mani. L'altro è più lento e arriva più lontano, e lo chiamo in causa quando il problema ha davvero bisogno di ragionamento. Ecco la parte che ho impiegato un po' ad ammettere. Il cambio non cambia quasi nulla del lavoro. La specifica che scrivo è la stessa. Il modo in cui scompongo il problema è lo stesso. La review alla fine è la stessa. Cambio il motore e tengo tutto quello che ci ho costruito intorno.

La domanda è un sondaggio

La domanda che mi fanno, e quella che vedo ovunque, è quale sia il tool migliore. Quale modello, quale agente, quale editor. Suona tecnica. In realtà è un sondaggio. Migliore in cosa, per chi, con quali vincoli, su quale codebase? Togli queste cose e non resta nessuna risposta, solo gusto, e il gusto non è conoscenza. E qualunque risposta trovassi sarebbe già vecchia alla release successiva. Avresti speso fatica vera per produrre un fatto che scade nel giro di settimane.

Stai ottimizzando la parte del sistema che cambia di più e conta di meno. Ci sono tre livelli in gioco. Il modello, che è quello su cui si litiga, e che puoi sostituire in un giorno. L'harness che gli sta intorno, il prodotto che compri davvero: come gestisce il context, se sa leggere la tua codebase, eseguire i tuoi test e riprendersi quando si rompe. E il loop che ci fai girare dentro, le specs e la review, che è tuo e ti segue ovunque. Per il lavoro di tutti i giorni i modelli di frontiera sono abbastanza vicini che scegliere tra loro è come lanciare una moneta; quello che resta è veloce contro profondo, ed è una scelta che fai task per task, non una classifica. La domanda sul tool si fissa sul primo livello e a malapena nomina gli altri due, e sono gli altri due a decidere il risultato.

Stesso tool, due mani

Metti lo stesso tool in mano a due sviluppatori e ottieni due risultati diversi. Uno specifica il problema, legge l'output, becca il punto in cui ha sbagliato e lo corregge. L'altro accetta qualunque cosa esca. Tieni fermo il tool e i risultati divergono. Tieni ferma la persona, io lo faccio ogni volta che cambio modello, e non si muove quasi nulla. Quell'asimmetria ti dice dove mettere l'attenzione.

C'è anche un costo nel saltare da un tool all'altro, e si paga proprio in quell'attenzione. Ogni cambio azzera qualcosa. Reimpari le stranezze e riscrivi le tue istruzioni, e il guadagno è piccolo e non dura. Intanto la cosa che si accumula nel tempo resta lì intoccata, perché tu eri impegnato a fare shopping. Lo sviluppatore che sceglie un tool abbastanza buono e va in profondità sul loop supera quello che sta sempre migrando.

Dove il tool conta davvero

Niente di tutto questo significa che il tool non sia niente, e la versione pigra di questo argomento finge che lo sia. La categoria conta parecchio. Un autocomplete che ti finisce la riga, un agente da terminale che modifica un intero repo e apre una pull request, e un runner che punti su un task e lasci andare sono strumenti diversi, e trattarli come intercambiabili è il modo in cui la gente finisce delusa.

Sui problemi più difficili, quelli che non entrano comodi in un benchmark, la differenza tra un setup forte e uno debole è se riesci a shippare oppure no, e gran parte di quella differenza sta nell'harness e nel loop, non nel nome del modello. Se il tuo lavoro vive su una sola piattaforma, il tool nativo di quella piattaforma può vincere solo per l'integrazione. Anche la velocità di cui parlavo è una differenza reale, non una questione di gusto; parte della competenza è sapere quando un task ha bisogno del modello veloce e quando di quello lento.

"Impara i fondamentali e basta" è una risposta vuota a modo suo, quando significa ignora i tool. I tool amplificano i fondamentali. È per questo che i fondamentali rendono, e non è un permesso per ignorare con cosa stai amplificando.

E poi c'è il conto

Il punto in cui il tool conta di più non ha niente a che fare con quale modello sia il più intelligente. È il pricing. Per molto tempo ho vissuto su un tool che faceva pagare un prezzo fisso, e ci andavo giù pesante, tutto il giorno, tutti i giorni, e il conto non si muoveva mai. Sapevo esattamente quanto costava un mese. Poi il pricing mi è cambiato sotto i piedi, da fisso a consumo, e lo stesso lavoro che avevo sempre fatto ha iniziato a sommarsi fino a superare i mille euro in una sola settimana. Non era cambiato niente della mia competenza o del mio loop, solo il contatore.

Un cambio di prezzo è una ragione vera per cambiare, ed è l'opposto di inseguire la novità. Sono passato a un tool con un tetto prevedibile, che fa girare gli stessi modelli che già preferivo, e il mio conto è tornato a una cifra su cui potevo fare i piani. Ogni tanto sbatto contro un limite. Le settimane da mille euro non mi mancano. I tool che ho lasciato fanno ancora pagare un sovrapprezzo esattamente per i modelli che voglio, che è un ottimo affare per loro e un pessimo affare per me.

Chiunque abbia fatto girare qualcosa nel cloud ha già visto entrambe le metà di questa storia. Il conto che diventa a consumo e poi ti sorprende. La capacità su cui non puoi contare fino in fondo: l'istanza che non parte nella tua region, il limite che colpisci esattamente nell'ora sbagliata. Il cloud ha passato un decennio a insegnare agli ingegneri a tenere d'occhio il contatore, a mettere un tetto dove si può, e a non legarsi mai a un provider così stretti che andarsene significhi riscrivere tutto. I tool di AI sono all'inizio della stessa storia, e la lezione si trasferisce pari pari.

Quindi quando qualcuno ti dice che il tool non conta, questa è la parte che sta lasciando fuori. L'intelligenza converge e l'harness conta, ma le condizioni del contratto possono contare più di entrambi. Non solo il prezzo e la capacità, ma la licenza che ti cambia sotto i piedi, e la privacy policy che inizia a leggere il tuo codice dentro il training set del prossimo modello. Sono leve che un vendor può tirare da un giorno all'altro senza toccare una riga del tuo codice, e ognuna di queste leve è stata tirata su qualcuno negli ultimi anni. È questo il vero argomento per tenere il tuo loop portabile. Non per inseguire una leaderboard, ma perché il giorno in cui le condizioni cambiano, tu possa alzarti e andartene.

La versione buona della domanda

La versione buona della domanda sul tool ha una risposta, perché nomina i suoi vincoli. Il migliore per i grandi refactor che devono stare in un solo context. Il migliore con un budget mensile fisso. Il migliore per codice che non può uscire dalle nostre macchine. Il migliore nel linguaggio in cui lavoriamo davvero. Queste hanno risposte. "Qual è il miglior tool di AI per scrivere codice" no, perché non dice mai migliore in cosa. Quindi scomponila, e cambia di proposito invece che d'impulso: quando hai dato un nome a una capacità che ti manca e hai fatto un confronto ad armi pari. Tieni anche un po' di tempo per l'esplorazione, guardando cosa adottano davvero le persone di cui ti fidi, perché a volte il cambio che conta di più è verso una categoria che non sapevi esistesse.

Ho scelto il mio setup così e poi ho più o meno smesso di pensarci. Le istruzioni di progetto, le specs e le abitudini di review si trasferiscono tutte; cambia solo il modello sotto, a seconda del task. Gli strumenti che ho costruito vanno nella stessa direzione: una pipeline che trasforma una frase in un piano e apre le sue pull request da sola, un control plane che governa flotte di agenti. A nessuno di loro importa quale modello ci sia dietro. Sono impalcature intorno allo stesso loop.

E la cosa va oltre i miei strumenti, perché la maggior parte di quello che sembra un nuovo prodotto AI è costruita su modelli di frontiera che chiunque può affittare. Ho contribuito a costruire prodotti che fanno lavoro serio nel diritto, nella sanità, nella ricerca scientifica e nell'auditing, e nessuno di loro gira su un motore segreto. Dentro c'è una pipeline: diversi passaggi con le loro dipendenze, spesso modelli diversi in passaggi diversi per ragioni diverse, uno veloce dove il vincolo è la latenza, uno profondo dove il vincolo è il ragionamento, la stessa divisione che faccio alla mia scrivania. Ma ogni modello nella catena viene dallo stesso menù corto da cui ordinano anche i concorrenti. Quello che rende questi prodotti degni di essere pagati è tutto ciò che sta intorno ai modelli: il retrieval sulle fonti che contano davvero, il grounding che tiene una risposta ancorata a quelle fonti, il workflow modellato su come la professione lavora davvero. I modelli non sono il moat di nessuno. Il valore si accumula intorno a loro, non dentro di loro, ed è la stessa lezione a un'altra quota.

Quello che ti resta davvero

Quindi insegui pure un tool per una settimana, se vuoi, e poi diventa bravo. Il modello che usi verrà sostituito da uno davvero migliore con tempi che non controlli, e comunque non salverà lo sviluppatore che non ha mai imparato a specificare o a leggere. Il modo in cui ragioni su un problema e l'occhio che becca la riga sbagliata restano tuoi a ogni cambio. Uno dei due vale la pena di costruirlo. L'altro merita una settimana della tua attenzione, e una via d'uscita che tieni aperta.