Post X di **Andrew Ng** del **14 agosto 2026** (16:29 UTC), ripreso dalla lettera "Dear friends" di ***The Batch* #366** (DeepLearning.AI, stessa data), ~900 parole. Ng presenta **The AI Engineering Skills Map** e pubblica **quattro competenze** ritenute le più importanti. **(1) Costruire e distribuire applicazioni IA** — la specificità viene nominata: *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, da cui l'enfasi su *evals* e cicli di error-analysis. **(2) Fondamenti di ingegneria del software**, perché *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — lo sviluppatore inesperto fallisce *« because they don't know what context to give their coding agent »*, da cui l'obiettivo di *« steering coding agents using the precise language of software engineering »*. **(3) Uso di agenti di coding**, in una formulazione operativa: *« help the agent autonomously close loops by providing verifiers or evals »*, e *« knowing how much to intervene and how much to leave them alone »*. **(4) *Shaping the build***: *« Given a clear spec, coding agents are rapidly improving at delivering to it. Thus, our work as engineers is shifting toward deciding what should be in the spec »*, accostato a *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* Una **nota terminologica** porta la maggior parte dell'inquadramento: Ng parla di **competenze** nell'ingegneria IA e **non del ruolo** "AI Engineer", con un'analogia esplicita — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* Il tutto è sostenuto da *« an analysis of more than 10,000 job postings, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data »*, di cui **non viene pubblicato alcun risultato numerico**: Ng descrive il proprio processo come *« informally… akin to running clustering »* e annuncia una mappa dettagliata in post futuri. Egli enuncia l'interesse nella penultima frase: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*
#AI Engineering Skills Map#skills map#Andrew Ng
**Andrew Ng** — fondateur de **DeepLearning.AI** · general partner d'**AI Fund** · cofondateur de **Coursera** et de **Google Brain** · ancien chief scientist de Baidu. Texte signé · à la première personne · écrit *« with my team »* sans qu'aucun collaborateur soit nommé. Publié le **14 août 2026** sur X et dans ***The Batch* n°366** — même texte aux deux endroits ; préférer *The Batch* pour toute citation durable. Quatrième fiche Ng du corpus · après les lettres n°350 (24 avril) · n°352 (8 mai) et n°359 (26 juin).
Analisi SFEIR (voce di una società di consulenza, "la lettura di un ingegnere") che articola due framework troppo spesso confusi: lo **SDLC** (Software Development Life Cycle — *costruire il software in modo corretto e affidabile*) e il **PDLC** (Product Development Life Cycle — *costruire il prodotto giusto e avere successo sul mercato*). Tesi centrale: i due cicli non sono concorrenti ma **annidati** — lo SDLC è il sottoinsieme del PDLC **ospitato nella sua fase di sviluppo**; quando un team di prodotto raggiunge la fase di "build", al suo interno gira un ciclo SDLC completo (progettazione → costruzione → test → revisione → deployment). Lo SDLC è standardizzato (**ISO/IEC/IEEE 12207**, edizioni 2017 e 2026), con la sua genealogia di modelli (Waterfall 1970, modello a V, iterativo/spirale, **Agile 2001**, **DevOps/DevSecOps 2009+**) e le sue metriche **DORA** (throughput, stabilità, MTTR, change failure rate). Il PDLC, essendo il ciclo ombrello, si estende dall'**ideazione/discovery** al **ritiro dal mercato** (da non confondere con il **PLC** di marketing di Theodore Levitt, 1965, che descrive una *curva commerciale*, non un *lavoro organizzato*: "il PLC osserva una curva; il PDLC organizza il lavoro"). **Punto di svolta**: lo SDLC affronta nativamente **un solo rischio su quattro** — tramite il framework dei **"Four Big Risks" di Marty Cagan** (Valore → PM, Usabilità → Designer, Fattibilità → Lead Engineer, Sostenibilità economica → PM) — un'organizzazione eccellente sullo SDLC ma cieca sul PDLC produce "software che nessuno vuole" — la **"feature factory"** di John Cutler (successo misurato sull'output, non sull'outcome). **Perché l'IA cambia tutto**: l'IA generativa **comprime lo SDLC** (dati Google/JetBrains, maggio 2026: **~85% degli sviluppatori** usa regolarmente agenti di coding, **~41% del nuovo codice** è generato dall'IA; l'implementazione passa da settimane a ore), quindi il **collo di bottiglia si sposta a monte** — decidere *cosa* costruire (Marty Cagan, aprile 2026: "quando il costo della delivery crolla, il collo di bottiglia si sposta sulla discovery"). Conseguenze: DORA 2025 (~5.000 professionisti, 90% di adozione dell'IA) mostra una **correlazione positiva con il throughput ma negativa con la stabilità** (più funzionalità non validate significa più instabilità e rework); Andrew Ng (AI Startup School, luglio 2025) segnala team che **invertono il rapporto "1 PM per 4 ingegneri" in "2 PM per 1 ingegnere"**; e con lo **spec-driven development**, il confine PDLC/SDLC diventa **poroso** (la specifica di prodotto diventa direttamente eseguibile dagli agenti). **Cosa dovrebbe trarne un CIO**: uno SDLC potenziato diventa uno **standard di mercato, non un elemento di differenziazione** — bisogna strumentare la giunzione con il prodotto, esigere **specifiche eseguibili** come input, incrociare le metriche tecniche con le metriche di outcome, e **rifiutare** il ruolo di "fornitore di feature". Per un CPO: lo spostamento del collo di bottiglia verso la discovery è al tempo stesso una **promozione** (il giudizio di prodotto torna a essere una risorsa scarsa) e un **avviso ad agire** (industrializzare la discovery per raggiungere la parità con lo SDLC). Il framework interno di SFEIR ("Progettare e costruire nell'era agentica" — **ciclo a 11 fasi** + **Software Factory 10x**) si posiziona come la risposta sul lato ingegneristico, con l'**articolazione dei due cicli** come prossima leva. Conclusione: "man mano che il codice diventa una commodity, il margine si sposta verso il giudizio di prodotto e la governance."
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**.