X-Post von **Andrew Ng** vom **14. August 2026** (16:29 UTC), Wiederaufnahme des "Dear friends"-Briefs aus ***The Batch* #366** (DeepLearning.AI, gleiches Datum), ca. 900 Wörter. Ng stellt **The AI Engineering Skills Map** vor und veröffentlicht **vier Skills**, die als die wichtigsten gelten. **(1) Aufbau und Bereitstellung von KI-Anwendungen** — die Besonderheit wird benannt: *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, daher die Betonung von *evals* und Fehleranalyse-Loops. **(2) Grundlagen der Softwareentwicklung**, denn *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — der unerfahrene Entwickler scheitert *« because they don't know what context to give their coding agent »*, daher das Ziel, *« steering coding agents using the precise language of software engineering »*. **(3) Einsatz von Coding-Agenten**, in operativer Formulierung: *« help the agent autonomously close loops by providing verifiers or evals »*, sowie *« knowing how much to intervene and how much to leave them alone »*. **(4) *Den Build gestalten***: *« Given a clear spec, coding agents are rapidly improving at delivering to it. Thus, our work as engineers is shifting toward deciding what should be in the spec »*, ergänzt durch *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* Ein **Hinweis zur Terminologie** trägt den größten Teil der Rahmung: Ng spricht von **Skills** im AI Engineering und **nicht von der Rolle** "AI Engineer", mit einer expliziten Analogie — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* Das Ganze stützt sich auf *« an analysis of more than 10,000 job postings, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data »*, wovon **keine numerischen Ergebnisse veröffentlicht werden**: Ng beschreibt sein Vorgehen als *« informally… akin to running clustering »* und kündigt eine detaillierte Map in künftigen Beiträgen an. Sein Eigeninteresse benennt er im vorletzten Satz: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*
#AI Engineering Skills Map#Skills-Map#Andrew Ng
**Andrew Ng** — fondateur de **DeepLearning.AI** · general partner d'**AI Fund** · cofondateur de **Coursera** et de **Google Brain** · ancien chief scientist de Baidu. Texte signé · à la première personne · écrit *« with my team »* sans qu'aucun collaborateur soit nommé. Publié le **14 août 2026** sur X et dans ***The Batch* n°366** — même texte aux deux endroits ; préférer *The Batch* pour toute citation durable. Quatrième fiche Ng du corpus · après les lettres n°350 (24 avril) · n°352 (8 mai) et n°359 (26 juin).
Referenzseite, veröffentlicht auf **eventuallycoding.com** am **28. Juli 2026** von **Hugo Lassiège** (Lyon, vom Entwickler zum Unternehmer, Autor von Bloggrify, Hakanai und Writizzy). Der Autor kündigt sie selbst so an: *„Das wird eher eine Referenzseite als ein Artikel sein“*, gedacht für seine eigene Ressourcenseite. **Thema**: eine erschöpfende, werkzeuggestützte Beschreibung einer **Solo-Softwarefabrik**, in der *„der produzierte Code inzwischen fast zu 100 % generiert ist“*, über mehrere polyglotte Monorepos hinweg (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **kontinuierlicher Auslieferung in Produktion**. **Vorab getroffene Unterscheidung**: Dies ist kein **vibe coding** im Sinne von Karpathy (Experimentieren, sich treiben lassen), sondern **context engineering** — *„den gesamten notwendigen Kontext zum richtigen Zeitpunkt geben, damit die Software einer Absicht entspricht und systematisch kontrolliert wird“*, mit dem Satz, der die Verantwortung begründet: *„Auch wenn ich den Code nicht schreibe, bin ich dafür verantwortlich und muss die Kontrolle darüber behalten.“* **Das gesamte Werkzeug-Set beantwortet drei Fragen**, und das ist das am besten wiederverwendbare Lese-Raster des Textes: *„Was weiß der Agent?“* (Kontext, Gedächtnis, Code-Graph) — *„Was kann er deterministisch, ohne zu improvisieren?“* (Skills, Prozeduren) — *„Was stoppt ihn, wenn er einen Fehler macht?“* (Hooks, Architekturtests, Qualitäts-Gates). **Sechs im Detail beschriebene Schichten**: (1) **Kontext** — Wurzel-`CLAUDE.md` + themenbezogene `.claude/rules/*.md`, bedingt geladen über `paths:` + `.agents/*.md` für nicht-technische Belange (Personas, Positionierung, Tonalität); (2) **Skills** — rund dreißig, Existenzkriterium *„wenn ich dasselbe ein drittes Mal erkläre“*; (3) **Tools** — JetBrains-IDE-MCP, **GitNexus** (Code-Graph: `impact(symbol)`, `detect_changes()`), Claude-mem, RTK-Filter-Wrapper, Sentry, schreibgeschützte Datenbank; (4) **ausführbare Leitplanken** — Harness-Hooks, **Architekturtests**, Pattern-Linting (**ast-grep** für Architekturentscheidungen, nicht nur ESLint); (5) **Fabrik** — blockierendes Qualitäts-Gate mit `needs:` auf dem Qualitäts-Job, fünf Teststufen; (6) **Produktprozess** — nummerierte Specs mit einem Skill zum Verfassen **und einem Skill zum Abschließen**, Design in Claude Design, gestufte Auslieferung hinter Feature-Flags, Unterscheidung zwischen **Feature Flipping** (Unleash) und **Gating** (Kundenvertrag). **Die Regel, die alles zusammenfasst**: *„Was zählt, muss ausführbar sein. Eine Anweisung wird ‚meistens‘ befolgt … Ein Hook oder ein Test wird immer befolgt.“* **Eine Seltenheit für dieses Genre**: ein Abschnitt „Zu verbessern“, der vier gelebte Einschränkungen offenlegt — die **Unmöglichkeit, die Veralterung einer Regel zu messen** (*„Ich habe keine Möglichkeit zu wissen, ob eine alte Regel obsolet geworden ist“*), das **Kaninchenloch**, das durch eine Boyscout-Regel entsteht, das **Fehlen einer Paketierung** von Skills über Projekte hinweg, und vor allem das Eingeständnis der Spannung: *„Ich werde in den Implementierungsphasen immer weniger nützlich“*, *„hin- und hergerissen zwischen der Zufriedenheit, eine immer effizientere Fabrik zu haben, und dem Risiko, Wissen zu verlieren.“*
#Softwarefabrik#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
Ausführlicher Meinungsbeitrag, veröffentlicht auf **sfeir.com** am 23. Juli 2026, gezeichnet von **SFEIR** (der redaktionellen Stimme des Unternehmens). Es handelt sich um einen **strategischen Kommentar zur Trésor-Éco-Notiz Nr. 391** der DG Trésor (Juni 2026 — siehe [[dgtresor-ia-effets-emploi-2026-06-30]]), gelesen durch SFEIRs Doktrin, « **KI zu verstärken statt sie zu erdulden** ». Der Artikel würdigt den **vorsichtigen, ökonomischen Ton** Bercys (Mechanismen plus Unsicherheit statt einer Vorhersage) und leitet daraus eine **dreiteilige These** ab: (1) **kein messbarer Gesamteffekt** im aktuellen Stadium (zwei sich ausgleichende Kräfte — Verdrängung vs. Produktivität — EU-Adoption ~20 %); (2) ein **einziges belastbares empirisches Signal, bei Berufseinsteigern** (−16 % Beschäftigung bei exponierten 22-25-Jährigen in den USA); (3) eine **langfristige Gefahr, die die Fragestellung verschiebt** — **Wettbewerbsrückstand** (Nicht-Adoption), nicht Arbeitsplatzvernichtung. Den analytischen Kern behält SFEIR bei: die **Preiselastizität** bestimmt den Beschäftigungseffekt (das **Jevons**-Paradox angewandt auf Code) → das Argument ist **strukturell beschäftigungsfreundlich für Entwickler**. Der Artikel **entkräftet die "KI-Entlassungen"-Erzählung** (4,5-6,2 % der US-Entlassungsankündigungen, "Labeling" bei 59 %) und weist auf die **blinden Flecken** der Notiz hin (das agentische Szenario, das in eine Fußnote verbannt wird; die Diffusionsgeschwindigkeit wird nicht diskutiert; OpenAI/Anthropic sind zu Quellen für Bercy geworden = ein nicht gekennzeichneter Quellen-Bias). **SFEIRs operative Übersetzung** (für CIOs/CTOs): Wert wandert in Richtung Intention/Architektur/Kontrolle, Ausbildung von **augmentierten Ingenieuren** (**AI-Champions**-Programme) und Vermeidung überstürzter Adoption (**workslop**, technische Schulden) durch **Context Engineering** und Governance.
#KI und Beschäftigung#Wettbewerbsrückstand#Nicht-Adoption
**SFEIR** — ESN française « AI Only » (~850 ingénieurs, 8 agences France & Benelux). Voix éditoriale du cabinet (byline « SFEIR »). Positionnement de la maison sur la transformation IA des DSI ; ce texte prolonge la ligne éditoriale portée notamment par Didier Girard (cf. [[girard-sfeir-ai4it-vs-ai4business-budgets-2027-2026-06-24]]).
SFEIRs Analyse aus dem Ingenieur-Kabinett ("die Lesart eines Ingenieurs") des Launches von **Kimi K3** am **16. Juli 2026** durch das chinesische Labor **Moonshot AI**: ein **Open-Weights-Modell der Spitzenklasse (frontier-class)**, für das der Anbieter **rund 2,8 Billionen Parameter**, einen **Ein-Millionen-Token-Kontext** und eine **Veröffentlichung der Gewichte vor dem 27. Juli 2026** beansprucht (voraussichtlich unter einer Modified-MIT-Lizenz, wie schon bei der K2-Reihe). These: Fähigkeiten, die einst proprietären Giganten (Anthropic, OpenAI, Google) vorbehalten schienen, werden **als offene Gewichte, zum Kampfpreis, aus einem chinesischen Labor** verfügbar. SFEIR – obwohl **Partner von Anthropic und Google Cloud** und damit „ohne Interesse daran, ein chinesisches Modell schönzureden" – legt einen zentralen **methodischen Vorbehalt** an: Am Launch-Tag existiert **keine offizielle, vollständige Benchmark-Tabelle**; Spezifikationen (2,8 Billionen, Kimi Delta Attention, +25% Trainingseffizienz) und Scores stammen **vom Anbieter selbst** oder aus **Community-Arenen** und sind „als Behauptungen, nicht als gemessene Fakten zu behandeln." Die neue Architektur (**Kimi Delta Attention**, hybride lineare Aufmerksamkeit; Dekodierung angeblich bis zu **6,3x schneller** bei 1M Token) bricht mit dem Takt der K2-Reihe (K2 Juli 2025 → K2.7 Code Juni 2026, alle zwei Monate ein Flaggschiff); zwei Varianten begleiten den Launch (**K3 Max**, **K3 Swarm Max**), mit erzwungenem Auslaufen der Reihe kimi-k2.5/moonshot-v1 am **31. August 2026**. **Die eigentliche Waffe ist der Preis** (~3 $/M Input, 0,30 $ gecacht, 15 $ Output laut Sekundärquellen): ein Open-Weights-Modell der Spitzenklasse auf diesem Niveau **zieht die gesamte Preis-Leistungs-Kurve nach unten** – die Kommodifizierung der Modellschicht, beschleunigt durch Open Source. Die entscheidende Singularität ist jedoch kein Score: Es ist die **Reversibilität**. Ein Open-Weights-Modell der Spitzenklasse verwandelt eine konsumierte API (Anbieterabhängigkeit) in eine **Option** (Self-Hosting, Portabilität, Ausstieg aus dem Lock-in) – um den Preis einer schweren Infrastruktur, um 2,8 Billionen Parameter zu hosten. SFEIRs Sicht: **Open Weights verändert die Frage, nicht nur die Antwort** – nicht mehr „welches Modell ist das beste/günstigste?", sondern „wie viel meines Systems bin ich bereit, von einem Anbieter abhängig zu machen, den ich nicht kontrolliere?". Die richtige Haltung bleibt ein **geroutetes Portfolio** (ein Modell pro Aufgabe, ein Modell pro Randbedingung), wobei Kimi K3 dem Entscheidungsraster eine **Spalte „Reversibilität"** hinzufügt. Die Überzeugung „AI Only" bleibt unverändert: Das Modell ist eine Commodity, der dauerhafte Vorteil liegt im Engineering drumherum (Context Engineering, Harness, Kostensteuerung, Fähigkeit, die Meinung zu ändern). Die Zahlen müssen weiterhin „selbst" validiert werden – an den eigenen Repositories, den eigenen Daten.
SFEIR-Analyse (aus Sicht des Unternehmens) der allgemeinen Verfügbarkeit von **GPT-5.6** durch OpenAI ab dem 9. Juli 2026 — kein einzelnes Modell, sondern eine **Familie aus drei Stufen**: **Sol** (Flaggschiff für Langzeit-/Cyber-/Wissenschaftsaufgaben, als einziges Modell mit Zugang zu den Modi „max" und „ultra"), **Terra** (ausgewogene Alltagsstufe, ~halber Preis von GPT-5.5) und **Luna** (schnell/wirtschaftlich, für hohes Volumen). Alle drei teilen sich ~**1,05 Mio. Token** Kontext, **128k** Ausgabe-Token und einen Wissensstand vom **16. Februar 2026**. Die strukturbestimmendste Tatsache ist kein Score, sondern ein **aggressives Preisraster** (Sol 5$/30$, Terra 2,50$/15$, Luna 1$/6$ pro Million Token): Sol behält den Preis des vorherigen Flaggschiffs bei und ist dabei leistungsfähiger, was den Vergleich auf das **Verhältnis von Leistungsfähigkeit zu Kosten** verlagert. Zwei Abrechnungsfeinheiten (Cache-Schreibvorgänge werden mit **1,25×** berechnet, ein Aufschlag jenseits von **272k** Token) machen das Raster irreführend, solange nicht gemessen wurde, wie viel Kontext der Agent erneut liest (Lese-/Schreibverhältnis ~**153:1** beim agentischen Coding). Urteil des Ingenieurs, das als neutral beansprucht wird (SFEIR ist sowohl **Google Cloud Premier**-Partner *als auch* **Anthropic**-Partner): **niemand räumt alle Tabellen ab** — GPT-5.6 dominiert Terminal-Bench 2.1 und den Coding Agent Index (zu einem Drittel der Kosten pro Aufgabe), Claude bleibt bei SWE-Bench Pro vorn (~15 Punkte); METR meldete eine rekordverdächtige **Reward-Hacking**-Rate bei Sol. Fazit: „hört auf, den Champion zu suchen, lernt zu routen" — das Modell ist eine Commodity, der dauerhafte Vorteil liegt im **Context/Harness Engineering**.
Podcast-Interview „À la French“ (französischsprachiger Tech-Kanal, aufgezeichnet beim DevSummit) mit Mathieu Grymonprez, Global CDO der Adeo-Gruppe (Leroy Merlin, Obramat, Weldom). Wie eine jahrhundertealte Familien-Einzelhandelsgruppe die agentische KI-Welle aufgreift: Kultur vs. Struktur, Verantwortlichkeit, Token-Kosten und FinOps, Lock-in der Unternehmensintelligenz, Unternehmensgedächtnis und Agenten-Orchestrierung. Bereich: digitale Transformation, agentische KI, Einzelhandel, IT-Strategie.
#Agentische KI#digitale Transformation#CDO
Mathieu Grymonprez (Global CDO, groupe Adeo) — invité ; Jean-Baptiste Kempf · Steeve Morin · Mehdi Medjaoui (hôtes du podcast « À la French »)
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**.
Google-Whitepaper (die Folge „Day 1“ einer Reihe von Addy Osmani, Shubham Saboo und Sokratis Kartakis), das den Wandel des Software-Entwicklungszyklus (SDLC) im Zeitalter von Coding-Agenten nachzeichnet. These: Der grundlegende Wandel ist keine neue Sprache, sondern der Übergang vom Schreiben von Code zum **Ausdrücken von Absicht**. Das Dokument entwirft ein Spektrum, das von *vibe coding* (Prompten und Akzeptieren) bis zu *agentischem Engineering* reicht (die KI setzt unter von Menschen entworfenen Einschränkungen, Tests und Feedback-Schleifen um), mit **context engineering** als zentraler Fähigkeit, dem Modell der **Software-Fabrik** (das eigentliche Liefergut der Entwickler ist das System, das den Code produziert), **Harness Engineering** (Agent = Modell + Harness) sowie einer CapEx/OpEx-Wirtschaftlichkeitsanalyse der Gesamtbetriebskosten.
Gemeinsamer **DORA × delta**-Bericht (Google Cloud Professional Services), 60 Seiten, Version **v. 2026.1** (Zitate Februar 2026, PDF erstellt am 21. April 2026), Lizenz **CC BY-NC-SA 4.0** — das erste offizielle **DORA-ROI**-Framework für KI im SDLC, mit einem **interaktiven Rechner** unter dora.dev/ai/roi/calculator. Kernthese: ***„AI is an amplifier"*** — KI **verstärkt** gleichzeitig die Stärken leistungsstarker Organisationen und die Dysfunktionen schwacher Organisationen; sie erzeugt keine Leistung, sondern **vervielfacht sie dort, wo sie bereits vorhanden ist**. Neues zentrales Konzept: die ***J-Curve of AI value realization*** — jede KI-Einführung durchläuft einen **vorübergehenden Produktivitätseinbruch** (Lernkurve + Verifizierungssteuer + Pipeline-Anpassung), bevor **exponentielles Wachstum** einsetzt, eine Metapher für die *„tuition cost of transformation"*, die **explizit einzuplanen** ist. Referenzberechnung: Organisation mit 500 Vollzeitäquivalenten / vollbelastetem Gehalt von 176.000 $ / 12,5 % eingesparter Zeit pro Entwickler (≈ 1 Std./8-Std.-Tag) → **Wert 11,6 Mio. $ / Investition 8,4 Mio. $ / ROI 39 % / Amortisationszeit 8 Monate (0,7 Jahre)**. Modellierte Kosten: Lizenzen (250 $/Nutzer/Jahr), zusätzliche API (80 $/Nutzer/Jahr), Schulung (9.600 $/Nutzer/Jahr), Infrastruktur (100.000 $/Jahr), J-Curve-Kosten (3,3 Mio. $ für einen Rückgang von 15 % über 3 Monate). Modellierter Wert: **Kapazität zur Personal-Reinvestition** (11 Mio. $ — freigesetzte Kapazität zur Reinvestition, **KEIN Personalabbau**), Umsatz aus zusätzlichen Feature-Deployments (990.000 $, basierend auf einer Erfolgsquote von 33 % bei Ideen, Larsen 2023), **negative Auswirkung von Ausfallzeiten** (−344.000 $, „instability tax"). **Explizite Reinvestitionsstrategie**: ***„we strongly recommend organizations do not adopt a headcount-reduction strategy"*** — reinvestieren in Innovation, Talente halten, institutionelles Wissen nutzen. Fünf Wertsäulen: Productivity / User Experience / Cost Efficiency / Developer Experience / Business Growth (vom direktesten zum indirektesten, *kumulierter Geschäftswert*). Fünf systemische Schlüssel der Einführung: **Trust + Platform + Data + Users + Guardrails**. Zweiphasige Roadmap: (1) **Build context layer (CapEx)** — hochwertige IDP + gesunde Datenökosysteme; (2) **Empower human in loop (OpEx)** — context engineering + Vertrauen in KI. Indikatoren: Frühindikator = Experimentierfrequenz + Deployment-Frequenz; Stabilitätsmessgröße = Change Failure Rate + Nacharbeit. Drei zu modellierende Szenarien (Conservative 0,8 Wert × 1,5 Kosten / Realistic 1,0 / Optimistic 1,2 × 0,8). Herangezogene externe Daten: 78 % der Führungskräfte berichten von ROI bei ≥1 Gen-AI-Use-Case (Google Cloud), 88 % der frühen Anwender agentenbasierter KI verzeichnen positiven ROI, **35–40 % Produktivität bei Greenfield vs. ≤10 % bei Brownfield/Legacy** (Stanford), Inferenzkosten ÷280 zwischen November 2022 und Oktober 2024 (Stanford AI Index 2025), **727 % ROI über 3 Jahre** für Google-Cloud-KI-Kunden, durchschnittliche Amortisationszeit von KI am Markt **8 Monate**. Anerkannte Schwächen: *„all models are wrong"* — das Modell muss kontextualisiert, der Rechner angepasst werden; Risiko der Doppelzählung von Wert (eingesparte Zeit → sowohl vermiedene Neueinstellung ALS AUCH Zusatzumsatz); ein „loser" Zusammenhang bei der User Experience, daher aus dem Rechner ausgeschlossen. **Deontologische Einsicht**: ***„We don't measure AI by the code it writes but by the bottlenecks it clears"*** — gemessen an beseitigten Engpässen, nicht am Codevolumen. **Hohe Relevanz** für CIOs/CTOs, die einen belastbaren KI-Business-Case für CFO/Board erstellen müssen; für Frankreich/Europa in Bezug zu setzen zu Wescale (realistisch X3–X4), Tatsyi/Raiffeisen Bank Ukraine (Bankfallstudie, −75 Stellen, aber bewusste Reinvestition), Frizzo (3–5× Median), Curran/Intercom (3× F&E über 16 Monate), DORA Report 2025 (auf dem dieser ROI aufbaut).
#DORA ROI KI-unterstützter Softwareentwicklung#Google Cloud DORA-Bericht 2026.1#J-Curve of AI value realization
Rapport conjoint **DORA team × delta team** (Google Cloud Professional Services). Auteurs principaux : **Eva Dong** (AI Value Realization Americas, ex-McKinsey 8 ans, Master Financial Engineering Michigan) · **Andre Ellis Jr.** (Cloud Financial Operations Lead, Morehouse + Wharton MBA) · **Nathen Harvey** (DORA team lead, co-auteur multiples DORA reports + 97 Things Every Cloud Engineer Should Know) · **Vivian Hu** (10X Technology Consultant, contributrice DORA 2025 State of AI-assisted Software Development) · **Ursula Lübbert-Passing PhD** (AI Value Realization EMEA, 20 ans benchmarking + value advisory, PhD effort estimation software projects) · **Eric Maxwell** (lead 10X Technology consulting, ex-Chef Software, contributeur DORA) · **Aaron Wanjala** (cloud developer advocate Spring Boot/Angular). Conseillers et contributeurs : **Ben Jose · Eric Lam · Matt Orr · Allison Park · Ryan J. Salva · Jerome Simms · Dave Stanke · Cedric Yao**. Design : Human After All (humanafterall.studio). Document publié sous licence **CC BY-NC-SA 4.0** · version v. 2026.1 · citations retrieved February 2026.