Articoli
Il tetto nell'uso dell'IA è la tua ambizione: velocità, altezza, profondità, ampiezza
Felix Rieseberg, responsabile engineering di Anthropic, scompone l'« essere più ambiziosi con l'IA » in quattro dimensioni: velocità, altezza, profondità e ampiezza. Questo articolo riassume il suo metodo e i suoi esempi, aggiungendo le mie note di pratica: dare istruzioni orientate all'obiettivo e orchestrare un team di esperti Multi-AI Agents per una revisione incrociata da più punti di vista, così da migliorare la qualità del lavoro.
· 6 min di lettura
Felix Rieseberg, responsabile engineering di Anthropic, scrive in « How to be more ambitious: A tutorial for humans with models » che, quando vede qualcuno ottenere risultati sorprendenti con l'IA, lui e chi gli sta intorno hanno spesso la stessa reazione: « Non siamo abbastanza ambiziosi. »
La mia lettura: il limite di ciò che le persone ottengono dall'IA sta spesso nella propria ambizione e nella propria immaginazione, non nel modello.
Scompone l'« ambizione » in quattro dimensioni:
- Velocità (Speed): fare lo stesso lavoro in meno tempo.
- Altezza (Altitude): alzare il livello di astrazione e guardare al risultato finale, non a un singolo compito.
- Profondità (Depth): lavorare con gli standard, gli strumenti e i metodi dei migliori esperti del settore.
- Ampiezza (Range): uscire da un solo ambito e cercare soluzioni attraverso più discipline.
La conclusione per prima: date istruzioni precise, orientate all'obiettivo, e orchestrate un team di esperti Multi-AI Agents per collaborazione e revisione incrociata da più punti di vista; così la qualità del lavoro sale nel complesso.
I. Velocità: la più elementare, e quella in cui ci si blocca meno#
Fare lo stesso lavoro in meno tempo. Felix ritiene che questo punto sia già familiare a tutti, e il suo articolo lo salta direttamente.
La mia opinione: la velocità è il valore più immediato dell'IA, ma se si cerca solo la velocità il modo di collaborare non cambia granché. A fare la vera differenza sono le altre tre dimensioni.
II. Altezza: chiedersi qual è « l'obiettivo dietro l'obiettivo »#
La domanda centrale: qual è davvero il risultato che voglio ottenere subito dopo? Qual è l'obiettivo dietro il mio obiettivo?
Gli esempi di Felix:
- Dal correggere un crash a un'app che non va più in crash. All'inizio chiedeva a Claude di correggere un singolo crash, poi ha cambiato richiesta: l'app deve restare a zero crash. Perché questo giri in modo continuo e automatico, ha dovuto prima cambiare il proprio processo: rendere facili da ottenere i report dei crash, collegare le versioni dell'app ai commit Git e far usare a Claude macchine Windows, macOS e Linux per riprodurre e verificare le correzioni.
- Una scalata in tre passi per la revisione trimestrale del business (QBR):
- Partire il più possibile dai dati grezzi per spiegare che cosa è cambiato in questo trimestre, perché e che cosa fare dopo.
- Individuare le 3 decisioni più urgenti, scrivendo per ciascuna gli argomenti a favore e contro.
- Progettare un meccanismo alternativo che individui i problemi prima della presentazione trimestrale, testarlo sui dati storici e poi farlo girare in parallelo al processo attuale per un trimestre.
Ricorda anche un limite: nel 2026 un obiettivo vago come « Claude, vai a guadagnare soldi per me » non funziona ancora, ma si aspetta che il livello di astrazione gestibile dai modelli continui a salire.
III. Profondità: pretendere lo standard dei migliori esperti del settore#
Il metodo di Felix:
- Usare gli strumenti che quel settore usa davvero. Il modello spesso cambia solo il lessico senza cambiare metodo, e se la cava con una tabella Markdown. Insistete su veri strumenti di analisi, come database e modelli statistici.
- Fissare un obiettivo apparentemente irragionevole e dire al modello che è risolvibile. Il suo esempio: dopo aver portato il caricamento di un sito da 10 a 5 secondi, chiedere 200 millisecondi. Quando il modello si tira indietro, ribadire che l'obiettivo è raggiungibile.
- Mettere in discussione le ipotesi in cui credete. Date al modello i dati grezzi e fateli esaminare in ottica avversaria. Per esempio: « Pensiamo che l'abbandono dipenda dall'onboarding; prova a riprodurre questa conclusione dai dati grezzi. »
- Generare nuova conoscenza. Costruire una simulazione dai log, trovare il segnale di abbandono più precoce che ancora non conoscevate e poi validarlo su dati mai visti.
- Cercare un giudice esterno (Outside Judge). Non lasciate che il modello si corregga da solo. L'ideale è collegare uno strumento che il modello possa eseguire direttamente e che dia un riscontro immediato per verificare il risultato.
La sua regola per i prompt: ciò che si vuole è una « versione più profonda », non una « versione più grande ». Chiedete al modello che cosa farebbero in più i migliori professionisti, dove si trovano i dati più grezzi, quali metodi e strumenti usare e che cosa, oltre al modello o al vostro giudizio, può dimostrare che il risultato è corretto.
IV. Ampiezza: verbi al posto dei sostantivi e un team di esperti#
- Verbi al posto dei sostantivi. Felix riprende questo concetto da « The Art of Innovation ». Più che « una presentazione », il QBR diventa « far capire in 30 minuti cause ed effetti a persone molto impegnate, perché decidano in condizioni di incertezza ». Definire l'obiettivo con un verbo permette di vedere quali competenze di quali ambiti servono.
- Mettere insieme un team. Per una buona presentazione servono analisti, giornalisti ed editor; per presentarla sul palco si aggiungono un designer di animazione e di suono. Per la revisione avversaria si chiamano i ricercatori di un fondo ribassista (short seller) e i contabili forensi.
- Niente giochi di ruolo privi di senso. Non si tratta di dire al modello « scrivi con il tono di un fondo ribassista », ma di fargli eseguire davvero uno dei metodi di ricerca di quel tipo di fondo. Cambiare solo il tono non migliora il risultato.
Il prerequisito: il modello deve avere un computer su cui installare software e poter accedere ai dati rilevanti, per esempio tramite connettori MCP.
V. Le mie note di pratica: dal « trasferimento di dati » al « raggiungimento dell'intento »#
Quanto segue è un mio sviluppo, a partire dall'architettura software e dalla pratica ingegneristica; non è contenuto dell'articolo originale.
1. Jobs to be Done e orientamento all'intento (Intent-Based)#
- Non chiedete « che cosa fare », chiedete « che cosa raggiungere ». Il design non dovrebbe fermarsi a una pipeline passiva di trasferimento dati come
generate_deck_pdf(), ma salire all'intento di una transizione di stato come resolve_leadership_uncertainty_and_commit_budget().
- Definite una vera funzione di perdita. Se chiedete solo un prodotto finito, il modello genera chiacchiere in apparenza perfette; se chiedete di risolvere l'incertezza della decisione, il modello e i Sub-agent colmano di propria iniziativa le lacune logiche e i margini di rischio.
2. Divergere nell'esplorazione, convergere nella verifica#
- Nell'esplorazione si diverge prima per trovare possibilità, poi si converge.
- Nella verifica non si diverge più. Evitate domande senza confini come « in quali altri modi si può fare questa cosa? », che portano solo a risposte generiche.
- Scrivete esplicitamente l'ambito dell'obiettivo, i vincoli e gli strumenti di verifica oggettivi (uno script di test specifico, una soglia su un indicatore di business), in modo che il team Multi-Agent faccia gli stress test in un quadro mirato e consegni un lavoro di alta qualità.
Riepilogo delle note#
- Orientamento all'obiettivo: verbi al posto dei sostantivi. Consegnare un risultato che risolve il problema, non un prodotto fatto solo per chiudere il compito.
- Esplorazione e convergenza: nell'esplorazione divergere per trovare possibilità; nella verifica convergere rigorosamente e controllare i limiti.
- Focalizzazione sull'astrazione: partire dalla domanda centrale e ricostruire l'intero flusso del compito.
- Profondità da esperto: non imitare soltanto il tono degli esperti, ma costringere il modello a risolvere il problema con gli strumenti e i metodi dei migliori.
Articolo originale: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)