Sulle spalle dei giganti

"Se ho visto più lontano, è perché stavo sulle spalle di giganti."

La frase è di Isaac Newton, da una lettera a Robert Hooke del 5 febbraio 1675. Due dettagli la rendono più interessante di come la usiamo di solito.

Il primo: non è sua. Girava già nel Medioevo. Giovanni di Salisbury, nel Metalogicon del 1159, la attribuisce al suo maestro Bernardo di Chartres, e la versione originale è parecchio meno lusinghiera per noi: siamo nani seduti sulle spalle di giganti, e vediamo più lontano non per acutezza di vista o per statura, ma perché ci porta in alto chi ci regge.

Il secondo: diversi storici sospettano che Newton la usasse con ironia. Hooke era di corporatura minuta, e i due litigavano da anni.

Mi tengo la versione scomoda, quella di Bernardo: il merito non è della vista, è di quello che ti sta sotto.

È esattamente quello che è successo al mio modo di lavorare negli ultimi mesi, e lo racconto perché credo stia cambiando per tutti, non solo per me.

Come si partiva prima

Per costruire un palazzo servono buone fondamenta. Vero. Ma per anni questo ha voluto dire una cosa precisa: prima di scrivere una riga, mettere giù tutto il piano.

Architettura. Livello applicativo. Piano di lavoro. Vincoli. Partner. Stakeholder. Costi ricorrenti. Risorse.

Non era burocrazia, era necessario. Ogni progetto nuovo ripartiva da zero, quindi ogni progetto nuovo doveva rispondere daccapo alle stesse domande: dove gira, chi ci accede, quanto costa al mese, cosa succede se cade. Settimane prima di vedere la prima schermata, e quando la vedevi era brutta.

Adesso lavoro in un altro modo. Le fondamenta le ho fatte una volta sola.

Le fondamenta si fanno una volta, e sono generiche

Il mio stack sta su server Hetzner, collegati a VS Code: lavoro da dove sono, con la stessa macchina sotto, che sia il portatile in ufficio o un terminale in viaggio. Sopra girano i mattoni, tutti in container: Postgres per i dati strutturati, Qdrant per la memoria semantica dei chatbot, Redis per code e cache, un nginx unico davanti a tutto, un browser headless per verificare davvero quello che gli agenti producono, i backup notturni.

Poi c'è la parte che conta di più e che non si vede: un varco unico per i modelli. Tutte le chiamate passano da lì, ogni consumatore ha la sua chiave e il suo tetto mensile, e quando il tetto è finito la porta si chiude da sola invece di avvisarmi il giorno dopo. Sopra ancora: i permessi per persona e per sito, le regole di sicurezza, quali modelli si usano e per cosa, come si tracciano i costi.

E infine gli agenti, con due primitivi tenuti separati. L'agente è un chi: ha un ruolo, obiettivi, un livello di autonomia (il mio board è CEO, CMO, CTO, COO, CFO, CISO, più gli specialisti sotto). La skill è un cosa: una capacità riusabile e documentata che più agenti possono invocare, scrivere una newsletter, generare un video, analizzare le keyword, pubblicare una pagina. Quando nasce una capacità nuova diventa una skill a catalogo, non uno script dimenticato in una cartella.

La parte difficile di tutto questo non è tecnica. È astrarre senza svuotare: abbastanza generico da servire a qualsiasi progetto, abbastanza concreto da essere usabile domani mattina. Ogni volta che ho scritto una regola pensando a un progetto specifico, l'ho pagata al progetto dopo.

Una cosa che ho scoperto solo dopo: questa roba ha un nome, e non l'ho inventata io. Nel mondo enterprise si chiama internal developer platform, e le strade già pronte che ci passano sopra si chiamano golden path. La ricerca DORA dice due cose che ho ritrovato identiche in casa mia. La prima: l'AI è un amplificatore, moltiplica i punti di forza di un'organizzazione e insieme le sue disfunzioni. La seconda: una piattaforma interna di qualità è quello che decide se l'adozione dell'AI produce risultati o solo movimento.

Il cuore: una kanban dove lavorano gli agenti e l'umano

Se devo indicare il pezzo che ha cambiato più di tutti il mio modo di lavorare, non è un modello e non è un server. È una kanban.

Ogni decisione e ogni attività è una card: owner, priorità, scadenza, allegati, link, card collegate. E due campi che sembrano dettagli e non lo sono:

• chi la esegue: un agente oppure una persona
• fatto quando: la condizione osservabile che dice che è finita

