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."
Netflix — Lettera agli azionisti Q2 FY2026: il GenAI si espande in produzione (≈300 titoli nel 2026), LLM per la scoperta e la ricerca in linguaggio naturale, strumenti AI lungo l'intero ciclo pubblicitario (Netflix)
Digest di tech-watch da fonti primarie sulla posizione di **Gregor Hohpe** (autore di *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; ex Enterprise Strategist per AWS e Google Cloud, ex Chief Architect di Allianz) riguardo al ruolo dell'architetto nell'era dell'IA generativa. Tesi: l'IA **non svaluta** l'architetto, ne **sposta il valore** dal codice a ciò che l'IA non fa — **prendere e assumersi decisioni, arbitrare i trade-off, "vendere opzioni," comunicare con gli esseri umani, produrre astrazioni solide**. Formula chiave (Craft Conference 2026): "*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*". La sua tesi distintiva (l'architetto non dovrebbe essere la persona più intelligente della stanza, dovrebbe **rendere più intelligenti tutti gli altri**) si rafforza man mano che il codice diventa abbondante: il vantaggio deriva dalla **disciplina decisionale** e dal **far emergere trade-off nascosti**, non dal volume. Il digest analizza inoltre le sue posizioni per ruolo (enterprise architect: da **cartografo a esploratore**; software architect: **debug** delle decisioni piuttosto che scrittura di codice; platform architect: **astrazioni, non illusioni**), la sua metafora delle **opzioni reali** (valore crescente con la volatilità tecnologica, analogia con Black-Scholes) e i suoi avvertimenti ("*An AI-driven SDLC punishes bad habits much faster*"; i vincitori dell'IA si distingueranno per la velocità con cui passano dalla sperimentazione alla **produzione governata**). ⚠️ La formula ampiamente diffusa "gli architetti che usano l'IA sostituiranno chi non la usa" **non è di Hohpe**. Dominio: architettura del software, ruolo dell'architetto, processo decisionale, opzioni reali, piattaforme, GenAI nell'SDLC.
Nota di analisi SFEIR che ripercorre il ruolo dell'architetto software nell'era dell'IA generativa attraverso il framework di **Gregor Hohpe** (*The Software Architect Elevator*). Tesi centrale: l'architetto « **Oracolo** » — il supremo custode della conoscenza che emette regole dalla torre d'avorio — è superato, poiché l'IA genera codice e proposte su richiesta; l'architetto moderno diventa un **amplificatore di intelligenza (IQ Amplifier)** che fornisce ai team i modelli mentali, il contesto di business e gli strumenti decisionali per sfruttare l'IA garantendo al contempo la coerenza del sistema. Il documento scompone l'impatto **piano per piano dell'"Architect Elevator"** (Enterprise / Solution / Platform / Software architect) e argomenta a favore del **Domain-Driven Design (DDD)** come salvaguardia indispensabile: il **linguaggio ubiquo** sottende i *system prompt* (un dizionario di dominio iniettato tramite `.clinerules`/template, che riduce le allucinazioni e le interpretazioni errate del business), e i **bounded context** limitano l'ambito affidato all'IA per massimizzare l'affidabilità della generazione. Conclusione: l'IA non è una minaccia ma un catalizzatore che solleva l'architetto dai compiti tecnici di input per mettere in primo piano la sintesi, la visione strategica, la modellazione e il legame umano tra tecnologia e business. Dominio: architettura software, ruolo dell'architetto, DDD, prompting strutturato, governance dell'IA aziendale.
Post LinkedIn di Fred Plais (CEO di Archie, ex Platform.sh): l'IA ha reso gli ingegneri così veloci che il **collo di bottiglia si è spostato a monte**, in un punto che nessuno sta osservando. Non essendo più l'esecuzione la parte lenta, il tempo di riflessione che esisteva un tempo "mentre il codice veniva costruito" è scomparso — la visione giusta deve ora formarsi e le decisioni giuste devono essere prese in una frazione del tempo precedente. Emergono due profili rari: quello capace di **articolare una visione abbastanza precisa** perché un agente la esegua senza deragliare, e quello che sa **orchestrare gli agenti** (anticipandone i fallimenti, concatenandoli, intercettando un errore prima che si propaghi). Assumere in base all'"output di codice" sta diventando obsoleto: è esattamente ciò che ha smesso di essere raro. Tesi finale: "pensare in modo chiaro è sempre stato il lavoro — la velocità ha solo reso impossibile fingere di farlo".
#collo di bottiglia#spostamento del collo di bottiglia#velocità di esecuzione
Episodio #351 del podcast francofono **If This Then Dev** (Bruno) con **Julien Lépine**, Chief Technology Officer di **AWS France** (13 anni in Amazon), registrato a margine dell'**AWS Summit Paris** (1° aprile 2026, ~10.000 partecipanti). Tesi centrale: nell'era agentica, scrivere codice diventa secondario, e il valore si sposta verso **la comprensione del contesto, i compromessi architetturali e la responsabilità umana**. Prova centrale: **la riprogettazione di Amazon Bedrock** — una piattaforma critica che gestisce migliaia di miliardi di richieste — realizzata da un team di **6 persone in 72 giorni** (contro una stima di 30 persone / 18 mesi), **codice interamente generato dall'IA**, senza vibe coding. AWS sta **standardizzando internamente su Kiro** (IDE + CLI, basato su Claude Sonnet/Opus) per ~30.000 sviluppatori (annunciato da Matt Garman a re:Invent). Filo conduttore: **mantenere il controllo** senza rivedere tutto — tramite **modellazione formale (TLA+)** e **Raisonnement automatisé** per dimostrare invarianti e delimitare gli agenti, **blameless post-mortem**, e il principio secondo cui "la responsabilità dell'azione di un agente ricade su chi lo opera". Emergenza dell'**AI DLC** (sprint → più **Bolt** giornalieri) e rischio di **sovraccarico cognitivo / burn-out**.
#AWS Summit Paris#Amazon Web Services#agenti di codice
**Julien Lépine** — Directeur de la technologie (CTO) d'Amazon Web Services France · 13+ ans chez Amazon ; ses équipes accompagnent les clients AWS sur le cloud · la data et l'IA. **Hôte** : Bruno (créateur et animateur du podcast *If This Then Dev*).
Evoluzione del ruolo dello sviluppatore con l'IA generativa, trasformazione dei ruoli IT, ingegneria dei sistemi, orchestration agentique - Yves Caseau - Michelin - LinkedIn
#sviluppatore#IA generativa#generazione di codice
Yves Caseau (Group Chief Digital & Information Officer chez Michelin)
Collasso dei costi e della complessità del software, l'IA generativa democratizza lo sviluppo, il software diventa "permissionless", debito tecnico sociale, produttività degli sviluppatori +55% - Cobus Greyling - Medium
#costo del software#collasso della complessità#IA generativa
Google DeepMind Genie 3 — modello di generazione video interattiva: modelli del mondo, generazione controllabile, giochi giocabili generati dall'IA (deepmind.google)
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**.