Zum Inhalt springen

Alle Fiches — Seite 20

Transformation & Adoption Automatisch geprüfte Übersetzung

Personal Software

Personal Software - KI-angepasste Anwendungen - Zukunft der Software - Lee Robinson

#KI#personal software#KI-angepasste Anwendungen

Lee Robinson

Wirtschaft & Markt Automatisch geprüfte Übersetzung

Outcome-based pricing for AI Agents

Sierra-Blogbeitrag (10. Dezember 2024, Elliot Greenwald), der den **Gründungstext des *outcome-based pricing*** für KI-Agenten formuliert. **Kernthese**: KI-Agenten, die Prozesse autonom ausführen, machen ein **völlig neues Preismodell** möglich — ***"you pay only when the software achieves specific, valuable outcomes: outcome-based pricing."*** Der Artikel zeichnet eine **vier Zeitalter umfassende Genealogie der Softwarepreisgestaltung** nach: (1) **verpackte Software** (shrink-wrapped software, 1980er-90er Jahre, die Diskette/CD-ROM-Box bei Fry's Electronics — *"Whether you actually used it or not, you paid for it"*) → (2) **SaaS / sitzplatzbasiert** (seat-based, von **Salesforce** eingeführt, gefolgt von Google/Microsoft/Adobe — das Internet macht es möglich, Software *as a service* zu verkaufen) → (3) **verbrauchsbasiert** (consumption-based, **Amazon/AWS** und **Snowflake** — *"charged only for what you used"*) → (4) **ergebnisbasiert** (outcome-based, KI-Agenten). **Kanonische 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."*** **Prinzip der ausgerichteten Anreize**: ***"With outcome-based pricing, Sierra gets paid only when we complete a task for you. Our incentives are aligned."*** **Kritik am sitzplatzbasierten Preismodell und am Konzept des *shelfware***: *"Unused seats sit idly on a proverbial store shelf, hence the derisive moniker 'shelfware'"* — pro Lizenz werden jährlich Tausende von Dollar gezahlt, unabhängig von der tatsächlichen Nutzung. **Struktureller Konflikt für Fournisseurs CX legacy**: Deren Umsatz hängt vom sitzplatzbasierten Preismodell ab, doch *"the more effective their AI becomes, the fewer contact center seats their clients need—undermining the provider's own revenue model"* — ein effektiver KI-Agent **kannibalisiert** das Umsatzmodell eines Anbieters, dessen Preisgestaltung auf Sitzplätzen beruht. **Granularität des Ergebnisses**: eine Unterscheidung zwischen **einfachen Lösungen** (Beantwortung einer Frage) und **komplexen Lösungen** (Bearbeitung eines Falls, der einen 20-minütigen L2-Anruf erfordert); **Eskalationen sind in der Regel kostenfrei**; **gemischte Preismodelle** (blended pricing) sind möglich (z. B. verbrauchsbasiert für Routing-/Begrüßungsinteraktionen). **Verpflichtung zur kontinuierlichen Optimierung** seitens des Anbieters: *"we continue to deploy concerted, directed optimizations to refine the agent's performance over time"* — der Anbieter bleibt darauf ausgerichtet, die Leistung zu verbessern, da er nur für das Ergebnis bezahlt wird. Bedeutung: **Ende 2024** formuliert, geht dieser Beitrag der gesamten Debatte von 2026 über die agentenbasierte Wirtschaft voraus und legt deren Grundlage — er liefert das **Vokabular der Abrechnungseinheit** (das erzielte *outcome* statt Sitzplatz, Nutzung oder Token), das später von Gupta (*cost of a completed outcome*, *token-to-outcome attribution*), Bain (*outcome-based pricing shifts revenue from fixed seats to labor/operations economics*) und Ng (*pricing power anchored on the salary of the replaced employee*) aufgegriffen wird. Mit Sierra als dem von Bain zitierten **Referenzbeispiel** (*autonomous customer issue resolution*) liefert dieser Text die **Sicht der Anbieterseite** auf die Mechanismen, die andere aus der Käuferperspektive analysieren. Direkt relevant für die Positionierung des Unternehmens zu **agentic-delivery / value-based pricing** sowie für den Slot **Cost Optimization** (das anbieterseitige Gegenstück zu *cost per outcome*).

#ergebnisbasierte Preisgestaltung#resultatsbasierte Preisgestaltung#KI-Agenten

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

Transformation & Adoption Automatisch geprüfte Übersetzung

Confronting Impossible Futures

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

#AGI#Artificial General Intelligence#strategische Planung

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

Transformation & Adoption Automatisch geprüfte Übersetzung

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

Offizielle Fallstudie von OpenAI zum Einsatz von ChatGPT Enterprise bei Moderna: 750 GPTs in 2 Monaten, 100 % Akzeptanz in der Rechtsabteilung, das Dose-ID-GPT für klinische Studien, Stéphane Bancels Zitat zu den „100.000 Mitarbeitern", ein Rahmenwerk für organisatorischen Wandel (mChat, Generative AI Champions, ein internes Forum mit 2.000 Teilnehmern).

#Moderna#OpenAI#ChatGPT Enterprise

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

Transformation & Adoption Automatisch geprüfte Übersetzung

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

Debattenbeitrag von **Olivier Rafal** (Consulting Director Strategy bei **WeNvision**), veröffentlicht am **23. Februar 2024** auf **CIO-Online** (Rubrik *Tribune*), der eine damals noch kontraintuitive These vertritt: **generative KI ist eher eine Frage des Technologieprodukts als ein KI-/Data-Science-Projekt**. **Argument 1 — Data Science ist nicht der Kern des Problems**: Der Aufbau eines *Foundation Model* von Grund auf erfordert *„mehrere Monate, Millionen von Euro und Zugang zu enormen Datenmengen“* — vorbehalten Akteuren mit spezifischen, monetarisierbaren Datensätzen (z. B. **Bloomberg** mit **BloombergGPT** für den Finanzbereich). Für nahezu alle Unternehmen ist es daher nicht der richtige Reflex, Data Scientists einzustellen. **Argument 2 — Kompetenz-Mismatch**: Hauptsächlich benötigt werden **Entwicklungs- und Integrationsingenieure** (Backend/Frontend), **solide Cloud-Kenntnisse** und **DevOps**. Kundenzitat: *„Man muss nicht unbedingt Data Scientist sein, aber man muss die Grundkonzepte verstehen, Backend-Entwicklungskenntnisse und solide Cloud-Kenntnisse mitbringen.“* **Argument 3 — Plattformarchitektur (Orchestratoren + APIs)**: Der Aufbau einer unternehmensinternen **plateforme d'IA générative** über Orchestratoren und APIs macht es *„möglich, mit den besten am Markt verfügbaren LLMs zu arbeiten und zwischen ihnen zu wechseln, sobald sich ihre jeweiligen Fähigkeiten weiterentwickeln, ohne die Anwendungen überarbeiten zu müssen“* (Anti-Vendor-Lock-in). **Argument 4 — vom Projekt zum Produkt**: *„Die Plattform […] muss als eigenständiges Produkt betrachtet werden“*; statt einer einmaligen Investition ist ein **monatlicher Finanzierungsstrom** einzuplanen (kontinuierliche Iteration, fortlaufende Innovation). **Argument 5 — Governance & Shadow AI**: Die beispiellose Demokratisierung generativer KI erzeugt *„ebenso viel Shadow AI wie starke Erwartungen an die CIO-Organisation“* → Governance, um Business-Bedarfe zu erfassen, **Produkte nach Wert zu priorisieren** und den ordnungsgemäßen Betrieb zu überwachen. Angekündigter **Paradigmenwechsel**: *„der Wandel führt von der klassischen algorithmischen Programmierung zu agents Langchain, die einen Teil der Entscheidungen übernehmen“*. **Relevanz für die Veille**: ein **Gründungstext (2 Jahre vorausschauend)** der WeNvision-Doktrin (Produkt > Projekt, Plattform/API, flussbasierte Finanzierung, Governance, Shadow AI), später erweitert durch [[wenvision-ai-agents-enterprise-deployment-2025-10-01]], [[habert-ia-agentique-production-2025-10-29]], und rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04 (FinOps/Token, flussbasierte Finanzierung → finanzielle Governance). Er nimmt zudem den *Harness/die Plattform rund um das Modell* vorweg (Dropbox/Okumura: *systems around the model*) sowie die durch eine Orchestrierungsschicht erreichte **Modellunabhängigkeit**.

#generative KI#Technologieprodukt#Produkt vs. Projekt

**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ät & Sicherheit Automatisch geprüfte Übersetzung

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** veröffentlicht am **7. Dezember 2022** (letzte Aktualisierung 17. März 2025) auf seinem persönlichen Blog eine **punktweise Gegenargumentation** zum berühmten Essay von **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Der Artikel ist in die Kategorien **Craft / Best-of** eingeordnet, eine Haltung des **Software-Craftsman**, der **Test-Driven Development** undogmatisch verteidigt. **Zentrale Unterscheidung**, die DHH laut Eveillard entgeht: ***"Test-first"*** (alle Tests vor jeglichem Code schreiben) vs. ***"Test-Driven Development"*** (Tests **leiten** mich beim Schreiben von Code an, sodass ich jedes Mal ein Stück Code *"als Reaktion"* auf einen neuen Test schreibe). DHH kritisiert tatsächlich *Test-first*, nennt es jedoch TDD — eine Verwechslung, die **eine völlig andere Art zu programmieren verdeckt**. **Punktweise Erwiderungen**: (1) *"TDD als Hammer, um Ungläubige niederzuschlagen"* — Eveillard räumt den deontologischen Punkt ein, definiert aber *"guten Code"* neu: nicht nur die Abwesenheit von Bugs, sondern **feingranulare Unit-Tests**, die das Verhalten auf niedrigster Ebene dokumentieren, direkt beim Code angesiedelt, ein **Sicherheitsnetz**; (2) *"Verschiebung vom Unit- zum System-Test"* — TDD **sagt nichts** über System-Tests aus und **behauptet nicht**, dass es außerhalb von TDD nichts gebe; System-Tests **ersetzen** Unit-Tests **nicht** (eine Ende-zu-Ende getestete Steuererklärung ergibt keinen Sinn); **Testpyramide** — jeder Typ trägt seinen Anteil bei, Unit-Tests für Feedback im **Millisekundenbereich** + frühe Fehlererkennung; (3) *"Horrende Architektur-Monstrositäten (Service Objects, Command Patterns)"* — Eveillard entgegnet, dass er **diese Effekte in der funktionalen Programmierung nicht beobachtet**, sodass der Effekt wahrscheinlich auf **OOP** zurückzuführen ist, nicht auf TDD; räumt aber ein, dass übermäßige Dependency Injection Test und Implementierung koppeln kann. **Ausgewogenes Fazit**: *"TDD ist keine Religion, sondern ein Werkzeug"*. TDD eignet sich besonders gut für **Domain-Code** (den funktionalen Kern eines *Bounded Context*, den *Kern des Hexagons*) — Berechnungs-Engines, feingranulare Geschäftsregeln, jede Menge Grenzfälle — ***"höchstens 30 % der Codebasis"***. Erwähnt das **Gesetz des Instruments** (wenn das Werkzeug nicht hilft, liegt es daran, dass man ihm verfallen ist). **Relevanz für den Corpus**: ein **Craft-Artikel außerhalb des KI-Corpus**, aber archivierungswürdig, um aktuelle Debatten über Coding-Agenten (Becks *Augmented Coding Beyond Vibes*, 2025-06-25, Vibe Coding vs. TDD, Frizzos *writing muscle atrophy*) in die historische Traditionslinie der Craft-Debatten rund um TDD einzuordnen. Zu verwenden als **Grundlagenmaterial** für Schulungen.

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

Architektur & Konstruktion Automatisch geprüfte Übersetzung

The Magic of Platforms

Keynote von **Gregor Hohpe** (Enterprise Strategist bei AWS, Autor von *The Software Architect Elevator* sowie des demnächst erscheinenden Buchs *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) bei **PlatformCon 2022** über **die Magie von Plattformen** — warum Plattformen erfolgreich sind, was sie von reinem *IT Service Management* unterscheidet, und **die nicht-trivialen Architekturentscheidungen**, die beim Aufbau einer solchen zu treffen sind. **Kernthese**: *"Standards schränken Kreativität nicht ein, sie können sie vervielfachen"* — analog zu Baltimore 1904 (Brand, inkompatible Pumpen), der ISO-Metrischschraube, HTTP, DIN-A4-Papier. **Kanonisches Zitat, entlehnt von Peter / Thoughtworks**: ***"Plattformen zentralisieren Expertise, aber nicht Innovation"*** — das Rad wird nicht neu erfunden, aber die Innovation bleibt den Teams überlassen, die dem Kunden am nächsten sind. **Zentrale Analogie**: die Automobilindustrie (der Volkswagen-Konzern baut den Audi A4 und den Bentley Bentayga auf derselben Plattform), *"undifferentiated heavy lifting"* (AWS-Vokabular) unter der Haube, Differenzierung sichtbar auf der Kundenseite. **Drei Eigenschaften einer echten Plattform**: (1) **geringe Reibung** (*low friction*) — Adoption lässt sich nicht erzwingen, Teams umgehen sie sonst; (2) **Transparenz** (keine *Black Box*) — Nutzer müssen diagnostizieren können, ob der Fehler bei ihnen oder bei der Plattform liegt; (3) **geteilte Verantwortung** (direkter Verweis auf das *AWS Shared Responsibility Model*) — die Plattform behebt keine schlecht konzipierte Anwendung. **Explizites Anti-Pattern**: *"eine gemeinsame Schicht kann vieles sein — sie ist nicht zwangsläufig eine Plattform"*; traditionelles IT Service Management zeigt dasselbe Bild (eine gemeinsame Schicht unter allen), aber die **Schnittstelle ist das Gegenteil** (hohe Reibung, Formulare, Flaschenhals). **Zwei Aufbauwege**: (a) jeden Bedarf antizipieren (Hohpe: *"Ich halte mich nicht für schlau genug dafür"*); (b) **Evolution** ausgehend von nützlichen Bausteinen, unter Beobachtung der Nutzung. **Explizit zu treffende Entscheidungen**: Ziele (kognitive Last ↓, sicherer / weniger Fehler, schneller durch Samples/Blueprints/Self-Service, Compliance), Form der Lernkurve (Klippe, Hockeyschläger, Gangwechsel). **Kanonisches Konzept Nr. 1 — Floating Platforms vs. Sinking Platforms**: Wenn die *Basisplattform* (typischerweise die Cloud) neue Fähigkeiten erhält, gibt es **zwei entgegengesetzte Strategien**: **Sinking Platform** (statisch, dupliziert, was die Basis nun bietet, sinkt mit steigendem Wasserspiegel) vs. ***Floating Platform*** (verwirft die redundant gewordenen Teile, **steigt über das neue Niveau**, innoviert weiter oben). Metapher *"U-Boot und Boot"*. Starke vertragliche Implikation: **Stakeholder explizit vorwarnen**, dass Komponenten entfernt werden, sobald die Basis sie absorbiert. **Kanonisches Konzept Nr. 2 — Fruit Salad vs. Fruit Basket**: Eine Plattform ist keine Sammlung nebeneinandergestellter Fähigkeiten (ein Korb), sondern ein **proportioniertes, mundgerechtes** Gefüge, in dem die Teile interagieren — *"der Kilopreis für Obstsalat ist höher als für einen Obstkorb"*. Der Titel leitet sich vom Ausdruck *the magic of platforms* ab — der kontraintuitive Effekt, bei dem **Standardisierung Innovation freisetzt, statt sie zu ersticken**, sofern Schnittstelle, Weiterentwicklung und Integration der Komponenten sorgfältig gehandhabt werden. Relevant für: Plattform-Architekten, **Platform-Engineering-/IDP-Teams 2026** (eine grundlegende Referenz, die dem *Internal-Developer-Platforms*-Boom vorausging, aber dessen Vokabular strukturiert), CIOs, die Build-vs-Stagnate gegenüber nativen Cloud-Fähigkeiten bewerten, Produkt-Führungsgremien. Konvergiert mit **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 — Plattform als systemischer Pfeiler).