Gli agenti fanno un giro ogni ora, sette giorni su sette. Ognuno guarda le proprie card e, se c'è tutto quello che serve, la lavora e scrive cosa ha fatto. Se manca qualcosa la card passa in feedback request e la domanda arriva a me. Quello che viene chiuso finisce nel diario degli interventi e nel report del lunedì, quindi il lunedì mattina non chiedo a nessuno a che punto siamo: lo leggo.

La regola che mi ha sorpreso di più è quella del fatto quando. Se non so dire quando una cosa è finita, non è una card: è un'idea, e sta in un altro elenco. Non l'ho messa per gli agenti. L'ho messa per me, e mi ha tolto di mezzo mesi di lavoro vago.

Qualche numero vero, dal 3 luglio a oggi:

• 193 card, di cui 124 chiuse e 38 annullate
• 123 con un agente che le esegue, 70 con una persona
• negli ultimi 30 giorni: 103 card nuove e 99 chiuse
• 156 esecuzioni di agenti, 142 andate a buon fine, 12 fallite

Il numero che mi interessa di più è quello delle 38 annullate. Una card annullata vuol dire che l'ho aperta, l'ho vagliata e ho deciso di non farla. Prima quella stessa decisione la prendevo senza accorgermene, semplicemente non facendo le cose.

Da idea a MVP in poche ore

Con le fondamenta ferme, quello che viene dopo ha una velocità che ancora mi stupisce.

Faccio partire un progetto nuovo e nasce già con le cartelle coerenti, lo stack approvato, i permessi impostati, il varco dei modelli configurato, le sue card. Non devo decidere dove gira, come si autentica, chi lo vede, quanto può spendere: è deciso una volta per tutte.

Quindi mi resta da pensare solo a quello che voglio davvero. Il contenuto. Il risultato. Le funzionalità. Il modo di lavorare che quel progetto deve abilitare. Non l'architettura, non la grafica, non la UI.

Da idea a MVP interno passano minuti, a volte poche ore. E per MVP intendo una cosa che gira davvero, non un disegno.

Poi chiamo i giganti

Quando l'MVP interno è validato e funziona, comincia la parte che preferisco.

Chiamo un modello di ragionamento e gli chiedo di andare a vedere come lo fanno i migliori. Non genericamente: i riferimenti veri di mercato per quel tipo di strumento, che sia un CRM, una piattaforma di email marketing, un pannello operativo, una landing page. Per ognuno i punti di forza. La UI e la UX, guardate davvero. Poi prendere il meglio di ognuno, togliere il superfluo, e confezionare un backend compatibile con la mia struttura e con la mia dimensione, più un frontend leggero e moderno costruito su quello che ha raccolto.

I guardrail li metto io, e sono la parte che non si negozia: vincoli di sicurezza, vincoli economici, il brand kit, i numeri reali del mio caso. Poi lo lascio lavorare per diversi minuti.

Parte una specie di gara: fare meglio degli altri.

Ho un MVP interno che funziona e voglio portarlo a livello di prodotto.

Cosa fa oggi: [due righe, più screenshot o indirizzo].
Chi lo usa: [chi, quante persone, con che frequenza].
Dimensione reale: [numeri veri: righe, utenti, volumi al mese].

Prima di toccare qualsiasi cosa, guarda come lo fanno i migliori.
1. Trova quattro prodotti di riferimento per questo tipo di strumento, vivi e usati davvero. Per ognuno: cosa risolve meglio degli altri e come si vede nell'interfaccia.
2. Guarda le loro schermate e descrivi le scelte concrete: cosa sta in cima, cosa si vede senza cercare, quante azioni servono per il lavoro principale, come mostrano gli stati.
3. Dimmi cosa prenderei da ognuno e soprattutto cosa NON prenderei, perché è peso che serve alla loro dimensione e non alla mia.

Poi fermati: la selezione la approvo io.

Quando il primo giro è pigro

Capita spesso: il primo giro è al risparmio, una pagina che funziona e basta.

La mia mossa era alzare la posta. "Sei il miglior specialista della migliore società di consulenza, confezionami un deliverable all'altezza." E funziona: in due o tre giri esce un'interfaccia che mi piace, senza che io abbia inventato niente, prendendo spunto dai migliori. Vale anche per report e analisi.

Poi sono andato a vedere se funziona per il motivo che credevo, e la risposta è no.

Uno studio presentato a EMNLP nel 2024 ha provato 162 ruoli diversi su 2.410 domande fattuali e quattro famiglie di modelli. Risultato: aggiungere una persona nel prompt non migliora l'accuratezza rispetto a non metterla, e sceglierne una adatta non dà un vantaggio stabile rispetto a sceglierne una a caso.

Allora perché il mio consulente immaginario funziona? Perché insieme al ruolo, senza accorgermene, passo altre tre cose:

