Ethan Mollick - Adozione dell'IA - Cambiamento organizzativo - One Useful Thing - Wharton - Ricerca accademica - Management
Ethan Mollick (Wharton School)
Sebastian Raschka - Machine Learning - Libro - Educativo - Deep Learning - PyTorch - Pratico
Sebastian Raschka
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.
**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**.
Weave (workweave.dev) - Startup Y Combinator - Misurazione del Lavoro di Ingegneria Basata sull'IA - Weave Hour - Attribuzione del Codice all'IA - YC Directory
Y Combinator
METR - AI Safety - Autonomous replication - AI agents - Risk assessment - Existential risk - Alignment
METR (formerly ARC Evals)
Crisi di significato sul lavoro - Il pulsante "Help me write" - Dare fuoco al proprio tempo - Segnali di impegno - Lettere di raccomandazione generate dall'IA - Ethan Mollick - One Useful Thing
Ethan Mollick
**Mathieu Eveillard** pubblica sul suo blog personale il **7 dicembre 2022** (ultimo aggiornamento 17 marzo 2025) una **controargomentazione punto per punto** al celebre saggio di **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Articolo classificato **craft / best-of**, una posizione da **artigiano del software** che difende il **Test-Driven Development** senza dogmatismo. **Distinzione cruciale** che secondo Eveillard sfugge a DHH: ***"Test-first"*** (scrivere tutti i test prima di qualsiasi codice) vs ***"Test-Driven Development"*** (i test mi **guidano** nella scrittura del codice, per cui ogni volta scrivo un po' di codice *"in reazione"* a un nuovo test). DHH in realtà critica il *Test-first* chiamandolo TDD — una confusione che **nasconde un modo di programmare completamente diverso**. **Risposte punto per punto**: (1) *"TDD come martello per abbattere i non credenti"* — Eveillard concede il punto deontologico ma ridefinisce il *"buon codice"*: non solo l'assenza di bug ma **unit test a grana fine** che documentano il comportamento al livello più basso, collocati insieme al codice, una **rete di sicurezza**; (2) *"Riequilibrare dallo unit al system"* — il TDD **non dice nulla** sui test di sistema e **non afferma** che non esista nulla al di fuori del TDD; i test di sistema **non sostituiscono** gli unit test (una dichiarazione dei redditi testata end-to-end non ha senso); **piramide dei test** — ogni tipo contribuisce con la propria parte, gli unit test per un feedback in **millisecondi** + individuazione precoce dei bug; (3) *"Mostruosità architetturali orrende (service object, command pattern)"* — Eveillard risponde di **non riscontrare questi effetti nella programmazione funzionale**, quindi l'effetto è probabilmente dovuto all'**OOP**, non al TDD; ma concede che un'iniezione di dipendenze eccessiva può accoppiare test e implementazione. **Conclusione equilibrata**: *"Il TDD non è una religione, è uno strumento"*. Il TDD è particolarmente adatto al **codice di dominio** (il nucleo funzionale di un *bounded context*, il *cuore dell'esagono*) — motori di calcolo, regole di business a grana fine, casi limite ovunque — ***"al massimo il 30% della codebase"***. Cita la **Legge dello Strumento** (se lo strumento non aiuta, è perché ci si è caduti dentro). **Rilevanza per il corpus**: un **articolo di craft esterno al corpus IA** ma da archiviare per collocare gli attuali dibattiti sugli agenti di codifica (l'*Augmented Coding Beyond Vibes* di Beck, 2025-06-25, Vibe Coding vs TDD, l'*atrofia del muscolo della scrittura* di Frizzo) nella linea storica dei dibattiti craft sul TDD. Da utilizzare come **base di libreria** per sessioni di formazione.
**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD · du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).
Keynote di **Gregor Hohpe** (Enterprise Strategist presso AWS, autore di *The Software Architect Elevator* e del prossimo libro *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) al **PlatformCon 2022** su **la magia delle piattaforme** — perché le piattaforme hanno successo, cosa le distingue dal semplice *IT Service Management*, e **le decisioni architetturali non banali** da prendere quando se ne costruisce una. **Tesi cardine**: *"gli standard non riducono la creatività, possono moltiplicarla"* — analoga a Baltimora 1904 (incendio, pompe incompatibili), la vite metrica ISO, HTTP, la carta A4. **Citazione canonica ripresa da Peter / Thoughtworks**: ***"le piattaforme centralizzano le competenze ma non l'innovazione"*** — la ruota non viene reinventata, ma l'innovazione è lasciata ai team più vicini al cliente. **Analogia cardine**: l'industria automobilistica (Volkswagen Group costruisce l'Audi A4 e la Bentley Bentayga sulla stessa piattaforma), *"undifferentiated heavy lifting"* (vocabolario AWS) sotto il cofano, differenziazione visibile lato cliente. **Tre proprietà di una vera piattaforma**: (1) **bassa frizione** — l'adozione non può essere imposta, i team la aggireranno; (2) **trasparenza** (non una *black box*) — gli utenti devono poter diagnosticare se la colpa è loro o della piattaforma; (3) **responsabilità condivisa** (riferimento diretto all'*AWS Shared Responsibility Model*) — la piattaforma non corregge un'applicazione mal progettata. **Anti-pattern esplicito**: *"un layer comune può essere molte cose — non è necessariamente una piattaforma"*; l'IT Service Management tradizionale ha la stessa immagine (un layer comune sotto tutti) ma **l'interfaccia è opposta** (alta frizione, moduli, collo di bottiglia). **Due percorsi di costruzione**: (a) anticipare ogni esigenza (Hohpe: *"non mi sento abbastanza intelligente"*); (b) **evoluzione** a partire da elementi utili, osservando l'utilizzo. **Decisioni da rendere esplicite**: obiettivi (carico cognitivo ↓, più sicuro / meno errori, più veloce tramite esempi/blueprint/self-service, conformità), forma della curva di apprendimento (falesia, mazza da hockey, cambio di marcia). **Concetto canonico #1 — Floating platforms vs Sinking platforms**: quando la *base platform* (tipicamente il cloud) acquisisce nuove capacità, **due strategie opposte**: **sinking platform** (statica, duplica ciò che la base ora offre, affonda man mano che il livello dell'acqua sale) vs ***floating platform*** (scarta gli elementi diventati ridondanti, **risale al di sopra del nuovo livello**, innova più in alto). Metafora *"sottomarino e barca"*. Forte implicazione contrattuale: **avvertire esplicitamente gli stakeholder** che i componenti verranno rimossi non appena la base li assorbirà. **Concetto canonico #2 — Fruit salad vs Fruit basket**: una piattaforma non è una raccolta di capacità giustapposte (un cesto) ma un assemblaggio **proporzionato, a bocconi** in cui gli elementi interagiscono — *"il prezzo al chilo della macedonia è più alto di quello del cesto di frutta"*. Il titolo deriva dalla frase *the magic of platforms* — l'effetto controintuitivo per cui **la standardizzazione libera l'innovazione invece di soffocarla**, a condizione che l'interfaccia, l'evoluzione e l'integrazione tra i componenti siano gestite con cura. Rilevante per: architetti di piattaforme, **team Platform Engineering / IDP 2026** (un riferimento fondativo, precedente al boom delle *Internal Developer Platforms* ma che ne struttura il vocabolario), CIO che valutano build-vs-stagnazione rispetto alle capacità cloud native, comitati esecutivi di prodotto. Converge con **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Platform come pilastro sistemico).
**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).
Tecniche di comunicazione orale, presentazione accademica, euristiche per un public speaking efficace
Patrick Winston
Voce enciclopedica (Wikipedia, inglese) sulla **legge di Goodhart**: enunciata dall'economista britannico Charles Goodhart nel 1975 a proposito della politica monetaria — "qualsiasi regolarità statistica osservata tende a collassare non appena viene sottoposta a pressione a fini di controllo" — poi generalizzata dall'antropologa Marilyn Strathern (1997) nell'aforisma canonico "quando una misura diventa un obiettivo, cessa di essere una buona misura". L'argomento collega economia, teoria degli incentivi, valutazione delle politiche pubbliche e, per estensione, l'ottimizzazione delle metriche nei sistemi di IA.
Wikipedia contributors (concept : Charles Goodhart ; généralisation : Marilyn Strathern)
Disfunzione dei sistemi di ricompensa organizzativi — Disallineamento incentivi-obiettivi — Comportamento organizzativo — Academy of Management Journal
Steven Kerr