Stanford HAI - AI Index - Annual report - Industry trends - Research metrics - Global AI development
Stanford Human-Centered AI Institute (HAI)
Google AI Mode - Search transformation - Personalized sites - Generative search - Generative web
Robby Stein (Google)
AEO (Answer Engine Optimization) - SEO - AI Answer Engines - Graphite
Graphite.io Team
Personal Software - AI-Customized Applications - Future of Software - Lee Robinson
Lee Robinson
Sierra blog post (December 10, 2024, Elliot Greenwald) laying out the **founding text of *outcome-based pricing*** for AI agents. **Pivot thesis**: AI agents that execute processes autonomously make possible an **entirely new pricing model** — ***"you pay only when the software achieves specific, valuable outcomes: outcome-based pricing."*** The article traces a **four-age genealogy of software pricing**: (1) **shrink-wrapped software** (1980s-90s, the floppy-disk/CD-ROM box at Fry's Electronics — *"Whether you actually used it or not, you paid for it"*) → (2) **SaaS / seat-based** (pioneered by **Salesforce**, followed by Google/Microsoft/Adobe — the Internet makes it possible to sell software *as a service*) → (3) **consumption-based** (**Amazon/AWS** and **Snowflake** — *"charged only for what you used"*) → (4) **outcome-based** (AI agents). **Canonical definition**: ***"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."*** **Aligned-incentives principle**: ***"With outcome-based pricing, Sierra gets paid only when we complete a task for you. Our incentives are aligned."*** **Critique of seat-based pricing & the concept of *shelfware***: *"Unused seats sit idly on a proverbial store shelf, hence the derisive moniker 'shelfware'"* — thousands of dollars per year are paid per license, whether used or not. **Structural conflict for Fournisseurs CX legacy**: their revenue depends on seat-based pricing, yet *"the more effective their AI becomes, the fewer contact center seats their clients need—undermining the provider's own revenue model"* — an effective AI agent **cannibalizes** the revenue model of a vendor whose pricing rests on seats. **Granularity of the outcome**: a distinction between **simple resolutions** (answering a question) and **complex resolutions** (handling a case that requires a 20-minute L2 call); **escalations generally incur no charge**; **blended pricing** is possible (e.g., consumption-based for routing/greeting interactions). **Continuous-optimization commitment** on the vendor side: *"we continue to deploy concerted, directed optimizations to refine the agent's performance over time"* — the vendor stays aligned to improve performance since it is paid only for the outcome. Significance: posed in **late 2024**, this post **precedes and grounds** the entire 2026 debate on the agentic economy — it supplies the **vocabulary of the billing unit** (the completed *outcome* rather than the seat, usage, or token) that will later be taken up by 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 anchored on the salary of the replaced employee*). With Sierra as the **reference example** cited by Bain (*autonomous customer issue resolution*), this text gives the **vendor-side view** of the mechanics that others analyze from the buyer side. Directly relevant to the firm's positioning on **agentic-delivery / value-based pricing** and to the **Cost Optimization** slot (the vendor-side counterpart of *cost per outcome*).
**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).
Kent Beck - Vibe Coding - TDD - AI-assisted development - Software craftsmanship - LinkedIn - Agile methodology
Kent Beck
LightRAG - Simple and Fast RAG - Knowledge Graphs - Dual-Level Retrieval - EMNLP2025 - GitHub
Zirui Guo · Lianghao Xia · Yanhua Yu · Tu Ao · Chao Huang (HKUDS - Hong Kong University Data Science)
Strategic Planning for AI's and AGI's Impossible Futures - One Useful Thing - Ethan Mollick
Ethan Mollick · Professeur à la Wharton School · University of Pennsylvania
NuExtract NuMind - foundation model for structured JSON extraction, compact format
Alexandre Constantin · Liam Cripwell · Etienne Bernard
OpenAI's official case study on the ChatGPT Enterprise deployment at Moderna: 750 GPTs in 2 months, 100% legal adoption, the Dose ID GPT for clinical trials, Stéphane Bancel's "100,000 employees" quote, an organizational transformation framework (mChat, Generative AI Champions, an internal forum with 2,000 participants).
OpenAI (étude de cas officielle, citations Stéphane Bancel, Brad Miller, Brice Challamel, Shannon Klinger, Kate Cronin, Meklit Workneh)
Ethan Mollick - AI adoption - Organizational change - One Useful Thing - Wharton - Academic research - Management
Ethan Mollick (Wharton School)
Sebastian Raschka - Machine Learning - Book - Educational - Deep Learning - PyTorch - Hands-on
Sebastian Raschka
Op-ed by **Olivier Rafal** (Consulting Director Strategy at **WeNvision**) published on **February 23, 2024** on **CIO-Online** (*Tribune* section), advancing a thesis still counter-intuitive at the time: **generative AI is more a matter of technology product than an AI/data science project**. **Argument 1 — data science is not the core issue**: building a *foundation model* from scratch requires *« several months, millions of euros, and access to enormous quantities of data »* — reserved for players with specific, monetizable datasets (e.g. **Bloomberg** and its **BloombergGPT** for finance). For nearly all companies, the right reflex is therefore not to hire data scientists. **Argument 2 — skills mismatch**: what is mainly needed is **development and integration engineers** (back/front), **strong cloud skills**, and **DevOps**. Client quote: *« You don't necessarily need to be a data scientist, but you need to understand the basic concepts, have back-office development skills, and strong cloud skills. »* **Argument 3 — platform architecture (orchestrators + APIs)**: building an enterprise **plateforme d'IA générative** via orchestrators and APIs makes it *« possible to work with the best LLMs on the market and switch between them as their respective capabilities evolve, without reworking the applications »* (anti vendor lock-in). **Argument 4 — from project to product**: *« The platform […] must be regarded as a product in its own right »*; instead of a one-off investment, plan for a **monthly funding stream** (continuous iteration, ongoing innovation). **Argument 5 — governance & shadow AI**: the unprecedented democratization of GenAI generates *« as much shadow AI as strong expectations toward the CIO office »* → governance to capture business needs, **prioritize products by value**, and oversee proper operation. **Paradigm shift** announced: *« the shift is from classic algorithmic programming to agents Langchain that handle part of the decisions »*. **Relevance to the watch**: a **founding text (2 years ahead)** of WeNvision's doctrine (product > project, platform/API, flow-based funding, governance, shadow AI), later extended by [[wenvision-ai-agents-enterprise-deployment-2025-10-01]], [[habert-ia-agentique-production-2025-10-29]], and rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04 (FinOps/token, flow-based funding → financial governance). It also foreshadows the *harness/platform around the model* (Dropbox/Okumura: *systems around the model*) and **model independence** achieved through an orchestration layer.
**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) - Y Combinator Startup - AI-Driven Measurement of Engineering Work - Weave Hour - AI Code Attribution - YC Directory
Y Combinator
METR - AI Safety - Autonomous replication - AI agents - Risk assessment - Existential risk - Alignment
METR (formerly ARC Evals)
Crisis of Meaning at Work - "Help me write" Button - Setting Time on Fire - Effort Signals - AI Recommendation Letters - Ethan Mollick - One Useful Thing
Ethan Mollick
**Mathieu Eveillard** publishes on his personal blog on **December 7, 2022** (last updated March 17, 2025) a **point-by-point counter-argument** to the famous essay by **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Article categorized **craft / best-of**, a **software craftsman** stance that defends **Test-Driven Development** without dogmatism. **Pivotal distinction** that DHH misses according to Eveillard: ***"Test-first"*** (writing all the tests before any code) vs ***"Test-Driven Development"*** (tests **guide** me in writing code, so each time I write a bit of code *"in reaction"* to a new test). DHH actually criticizes *Test-first* while calling it TDD — a confusion that **hides an entirely different way of programming**. **Point-by-point responses**: (1) *"TDD as hammer to beat down the nonbelievers"* — Eveillard concedes the deontological point but redefines *"good code"*: not just the absence of bugs but **fine-grained unit tests** documenting behavior at the lowest level, co-located with the code, a **safety net**; (2) *"Rebalance from unit to system"* — TDD **says nothing** about system tests and **does not say** there is nothing outside TDD; system tests do **not replace** unit tests (an income tax return tested end-to-end makes no sense); **test pyramid** — each type contributes its share, unit tests for **millisecond** feedback + early bug detection; (3) *"Horrendous monstrosities of architecture (service objects, command patterns)"* — Eveillard responds that he **does not see these effects in functional programming**, so the effect is likely due to **OOP**, not TDD; but concedes that excessive dependency injection can couple test and implementation. **Balanced conclusion**: *"TDD is not a religion, it's a tool"*. TDD is particularly well suited to **domain code** (the functional core of a *bounded context*, the *core of the hexagon*) — calculation engines, fine-grained business rules, edge cases galore — ***"30% of the codebase at most"***. Mentions the **Law of the Instrument** (if the tool doesn't help, it's because you've fallen into it). **Relevance to the corpus**: a **craft article outside the AI corpus** but worth archiving to position current debates on coding agents (Beck's *Augmented Coding Beyond Vibes*, 2025-06-25, Vibe Coding vs TDD, Frizzo's *writing muscle atrophy*) within the historical lineage of craft debates around TDD. To be used as a **library foundation** for training sessions.
**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 by **Gregor Hohpe** (Enterprise Strategist at AWS, author of *The Software Architect Elevator* and of the forthcoming book *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) at **PlatformCon 2022** on **the magic of platforms** — why platforms succeed, what distinguishes them from plain *IT Service Management*, and **the non-trivial architecture decisions** to make when building one. **Pivot thesis**: *"standards don't reduce creativity, they can multiply it"* — analogous to Baltimore 1904 (fire, incompatible pumps), the ISO metric screw, HTTP, A4 paper. **Canonical quote borrowed from Peter / Thoughtworks**: ***"platforms centralize expertise but not innovation"*** — the wheel isn't reinvented, but innovation is left to the teams closest to the customer. **Pivot analogy**: the automotive industry (Volkswagen Group builds the Audi A4 and the Bentley Bentayga on the same platform), *"undifferentiated heavy lifting"* (AWS vocabulary) under the hood, differentiation visible on the customer side. **Three properties of a true platform**: (1) **low friction** — adoption can't be forced, teams will work around it; (2) **transparency** (not a *black box*) — users must be able to diagnose whether the fault lies with them or with the platform; (3) **shared responsibility** (direct reference to the *AWS Shared Responsibility Model*) — the platform does not fix a poorly designed application. **Explicit anti-pattern**: *"a common layer can be many things — it is not necessarily a platform"*; traditional IT Service Management has the same image (a common layer underneath everyone) but the **interface is the opposite** (high-friction, forms, bottleneck). **Two construction paths**: (a) anticipating every need (Hohpe: *"I don't feel I'm smart enough"*); (b) **evolution** from useful pieces, observing usage. **Decisions to make explicit**: objectives (cognitive load ↓, safer / fewer mistakes, faster via samples/blueprints/self-service, compliance), shape of the learning curve (cliff, hockey stick, gear shift). **Canonical concept #1 — Floating platforms vs Sinking platforms**: when the *base platform* (typically the cloud) gains new capabilities, **two opposing strategies**: **sinking platform** (static, duplicating what the base now offers, sinking as the water level rises) vs ***floating platform*** (discards the pieces that have become redundant, **rises above the new level**, innovates further up). *"Submarine and a boat"* metaphor. Strong contractual implication: **explicitly warn stakeholders** that components will be removed once the base absorbs them. **Canonical concept #2 — Fruit salad vs Fruit basket**: a platform is not a collection of juxtaposed capabilities (a basket) but a **proportioned, bite-sized** assembly where the pieces interact — *"the per-kilo price for fruit salad is higher than for a fruit basket"*. The title derives from the phrase *the magic of platforms* — the counter-intuitive effect where **standardizing frees up innovation instead of stifling it**, provided the interface, the evolution, and the integration between components are handled with care. Relevant for: platform architects, **Platform Engineering / IDP teams 2026** (a foundational reference, predating the *Internal Developer Platforms* boom but structuring its vocabulary), CIOs assessing build-vs-stagnate against native cloud capabilities, product executive committees. Converges with **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 as a systemic pillar).
**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).
Oral communication techniques, academic presentation, effective speaking heuristics
Patrick Winston
Encyclopedic article (Wikipedia, English) on **Goodhart's law**: stated by British economist Charles Goodhart in 1975 regarding monetary policy — "any observed statistical regularity tends to collapse once pressure is placed upon it for control purposes" — then generalized by anthropologist Marilyn Strathern (1997) into the canonical aphorism "when a measure becomes a target, it ceases to be a good measure." The subject connects economics, incentive theory, public policy evaluation and, by extension, metric optimization in AI systems.
Wikipedia contributors (concept : Charles Goodhart ; généralisation : Marilyn Strathern)