1. un metro di paragone concreto: quel nome evoca deliverable che il modello ha visto, con una certa densità, una struttura, un livello di finitura
2. uno standard di consegna: non "fammi un'analisi", ma "una cosa che si possa mettere davanti a un cliente"
3. un'insoddisfazione dichiarata: gli sto dicendo che il giro prima non andava bene, e in cosa

Sono quelle tre cose a lavorare, non il nome dell'azienda. Ed è una buona notizia, perché si possono dire meglio e senza travestimenti. È lo stesso meccanismo che avevo raccontato parlando del Gauntlet Loop: un agente migliora quando ha un riferimento reale con cui confrontarsi, non quando gli dici di impegnarsi.

Il giro precedente è sotto il livello che mi serve, e ti dico dove: [una o due mancanze precise].

Non voglio un ruolo, voglio uno standard di consegna:
- il risultato deve reggere accanto a [prodotto o documento di riferimento], aperto qui di fianco
- niente da spiegare a voce: chi lo apre capisce in dieci secondi cosa può fare
- ogni numero mostrato viene da un dato vero, e se un dato manca si dichiara che manca
- [vincolo di sicurezza] e [vincolo economico] restano non negoziabili

Rifallo con questo metro. Alla fine dimmi in tre righe dove sei ancora sotto il riferimento, senza addolcire.

Cosa non torna, e va detto

Se ci fermassimo qui, la conclusione sarebbe che l'AI rende tutti più veloci. I dati dicono una cosa più sottile.

Nel 2025 METR ha fatto una prova controllata su 16 sviluppatori esperti, 246 attività vere sui loro stessi repository. Con gli strumenti AI hanno impiegato il 19% di tempo in più. Il dettaglio che mi interessa davvero: gli stessi sviluppatori erano convinti di essere andati il 20% più veloci. Quasi 40 punti di differenza tra la sensazione e il cronometro.

Perché è andata così? Perché lavoravano su codice che conoscevano a memoria, in progetti maturi, senza nessuna piattaforma attorno che rendesse verificabile il lavoro della macchina. Il tempo se n'è andato in revisione e correzione.

È il messaggio della ricerca DORA, letto al contrario: l'AI amplifica quello che trova. Se trova fondamenta solide moltiplica; se trova disordine, moltiplica quello. E i guadagni di velocità nella scrittura si perdono quasi sempre più a valle, nelle verifiche, nella sicurezza, nel rilascio.

Quindi la frase onesta non è "vado dieci volte più veloce". È: la fatica si è spostata. Prima stava nel progettare e nello scrivere, adesso sta nel governare, nel verificare e nel decidere cosa non fare. Le 38 card annullate sono lì a dirlo.

C'è un secondo limite, e riguarda proprio il prendere il meglio dai migliori. Se prendi il meglio da tutti rischi un prodotto senza punto di vista: ragionevole e completamente anonimo. La regola che mi sono dato è che si copiano le convenzioni, mai l'identità. Dove sta il pulsante di salvataggio, come si mostra uno stato, quante azioni servono per il lavoro principale: quelle sono convenzioni, e andare contro le convenzioni non è creatività, è attrito per chi usa. Il tono, il colore, il nome, la cosa che il tuo prodotto fa diversamente da tutti: quelle restano tue. In ogni progetto tengo almeno una differenza voluta, altrimenti sto solo facendo una copia educata.

E aggiungo l'ovvio, che ovvio non è: i riferimenti si guardano, non si scaricano. Prendere layout, testi o grafica di un prodotto vivo non è ispirarsi, ed è un problema legale prima ancora che di gusto.

Il post scriptum che vale più dell'articolo

C'è un gesto che tiene in piedi tutto il sistema, ed è il più noioso di tutti.

A ogni progetto finito aggiorno le regole dell'azienda: modalità operative, stack applicativo, scelte di interfaccia, permessi, cosa è andato storto e come si evita la prossima volta. Se salti questo passo le fondamenta restano ferme, e ogni progetto nuovo ripaga la stessa tassa.

Ed è qui che la metafora di Bernardo si chiude. I giganti su cui sto seduto sono due. Ci sono i prodotti degli altri, che guardo per non reinventare quello che il mondo ha già capito. E ci sono le fondamenta che mi sono costruito, che crescono ogni volta che ci scrivo sopra una regola in più.

Del primo gigante non decido l'altezza. Del secondo sì.

La cosa che mi piace di più, alla fine, non è nemmeno la velocità. È che libera la testa: se non devo più pensare a dove gira, a come si autentica e a che colore ha il pulsante, mi resta tutto lo spazio per la parte che mi diverte, cioè decidere cosa costruire e perché.

E tu, quante volte hai ricominciato da zero le stesse fondamenta senza accorgertene?