Video-Interview aufgezeichnet auf der **VivaTech** (Stand von **Scaleway**), ausgestrahlt vom Medienunternehmen République, mit **Damien Lucas** (CEO von Scaleway) und **Franck Le Moal** (Global Technical Officer der Gruppe **LVMH**). **Zentrale These**: Das Aufkommen einer **„Tech-Geopolitik“** zwingt multinationale Konzerne dazu, die einheitliche globale Lösung zugunsten eines **in drei Blöcke regionalisierten Informationssystems** (Vereinigte Staaten, Europa, China) aufzugeben. LVMH (80 Mrd. € Umsatz, 75 Maisons, über 100 Länder) formalisiert eine **Cloud-Partnerschaft mit Scaleway** zum Aufbau eines **autonomen europäischen Bausteins**, neben Google Cloud (Daten, seit 2021), SAP, Salesforce auf westlicher Seite und Alibaba Cloud / Huawei / Tencent auf chinesischer Seite. Die Gruppe bezeichnet sich selbst als **„hybrid“** und **autonom** statt **„souverän“** (ein Wort, das sie als mehrdeutig ablehnt). Scaleway positioniert sich als **europäischer Cloud-Anbieter**, immun gegen extraterritoriale Gesetze und geschützt vor einem **Kill Switch** („keine Science-Fiction“, angesichts der Nachrichten des Wochenendes). Das wirtschaftliche Argument von Damien Lucas: **1 € bei Scaleway ausgegeben = 68 Cent, die in der europäischen Wirtschaft verbleiben** (gegenüber < 20 Cent bei einem US-Hyperscaler, selbst wenn in Frankreich gehostet). Zeitplan: PoCs abgeschlossen, Rollout beginnt bei **Sephora und Louis Vuitton**, signifikante Durchdringung innerhalb von **12-18 Monaten** angestrebt. Erklärte Mission von Scaleway: Fokus auf **IaaS/PaaS** (keine Vertikalisierung wie z. B. Bürosoftware), gestützt auf ein Partner-Ökosystem (souveräne Anwendungen, europäische Chipsätze und Server). Das **Nvidia-GPU/KI**-Angebot von Scaleway ist **kurzfristig nicht geplant**, bleibt aber offen (Open-Source-Modelle für Autonomie + wirtschaftliche Leistungsfähigkeit).
**Bertrand** — journaliste / présentateur du média **République** (partenaire de VivaTech) · conduit l'entretien. **Damien Lucas** — CEO de **Scaleway**. **Franck Le Moal** — Global Technical Officer du groupe **LVMH**.
Ein arXiv-Paper (cs.SE) von Martin Monperrus, das für den SDLC eine radikale These vertritt: Coding-Agenten haben eine Fähigkeitsschwelle überschritten, sodass menschliches Code-Review keine notwendige Komponente einer Qualitätspipeline mehr ist. Zwei Thesen: (1) autonome LLM-basierte Systeme erreichen alle Ziele des Reviews (Fehlererkennung, Qualität, Compliance) bei geringeren Kosten und höherem Durchsatz; (2) das hybride Modell „der Agent schreibt, der Mensch reviewt“ ist nicht haltbar — es gewährleistet weder echte Qualität noch skaliert es mit der KI-Geschwindigkeit und erzeugt ein „trügerisches Sicherheitsgefühl“. Monperrus stellt der inspection de Fagan (1976) eine multi-agentenbasierte adversarial verification pipeline gegenüber (Generator-Agent + unabhängige Reviewer-Agenten + Tests/formale Methoden + abstimmungsbasierter Konsens). Der Mensch konzentriert sich auf die Spezifikation, architektonische Trade-offs, die Freigabe kritischer Domänen sowie Grenzfälle. Empfehlungen: zunächst Pilotierung an risikoarmen Komponenten, Messung Agent vs. Mensch, explizite Ablehnungsentscheidungen.
Philippe Ensarguet (Orange) vertritt die These, dass fünfzig Jahre Design Patterns eine durchgängige Linie bilden: In einer Zeit, in der KI Code zur Commodity macht und die traditionelle Ausbildung von Architekten aufbricht, wird „Pattern Literacy" (das Lesen eines Systems anhand seiner invarianten Kräfte) zur dauerhaften Fähigkeit, die es zu vermitteln gilt — als Grammatik, nicht als Kataloge.
Produktankündigung von Stack Overflow (offizieller Blog) zur Einführung von **Stack Overflow for Agents**, einer *API-first*-Plattform für Wissensaustausch, konzipiert für das agentische Zeitalter. Kernthese: Coding-Agenten arbeiten **isoliert**, ohne Zugang zu einer gemeinsamen, verifizierten Wissensbasis. Daraus resultiert die **„Ephemeral Intelligence Gap“** — Agenten lösen weltweit unabhängig voneinander dieselben Probleme, verschwenden dabei Tokens und Rechenleistung und verlieren die Lösung am Ende der Session; dieselben Architekturmuster werden in einer Schleife immer wieder neu entdeckt. Leitprinzip: *„plausible Antworten zu generieren ist billig geworden, aber zu verifizieren, welche davon in der Produktion Bestand haben, nicht.“* Vierstufiger Workflow: **zuerst suchen** (validiertes Wissen nutzen) → **beitragen, wenn eine Lücke besteht** (der Agent entwirft, der Mensch genehmigt vor der Veröffentlichung) → **verifizieren** (Ergebnisse, Anpassungen, Kontextbedingungen) → **Signale kumulieren** (Stimmen, Antworten, Verifizierungen erzeugen einen Konsens). Drei maschinenlesbare Formate: **Questions**, **TIL** (Debug-Spuren), **Blueprint** (wiederverwendbare Muster, höchster Qualitätsanspruch). Vertrauen beruht auf **Community-Moderation** und **Multi-Agenten-Verifizierungsschleifen**; Menschen beanspruchen die Eigentümerschaft ihres Agenten über Stack Overflow SSO (einen „Community-Anker“, der den Agenten an eine menschliche Reputation bindet). Differenzierte Vorteile: Entwickler (weniger Retry-Schleifen), KI-Labore (hochwertige Daten für Fine-Tuning/Evaluation), Unternehmen (**Stack Internal**, eine proprietäre Wissensebene ohne Datenabfluss).
#Stack Overflow for Agents#Coding-Agenten#Wissensbasis
Anthropic bringt Claude Fable 5 (ein Modell der Mythos-Klasse, das für den allgemeinen Einsatz sicher gemacht wurde) und Claude Mythos 5 (dasselbe Modell mit aufgehobenen Schutzmechanismen, beschränkt auf Cyberverteidiger über Project Glasswing) auf den Markt: Spitzenleistung in Softwareentwicklung, Bildverarbeitung, Langzeitgedächtnis mit langem Kontext und den Lebenswissenschaften.
Fundierter technischer Leitfaden (Blog der Agentur Lushbinary) zum **Loop Engineering**: Gestaltung der Systeme, die Coding-Agenten in einer Schleife steuern, statt sie manuell zu prompten. Behandelt die Genealogie Prompt → Context → Loop Engineering, die Ralph-Technik (Geoffrey Huntley), die **fünf Bausteine + Memory** einer Loop, ihre Umsetzung in Claude Code und OpenAI Codex, das Schreiben überprüfbarer Abbruchbedingungen, eine Reifegradskala für die Einführung sowie die Risiken, die mit zunehmender Ausgereiftheit der Loops zunehmen. Bereich: agentisches Software-Engineering, Coding-Agenten, Harness/Orchestrierung.
Leitfaden von Augment Code (Paula Hingel), der beschreibt, wie KI-Agenten den Software Development Lifecycle (SDLC) Stufe für Stufe umstrukturieren. These: KI erzeugt **in manchen Phasen höheren Durchsatz und in anderen ein höheres Instabilitätsrisiko** — ein Symptom ungleichmäßiger Adoption ohne Neuziehung der Review-Grenzen. Stützt sich auf **DORA 2025**: KI-Adoption korreliert positiv mit Delivery-Durchsatz und Produktperformance, aber **negativ mit Stabilität**. Sechs neu betrachtete Phasen (Requirements, Design/Architektur, Implementierung, Testing/QA, Deployment, Maintenance), drei zentrale Risiken (Erosion der Junior-Pipeline, **zirkuläre Validierung** von KI-generierten Tests, Governance-Lücken bei Skalierung) und drei entstehende Rollen (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Umsetzbare Empfehlungen: eine Phase vor der Skalierung auditieren, Governance einem Stresstest unterziehen, die **Spezifikation** ins Zentrum stellen, explizite Rollback-Richtlinien definieren, die Junior-Rolle rund um Review neu gestalten.
#SDLC#Software Development Lifecycle#Coding Agents
Sonntäglicher Tüftler-Beitrag von **Mark Dembo** (Head of Solutions, Developer Platform & AI bei **Cloudflare**), veröffentlicht am **7. Juni 2026** auf seinem persönlichen Blog. **Erzählung**: Inspiriert von **Steve Ruiz** kauft sich der Autor ein kleines Gerät **M5Stack Stick 3** (~30 €) und baut sich, die Veröffentlichung von **Opus 4.8** nutzend, einen **DIY-KI-Agenten** „aus reiner Neugier, ohne Ziel". **Iteration 1 (45 Min.)**: Er wirft die Dokumentation des Geräts **Claude Code** vor, das Python-Skripte (~200 LOC, *„zero blast radius“*) generiert, die das Wetter in München und dann in mehreren Städten anzeigen; ein **Cloudflare Workers + Workers AI Backend** ergänzt **Text-to-Speech (TTS)**, **Push-to-Talk** (Speech-to-Text) und ein zentrales **kleines LLM** zur Beantwortung von Fragen. **Iteration 2 (ein echter Agent)**: Umstellung der REST-Endpunkte auf **WebSocket**-Transport via **Cloudflare Agents SDK** + **Dynamic Worker execution** → das Muster ***„Code Mode“*** (der Agent schreibt und führt Code aus, um seine Aufgabe zu erledigen). Der Agent beantwortet daraufhin Fragen zu öffentlichen Daten (11! = Fakultät, der Champions-League-Sieger via `fetch()` auf Wikipedia, das Wetter für eine beliebige Stadt). **Iteration 3 (echte Befugnisse)**: Verbindung zu **Todoist** über einen **MCP OAuth**-Flow → 50 Tools auf einmal, daher zwei Probleme: **Context Bloat** und **echtes Schadensrisiko**. Die Lösung stützt sich auf Cloudflares **MCP Server Portal** + die Claude-Connector-Einstellungen: pro Tool **Always allow / Ask for approval / Disable** (*Disabled*-Tools gelangen nie in den Kontext; ein **LLM-Klassifikator** akzeptiert nur eindeutige „Allow“-Freigaben und **verweigert standardmäßig**). **Erklärte Haltung**: Reduzierung seiner Rolle auf ***„idea generator, executor and judge“*** (und selten technischer Anleiter), ein „Human-in-the-Loop“-Ablauf, den er als wenig *„2026“* empfindet (Copy-Paste in UIFlow). **Was er NICHT getan hat**: keine Latenz-/Streaming-Optimierung, keine optimistischen LLM-Aufrufe, keine Evals, ***„I did not even look at the code once.“*** **Verwunderung**: 30 € + ein Anthropic-Session-Fenster + ein paar Cent Cloudflare-Inferenz → ein Objekt, das zuhört und spricht, gesteuert in natürlicher Sprache; *„the true unlock is how accessible it is.“* Scharfer Kontrast zu [[thomas-pragdave-failing-faster-code-rot-ai-velocity-2026-06-06]] (hier rechtfertigt *„zero blast radius“*, den Code nie anzusehen); illustriert konkret *Code Mode* / *„the agent just writing and executing code,“* das **MCP**-Muster ([[claude-skills-bigger-than-mcp-willison-2025-10-16]]), *Ask for approval*-artige Tool-Governance (uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21) sowie die Doktrin der *systems around the model* aus dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28.
#BYO Agent#eigene KI mitbringen#Tüfteln
**Mark Dembo** (@darkmembo / @mdembo) · **Head of Solutions – Developer Platform & AI** chez **Cloudflare** (auparavant auteur sur le blog Cloudflare). Billet personnel publié sur son blog *markpauldembo.com* le **7 juin 2026** (description : *« Thoughts about tinkering on a Sunday »*).
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.
Kurzartikel (**8 Seiten**, 4 Exhibits) von **McKinsey Technology**, verfasst von **Jared Moon** (Senior Partner, London), **Rory Walsh** und **Vito Di Leo** (Partner, Dublin und Zürich), mit **Adam Thelwall**, veröffentlicht im **Mai 2026**. Die Autoren berichten von Produktivitätssteigerungen um das **×3- bis ×5-Fache** bei einer **Verkleinerung der Teamgröße um 60%** in mehreren Unternehmen und führen dies auf die Neugestaltung des Betriebsmodells zurück, nicht allein auf den Einsatz von Agenten. Vier Hebel: (1) der **24-Stunden-Sprint**, mit einer Nachtschicht aus Agenten (16h) und einer menschlichen Tagschicht (8h); (2) die Automatisierung der **Handoffs** zwischen Requirements, Design und Code, die nach Angabe der Autoren **70% der Tech-Ausgaben** ausmachen, gegenüber 30% für das Deployment; (3) eine **Wissensinfrastruktur** aus domänenspezifischen Graphen, abgefragt von einem Agenten „bibliothécaire“; (4) die Neudimensionierung von Teams und Portfolio. Zum Graphen: *„das sollte nicht mit einem großen, top-down angelegten Ontologie-Projekt beginnen“*. Die Teamzahlen werden als illustrativ präsentiert, abgeleitet aus der „Erfahrung und Beobachtung“ der Firma. Schließt an McKinseys Präsentation vom November 2025 zur agentengestützten Softwarebereitstellung an ([[harrison-maniar-mckinsey-reshaping-software-delivery-agents-2025-11-23]]).
#McKinsey#agentischer SDLC#Betriebsmodell
Jared Moon (senior partner) · Rory Walsh · Vito Di Leo (partners) · avec Adam Thelwall (associate partner) — McKinsey & Company
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**.