Andrew Ng: agentic workflow e velocità nelle startup AI

Perché la velocità è il predittore che conta

Andrew Ng apre il suo intervento alla AI Startup School di Y Combinator con una tesi netta: tra i fattori che predicono le probabilità di successo di una startup, la velocità di esecuzione è uno dei più forti. La prospettiva nasce da AI Fund, il venture studio che co-fonda in media una startup al mese, scrivendo codice e prendendo decisioni di prodotto e di prezzo accanto agli imprenditori. Da questa posizione operativa Ng osserva un cambiamento continuo nelle pratiche di costruzione, che a suo dire si rinnovano ogni due-tre mesi grazie alla tecnologia AI.

Prima delle leve di velocità, l'intervento inquadra dove si trovano le opportunità nell'AI stack. Alla base ci sono i semiconduttori, poi i cloud e gli hyperscaler, sopra i modelli di base e infine il livello applicativo. Sopra i modelli è emerso nell'ultimo anno un nuovo livello di orchestrazione agentica. I livelli tecnologici attirano hype e copertura mediatica, ma Ng sostiene che le opportunità più grandi stanno quasi per definizione nelle applicazioni: sono le applicazioni a generare i ricavi che pagano i livelli sottostanti.

Idee concrete contro idee vaghe

La prima leva di velocità è lavorare solo su idee concrete. Per Ng un'idea concreta è specificata abbastanza nel dettaglio da permettere a un ingegnere di costruirla. "Usare l'AI per ottimizzare gli asset sanitari" non è concreta: ingegneri diversi costruirebbero cose completamente diverse. "Scrivere software che permetta ai pazienti di prenotare online gli slot della risonanza magnetica per ottimizzarne l'uso" lo è, e si può costruire in fretta. Il punto non è sapere in anticipo se l'idea è buona: con un'idea concreta lo si scopre rapidamente, validandola o smentendola.

L'aspetto ingannevole è che le idee vaghe raccolgono molti complimenti. Quando si è vaghi si ha quasi sempre ragione, ma proprio per questo non si impara nulla; quando si è concreti si può avere torto, e va benissimo, perché lo si verifica molto più in fretta. Trovare buone idee concrete richiede di solito una persona che abbia riflettuto a lungo su un problema. Ng cita la sua esperienza prima di fondare Coursera: anni passati a parlare con gli utenti e ad affinare l'intuizione su cosa rendesse valida una piattaforma edtech. È quel lavoro lungo a costruire il "gut", l'istinto che permette di decidere in modo istantaneo quale funzionalità costruire. Raccogliere dati, ricorda, è spesso un meccanismo lento per decidere; l'istinto di un esperto è spesso più rapido e altrettanto affidabile.

Da qui due indicazioni operative. La prima: in ogni momento si insegue una sola ipotesi chiara, perché una startup non ha le risorse per tentarne dieci insieme. Se i dati smentiscono l'ipotesi, si cambia direzione e si insegue con la stessa determinazione un'altra idea concreta. La seconda: se ogni nuovo dato fa cambiare idea, probabilmente si parte da una base di conoscenza troppo debole, e affidarsi a chi ha studiato il settore più a lungo aiuta a partire meglio.

Agentic workflow e il loop di costruzione

Il modo abituale di usare un LLM è chiedergli di generare un output tutto in una volta, dalla prima all'ultima parola, senza mai tornare indietro: come obbligare una persona a scrivere un saggio in ordine lineare, senza correzioni. Gli agentic workflow rompono questo schema. Si chiede al sistema di scrivere prima una scaletta, poi di fare ricerca sul web se serve, poi una prima bozza, quindi di rileggerla, criticarla e revisionarla, ripetendo il ciclo più volte. È più lento, ma il risultato è molto migliore. Nei progetti di AI Fund, dall'estrazione di documenti di compliance alla diagnosi medica al ragionamento su documenti legali, Ng indica negli agentic workflow la differenza tra qualcosa che funziona e qualcosa che non funziona.

La stessa accelerazione tocca il loop di costruzione del prodotto. Lo schema classico alterna una fase di ingegneria, in cui si costruisce il software, e una fase di product management, in cui si raccoglie il feedback degli utenti, ripetendo il giro fino al product-market fit. Con gli assistenti di coding AI l'ingegneria diventa molto più rapida ed economica. Ng distingue due tipi di software: i prototipi veloci e approssimativi (quick and dirty) per testare un'idea e il codice di produzione da mantenere nel tempo. Sul codice di produzione stima un guadagno dell'ordine del 30-50%, pur ammettendo che dati rigorosi sono difficili da reperire; sui prototipi standalone parla di un'accelerazione di circa 10 volte, e forse molto di più, perché ci sono meno integrazioni con sistemi legacy e requisiti più bassi di affidabilità, scalabilità e sicurezza.