#Software-Plattformen#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).

Philosophie & Gesellschaft Automatisch geprüfte Übersetzung

How To Speak

Techniken der mündlichen Kommunikation, akademischer Vortrag, Heuristiken für wirkungsvolles Sprechen

#mündliche Kommunikation#Redekunst#Präsentation

Patrick Winston

Philosophie & Gesellschaft Automatisch geprüfte Übersetzung

Goodhart's law

Enzyklopädischer Artikel (Wikipedia, Englisch) über das Goodhartsche Gesetz: 1975 vom britischen Ökonomen Charles Goodhart im Zusammenhang mit der Geldpolitik formuliert — „jede beobachtete statistische Regelmäßigkeit neigt dazu, zusammenzubrechen, sobald Druck zu Kontrollzwecken auf sie ausgeübt wird“ — später von der Anthropologin Marilyn Strathern (1997) zum kanonischen Aphorismus verallgemeinert: „wenn ein Maß zum Ziel wird, hört es auf, ein gutes Maß zu sein“. Das Thema verbindet Ökonomie, Anreiztheorie, Bewertung öffentlicher Politik und, im weiteren Sinne, die Optimierung von Metriken in KI-Systemen.

#Goodhartsches Gesetz#Maß wird zum Ziel#statistische Regelmäßigkeit

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