Lettera "Dear friends" di Andrew Ng su *The Batch* (DeepLearning.AI, numero 359) sul **loop engineering** applicato allo sviluppo di prodotto **0-to-1**. Ng condivide i suoi **3 loop chiave** — loop di coding agentico (~minuti), loop di feedback dello sviluppatore (~ore), loop di feedback esterno (~giorni) — annidati per scala temporale crescente, collegando *coding agent → product spec/evals → visione dello sviluppatore → feedback esterno*. Tesi centrale: gli esseri umani mantengono un **vantaggio di contesto** (piuttosto che un "gusto") che rende indispensabile l'human-in-the-loop; gli ingegneri assumono un ruolo parziale di product management. Dominio: coding agent, product engineering, metodologia agentica.
#Loop engineering#sviluppo di prodotto#loop di coding agentico
Saggio lungo di **Shubham Saboo** (X/Twitter) che sostiene una tesi sul ruolo del Product Manager nell'era degli agenti: la prossima competenza chiave **non è il prompt engineering** ma il **Loop Engineering** — progettare un *sistema che migliora a ogni esecuzione* anziché scrivere il prompt perfetto ogni volta. Un **loop** è un ciclo ripetuto: modificare ciò che modella il comportamento dell'agente → eseguirlo → valutare l'output → mantenere la modifica se la qualità aumenta, altrimenti annullarla → **capitalizzare l'apprendimento** in modo che la versione successiva parta avvantaggiata. Per un PM, il punto d'ingresso non è il codice ma gli **artefatti durevoli** che codificano il suo giudizio: skill di PRD-review, *summarizer* di chiamate con i clienti, griglia di valutazione, checklist di lancio, workflow di ricerca, `CLAUDE.md`, template di prompt, framework di prioritizzazione. Poiché vengono riutilizzati, questi artefatti **si accumulano in entrambe le direzioni** — e **degradano** silenziosamente (un CLAUDE.md che continua a crescere, una checklist ignorata…): il modello non è peggiorato, sono gli artefatti a essere degradati senza sorveglianza. Un loop ha **5 componenti**: trigger, azione, **prova**, memoria, **condizione di arresto** (la più critica). Gli **eval** diventano lavoro del PM (testare l'artefatto su esempi noti: 3 PRD buoni / 3 cattivi, 5 chiamate comprese, 2 lanci passati). La **memoria** risiede su **GitHub** (il repository diventa "memoria di prodotto": commit, diff, risultati degli eval, registro delle decisioni, rollback). Primo loop consigliato: un **loop settimanale di segnale di prodotto** (ogni venerdì). Il gusto/istinto resta centrale — ma ora richiede una **prova**. Cita Boris (creatore di Claude Code): "non scrive più prompt, scrive loop".
Editoriale di **Olivier Rafal** (Consulting Director Strategy presso **WeNvision**) pubblicato il **23 febbraio 2024** su **CIO-Online** (sezione *Tribune*), che avanza una tesi allora ancora controintuitiva: **l'IA generativa è più una questione di prodotto tecnologico che un progetto di IA/data science**. **Argomento 1 — la data science non è il problema centrale**: costruire un *foundation model* da zero richiede *« diversi mesi, milioni di euro e l'accesso a quantità enormi di dati »* — riservato ad attori con dataset specifici e monetizzabili (ad es. **Bloomberg** e il suo **BloombergGPT** per la finanza). Per quasi tutte le aziende, il riflesso corretto non è quindi assumere data scientist. **Argomento 2 — disallineamento delle competenze**: ciò che serve principalmente sono **ingegneri di sviluppo e integrazione** (back/front), **solide competenze cloud** e **DevOps**. Citazione di un cliente: *« Non è necessariamente indispensabile essere data scientist, ma bisogna comprendere i concetti di base, avere competenze di sviluppo back-office e solide competenze cloud. »* **Argomento 3 — architettura a piattaforma (orchestratori + API)**: costruire una **plateforme d'IA générative** aziendale tramite orchestratori e API rende *« possibile lavorare con i migliori LLM del mercato e passare dall'uno all'altro man mano che le rispettive capacità evolvono, senza dover rilavorare le applicazioni »* (anti vendor lock-in). **Argomento 4 — dal progetto al prodotto**: *« La piattaforma […] deve essere considerata un prodotto a tutti gli effetti »*; invece di un investimento una tantum, va previsto un **flusso di finanziamento mensile** (iterazione continua, innovazione permanente). **Argomento 5 — governance e shadow AI**: la democratizzazione senza precedenti della GenAI genera *« tanta shadow AI quanto forti aspettative verso la direzione IT »* → una governance per raccogliere i bisogni di business, **dare priorità ai prodotti in base al valore**, e vigilare sul corretto funzionamento. **Cambio di paradigma** annunciato: *« si passa dalla programmazione algoritmica classica ad agents Langchain che gestiscono parte delle decisioni »*. **Rilevanza per la veille**: un **testo fondativo (con 2 anni di anticipo)** della dottrina di WeNvision (prodotto > progetto, piattaforma/API, finanziamento a flusso, governance, shadow AI), successivamente ampliato da [[wenvision-ai-agents-enterprise-deployment-2025-10-01]], [[habert-ia-agentique-production-2025-10-29]] e rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04 (FinOps/token, finanziamento a flusso → governance finanziaria). Prefigura inoltre l'*harness/piattaforma attorno al modello* (Dropbox/Okumura: *systems around the model*) e l'**indipendenza dal modello** ottenuta grazie a uno strato di orchestrazione.
#IA generativa#prodotto tecnologico#prodotto vs progetto
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (cabinet de conseil FR). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Auteur déjà présent dans la veille (cf. fiches WeNvision/Atlas/Tokenomics). Publié le **23 février 2024**.