Per i prototipi destinati a girare solo in locale, Ng arriva a dire ai suoi team di scrivere pure codice insicuro per testare in fretta, a patto di renderlo sicuro e scalabile prima di mostrarlo a chiunque all'esterno, perché dati sensibili esposti restano un danno grave. Il costo bassissimo di un proof of concept rende accettabile che molti non arrivino mai in produzione: si possono costruire venti prototipi per vedere cosa funziona. È il "muoversi in fretta ed essere responsabili", la sua riformulazione del vecchio motto che aveva fatto danni.

Codice meno prezioso e tutti che imparano a programmare

Una conseguenza sorprendente è che il codice vale meno di prima come artefatto, proprio perché è meno costoso produrlo. Ng racconta team che hanno ricostruito da zero la stessa codebase tre volte in un mese, cambiando schema dati senza drammi. Riprende la distinzione di Jeff Bezos tra porte a senso unico e porte a doppio senso: scegliere lo stack tecnologico era una porta a senso unico, costosa da invertire, e oggi è molto più reversibile di prima. Il consiglio implicito è ripensare quali decisioni siano davvero irreversibili, perché molte non lo sono più.

Su questa base Ng difende l'idea che imparare a programmare resti utile per tutti. Definisce uno dei peggiori consigli di carriera mai dati l'invito a non imparare a programmare perché tanto lo farà l'AI: storicamente, ogni volta che gli strumenti hanno reso più facile scrivere codice, dalle schede perforate ai linguaggi ad alto livello fino agli assistenti AI, più persone si sono messe a programmare, non meno. Nel suo team anche chi non fa ingegneria sa programmare, e secondo Ng lavora meglio. La competenza chiave del futuro, sostiene, è saper dire a un computer esattamente cosa si vuole: per questo guidare l'AI a scrivere codice resta una via privilegiata, anche senza scrivere il codice di propria mano.

Il collo di bottiglia si sposta sul prodotto

Quando l'ingegneria accelera, il vincolo si sposta a monte: capire cosa costruire. Ng segnala che molti dei suoi team lamentano un collo di bottiglia su product management e design, non più sull'ingegneria. I vecchi rapporti tra product manager e ingegneri, dell'ordine di un PM ogni sei o sette ingegneri, si stanno spostando; un team gli ha proposto per la prima volta un rapporto di un PM ogni mezzo ingegnere, cioè il doppio dei PM rispetto agli ingegneri. Non si sbilancia sulla bontà della proposta, ma la legge come un segnale di direzione, e nota che i PM capaci di programmare e gli ingegneri con istinto di prodotto tendono a cavarsela meglio.

Da qui il valore di un portafoglio di tattiche per ottenere feedback rapido, ordinate dalla più veloce e meno accurata alla più lenta e accurata: guardare il prodotto e affidarsi al proprio istinto, chiedere a tre amici o colleghi, poi a tre-dieci sconosciuti, inviare il prototipo a cento tester, fino all'A/B test, che oggi risulta tra le tattiche più lente del menu. Una nota controintuitiva: il punto dell'A/B test non è solo scegliere tra la versione A e la B, ma sedersi a studiare i dati per affinare l'istinto e fare in futuro decisioni rapide e di qualità.

L'ultima leva è capire l'AI. Su tecnologie mature come il mobile l'intuizione di cosa sia fattibile è ormai diffusa; sull'AI, tecnologia emergente, quella conoscenza è ancora rara, e i team che la padroneggiano hanno un vantaggio reale. Una decisione tecnica giusta su latenza, prompt o fine-tuning può risolvere un problema in pochi giorni, mentre quella sbagliata fa inseguire un vicolo cieco per mesi. A questo si aggiunge la libreria crescente di componenti pronti (i building block) dell'AI generativa, da prompting ed eval a guardrail, RAG, voice e fine-tuning: chi ne conosce di più li combina in modi sempre più ricchi, aumentando in modo combinatorio ciò che può costruire.

In pratica: scegliere idee concrete da validare o scartare in fretta, sfruttare gli assistenti di coding AI per accelerare l'ingegneria, presidiare il feedback di prodotto che diventa il nuovo collo di bottiglia e tenersi aggiornati sull'AI per fare decisioni tecniche che fanno risparmiare mesi.