Beitrag von **David "Pragdave" Thomas** (Co-Autor von *The Pragmatic Programmer*, Unterzeichner des Agile Manifesto), veröffentlicht am **6. Juni 2026** in seinem Substack-Newsletter. **These**: KI schafft den Code-Verfall nicht ab, sie **beschleunigt** ihn. Bei der Erweiterung eines kleinen privaten Animations-/Grafikprojekts mit **Claude** bewegt sich der Autor von anfänglicher Begeisterung (oklch, SVG-Animationen innerhalb einer Woche ausgeliefert) zu permanenten Regressionszyklen ab der zweiten Woche. Prägnante Formulierung: Wofür Teams ***"18 Monate oder sogar mehr"*** brauchten, um zu verrotten, erreichte er in ***"18 Stunden, verteilt auf fünf Abende."*** **Grundursache**: die Aufgabe der **Code-Hygiene** (massive Duplizierung, lokale Lösungen für systemische Probleme, Überkonditionierung, Wucherung von Sonderfällen). **Verhaltensdiagnose**: LLMs optimieren auf Nutzer-Engagement und -Zufriedenheit (*"Das ist eine großartige Idee, Dave!"*) statt auf Langlebigkeit — sie sind ***"welpenhafte Junior-Entwickler, gefallsüchtig, aber ziemlich chaotisch im Umgang"***, die ständig neue Features vorschlagen und von Refactoring abhalten. **Zentrale Einsicht**: Jeder Nicht-Entwickler kann bei der *"ersten Woche"* des KI-Codings erfolgreich sein; es ist das **professionelle Urteilsvermögen** — zu wissen, wann man innehalten muss, um zu refaktorisieren —, das den erfahrenen Ingenieur vom Neuling unterscheidet. **Epigraph** (Gordon Bell): *"Jede große Computer-Katastrophe entstand dadurch, dass zu viele Ideen an einem Ort zusammengeführt wurden."* **Fazit**: ***"Es ist immer noch nur Programmierung"*** — unversorgter Code verrottet, ob in 18 Stunden oder 18 Monaten; alles, was über guten Code gelernt wurde, gilt weiterhin, der Effekt wird lediglich **verstärkt**. Konvergiert mit der Doktrin *"je schneller die Ausführung wird, desto strikter muss der Rahmen sein"* von [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], dem *"KI-unterstützte Entwicklung ist eine Falle ohne Continuous Delivery"* von [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], und dem *"KI verschiebt Engpässe, sie beseitigt sie nicht"* von dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28; ein Handwerks-Gegenpol zum vibe coding von karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.
#Code-Hygiene#Code-Verfall#Code-Degradation
**David Thomas** (alias **« Pragdave »**) · co-auteur avec Andy Hunt de *The Pragmatic Programmer* (1999, éd. 20e anniversaire 2019) · co-fondateur de **The Pragmatic Bookshelf** et l'un des **17 signataires du Manifeste Agile** (2001). Figure historique du *software craftsmanship*. Billet publié le **6 juin 2026** sur sa newsletter Substack *articles.pragdave.me*.
Analyse von **Olivier Rafal** für **WeNvision** (französisches Beratungsunternehmen), veröffentlicht am **4. Juni 2026** (~4 Min. Lesezeit), zur Einordnung der Gründung der **Tokenomics Foundation** durch die **Linux Foundation** (angekündigt am 3. Juni, in Partnerschaft mit der **FinOps Foundation**), die er als die offizielle Eröffnung **der Ära des „FinOps for AI“** wertet. **Kernthese**: KI hat die Ökonomie der Softwareentwicklung verändert; das **Token** ist zur *„neuen Maßeinheit für Technologieausgaben“* geworden – eine Parallele zur Cloud der 2010er-Jahre (**wiederkehrende und variable** Kosten, die aktiv gesteuert werden müssen), woraus sich die Verschiebung der Anbieter von Pauschalpreisen hin zur **tokenbasierten Abrechnung** ergibt. **Größenordnung (Dringlichkeit)**: *„Laut Goldman Sachs soll sich die weltweite Token-Nutzung bis 2030 um das 24-Fache erhöhen und 120 Billiarden Token pro Monat erreichen“* — eine Größenordnung, die die Token-Effizienz von einem *„technischen Detail“* zu einem Thema für die **Vorstandsetage** macht. Zitat von **J.R. Storment** (Gründer der FinOps Foundation): *„Token-Kosten und -Effizienz sind zu einem Thema auf CEO-Ebene geworden, nicht zu einer technischen Randnotiz.“* **Transparenz-/Standardisierungsproblem**: Die aktuelle KI-Preisgestaltung ist nicht vergleichbar (Input-Token/Caching-Systeme/Output unterscheiden sich von Modell zu Modell) → Die Tokenomics Foundation will die **spécification FOCUS (Open Source) erweitern**, um eine **gemeinsame Sprache** für Einkauf und Vergleich bereitzustellen. **Rafals zentrale Botschaft (jenseits der Kosten)**: *„Bei FinOps geht es weniger darum, Kosten zu senken, als vielmehr darum, die Effizienz zu optimieren“* — die eigentliche Kennzahl ist das **Verhältnis von KI-Kosten zu Geschäftswirkung** (*Time to Market, Qualität, Funktionen, Eco-Design*). **Grenzen reiner Standards**: Technische Normen allein reichen nicht aus; das **Target Operating Model muss neu gedacht werden** (Teams, Prozesse, Datenkultur, Business-Alignment); in den USA wird bereits *„das Ende der Double-Pizza-Teams zugunsten von Sandwich-Teams“* angekündigt. **Warnsignal**: *„ein KI-beschleunigter SDLC wird lediglich […] die Probleme verstärken und einem nur dabei helfen, schneller … gegen die Wand zu fahren“* (bei fehlenden organisatorischen Grundlagen). **Genannte Sponsoren der Foundation**: Accenture, Booking.com, Google Cloud, Microsoft, IBM, Salesforce. **Angebot von WeNvision**: *„gemeinsam eine Roadmap erarbeiten, das Betriebsmodell für das agentische Zeitalter neu denken und die unverzichtbar gewordene finanzielle Governance etablieren.“* **Französischsprachige Lesart, gerichtet an Führungskräfte/Transformationsverantwortliche**, der Fiche [[tokenomics-foundation-linux-finops-token-economics-about-2026-06-03]]; konvergiert mit dem agentischen FinOps-Cluster [[finops-foundation-finops-for-ai-overview-2026-02-17]], finout-finops-ai-agents-four-step-allocation-framework-2026-04-27, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (Token→Ergebnis, Wert > Volumen).
#Tokenomics Foundation#FinOps for AI#FinOps for AI
**Olivier Rafal** · pour **WeNvision** (cabinet de conseil français — bureaux à Paris, Lille, Strasbourg, Bordeaux, Nantes, Toulouse, Belgique, Luxembourg). Olivier Rafal écrit en analyste/conseil familier des préoccupations de comité de direction (ancien analyste IT, profil conseil-transformation). Publié le **4 juin 2026**.
Fachbeitrag des Teams **Data Science & Data Engineering** von Anthropic (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry), veröffentlicht am **3. Juni 2026** im Anthropic-Blog (Kategorie *Enterprise AI*, Schwerpunkt **Claude Code**). **Kernergebnis**: ***"95% of business analytics queries are automated by Claude, with ~95% accuracy in aggregate"*** (bis zu **~99%** in bestimmten Domänen). **Kernproblem**: Analytics ist **kein** Code — *"there's often only a single correct answer using a single correct source"* — es erfordert, **eine Nutzerfrage auf präzise, aktuelle Entitäten** im Datenmodell abzubilden. Drei **Fehlermodi**: (1) **Ambiguität zwischen Konzept und Entität** (z. B. *"active users"*: welche Aktionen? Betrüger ausschließen? welches Zeitfenster?); (2) **Veralterung (Staleness)** (Assets und das Wissen des Agenten werden *"subtly wrong"*); (3) **Retrieval-Fehler** (*"80% of failed queries had the information present in the corpus"*, aber nicht auffindbar). **Lösung = ein 4-schichtiger "agentic analytics stack"**: (L1) **Data foundations** — dimensionale Modellierung, **kanonische Datensätze** *"single source-of-truth"*, Metadaten *"as a first-class product"*, Integrität via CI/CD; (L2) **Sources of truth** in absteigender Vertrauensreihenfolge — **semantic layer** (der Agent ist *"structurally required (by skill instruction) to leverage the semantic layer first"*), Lineage-Graph, **Query-Korpus** (destilliert in strukturierte Dokumente, **nicht** rohes Retrieval), Geschäftskontext (Knowledge Graph: Roadmaps, Entscheidungsprotokolle, Organisation); (L3) **Skills** — der entscheidende Hebel: ***"without skills … didn't exceed 21% … Adding skills gets these numbers consistently above 95%"***; strukturiert **in Paaren** (*Knowledge skill* = Router zu ~30 Referenzdateien; *Unbook skill* = Workflow eines Senior-Analysten: klären → Quellen finden → ausführen → **adversarial review**); Wartung **kolokiert** (*"a code-review hook flags any reporting-model change that doesn't touch a skill file"* → **~90% der Daten-PRs enthalten eine Skill-Änderung**); (L4) **Validation** — Offline-Evals (Schwellenwert ~90% zur Freigabe eines Agenten, Ziel ~100%), **Ablation-Testing** (bemerkenswertes negatives Ergebnis: rohes Grep über tausende SQL-Dateien → Genauigkeit bewegt sich *"less than a point"*), Online (Adversarial Review: **+6% Genauigkeit, +32% Tokens, +72% Latenz**), **Provenance-Footer** (Quellenstufe + Aktualität + Ownership), **aktives Correction Harvesting** (geplante Agenten durchsuchen Kanäle, um Markdown-Korrekturen zu entwerfen). **Strategische Erkenntnis**: *"documentation generated, definitions owned by humans"* — dem LLM zu überlassen, Metriken zu **definieren**, war *"net-negative"*. **Minimaler Startpunkt**: eine Handvoll kanonischer Datensätze + einige Dutzend Evals + ein *thin knowledge skill* erfassen *"most of the upside"*. Starke Konvergenz mit [[shihipar-claude-code-lessons-building-skills-2026-06-03]] (Skills = Ordner, Gotchas, Hooks), der Doktrin *systems around the model* von [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], dem **semantic layer / Ontologie**-Ansatz von talisman-modern-data-101-ontology-pipeline-refresh-2026-05-04 und seale-semantic-agent-model-harness-ontology-data-2026-04-17, dem *context development lifecycle* von debois-tessl-context-development-lifecycle-ai-coding-agents-2026-02-19 sowie der UDA/Knowledge-Graph von netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12.
#self-service analytics#agentic data analytics#Claude Code
**Chen Chang · Clement Peng · Justin Leder · Johanne Jiao · Josh Cherry** — équipe **Data Science & Data Engineering d'Anthropic**. Article publié le **3 juin 2026** sur le blog Anthropic (claude.com/blog) · catégorie *Enterprise AI* · ~5 min de lecture.
Blogbeitrag von **Anthropic / claude.com** von **Thariq Shihipar** (Member of Technical Staff, Claude Code-Team), veröffentlicht am **3. Juni 2026**, der Anthropics **interne Erfahrung** bei der Konzeption und Nutzung von **Skills** destilliert. **Rahmenthese**: Ein Skill ist keine einfache Markdown-Datei, sondern ein **Ordner** (Anweisungen + Skripte + Ressourcen + Konfiguration + Hooks), den der Agent **entdeckt und bearbeitet**; *« Man sollte das gesamte Dateisystem als eine Form von Context Engineering und progressiver Offenlegung betrachten. »* Der Artikel liefert zwei strukturierende Beiträge. **(A) Eine Taxonomie von 9 bei Anthropic beobachteten Skill-Kategorien**: (1) **Library/API Reference** (Dokumentation für interne Bibliotheken/CLIs mit *Gotchas* — z. B. `billing-lib`, `internal-platform-cli`, `sandbox-proxy`); (2) **Product Verification** (Testing/Verifikation via Playwright oder tmux — `signup-flow-driver`, `checkout-verifier`, `tmux-cli-driver`); (3) **Data Fetching & Analysis** (Zugriff auf Daten-/Monitoring-Stacks — `funnel-query`, `cohort-compare`, `grafana`, `datadog`); (4) **Business Process Automation** (wiederkehrende Workflows — `standup-post`, `weekly-recap`, `create-<ticket>-ticket`); (5) **Code Scaffolding** (Framework-Boilerplate — `new-migration`, `create-app`); (6) **Code Quality & Review** (`adversarial-review`, `code-style`, `testing-practices`); (7) **CI/CD & Deployment** (`babysit-pr`, `deploy-<service>`, `cherry-pick-prod`); (8) **Runbooks** (Multi-Tool-Diagnosen — `<service>-debugging`, `oncall-runner`, `log-correlator`); (9) **Infrastructure Operations** (Wartung mit Schutzmechanismen — `<resource>-orphans`, `cost-investigation`). **(B) Eine Reihe von Best Practices**: Nicht das Offensichtliche wiederholen (*« Claude weiß bereits, wie man programmiert, und kann die Codebasis lesen »* → auf das zielen, was dem Standardverhalten widerspricht); den **Gotchas-Abschnitt** verfeinern (*« der Inhalt mit dem höchsten Signalwert in jedem Skill »*); **progressive Offenlegung** über den Dateibaum (je nach Situation auf Referenzdateien verweisen, statt alles im Voraus zu laden); **für das Modell geschriebene Beschreibungen** (*« das Beschreibungsfeld ist keine Zusammenfassung, sondern eine Beschreibung, wann dieser Skill ausgelöst werden soll »*); **Setup-Abläufe** (Konfiguration in `config.json`, andernfalls Abfrage via `AskUserQuestion`); **persistenter Speicher** (Append-only-Logs / JSON über die Variable `${CLAUDE_PLUGIN_DATA}`); **Hilfsskripte** (*« erlaubt es Claude, seine Turns auf Komposition zu verwenden … statt Boilerplate neu zu konstruieren »*); **hooks conditionnels** (nur für die Dauer des Skills aktiviert — z. B. ein Sicherheits-Hook, der destruktive Befehle blockiert). **Verbreitung bei Anthropic**: Skills werden in `./.claude/skills` gespeichert, informell über Slack in einem Sandbox-Ordner geteilt und dann per **PR** in den internen **Marketplace** überführt, sobald sie an Zugkraft gewinnen; **Nutzungsmessung** über einen **hook PreToolUse**, der Aufrufe protokolliert (und so populäre gegenüber wenig genutzten Skills sichtbar macht). Direkte Fortsetzung der Fiche [[shihipar-claude-code-html-unreasonable-effectiveness-markdown-2026-05-10]] (gleicher Autor) und konkrete Ergänzung zu den Skills-Fiches von Anthropic/Willison/Vincent sowie zum Harness Engineering.
#Skills#Claude Code#Anthropic
**Thariq Shihipar** (Member of Technical Staff chez Anthropic, équipe **Claude Code** ; @trq212 / @trq sur X, thariqs.github.io) · pour le blog **claude.com**. Même auteur que la fiche *Using Claude Code: The Unreasonable Effectiveness of HTML* (2026-05-10). Publié le **3 juin 2026**.
**About**-Seite der Website **tokeneconomics.com**, die die **Tokenomics Foundation** vorstellt — ein Projekt der **Linux Foundation**, angekündigt am **3. Juni 2026**, betrieben in **enger Partnerschaft mit der FinOps Foundation**. **Erklärte Mission**: *"establish open industry standards, benchmarks, and best practices for the economics of AI infrastructure"* — sie verknüpft **Produktion, Konsum und Monetarisierung** von Tokens mit dem **Geschäftswert**. **Rahmendefinition von Tokenomics**: *"Tokenomics is not just about the cost of tokens, it's about the entire layer of AI that they drive from production, to consumption to monetization"* — das heißt **die gesamte ökonomische Schicht der KI**, von den Infrastrukturkosten über die Modellwahl bis zur Wertoptimierung. **Phasenthese**: Die frühe KI-Adoption priorisierte **Leistungsfähigkeit**; die aktuelle Phase verschiebt sich hin zu **Effizienz und Wert**, was systematisches Kostenmanagement und **Transparenz** erfordert. **5 Gründungsprinzipien**: (1) ***"Efficiency is a design choice. AI cost is shaped by architecture, not just usage"***; (2) ***"Bigger is not always better. The best AI system is not always the one using the most expensive model"*** (Right-Tool / Routing); (3) ***"Visibility comes before optimisation. Teams cannot manage what they cannot see"***; (4) ***"Value matters more than volume. More tokens, more calls, and more automation do not automatically mean better outcomes"***; (5) ***"Open knowledge benefits everyone"*** (gemeinsame Standards, gemeinschaftliches Lernen, Transparenz). **Governance**: ein **Governing Board** (Branchenausrichtung + Mitteleinsatz) und ein **Technical Committee** (offene Spezifikationen + Benchmarks). **Ergebnisse**: Erweiterung der **FOCUS specification** (FinOps), offene Spezifikationen, Benchmarks, gemeinsame Frameworks und Metriken. **Zielgruppe**: CAIO, CTO, CIO, CFO, Ingenieure, Produktteams, FinOps-Praktiker, Forscher, Start-ups, Unternehmen, öffentlicher Sektor. **Erklärtes Ziel**: Organisationen *"from experimental AI adoption to sustainable AI operations"* zu führen, indem die Disziplin der **variablen Technologieausgaben** auf die Token-Ära ausgeweitet wird. **Relevanz für diese Veille**: Institutionalisierung/Standardisierung von **agentischem FinOps** auf Ebene einer Branchenstiftung — steht in direktem Zusammenhang mit den Fiches [[finops-foundation-finops-for-ai-overview-2026-02-17]], [[finout-finops-ai-agents-four-step-allocation-framework-2026-04-27]], orq-ai-finops-ai-agents-cost-per-outcome-hosseini-2026-04-15, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (Allocation Layer, Token-to-Outcome) sowie mit der Verschiebung **Token → Outcome** (Salesforce/Tallapragada, Sierra/Greenwald). Die 5 Prinzipien decken sich genau mit bereits erfassten Hebeln: Architektur > Nutzung, **Haiku/Sonnet/Opus-Routing**, Beobachtbarkeit vor Optimierung, Wert ≠ Volumen.
#Tokenomics Foundation#Tokenomics#Token-Ökonomie
**Tokenomics Foundation** (entité collective, projet de **The Linux Foundation**, en partenariat avec la **FinOps Foundation**). Page institutionnelle *About* — **aucun auteur individuel nommé**. Annonce datée du **3 juin 2026**.
Am Vorabend des rekordverdächtigen Börsengangs von SpaceX (Zielbewertung von ca. 1,75 bis 1,8 Billionen US-Dollar) veröffentlicht The New York Times eine interaktive Analyse der Bilanz von Elon Musks öffentlichen Versprechen. Von mehr als 600 datierten, quantifizierten Zusagen (Aussagen, Posts, Investorentelefonate) wurden nur ~19% pünktlich eingehalten, wenn überhaupt. Die Quote verschlechtert sich im Zeitverlauf: ~75% eingehalten im Jahr 2015, weniger als 50% im Jahr 2020. Mars, das Robotaxi und die vollständige Autonomie machen den Großteil der wiederholten und verschobenen Ziele aus. Der Beitrag verknüpft diese Bilanz mit dem SpaceX-Prospekt, der nun auf KI setzt (xAI wurde eingegliedert) und selbst einräumt, dass der Zeitplan für seine großen Vorhaben nicht bestimmbar ist.
Guide des Medienunternehmens **Every** (every.to/guides), veröffentlicht am **2. Juni 2026** und mitunterzeichnet von **Mike Taylor, Laura Entis und Claude**, der eine **8-Stufen-Reifegradskala für die KI-Einführung** vorschlägt. **Kernthese**: Die Einführung von KI **ist kein Wettlauf um maximale Ausgereiftheit** — ***„eine höhere Stufe ist nicht zwangsläufig besser“*** ; man muss die Stufe identifizieren, die **zum eigenen Workflow und Vertrauensniveau passt**, und dann regelmäßig neu bewerten, ob ein Aufstieg um eine Stufe **echten Mehrwert** bringt. ***„Der beste Weg, in KI einen Nutzen zu finden, besteht darin, sie so einzusetzen, dass sie zur eigenen Arbeit passt.“*** **Strukturierende Achse**: Auf jeder Stufe *„delegiert man mehr von seiner Arbeit an die KI – und bringt ihr mehr Vertrauen entgegen“* (zunehmende Delegation + Vertrauen). **Die 8 Stufen**: **(1) Chatbot** — Konversationsschnittstelle ohne eingebetteten Kontext (ChatGPT, Claude, Gemini); **(2) Copilot** — in den Arbeitsbereich eingebettete KI mit Zugriff auf die aktuelle Datei (Cursor, Claude in Excel, Gemini in Docs); **(3) Agent** — reaktives System, das Schritt für Schritt ausführt und dabei um Freigabe bittet (Cowork, Codex); **(4) Autopilot** — man beschreibt das **Ergebnis**, und der Agent führt es eigenständig aus; überprüft wird nur das **Endergebnis** (Lovable, Codex, Claude Code; verbunden mit *vibe coding*); **(5) Workflows** — Engineers bauen **Harnesses** rund um Agenten (Planung, Review, Vertrauensprüfungen, Guardrails; Compound engineering, Claude Workflows, Copilot AI Studio; Übergang von einmaligem vibe coding → **agentic engineering**); **(6) Assistent** — **proaktive, dauerhaft aktive** Agenten, die einen Bereich überwachen und Informationen liefern, ohne dazu aufgefordert zu werden (OpenClaw, Hermes Agent, Claude Managed Agents; z. B. `heartbeat.md` alle 30 Minuten); **(7) Multi-Agent** — gleichzeitige Verwaltung **mehrerer langlaufender Agenten** mit unterschiedlichen Rollen (Claude Managed Agents, OpenClaw, Codex Goals; *„eindeutig im Bereich des Senior Engineering“*); **(8) Orchestrator** — ein **Agent-Manager** leitet ein Team von Sub-Agenten (Planung, Delegation, Überwachung, Konsolidierung; Gas Town, Paperclip, Symphony/OpenAI; *„hochgradig experimentell“* — selbst führende Engineers übernehmen diese Rolle). **Sweet Spots nach Rolle**: **Wissensarbeiter** bewegen sich typischerweise zwischen den Stufen **1-4**, **Engineers** zwischen **5-8**. **Kanonische Parallele zur Einarbeitung eines Praktikanten**: *„Rechnen Sie damit, einen ähnlichen Aufwand in Ihre Agenten zu investieren, bevor Sie ihnen vertrauen können … auf der nächsten Autonomiestufe“* ; sowie der Kennsatz ***„Sie würden nicht damit prahlen, acht Praktikanten über Nacht an einem Schlüsselprojekt arbeiten lassen zu haben, ohne deren Ergebnisse geprüft zu haben.“*** Die richtige Stufe hängt von **4 Kriterien** ab: Qualität der Ergebnisse, Kosten, Zuverlässigkeit (Vertrauenswürdigkeit), Tragweite eines Scheiterns; und die **Modellfähigkeit** verschiebt schrittweise die als „sicher“ geltende Autonomiestufe. Ein Framework, das sich direkt nutzen lässt, um auf der Beratungsseite eine **Einführungsdoktrin** zu strukturieren. Konvergenz mit *Systemen rund um das Modell* (Dropbox/Okumura), *harness engineering* (Böckeler, Lattice, Wescale), Karpathy (vibe coding → agentic engineering), Cherny (/loop + Routines) und der Doktrin des *Agent-Managers* (BFM/Girard).
#KI-Einführung#Reifegradskala#acht Stufen
**Mike Taylor** · **Laura Entis** et **Claude** (co-auteurs déclarés) · pour **Every** (every.to) · rubrique *Guides*. Mike Taylor est un auteur connu sur les sujets prompt/AI (co-auteur de *Prompt Engineering for Generative AI*) ; Laura Entis est journaliste/éditrice. La co-signature explicite de **Claude** comme auteur fait partie du positionnement éditorial d'Every (entreprise AI-native). Publié le **2 juin 2026**.
Meinungsbeitrag von **Olivier Rafal** (Consulting Director Strategy, **WeNvision** — Gruppe **SFEIR**; ehemaliger Chefredakteur von *Le Monde Informatique*), veröffentlicht am **1. Juni 2026** auf **CIO-Online**, aufgebaut um ein **Paradox**: im Zeitalter der KI **verändert sich alles … und nichts verändert sich** im Software Engineering. **Was sich verändert, ist das Betriebsmodell.** Die Rollen werden neu definiert: Der **Product Owner** wechselt vom Backlog-Zerlegen zum **Generieren von für KI nutzbarem Kontext**; der **Entwickler** wechselt vom Codeschreiben zum **Rahmen, Steuern und Überprüfen** der Agentenausführung; **QA** erhält die Fähigkeit, den **erwarteten Nachweis** im Voraus zu definieren. Die Teamstruktur wandelt sich von *„double pizza teams“* (Übergabeketten von ca. 8 Personen) zu ***„sandwich teams“***: einer **engen Paarung aus einem Fachexperten und einem Tech Lead, beide KI-unterstützt**, mit weiteren Kompetenzen als Unterstützung. Interne Zahl von **Sfeir**: *„dieses Duo steuert nun etwa 80 % der Produktionskette“*, die verbleibenden ca. 20 % (Architektur, Data Governance, Sicherheit) werden zentralisiert. Schlüsselzitat: ***„Es ist kein Werkzeugproblem, es ist ein Problem des Betriebsmodells.“*** **Was sich nicht verändert, ist die Disziplin des Zyklus.** Die **SDLC**-Phasen (definieren → bauen → verifizieren → bereitstellen → warten) bleiben identisch und nicht verhandelbar; KI hebt keine von ihnen auf, sie **verschärft** sie: ***„aller Spielraum, den das menschliche Tempo früher – wenn auch unvollkommen – absorbiert hat, wird bei KI-Geschwindigkeit zu Fehlern von industrieller Tragweite“*** (eine Metapher aus dem Amateur- versus Profisport). Daraus ergeben sich **drei unverletzliche *Gates*** (menschliche Kontrolle): **Spezifikation, Planung, Delivery-Review**; Validierung **durch Nachweis** (nicht durch die eigenen Behauptungen der KI); **systematische Kapitalisierung** (jeder Zyklus speist den nächsten) → gemessenes Ergebnis: **−30 % Korrekturiterationen nach ca. 10 Zyklen**. Prinzip: ***„je schneller die Ausführung, desto strikter muss der Rahmen sein.“*** Herangezogene Konzepte: **harness** (an den Kontext angepasste agentische Regeln), **vibe-coding**, das als **im Unternehmen nicht haltbar** eingestuft wird. **Dritte Säule = Governance, FinOps & wertorientiertes Management**: **variable und wiederkehrende** KI-Kosten (~**10 €/Stunde** pro augmentierter Rolle), Wechsel von Pauschallizenzierung zu nutzungsbasierter Abrechnung (eine Parallele zur Cloud der 2010er-Jahre); **FinOps** zielt nicht auf Kostensenkung, sondern darauf, *„die Werkzeugeffizienz zu optimieren“* (Kosten im Verhältnis zum Wert); vorab abgestimmte **Geschäftskennzahlen** (Time-to-Market, Funktionsumfang, Performance, Eco-Design). **Fazit**: Die Beschleunigung macht die Grundlagen **nicht verhandelbar**; die Herausforderung ist **organisatorisch und kulturell**, nicht technologisch – ohne Absicherung der Business-Beziehung und kollektiver Disziplin **verstärkt** ein KI-gestützter SDLC nur die Probleme (schneller gegen die Wand fahren). Erweitert die WeNvision-Doktrin aus [[rafal-wenvision-ia-generative-produit-techno-pas-projet-2024-02-23]] und [[rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04]]; trifft sich mit *systems around the model* dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28, *harness engineering* osmani-agent-harness-engineering-2026-04-19, agentischem Salesforce und der Debatte um den *agent manager* (BFM/Girard, SFEIR).
#Software Engineering#KI#alles verändert sich nichts verändert sich
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (groupe **SFEIR**). Ancien **rédacteur en chef du *Monde Informatique*** · et auparavant consultant analyste du marché IT (~10 ans). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Publié le **1er juin 2026**.
Atlassian-Datenstudie (Inside Atlassian), die den tatsächlichen Ertrag eines **AI-native SDLC** misst, der von **Rovo Dev** angetrieben wird. Bei 3.400 Repositories von 2.500 Kunden (ein Quasi-Experiment mit Propensity-Score-Matching) mergen adoptierende Repositories **19 % mehr PRs pro Monat**; bis zu **37–51 %** bei Repositories mit geringer/mittlerer Aktivität und **59–87 %**, wenn **3 bis 5 Mitglieder** des Teams das Tool nutzen. Auf der Effizienzseite sparen Entwickler **2–3 Std./Woche** (≈10 % der 24 Stunden, die für Coding und Review aufgewendet werden), d. h. 20–30 Stunden/Woche, die bei einem Team von 10 reinvestiert werden. Die These: Solows (1987) „Produktivitätsparadox“ auflösen, indem man von **Nutzungsmetriken** (Tokens) zu **Wirkungsmetriken** (Durchsatz, eingesparte Zeit, Fehlerquote, Zufriedenheit) übergeht. Empfehlung: mit einem **Team** (nicht einer Einzelperson) beginnen und 2–3 Monate später messen.
Blogbeitrag von **Pasquale Pillitteri** (Softwareingenieur, Palermo), veröffentlicht am **29. Mai 2026** (FR-Version), 18 Minuten Lesezeit, Rubrik *Claude Code & Anthropic*. **Kernthese**: *« Claude Opus 4.8 ist das leistungsstärkste SEO-Modell des Jahres 2026, aber fast alle nutzen es falsch »* — kein Modellproblem, sondern ein **System**-Problem. Die goldene Regel: ***« Strategie ist ein Whiteboard, Produktion ist ein Fließband »*** — SEO muss **in zwei getrennte Phasen aufgeteilt werden**, und deren Vermischung ist *« der schnellste Weg, ein Modell zu verschwenden, das fünf Dollar pro Million Input-Token und fünfundzwanzig für Output kostet »*. **Modellkontext**: Opus 4.8 veröffentlicht am **28. Mai 2026** (41 Tage nach Opus 4.7), **1-Mio.-Token**-Kontext, **GraphWalks Long-Context F1 bei 1M: 40,3 % → 68,1 %**, **SWE-bench Verified 88,6 %**, **USAMO 2026 96,7 %** (+27,4 Punkte), **HLE with tool 57,9 %**, unveränderter Preis **5 $/25 $** pro Mio. Token, **Fast Mode 2,5× zu 10 $/50 $**, vier **Aufwandsstufen** (Low, High, Extra, Max). **Das zentrale Anti-Pattern** = *« das riesige Gespräch »* / **Context Drift**: die Vermischung von Strategie, Keyword-Recherche, Wettbewerbsanalyse und Texterstellung in einem einzigen Chat erzeugt einen *« Brei widersprüchlicher Absichten »* → das Modell driftet zu **generischen Best Practices** („holistic optimization“, „strategic approach“) statt zu datenverankerten Inhalten. **Phase 1 – Strategie (Whiteboard, visuelle UI, einmalig)**: Dashboard / Google Sheet / Claude.ai-Canvas, um gemeinsam anhand der Daten zu entscheiden. **3 Spielzüge**: (a) **klassifizierte Keyword-Recherche** (Tabelle mit Volumen / Schwierigkeit 0-100 / Intent / Geschäftspotenzial / Priorität = Volumen÷Schwierigkeit×Geschäftsgewichtung); (b) **visuelle Wettbewerbsanalyse** (Themenabdeckungs-Matrix, Lücken); (c) **phasenweise Roadmap** (Quick Wins M1-2 / mittelfristig M3-6 / Pillar-Seiten M7-12). Der **Extra/Max**-Modus ist hier gerechtfertigt (*« eine richtige strategische Entscheidung ist tausend gut geschriebene Seiten zu den falschen Keywords wert »*). 3 abgeschlossene Artefakte, gespeichert in Notion/Drive. **Phase 2 – Produktion (Fließband, Opus 4.8 + MCP)**: Das Modell wandelt sich vom Strategen zur **Ausführungsmaschine**; jede Entscheidung wird über das **Model Context Protocol** in **Live-Daten verankert**. **Minimaler MCP-Stack**: **GSC MCP** (AminForou/mcp-gsc, 500+ Stars), **offizieller Ahrefs MCP** (98 Stars), **GA4 MCP**; das Repo `modelcontextprotocol/servers` = **86.440 Stars**, **10.000+ aktive Server**, 97 Mio. SDK-Downloads/Monat. Setup ~35 Min., monatliches Refresh ~20 Min. **Wöchentliche Schleife**: ein einziger Prompt zieht Live-Daten, erstellt das Brief (Top-10-SERP + GSC + Ahrefs), leitet H2/H3 ab, schreibt, prüft die Dichte, schlägt Titel vor → **+45 % Produktivität**, Entwurf in **6-12 Min.** (expliziter Verweis auf **Ryan Law / Ahrefs Content Engineering**, 23 Skills). Erwähnt Anthropics **Dynamic Workflows** (bis zu 1.000 Subagenten). **4 häufige Fehler**: (1) die Zahlen nicht zu überprüfen (Stichprobenkontrolle verpflichtend, *trust & verify*); (2) Semrush/Ahrefs vollständig zu ersetzen (MCP ist eine **zusätzliche Schicht**, kein Ersatz); (3) die **Paid-Organic-Content-Lücke** zu ignorieren (Kundenfall aus dem Bildungsbereich: **2.742 verschwendete Begriffe / 351 Chancen** in 90 s identifiziert); (4) Opus 4.8 dort einzusetzen, wo **Haiku 4.5** ausreicht (Meta-Beschreibungen, Alt-Texte). **Kosten**: 1-3 $ pro Artikel mit 2.500 Wörtern. **Sonnet 4.6** genügt für die laufende Produktion, Opus 4.8 bleibt der Strategie vorbehalten. SEO-optimierter und selbstreferenzieller Artikel (der Autor schreibt über SEO in einem Inhalt, der selbst darauf ausgelegt ist, für „Opus 4.8 SEO“ zu ranken). Direkte Konvergenz mit **Ryan Law/Ahrefs** (zitiert), **Systemen rund um das Modell** (Dropbox/Okumura), **Skills-over-Prompts** (Lattice), Haiku/Sonnet/Opus-Modell-Routing (Gupta Token-to-Outcome).
#Claude Opus 4.8#KI-SEO#Zweiphasen-Workflow
**Pasquale Pillitteri** — Ingénieur informatique / développeur logiciel basé à **Palerme** (Italie) · certifié Innovation Manager UNI 11814:2021. Auteur d'un blog tech actif (rubrique *Claude Code & Anthropic*) · avec une newsletter hebdomadaire (~3,4k lecteurs). Article publié en version **FR** le **29 mai 2026** (lendemain de la sortie d'Opus 4.8).
Beitrag aus dem **Dropbox Tech Blog** (Bereich *culture*), veröffentlicht am **28. Mai 2026** von **Kazuaki Okumura** (Dropbox, Rolle im Artikel nicht näher spezifiziert), als Rückblick auf einen Vortrag auf der Konferenz **DX Annual 2026** (Developer Productivity). **Kernthese**: Engineering-Produktivität muss über die *Code-Generierung* hinausgehen. *« Accelerating code generation simply shifted some bottlenecks downstream »* — KI hat den Code-Durchsatz massiv erhöht, aber *« the faster code moves, the more pressure it puts on review queues, CI systems, validation workflows, release coordination, and production operations »*. Die eigentliche Herausforderung besteht nicht mehr darin, schneller Code zu schreiben, sondern den gesamten SDLC in die Lage zu versetzen, ein deutlich größeres Volumen **sicher aufzunehmen, zu validieren und auszuliefern**. **Vom Copilot zum Agenten**: Die erste Welle (Code-Erklärung, Snippets, Q&A) fungierte *« as copilots alongside the engineer »*; der Agent hingegen *« can take a scoped task, inspect the codebase, edit files, run tests, iterate on failures, and return an artifact for human review »* — wobei der Engineer weiterhin *« accountable for intent, architecture, quality, and release decisions »* bleibt (mehr Parallelarbeit, mehr Optionen, Auslagerung repetitiver Ausführung). **Nova** = Dropboxs **interne** Coding-Agent-Plattform: eine Aufgabe in natürlicher Sprache beschreiben, Ausführung in einer kontrollierten Umgebung mit Codebase-Kontext. Zentraler Datenpunkt: ***« Nova's value comes less from the model itself than the systems surrounding it »*** (Codebase-Kontext, interne Praktiken, sichere Ausführung, Workflow-Integration, menschliche Prüfung); Nova macht heute **rund 1 von 12 PRs bei Dropbox** aus (wachsende Adoption) und erstreckt sich über Features hinaus auf **Migrationen, Behebung flakiger Tests, Bug-Untersuchung, Dependency-Updates** (Arbeit mit hohem Aufwand/geringem Mehrwert). **Produktgeschwindigkeit messen, nicht Code-Output**: *PR-Durchsatz*, ein nützliches Signal, solange die Coding-Geschwindigkeit der limitierende Faktor war, *« was no longer sufficient »*. Ein **vierstufiges** Messmodell: ***Fuel*** (werden KI-Tools genutzt?) → ***Adoption*** (wie verändern sich die Workflows teamübergreifend) → ***Output*** (trägt KI zur Produktionsarbeit bei?) → ***Impact*** (*« improving product velocity and reducing the time it takes to move from idea to customer value »*). Erfasste Qualitätssignale: **Durchlaufzeit des Code-Reviews, Erfolgsquote von Tests im ersten Durchlauf, Fehlerquote, Nacharbeitsquote**. *« Quality and trust matter as much as speed »* — der Kern des Wandels: *« moving from local activity metrics toward broader system outcomes »*. **Auch die Workflows müssen sich weiterentwickeln**: Dies ist *« not just a tooling shift »*, sondern eine Veränderung des **Betriebsmodells** — die Rolle des Engineers verschiebt sich hin zu *« defining intent, mapping problems, reviewing generated changes, and making higher-context architectural and quality decisions »*. **Enablement** ist ebenso entscheidend wie das Tool selbst (praktisches Lernen, Hackathons, Workflow-Spotlights, Bootcamps, von Peers geleitete Beispiele); die Adoption verläuft teamübergreifend unterschiedlich schnell; *« The goal is not to force every workflow through an agent »* — das Ziel ist, es dort *« useful, safe, measurable, and repeatable where it creates meaningful leverage »* zu machen. **Erkenntnisse**: ***« AI doesn't eliminate bottlenecks in software development, but it does move them »*** (stromabwärts: Review, Validierung, Testing, Release, Produktionsbetrieb) → die Optimierung des alten Engpasses erzeugt nicht mehr denselben Hebel. *« The advantage will not come from access to the same foundation models everyone else can use. It will come from the systems built around those models: context, internal tooling, quality controls, and the workflows that connect them together. »* Der Druck baut sich auch **stromaufwärts** auf (Produkt & Design): strukturierte Specs, Design-Klarheit, schärfere Problemformulierung. Schluss: ***« The future of engineering productivity will not be defined solely by who has the best models. It will be defined by who builds the best systems around them »***; *« The real challenge is no longer just generating more code, but building engineering systems that can reliably turn AI-assisted output into valuable experiences for our customers »*. Direkte Konvergenz mit **Salesforce/Tallapragada** (Effective Output: Wert statt Volumen messen; kein Trade-off zwischen Geschwindigkeit und Qualität), **Gupta** (Token-zu-Outcome-Zuordnung, Kosten eines abgeschlossenen Outcomes), **DORA** (jenseits des Durchsatzes) und die Verschiebung des KPI hin zum **System-Outcome** (Idee→Kundennutzen).
**Kazuaki Okumura** — Dropbox (rôle non précisé dans l'article ; le billet reprend une intervention présentée à la conférence **DX Annual 2026** sur la productivité développeur, ce qui suggère un profil engineering leadership / platform, sans confirmation). Publié sur le **Dropbox Tech blog** (dropbox.tech) · rubrique *culture* · le **28 mai 2026**.
Viraler X-Thread (**230,5K Aufrufe**, 28. Mai 2026, 1:51 Uhr) von **Jaya Gupta** (@JayaGup10, Investorin — vermutlich bei Foundation Capital, Autorin des *Context Graphs*-Frameworks) mit dem Titel ***„Token Budget Wars“***. **Kernthese**: ***„Enterprise AI has moved from adoption to allocation“*** — Phase 1 der Unternehmens-KI hat bewiesen, dass Modelle funktionieren; Phase 2 wird entscheiden, **wie viel diese Arbeit wert ist**. Die neue Währung an der Unternehmensspitze ist die **Fähigkeit, den KI-ROI zu quantifizieren**: *„zeig mir den Wert“*. Kernkonzept: ***marginaler Token-Nutzen*** = *„der Geschäftswert, den jeder zusätzliche Dollar an Inferenz schafft“* — die Zahl, die im großen Maßstab zählt und die **die meisten Unternehmen nicht sehen können**. Zeitachse: **Claude wurde im November 2025 ausgeliefert**, nachdem die Jahresbudgets 2026 bereits festgelegt waren → schon im **Q1** lagen Unternehmen *„um ein Vielfaches über Plan“* → Inferenz hört auf, ein Experimentierposten zu sein, und wird zu **wiederkehrenden Betriebskosten**. Verschiebung von **Experimentieren (ein paar 100.000 $) → Infrastruktur (siebenstellig, 1 Mio. $+)**: Im Infrastruktur-Maßstab erzeugt **technische Varianz materielle Schwankungen in der Gewinn- und Verlustrechnung — zwei Durchläufe desselben Workflows mit demselben Input können sich im Token-Kostenaufwand um das 5- bis 10-Fache unterscheiden**, ohne dass sichtbar etwas kaputt ist, *„eine Zahl, die der CFO dem CEO erklären muss“*. **KI konkurriert mit Arbeitskraft**: 3 Arten von Budgetanfragen (ausgelagerte Arbeit ersetzen / interne Arbeit ersetzen / Umsatz generieren) → Verschiebung hin zu den ***Kosten eines abgeschlossenen Ergebnisses*** (Kosten pro gelöstem Ticket, bearbeitetem Schadensfall, geprüftem Vertrag, abgeschlossener Rechnung, vermiedener Neueinstellung, gehaltenem Kunden, bewegtem Umsatzdollar). **BPO = die einfachste Vergleichsbasis** (bereits in abgeschlossenen Einheiten bepreist); interne Arbeit ist deutlich schwieriger (multiskillte Mitarbeitende, diffuse Gewinne, Widerstand der Personalabteilung gegen Stellenabbau). **Warum es sich von SaaS unterscheidet**: SaaS hat gelernt, Nutzung als Proxy für Wert zu behandeln; KI bricht diesen Proxy — *„Signal und Rauschen teilen sich dieselbe Einheit“* (den Token), *„SaaS-Nutzung sagte dir, dass die Software adoptiert wurde. KI-Nutzung sagt dir, dass der Zähler läuft. Sie sagt dir nicht, ob dein Unternehmen brodelt.“* **Drei Ursachen für die Unsichtbarkeit des marginalen Token-Nutzens**: (1) ***Retry-Tails*** — Tokens pro gelöstem Workflow ≈ **T/p**; ein Rückgang der Abschlussquote von 90 % auf 70 % erhöht die effektiven Kosten um ~**28 %**, nicht 20 %, weil sich Fehlschläge kumulieren; (2) ***Kontext-Inflation*** — die Inferenzkosten verhalten sich ≈ **O(n²)** zur Kontextlänge (Attention), eine Verdopplung des Kontexts **vervierfacht** die Kosten des Reasonings (Over-Retrieval: 50 Dokumente, wo 5 genügen würden); (3) ***Routing*** — standardmäßig wird das leistungsstärkste Modell verwendet (einfache Klassifikation läuft auf einem komplexen Reasoning-Modell); über Millionen von Aufrufen hinweg macht der Unterschied zwischen dem Routing einfacher Aufgaben zu einem kleinen Modell und dem Versenden von allem an das Frontier-Modell *„den Unterschied zwischen einer überschaubaren Rechnung und einem Problem auf Vorstandsebene“* aus. **Sektorale Aufteilung**: **Software**-Unternehmen = ein Problem der **Produktivitätsmessung** (bereits instrumentiert: PRs, Commits, Deployments, Incidents, Zykluszeit, MTTR — verfolgt *„KI-Entlassungen“*); **Nicht-Software**-Unternehmen = ein **Transformations**-Problem (operative Arbeit: Schadensfälle, Underwriting, Support, Compliance-Prüfungen, Ausnahmen in der Lieferkette, Zahlungsstreitigkeiten — *im Audit korrekt, nicht nur im Durchschnitt korrekt*). **Die fehlende Schicht = Token-zu-Ergebnis-Attribution**: eine Umwandlungsschicht, die Inferenzausgaben → geleistete Arbeit → Geschäftsergebnis verknüpft und 3 Fragen beantwortet (reale Kosten einschließlich Retries/Korrekturen; welche Teile der Trace zählten vs. Thrashing; hat die Arbeit das Betriebsmodell verändert). ***Messung wird zu Gedächtnis***: Um einen Token mit einem Ergebnis zu verknüpfen, müssen **Entscheidungs-Traces** erfasst werden (was der Agent gesehen, abgerufen, aufgerufen, ignoriert hat, wo er es erneut versucht hat, wann ein Mensch eingegriffen hat) — *„die Entscheidungsbegründung ist eines der am schnellsten verderblichen Vermögenswerte eines Unternehmens“* (lebt in Slack, E-Mails, Eskalationsanrufen, in den Köpfen der Menschen). Agenten **erzeugen** diese Traces; zunächst erfasst, um die Ausgaben zu rechtfertigen, werden sie *„wertvoller als der Kostenbericht“* → ein **Context Graph** (*„auch wenn ich dieses Wort in letzter Zeit schon so leid bin“*). **Die Allokationsschicht ist der Preis**: Wer die Token-zu-Ergebnis-Attribution besitzt, trifft die **Allokationsentscheidungen** (welche Workflows mehr Rechenleistung verdienen, welche gedeckelt werden, welche zu günstigeren Modellen wechseln, welche menschlich bleiben, welche BPO ersetzen). Unternehmen werden das nicht allein tun — sie werden es **als Transformation einkaufen** (Fortune-500-Playbook: McKinsey- und Palantir-Alumni + top-down agierender CEO, nach Art von ERP/BI/digitaler Transformation, ein *„Programm“* mit einem Executive Sponsor und einer Infrastruktur, die zur **neuen Single Source of Truth** wird). Eingerahmt mit **Charlie Munger**: *„zeig mir den Anreiz, und ich zeige dir das Ergebnis.“* Organisatorische Nebenthese: der jahrzehntealte Führungsinstinkt, dass *große Teams = große Aufgaben/Reichweite/Macht* bedeuten → sobald Intelligenz zur **knappen Ressource** wird, ist das neue Statussymbol *„wie viel davon man orchestriert.“* Direkte Relevanz für die **Positionierung Cost Optimization / agentisches FinOps**: bestätigt empirisch die Hebel (Model-Routing, Prompt-Caching, Context-Hygiene, Sub-Agenten) und verschiebt den KPI hin zu **Kosten pro abgeschlossenem Ergebnis**. Starke Konvergenz mit Bains *Cross-System Labor* (Execution-Data-Moat, Cursor), Ngs *No AI Jobpocalypse* (Preisgestaltung verankert am Gehalt der ersetzten Arbeitskraft), DORA ROI (Kosten pro Feature), Mensch/Mistral (Elektron→Token), Ensarguet (Ökonomie der Berechnung), Foundation Capitals *Context Graphs* (Entscheidungs-Traces, gleiche Autorin), Wescales *Token Burning*, BFM/Girard (Token = Wert-Treibstoff).
**Jaya Gupta** (@JayaGup10) — investisseuse / VC. Très probablement **Foundation Capital** (le thread s'auto-réfère au cadre ***Context Graphs*** — *« ahem, context graph, although I am so tired of that word these days »* — concept porté par Foundation Capital, cf. fiche `bain-100b-saas-opportunity` qui cite *Foundation Capital — Context Graphs trillion-dollar opportunity, 2025-12-22*). Thread publié sur X le **28 mai 2026 à 1h51** · **230 · 5K vues** · format essai long en un seul post. Une réponse notable de **@tuning_engines** (*« DevSecFinOps for the Agentic Era »*) : *« Tokens will basically have to be managed like headcount […] model hierarchies too »*.
Offizieller **Salesforce News**-Blogbeitrag (Rubrik *Agentic Enterprise*, Reihe *„Pioneering the Agentic Shift Within Salesforce Engineering“*), veröffentlicht am **27. Mai 2026** (6 Minuten Lesezeit) von **Srinivas „Srini“ Tallapragada**, *President and Chief Engineering and Customer Success Officer* bei Salesforce. Direkte Fortsetzung eines früheren Beitrags (*„How we got our engineers to use AI — without breaking everything“*), der das Überschreiten von **>90 % Adoption** schilderte. **Kernthese**: Salesforce Engineering ist von einer Welt, in der KI ein nützlicher *Copilot* war, zu einer Welt übergegangen, in der **agentische Tools den Software-Entwicklungszyklus (SDLC) selbst steuern** — Code schreiben, PRs reviewen, Tests generieren, Dokumentation aktualisieren, Deployments verwalten, Arbeit koordinieren, die früher über menschliche Übergaben lief. **Kanonische Signalentscheidung**: unternehmensweite Standardisierung auf **Claude Code** + ***„we removed all token limits“*** — *„remove every last piece of friction between our engineers and the tools that make them faster and more effective“*. **Zentrales empirisches Ergebnis** (April 2026 vs. April 2025): abgeschlossene Arbeitspakete pro Entwickler **+50,8 %**, gemergte PRs pro Entwickler **+79 %**, und vor allem der **Effective-Output-Score** (ein ML-Maß für den **realen Wert des gelieferten Codes**, nicht dessen Volumen) **+151,3 % im Jahresvergleich**. **Vorzeige-Anwendungsfall**: Migration von **33 API-Endpunkten** auf eine Cloud-native Architektur, auf dem klassischen Weg geschätzt auf **~231 Personentage** (7 pro API), abgeschlossen in **13 Tagen — 18-mal schneller** — mittels eines **regelbasierten, in Claude gebauten Frameworks** (Markdown-Dateien + Referenzimplementierungen), wobei PR-Feedback laufend in das Regelwerk zurückgespeist wurde, **autonome LLM-Loops (build, fix, validate)** ohne manuellen Eingriff, parallelisiert über isolierte Umgebungen → **5 PRs**, wobei der größte **21 Endpunkte mit 100 % Testabdeckung** lieferte. **Kein Zielkonflikt zwischen Geschwindigkeit und Qualität**: über die Plattform **Engineering 360** (die Engineering-Daten aus Hunderten von Systemen zentralisiert) **sinkt die Gesamtzahl der Incidents um 5 %**, trotz der steigenden Zahl an PRs (*„quality doesn't suffer from speed. It benefits from it“*), dank **strukturell eingebetteter Sicherheits-Leitplanken und Qualitätsstandards** im agentischen Workflow (Trust als Wert Nr. 1). **SDLC-Überholung**: sobald KI eingeführt ist, **reißen die Ingenieure Workflows ein und bauen sie neu auf** (welche Prozesse lassen sich eliminieren? welche Übergaben sind jetzt überflüssig? wo erledigt noch ein Mensch Arbeit, die ein Agent übernehmen könnte?). **Neues Ingenieurshandwerk**: **Claude-Code-Skills** (paketierte, wiederverwendbare Fähigkeiten, die Teamkontext, Namenskonventionen, Muster kodieren) werden zu einem gemeinsamen, komponierbaren **Engineering-Artefakt**; **AI Expert Suite** + **Salesforce Foundation Plugins** = eine institutionalisierte, kuratierte Skill-Bibliothek (interner Benchmark: **höhere Genauigkeit und Zuverlässigkeit, weniger unnötige Kosten**); **Subagents & Agent-Teams** parallelisieren Arbeitsstränge (*„They describe the outcome, and a set of coordinated agents figures out the steps“*). **Was weiterhin schwierig bleibt**: (1) **Kontextmanagement** in langen Sessions — die **Qualität der CLAUDE.md-Datei** schwankt stark und wirkt sich erheblich auf die Output-Qualität aus; (2) **agentische Sicherheit** = ein grundlegend anderes Modell (Agenten, die *handeln*, nicht nur *vorschlagen* → größerer Blast Radius); (3) **sich wandelnde Rollen** (wie werden Junior- zu Senior-Ingenieuren, wenn KI die Einstiegsarbeit übernimmt? Rolle von Designer/PM? die Ausführungseinheit = Scrum-Team → Experimente mit Einheiten aus 1 oder 3 Personen). Fazit: *„It changed what was economically possible“*; die erklärte Ambition lautet **„the most automated, agentic SDLC in the industry“**. Berührt sich direkt mit Gupta (*Kosten eines abgeschlossenen Outcomes*, Grenznutzen des Tokens), Greenwald/Sierra (outcome-basierte Preisgestaltung), DORA (ROI / Kosten pro Feature) und der BFM/Girard-Debatte (Token als Wert-Treibstoff, nicht als zu kürzende Kostenposition).
#Agentischer SDLC#agentischer SDLC#Claude Code
**Srinivas « Srini » Tallapragada** — *President and Chief Engineering and Customer Success Officer* de **Salesforce**. Plus d'une décennie chez Salesforce · dirige l'ingénierie mondiale de la plateforme unifiée. Auteur de la série *Agentic Enterprise* sur le blog Salesforce News ; ce billet (27 mai 2026) est la **suite** d'un premier opus consacré à l'adoption de l'IA par les milliers d'ingénieurs Salesforce (*« How we got our engineers to use AI — without breaking everything »*). Position d'autorité = **dirigeant exécutif** parlant en son nom et au nom d'une organisation d'ingénierie à grande échelle (donnée terrain à l'échelle d'un hyperscaler SaaS) · avec accès aux métriques internes (Engineering 360, Effective Output).
Wegweisender Essay von **Dan Shipper** (CEO Every), veröffentlicht am **21. Mai 2026** auf every.to, *"After Automation"* — eine argumentative Erwiderung auf die These vom KI-getriebenen Zusammenbruch der Wissensarbeit. **Kernthese**: Der KI-Fortschritt schafft **mehr Arbeit für Menschen, nicht weniger**. Looping-Mechanik (***"der Kommodifizierungszyklus"***): (1) KI kommodifiziert die menschliche Fähigkeit von gestern; (2) diese billige Fähigkeit wird breit übernommen → Überfluss; (3) Überfluss erzeugt *Gleichförmigkeit* (den *"Slop"*); (4) Menschen verlangen Unterschied → erneuerte Nachfrage nach Experten; (5) Experten nutzen KI, um die Probleme von heute zu lösen → Schleife. **Kanonisches Zitat**: ***"There's more work to do than ever"***; ***"AI commoditizes the residue of human expertise, creating demand for what's different"***. **Zentraler konzeptueller Rahmen — Frame vs. Framer**: Benchmarks messen Leistung ***"within frames"*** (spezifische Problemrahmungen); sobald diese gesättigt sind, *setzt eine Änderung des Rahmens den Zähler zurück* — Modelle **eskalieren innerhalb von Rahmen, ersetzen aber nicht die Framer**. Kernformel: ***"the frame is not the framer"***. Selbst bei AGI müssen Menschen **Ziele festlegen und Ergebnisse interpretieren** — *"the frame problem regenerates one level up"*. **Der "Human Sandwich"**: Mensch setzt Rahmen → KI führt aus → Mensch beurteilt und erweitert. **Zwei Arbeitsmodi mit Agenten**: (a) ***agent employees*** — asynchrone Delegation (Kollege / eingebettet — Claudie, Andy, Viktor, Fin); (b) ***human-AI collaboration*** synchron (Claude Code und Äquivalente). **Every-Daten**: 95 % der CEO-E-Mails werden von KI bearbeitet; **Fin (Intercom) löst 65 % der Support-Konversationen**. **Zenons Paradox der KI**: Die KI schließt kontinuierlich die Lücke, doch der Mensch bleibt "die Schildkröte vorn", weil er ***"alive to a specific moment"*** ist — *"running wants, running concerns"* —, während Modelle auf historischen Trainingsdaten operieren. **Detaillierte Benchmarks**: **GPT-5.5 = 62/100 bei der Senior-Engineer-Codebase-Neufassung** (vs. Mensch 80-90er); **GDPval**: 40-49 % des Expertenniveaus, **aber mit umfangreicher menschlicher Rahmung**. **OpenClaw 44.469 PRs** im Mai 2026 (vs. Kubernetes 5.200 im Jahr 2022) — Beweis, dass agentische Arbeit *"mehr Arbeit"* schafft, nicht *"weniger menschliche Arbeit"*. **AGI-Implikationen**: Selbst bei AGI bleibt der **menschliche Framer** strukturell im Vorteil — er adressiert *"aktuelle, situierte"* Probleme, während das Modell auf *"historischen Trainingsdaten"* operiert. **Anti-Tipping-Point-Schlussfolgerung**: Dies ist kein Kipppunkt-Ereignis, sondern ***ein anhaltendes Muster***, das die Zukunft der Arbeit bestimmt. **Hohe Relevanz**: eine explizite Gegen-Erzählung zu *Amodei white-collar bloodbath* / *Sun permanent underclass* / *Anthropic Economic Index* — Shipper, **CEO eines Unternehmens, das täglich mit Agenten lebt**, liefert den theoretischen Rahmen, der die beiden empirischen Beobachtungen versöhnt (KI leistet mehr + Menschen bleiben unverzichtbar). Starke Konvergenz mit **Ng "No AI jobpocalypse"** (2026-05-08), **Mollick × roon ASI / FDE** (2026-05-10), **Tatsyi/Raiffeisen "AI made engineers different"** (2026-05-05), **Curran/Intercom 3× R&D** (2026-04-16) — alle beschreiben Menschen als *in Richtung Rahmung umverteilt (redeployed toward framing)* statt *ersetzt*. Produktive Spannung mit **Sun NYT permanent underclass** (2026-04-30), **Wallace-Wells AI populism** (2026-05-08), **Osmani Cognitive Surrender** (2026-05-05 — der menschliche Framer muss aktiv bleiben). Zu nutzen für COMEX / DG / Boards: strategisches Vokabular für 2026 — *"frame vs framer"* wird zum kanonischen Raster für KI-Governance.
#Dan Shipper#Every#after automation
**Dan Shipper** — CEO et co-fondateur de **Every** (média / studio AI-native, créateur de la newsletter *Every*, propriétaire du framework et plugin *Compound Engineering* — cf. fiche `shipper-klaassen-compound-engineering-every-agents-2025-12-11.md`). Profil rare : **opérateur-théoricien** · dirige une organisation entièrement augmentée par l'IA (95 % emails CEO automatisés, agents Claudie/Andy/Viktor en production, Fin pour le support) tout en publiant régulièrement des essais conceptuels sur every.to. Voix éditoriale anglo-saxonne de référence dans le corpus 2025-2026 sur les **modes de travail humain-IA**. Article publié sur **every.to/p/after-automation** le **21 mai 2026**.
Engineering-Artikel, veröffentlicht im **Uber** Engineering-Blog von sechs Ingenieuren (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) am **21. Mai 2026**, der die bei Uber für mehrere Tausend interne Agenten produktiv eingesetzte **Doktrin für Agentenidentität und Zugriffskontrolle bei KI** darlegt. **Kernthese**: Bestehende Identitätsmodelle (Menschen + Workloads) scheitern daran, **Handlungsvollmacht (Agency)** zu beschreiben — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — und verlieren die **Provenienz** über die Hops eines agentischen Workflows hinweg. **Zwei identifizierte operative Probleme**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — Delegation ist der Standardmodus, Workflows sind kompositional (Agenten rufen Agenten auf, die Tools aufrufen), das Verhalten ist dynamisch (Pläne entwickeln sich basierend auf Zwischenergebnissen); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* **Vorgeschlagene Architektur** als Erweiterung von Ubers Zero-Trust-Architektur: **Agent Registry** (Source of Truth für Agent↔Workload-Zuordnungen) + **AI Agent Mesh** (Datenebene zwischen Agenten) + **STS (Security Token Service)** (Ausstellung kurz begrenzter JWTs) + **MCP Gateway** (Policy-Enforcement-Point für Tool-Aufrufe) + **AI Gateway** (Vermittlung externer LLM-Aufrufe mit Guardrails) + **SPIRE** (Anbieter von Workload-Credentials). **Kryptografische Mechanik**: Workloads beziehen kryptografisch signierte **SVIDs (SPIFFE Verifiable IDs)** von SPIRE → das SDK fordert über die Workload-Identität ein JWT vom STS an → der STS prüft die Autorisierung des Agenten gegen die Agent Registry → ein kurzlebiges Token (TTL in der Größenordnung von Minuten) wird für ein **spezifisches Single-Hop-Ziel** ausgestellt (gezielter `Audience`-Claim). **Kerndoktrin**: ***"Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes."*** **Erhalt der Akteurskette**: ein Multi-Hop-Beispiel mit Bereitschaftsingenieur `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; das finale JWT trägt eine verifizierbare **Akteurskette `[user1, oncall-agent, investigation-agent]`**, die Zugriffsentscheidungen auf Tool-Ebene auf Basis der **vollständigen Historie der Anfrage** ermöglicht. **Standardisierung**: ein **Standardized A2A (Agent-to-Agent) Client**, der STS-Austausche und die Propagierung der Akteurskette automatisiert — *"the secure path is also the easiest path for developers to implement A2A calls"* — mit schrittweiser Migration von Legacy-Agenten. **Produktionskennzahlen**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** Tausende interner Agenten im Einsatz, ein Echtzeit-Observability-Dashboard, das Multi-Agenten-Sitzungen nachverfolgt. **Langfristvision — dreischichtiges Framework**: (1) Identity & Trust Foundation (verifizierbare Agentenidentität + Delegationsketten), (2) Dynamic Access Control (kontextbasierte Berechtigungen + Human-in-the-Loop), (3) Unified Enforcement Plane (zentralisierte, beobachtbare Policy). **Abstimmung mit Standards**: die IETF-**WIMSE**-Arbeitsgruppe + der Entwurf `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, konzeptionell gestützt auf **OAuth 2.0 Token Exchange (RFC 8693)** und **SPIFFE/SPIRE** (CNCF graduated). Die erste Referenzpublikation eines Hyperscalers außerhalb der KI-Labs (Logistik/Mobilität), der Agentensicherheit auf Infrastrukturebene industrialisiert und die doktrinäre Lücke zwischen Skills-/Harness-Frameworks (Vincent, Lattice, PROJ-AI) und Fragen der Unternehmensidentität schließt.
Pivot-Artikel **Ivan Chepurin & Travis Turner** (Evil Martians Chronicles, **19. Mai 2026**) — ***« AI-assisted engineers are burning out, is this fine? »*** — **strukturierte Diagnose des Burnouts bei KI-unterstützten Entwicklern** und ein **5-Achsen-Interventions-Toolkit**. **Pivot-These**: KI-beschleunigte Produktivität verbirgt **versteckte Kosten — Erschöpfung der Entwickler**. *« Higher productivity doesn't translate to sustainable work practices or job satisfaction. »* Epigraph von Shunryu Suzuki über mentale Unruhe. **TL;DR — 3 wesentliche Abhilfen**: (1) Freude am Prozess wiederherstellen, (2) Erfolgserlebnis / Eigenverantwortung / Stolz wiederaufbauen, (3) den Druck der kontinuierlichen Produktivitätsmaximierung beseitigen. **Zentraler Erzählrahmen — Ben vs. Alice**: Ben (traditionelles Coding) = 4 Std. stetige Arbeit, verteilte kognitive Last, Zufriedenheit bei Fertigstellung; Alice (KI-unterstützt) = 2 Std. kognitiv hochintensive Arbeit, kontinuierliches Task-Switching, **keine Zufriedenheit** + füllt die freigewordene Zeit mit weiteren Aufgaben → **exponentielle Eskalation der Last** trotz beschleunigtem Output. **Kanonische Formel**: ***« We compensate for a lack of satisfaction with work quantity. »*** **Strukturelle Störung des Craft-Zyklus**: (Planung → Handwerk → Ergebnis) komprimiert zu (Planung → Ergebnis), Wegfall der meditativen Handwerksphase, ersetzt durch **kognitiv anspruchsvolles Code-Review**. Direkte Konvergenz mit **HBR study 2026** (zitiert): *« cognitive exhaustion from intensive oversight of AI agents is both real and significant »* + **UC-Berkeley-Forschung 2026**: Beschäftigte füllen natürliche Pausen mit KI-Aufgaben. **Quiet career change** — Pivot-Konzept: für das Programmieren eingestellte Entwickler leisten nun **andere Arbeit ohne bewussten Karrierewechsel**. 4 mögliche Wege: (1) Freude an der neuen Struktur finden (priorisiert), (2) KI ignorieren, (3) ohne Freude arbeiten (nicht nachhaltig), (4) Karriere wechseln. **5 identifizierte tägliche Burnout-Faktoren**: (1) ***Losing context*** — der Agent trägt das Projektverständnis extern, Verschiebung der kognitiven Schuld von Code zu Menschen, Verlust der Systemintuition; (2) ***No time for passive thinking*** — *« The model fills the silence before your own thinking has a chance to connect dots »* (Duschen, Spaziergänge als Momente unbewusster Problemlösung entfallen); (3) ***False expectations*** — anfängliche Geschwindigkeit = unrealistische Baseline, spätere Verlangsamungen werden als Scheitern erlebt; (4) ***Review bottlenecks*** — *« the more code is generated, the more code needs to be reviewed »*, unverhältnismäßige kognitive Last bei Senior-Entwicklern, Verantwortungsdiffusion; (5) ***Endless possibilities*** — geringe Prompting-Friktion begünstigt ständige Kurswechsel, Fehlen eines natürlichen Scopings. **5-Interventions-Toolkit**: (a) **Acknowledge your wins** (Win-Log, Team-Demos, Stundentracker); (b) **Rethink AI workflow** (Planung > Review, **max. 3-4 Iterationen**, kein paralleles Task-Switching, KI-intensive Aufgaben durch Pausen trennen, aufteilen); (c) **Keep exercising your craft** (geschützte KI-freie Handwerksstunden, *« ask » mode > generation mode*, Agenten bei Passion-Projekten ausschalten); (d) **Discipline + work-life balance** (feste Arbeitszeiten, echte Pausen, tägliche Vorsätze, aufhören, wenn fertig); (e) **Find new areas of interest** (User Research, Soft Skills, Analytics, Agent-Fine-Tuning + Guardrails, Performance-Optimierung). **Fazit**: *« AI can be helpful. Problems appear only if you misuse it. »* Branchenentwicklung = unvermeidlich; individuelles Wohlbefinden = kontrollierbar. Starke Konvergenz mit **Osmani Cognitive Surrender** (2026-05-05), **Frizzo "Year With Claude Code"** (2026-05-05 — *« writing muscle atrophy »*, *« deep flow rare »*), **Bedard BCG/HBR Brain Fry** (2026-03-05 — 1.488 Beschäftigte, Spitzenwert von 3 Tools, +39 % Fehler, +39 % Kündigungsabsicht). Hohe Relevanz für **CTO / VP Engineering / IT-HR** im Zusammenhang mit der Bindung KI-erweiterter Entwickler im Jahr 2026.
#Ivan Chepurin#Travis Turner#Evil Martians
**Ivan Chepurin** & **Travis Turner** — auteurs Evil Martians (cabinet de conseil ingénierie indépendant, Berkeley/global, ~150 ingénieurs, spécialiste Ruby on Rails / React / produits SaaS depuis 2010 ; éditeurs du blog *Evil Martians Chronicles* — référence dans la communauté Rails et JS). Article publié dans la catégorie **AI / Developer Community** sur evilmartians.com le **19 mai 2026**. Profil Evil Martians : voix éditoriale **opérateur-praticien** · articles longs ancrés dans le terrain produit · registre **soin du craft + lucidité business** · public habituellement développeurs / CTO / fondateurs early-stage.
Interner Teardown-Bericht zur Open-Source-Veröffentlichung **`xai-org/x-algorithm`** (15. Mai 2026) — dem **For-You-Feed**-Algorithmus von **X (ehemals Twitter)** im Jahr 2026, mit vier zielgruppenspezifischen Wachstums-Empfehlungssträngen (persönlich/Gründer, Marke/Unternehmen, verallgemeinertes Framework, Kunden-/Beratungs-Deliverable). **Kernthese**: ***« Die berühmte Gewichtstabelle von 2023 — Antworten zählen mit einem großen Multiplikator mehr als Likes — beschreibt ein System, das in dieser Form nicht mehr existiert. »*** Der Algorithmus von 2026 ist ein **Transformer (Phoenix, von Grok-1 abgeleitet)**, der Gewichte aus dem eigenen Engagement-Verlauf lernt und gegen eine **19-dimensionale Multi-Aktions-Oberfläche** bewertet wird, gesteuert durch einen Offline-Dienst zum Content-Verständnis (**Grox**). **Die Form des Scorings zählt heute weit mehr als die Zahlen — und die Zahlen selbst sind nicht Teil der öffentlichen Veröffentlichung**. **Architektur mit 4 Komponenten**: (1) **Home Mixer** (Rust, Orchestrator zur Anfragezeit, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, mit Kafka gespeister In-Memory-Store aktueller Posts, Sub-Millisekunden-Lookups für In-Network-Kandidaten); (3) **Phoenix** (JAX-ML, Two-Tower-Retrieval + Ranking-Transformer, ~von Grok-1 abgeleitet); (4) **Grox** (offline, Spam-/Safety-/PTOS-/Banger-Klassifikatoren + multimodaler v5-Embedder). **Die 19 von Phoenix vorhergesagten Aktionen** (zentrale Änderung gegenüber 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view, durch Mindestdauer gesteuert), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (kontinuierlich). **Endscore** = `Σ (weight × P(action))`, modifiziert durch **3 strukturelle Multiplikatoren**: (a) **OON_WEIGHT_FACTOR < 1** (Out-of-Network-Abschlag), (b) **Author-Diversity-Decay** `(1-floor) × decay_factor^position + floor` (exponentielle Abschwächung wiederholter Posts desselben Autors innerhalb eines einzelnen Renders), (c) **Video-Dauer-Gate** (vqv trägt nur bei, wenn `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Zentraler Vorbehalt**: **kein numerischer Gewichtswert** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) ist in der Veröffentlichung enthalten — alles ist `crate::params::*`, verwaltet von einem internen X-Feature-Switch-Dienst für A/B-Tests. ***« Wer behauptet, ‚Antworten sind 2026 N,N-mal mehr wert als Likes‘, erfindet eine Zahl, die sich aus der OSS-Veröffentlichung nicht ableiten lässt. »*** **Zentrale Unterschiede zu 2023**: (1) Entfernung sämtlicher handgefertigter Features (*« Wir haben jedes einzelne handgefertigte Feature und die meisten Heuristiken aus dem System entfernt »*); (2) ein einzelnes Modell sagt 19 Aktionen voraus statt mehrerer Einzelaktions-Modelle; (3) Grox trennt Content-Verständnis vom Ranking; (4) neue erstklassige Signale (kontinuierliches dwell, gesteuertes vqv, follow_author, 3 Share-Varianten); (5) Two-Tower-OON-Retrieval (statt SimClusters+Heuristiken) mit multimodalen Text+Bild+ASR-Video-Embeddings. **Drei Reichweiten-Schichten** (verallgemeinertes Framework): Eligibility (binär, Grox+Filter) → Retrieval (probabilistisch, Two-Tower-ANN) → Ranking (kontinuierlich, gewichtete Summe + Multiplikatoren). **Zwei Gesetze des mechanischen Wachstums**: (1) In-Network ist multiplikativ, OON ist additiv; (2) Die Aufgabe des Modells ist es, dich vorherzusagen, nicht dich zu belohnen. **Bewusste Ehrlichkeitsgrenze**: veröffentlichter Phoenix-Checkpoint = Mini-Version (2 Layer, 4 Heads, 256-dim, 537K-Sportpost-Korpus), nicht das Produktionsmodell; Thrift-Integrationen sind Stubs (`panic!("Not implemented")` in `candidate_features.rs`); Brand-Safety-Listen, Topic-ID-Zuordnungen, Sprachabschläge und Ad-Blending-Regeln fehlen in der öffentlichen Veröffentlichung.
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
Erste Sozialenzyklika von **Papst Léon XIV** (Robert Francis Prevost), datiert auf den **15. Mai 2026** (Rom, bei St. Peter, im 2. Jahr des Pontifikats), veröffentlicht zum **135. Jahrestag von *Rerum Novarum*** (Léon XIII., 15. Mai 1891) und ausdrücklich als **Fortsetzung der Soziallehre der Kirche im Zeitalter der KI** vorgestellt. Kanonischer Untertitel: *„über den Schutz der menschlichen Person im Zeitalter der künstlichen Intelligenz“*. **245 Abschnitte**, gegliedert in **Einleitung + 5 Kapitel + Schluss**. **Zentrale These**, organisiert um zwei **biblische Bilder**: den **Turmbau zu Babel** (Gen 11) — technologische Gleichförmigkeit ohne Gott, *„Verabsolutierung des Menschlichen“* — gegenüber dem **Wiederaufbau der Mauern Jerusalems durch Nehemia** (Neh 2-6) — geteilte Verantwortung Stein für Stein, Zuhören, Koordination unter den Familien. *„Die erste Wahl besteht nicht zwischen einem 'Ja' oder 'Nein' zur Technik, sondern zwischen dem Bau Babels oder dem Wiederaufbau Jerusalems“* (Nr. 9). **Kanonische Konzepte**: (1) **KI „kultiviert“ statt „konstruiert“** — *„Entwickler entwerfen nicht jedes Detail direkt, sondern schaffen eine Architektur, auf der sich die KI entwickelt“* (Nr. 98), eine bemerkenswerte theologische Formulierung, die an aktuelles ML-Forschungsvokabular anknüpft; (2) ***„Die KI entwaffnen“*** (Nr. 110) — *„sie der Logik eines Wettrüstens entziehen, das heute nicht mehr nur militärisch, sondern auch wirtschaftlich und kognitiv ist“*, um die KI *„bewohnbar zu machen, indem man sie der Vielfalt menschlicher Kulturen zurückgibt“*; (3) **Radikale Kritik am „Alignment“** — *„Wir können uns nicht damit begnügen, die Moralisierung der Maschine zu fordern, das sogenannte 'Alignment' der KI mit menschlichen Werten, ohne den Mut zu haben, eine weitere Bedingung hinzuzufügen: die Möglichkeit, den zu verwendenden ethischen Kodex zu debattieren“* (Nr. 107). ***„Eine moralischere KI nützt nichts, wenn diese Moral von einer Handvoll Menschen entschieden wird.“*** (4) **Epistemische Asymmetrie** und **neue KI-Monopole** (Nr. 109) — *„in einer Welt, in der wenige Akteure Daten, Rechenressourcen und regulatorische Macht konzentrieren“*; (5) **Unsichtbare Arbeit** von Daten-Labelern/Moderatoren/Seltene-Erden-Schürfern (Nr. 109, 173) — *„gezeichnete, verstümmelte, benutzte Körper, damit der Rechenfluss nie stoppt“*; (6) **Datenkolonialismus** (Nr. 178) — *„er beherrscht nicht nur Körper, sondern eignet sich Daten an“*, *„neue seltene Erden der Macht“*; (7) **KI und Krieg** (Nr. 197-200) — *„Kein Algorithmus, der Krieg moralisch akzeptabel machen kann“* (Nr. 198), drei Kriterien: nachvollziehbare persönliche Verantwortung, Verweigerung der Verkürzung der Zeit für moralisches Urteilen, Schutz der Zivilbevölkerung; (8) **Kritik an Transhumanismus/Posthumanismus** (Nr. 115-117) als *„ein Archipel konzeptueller Inseln, verbunden durch denselben Ozean von Annahmen: die Zentralität der Technik und der Traum, die Grenzen der menschlichen Verfassung zu überschreiten“*; (9) **Arbeit im Übergang** (Nr. 150-156) — *„entgegen den angepriesenen Vorteilen der KI können aktuelle Technologieansätze Arbeitnehmer paradoxerweise dequalifizieren, sie automatisierter Überwachung unterwerfen“*, Zugang zur Arbeit als öffentliche Priorität, Antizipation des Wandels, Festlegung sozialer Kriterien für Innovation; (10) **Kanonische Frage nach Johannes Paul II.** (Redemptor hominis 1979): ***„Macht die KI das menschliche Leben auf der Erde in jeder Hinsicht 'menschlicher'? Macht sie es 'des Menschen würdiger'?“*** (Nr. 129); (11) **Authentisches „Mehr als Mensch“**: nicht Transhumanismus, sondern Gnade — *„wir schaffen es, ganz Mensch zu sein, wenn wir mehr als Mensch sind, wenn wir Gott zulassen, uns über uns selbst hinauszuführen“* (Nr. 128, unter Verweis auf Franziskus, *Evangelii gaudium*); (12) **Die Worte entwaffnen** (Nr. 214) — *„Lasst uns die Worte entwaffnen, und wir werden helfen, die Erde zu entwaffnen“*. **Adressaten**: *„An alle katholischen Gläubigen, an alle Christen, an alle Menschen guten Willens“* (Nr. 16) — ein **universelles** Register in der Linie von *Pacem in terris* (Johannes XXIII., 1963), *Laudato si'* (Franziskus, 2015) und *Fratelli tutti* (Franziskus, 2020). **Besonderer Appell an KI-Entwickler** (Nr. 111): *„jede Designentscheidung drückt eine Vision des Menschen aus“*. Zentrale zitierte **Lehramtsquelle**: *Antiqua et nova* (Dikasterien für die Glaubenslehre + Kultur und Bildung, 14. Januar 2025) + *Quo vadis, humanitas ?* (Internationale Theologenkommission, 9. Februar 2026). Ein bedeutendes Dokument des **sozialen Lehramts von 2026**, an der Schnittstelle von Soziallehre ↔ KI-Ethik ↔ Big-Tech-Geopolitik ↔ Kritik an Mikroarbeit/Seltene-Erden-Abbau. Implizite Konvergenz mit **Mensch / Mistral** (energetische Souveränität der KI), **Sun / NYT Permanent Underclass** (vgl. Verschiebung Arbeit→Kapital), **Wallace-Wells / NYT AI Populism** (vgl. Kritik an Tech-Oligarchen), **Mollick × roon** (vgl. ASI und interne Politik). Erste Enzyklika eines Papstes, die KI ausdrücklich als **zentrales, strukturierendes Thema** behandelt und nicht nur als eines unter vielen.
#Léon XIV.#Robert Francis Prevost#Sozialenzyklika
**Léon XIV** (de naissance Robert Francis Prevost) · 267e Pape de l'Église catholique · élu le **8 mai 2025** · premier pape américain de l'histoire (né à Chicago, USA, 1955 ; double nationalité américano-péruvienne). Augustinien (ancien Prieur général de l'Ordre de Saint-Augustin 2001-2013) · ancien évêque de Chiclayo (Pérou) puis Préfet du Dicastère pour les Évêques (2023-2025). *Magnifica Humanitas* est sa **première encyclique sociale** · signée *« Donné à Rome · près de Saint-Pierre · le 15 mai de l'année 2026 · la deuxième de mon Pontificat »* — date choisie pour **coïncider avec le 135e anniversaire de *Rerum Novarum*** (15 mai 1891) de Léon XIII · dont il a explicitement repris le nom de pontificat en référence à la tradition sociale lancée par son prédécesseur du XIXe siècle. La référence augustinienne est centrale dans le document (citations massives des *Confessions*, du *De civitate Dei* — *« deux amours ont fait deux cités »*, des *Enarrationes in Psalmos*, des *Sermones*). Trace de paternité collective : multiples références à *Antiqua et nova* (note conjointe DDF + DCE, 14 janvier 2025) et *Quo vadis · humanitas ?* (CTI, 9 février 2026) · suggérant un travail conjoint entre la Secrétairerie d'État · le Dicastère pour la Doctrine de la Foi · le Dicastère pour la Culture et l'Éducation · et le Dicastère pour le Service du Développement humain intégral.
Blogbeitrag von **Zed**, verfasst von **Franciska Dethlefsen** (Head of Growth and Marketing), veröffentlicht am **14. Mai 2026** — am Tag nach Anthropics Ankündigung —, um Fragen der Zed-Nutzer zu beantworten. **Thema**: Ab dem **15. Juni** teilt Anthropic die Abrechnung des Claude-Abonnements in **zwei Pools** auf — einen für die **First-Party-Tools** (Chat, die offizielle Claude Code CLI), den anderen für **Drittanbieter-Agenten- und SDK-Nutzung** (alles, was über **ACP**, `claude -p` oder ein Drittanbieter-Tool läuft). Die Nutzung über ACP **zieht dann nicht mehr von den Pro- oder Max-Limits ab** und wechselt zu einem monatlichen **"Agent SDK"-Guthaben**: **20 $ für Pro, 100 $ für Max 5x, 200 $ für Max 20x**. Ist das Guthaben aufgebraucht, läuft die Nutzung **zu Standard-API-Preisen** weiter, sofern Overage aktiviert ist — andernfalls stoppen die Anfragen bis zum nächsten Zyklus. **Die für den Artikel entscheidende Zahl**: Abonnements hatten die agentische Nutzung bis dahin um den Faktor **≈15 bis 30×** gegenüber den API-Preisen subventioniert, und die neuen Guthaben werden **zu vollen API-Sätzen** abgerechnet — daher *„für alle, die Agenten intensiv nutzen, ist dies ein erheblicher Kostenanstieg"*. **Es werden drei Optionen vorgeschlagen**, in einer Reihenfolge, die Zeds Haltung offenbart: (1) das Abonnement behalten, indem man die **offizielle `claude`-CLI im Terminal innerhalb von Zed** statt über ACP ausführt — *„wenn die offizielle claude-CLI im Terminal läuft, nutzt sie die Limits deines Abonnements, nicht das neue Guthaben"*; (2) Zeds integrierten Agenten mit dem Anbieter eigener Wahl nutzen (von Zed gehostete Modelle, API-Schlüssel, Copilot, lokales Ollama, DeepSeek); (3) **einen beliebigen ACP-Agenten** einbinden — OpenCode, Codex, Factory, Cursor —, von denen mehrere weiterhin ratenlimitierte Abonnements anbieten, die eine intensive Nutzung subventionieren. **Die zugrunde liegende These**, und der eigentliche Grund für den Beitrag: *„ACP ist ein offenes Protokoll … damit dein Editor niemals an die Preisentscheidungen eines einzelnen Anbieters gebunden ist"*, mit der expliziten Erwartung, dass *„diese Art von Änderung nicht die letzte sein wird"*. **Der Beitrag trägt ein auf den 16. Juni 2026 datiertes Addendum**, das ankündigt, dass **die Änderung ausgesetzt wird**: ACP, `claude -p`, das Agent SDK und Drittanbieter-Anwendungen funktionieren **wie zuvor** mit Abonnements weiter, kein separates Guthaben ist zu beanspruchen, die Limits bleiben unverändert, Anthropic überarbeite seinen Plan mit angekündigter Vorlaufzeit. **Das Artefakt widerspricht sich damit selbst**: sein wichtigster Inhalt — die Rücknahme — datiert einen Monat nach seinem eigenen Veröffentlichungsdatum.
#Zed#Anthropic#Claude-Abonnement
**Franciska Dethlefsen** — head of growth and marketing chez **Zed Industries**. Le rôle est déterminant pour lire le texte : ce n'est pas un billet d'ingénierie mais une **communication de crise produit** · écrite le lendemain d'une annonce d'un fournisseur dont Zed dépend · à destination d'utilisateurs inquiets. La signature growth/marketing explique la structure (problème → options → réassurance) et le fait que l'argument protocolaire arrive en conclusion plutôt qu'en tête.
Continuous Delivery als nicht verhandelbare Grundlage KI-gestützter Softwareentwicklung — Dave Farley argumentiert auf seinem Kanal *Modern Software Engineering*, dass KI ohne CD kein Beschleuniger, sondern eine Falle ist (Theory of Constraints und Jevons-Paradoxon angewandt auf generierten Code, ATDD/BDD als Absicherung, Deployment-Pipeline als Qualitätsschiedsrichter).
#Continuous Delivery#Generative KI im SDLC#ATDD (Acceptance Test-Driven Development)
Dave Farley (Modern Software Engineering — YouTube channel)