Vai al contenuto

Tutte le fiches — Pagina 20

Trasformazione e Adozione Traduzione verificata automaticamente

Personal Software

Personal Software - Applicazioni Personalizzate con l'IA - Il Futuro del Software - Lee Robinson

#IA#personal software#applicazioni personalizzate con l'IA

Lee Robinson

Economia e Mercato Traduzione verificata automaticamente

Outcome-based pricing for AI Agents

Articolo del blog Sierra (10 dicembre 2024, Elliot Greenwald) che espone il **testo fondativo dell'*outcome-based pricing*** per gli agenti IA. **Tesi cardine**: gli agenti IA che eseguono processi in autonomia rendono possibile un **modello di pricing del tutto nuovo** — ***"you pay only when the software achieves specific, valuable outcomes: outcome-based pricing."*** L'articolo ripercorre una **genealogia in quattro ere del pricing del software**: (1) **shrink-wrapped software** (anni '80-'90, la scatola con floppy disk/CD-ROM da Fry's Electronics — *"Whether you actually used it or not, you paid for it"*) → (2) **SaaS / seat-based** (introdotto da **Salesforce**, seguito da Google/Microsoft/Adobe — Internet rende possibile vendere il software *as a service*) → (3) **consumption-based** (**Amazon/AWS** e **Snowflake** — *"charged only for what you used"*) → (4) **outcome-based** (agenti IA). **Definizione canonica**: ***"outcome-based pricing is tied to tangible business impacts—such as a resolved support conversation, a saved cancellation, an upsell, a cross-sell, or any number of valuable outcomes. If the conversation is unresolved, in most cases, there's no charge."*** **Principio di incentivi allineati**: ***"With outcome-based pricing, Sierra gets paid only when we complete a task for you. Our incentives are aligned."*** **Critica del seat-based pricing e del concetto di *shelfware***: *"Unused seats sit idly on a proverbial store shelf, hence the derisive moniker 'shelfware'"* — vengono pagate migliaia di dollari all'anno per licenza, usata o meno. **Conflitto strutturale per i Fournisseurs CX legacy**: il loro fatturato dipende dal seat-based pricing, eppure *"the more effective their AI becomes, the fewer contact center seats their clients need—undermining the provider's own revenue model"* — un agente IA efficace **cannibalizza** il modello di fatturato di un fornitore il cui pricing poggia sui seat. **Granularità dell'outcome**: una distinzione tra **risoluzioni semplici** (rispondere a una domanda) e **risoluzioni complesse** (gestire un caso che richiede una chiamata L2 di 20 minuti); le **escalation generalmente non comportano addebiti**; è possibile un **pricing misto (blended)** (ad es. consumption-based per le interazioni di routing/accoglienza). **Impegno di ottimizzazione continua** lato fornitore: *"we continue to deploy concerted, directed optimizations to refine the agent's performance over time"* — il fornitore resta allineato nel migliorare le prestazioni poiché è pagato solo per il risultato. Rilevanza: pubblicato a **fine 2024**, questo post **precede e fonda** l'intero dibattito 2026 sull'economia agentica — fornisce il **vocabolario dell'unità di fatturazione** (l'*outcome* completato piuttosto che il seat, l'usage o il token) che verrà ripreso in seguito da Gupta (*cost of a completed outcome*, *token-to-outcome attribution*), Bain (*outcome-based pricing shifts revenue from fixed seats to labor/operations economics*), Ng (*pricing power ancorato allo stipendio del dipendente sostituito*). Con Sierra come **esempio di riferimento** citato da Bain (*autonomous customer issue resolution*), questo testo offre la **visione lato fornitore** delle dinamiche che altri analizzano dal lato acquirente. Direttamente rilevante per il posizionamento dell'azienda su **agentic-delivery / value-based pricing** e per lo slot **Cost Optimization** (la controparte lato fornitore del *cost per outcome*).

#outcome-based pricing#pricing basato sui risultati#agenti IA

**Elliot Greenwald** — Sierra (entreprise fondée par Bret Taylor & Clay Bavor, plateforme d'agents IA conversationnels pour l'expérience client). Billet publié sur le blog Sierra le **10 décembre 2024**. Sierra est l'**exemple-référence** cité par Bain (*The $100-Billion SaaS Opportunity*) pour l'*autonomous customer issue resolution* · et fait l'objet de plusieurs fiches du dossier (recrutement AI-native, interview Plan/Build/Review).

Trasformazione e Adozione Traduzione verificata automaticamente

Confronting Impossible Futures

Strategic Planning for AI's and AGI's Impossible Futures - One Useful Thing - Ethan Mollick

#AGI#Artificial General Intelligence#pianificazione strategica

Ethan Mollick · Professeur à la Wharton School · University of Pennsylvania

Trasformazione e Adozione Traduzione verificata automaticamente

Accelerating the development of life-saving treatments — Moderna case study

Case study ufficiale di OpenAI sull'implementazione di ChatGPT Enterprise presso Moderna: 750 GPT in 2 mesi, adozione al 100% nel reparto legale, il GPT Dose ID per i trial clinici, la citazione di Stéphane Bancel sui "100.000 dipendenti", un framework di trasformazione organizzativa (mChat, Generative AI Champions, un forum interno con 2.000 partecipanti).

#Moderna#OpenAI#ChatGPT Enterprise

OpenAI (étude de cas officielle, citations Stéphane Bancel, Brad Miller, Brice Challamel, Shannon Klinger, Kate Cronin, Meklit Workneh)

Trasformazione e Adozione Traduzione verificata automaticamente

L'IA générative est plus une affaire de produit technologique qu'un projet d'IA

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**.

Qualità e Sicurezza Traduzione verificata automaticamente

TDD is dead. Long live testing. (Une contre-argumentation point à point à l'article phare de David Heinemeier Hansson, détracteur du Test-driven development)

**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#TDD#Test-Driven Development

**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"*).

Architettura e Costruzione Traduzione verificata automaticamente

The Magic of Platforms

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).

#Piattaforme software#platform engineering#Internal Developer Platforms IDP

**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).

Filosofia e Società Traduzione verificata automaticamente

How To Speak

Tecniche di comunicazione orale, presentazione accademica, euristiche per un public speaking efficace

#comunicazione orale#oratoria#presentazione

Patrick Winston

Filosofia e Società Traduzione verificata automaticamente

Goodhart's law

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.

#legge di Goodhart#misura che diventa obiettivo#regolarità statistica

Wikipedia contributors (concept : Charles Goodhart ; généralisation : Marilyn Strathern)

Filosofia e Società Traduzione verificata automaticamente

On the Folly of Rewarding A, While Hoping for B

Disfunzione dei sistemi di ricompensa organizzativi — Disallineamento incentivi-obiettivi — Comportamento organizzativo — Academy of Management Journal

#sistemi di ricompensa#disallineamento degli incentivi#comportamento organizzativo

Steven Kerr