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)
Dysfunction of organizational reward systems — Incentive-goal misalignment — Organizational behavior — Academy of Management Journal
Steven Kerr