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).
SFEIR-Analyse (Stimme eines Beratungsunternehmens, „die Lesart eines Ingenieurs“), die zwei zu oft vermischte Frameworks artikuliert: den **SDLC** (Software Development Life Cycle — *die Software korrekt und zuverlässig bauen*) und den **PDLC** (Product Development Life Cycle — *das richtige Produkt bauen und am Markt erfolgreich sein*). Zentrale These: Die beiden Zyklen sind keine Konkurrenten, sondern **verschachtelt** — der SDLC ist die Teilmenge des PDLC, **untergebracht in dessen Entwicklungsphase**; wenn ein Produktteam die „Build“-Phase erreicht, läuft darin ein vollständiger SDLC-Zyklus (Design → Build → Test → Review → Deployment) ab. Der SDLC ist standardisiert (**ISO/IEC/IEEE 12207**, Ausgaben 2017 und 2026), mit seiner Modell-Genealogie (Waterfall 1970, V-Modell, iterativ/spiralförmig, **Agile 2001**, **DevOps/DevSecOps ab 2009**) und seinen **DORA**-Metriken (Durchsatz, Stabilität, MTTR, Change-Failure-Rate). Der PDLC, als übergeordneter Zyklus, reicht von **Ideation/Discovery** bis zum **Marktrückzug** (nicht zu verwechseln mit dem marketingbezogenen **PLC** von Theodore Levitt, 1965, der eine *kommerzielle Kurve* beschreibt, keine *organisierte Arbeit*: „der PLC beobachtet eine Kurve; der PDLC organisiert Arbeit“). **Wendepunkt**: Der SDLC adressiert nativ **nur eines von vier Risiken** — über **Marty Cagans „Four Big Risks“**-Framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business Viability → PM) — eine Organisation, die im SDLC exzellent, aber gegenüber dem PDLC blind ist, produziert „Software, die niemand will“ — John Cutlers **„Feature Factory“** (Erfolg gemessen am Output, nicht am Outcome). **Warum KI alles verändert**: Generative KI **komprimiert den SDLC** (Google/JetBrains-Daten, Mai 2026: **~85 % der Entwickler** nutzen regelmäßig Coding-Agenten, **~41 % des neuen Codes** ist KI-generiert; die Implementierung schrumpft von Wochen auf Stunden), sodass sich der **Engpass stromaufwärts verlagert** — die Entscheidung, *was* gebaut werden soll (Marty Cagan, April 2026: „wenn die Kosten der Auslieferung einbrechen, verlagert sich der Engpass zur Discovery“). Konsequenzen: DORA 2025 (~5.000 Fachleute, 90 % KI-Adoption) zeigt eine **positive Korrelation mit dem Durchsatz, aber eine negative mit der Stabilität** (mehr unvalidierte Features bedeuten Instabilität und Nacharbeit); Andrew Ng (AI Startup School, Juli 2025) berichtet von Teams, die das **Verhältnis „1 PM auf 4 Ingenieure“ zu „2 PMs auf 1 Ingenieur“ umkehren**; und mit **Spec-driven Development** wird die Grenze zwischen PDLC/SDLC **durchlässig** (die Produktspezifikation wird direkt von Agenten ausführbar). **Was ein CIO mitnehmen sollte**: Ein augmentierter SDLC wird zum **Marktstandard, nicht zum Differenzierungsmerkmal** — die Schnittstelle zum Produkt muss instrumentiert, **ausführbare Spezifikationen** als Input verlangt, technische Metriken mit Outcome-Metriken abgeglichen und die Rolle des „Feature-Lieferanten“ **abgelehnt** werden. Für einen CPO: Die Verlagerung des Engpasses zur Discovery ist zugleich eine **Aufwertung** (Produkturteil wird wieder knapp) und eine **Handlungsaufforderung** (Discovery industrialisieren, um mit dem SDLC gleichzuziehen). SFEIRs eigenes Framework („Designing and building in the agentic era“ — **11-Phasen-Zyklus** + **Software Factory 10x**) wird als Antwort auf der Engineering-Seite positioniert, wobei die **Verknüpfung der beiden Zyklen** als nächster Hebel gilt. Fazit: „während Code zur Commodity wird, verschiebt sich die Marge hin zu Produkturteil und Governance.“
Debattenbeitrag von **Olivier Rafal** (Consulting Director Strategy bei **WeNvision**), veröffentlicht am **23. Februar 2024** auf **CIO-Online** (Rubrik *Tribune*), der eine damals noch kontraintuitive These vertritt: **generative KI ist eher eine Frage des Technologieprodukts als ein KI-/Data-Science-Projekt**. **Argument 1 — Data Science ist nicht der Kern des Problems**: Der Aufbau eines *Foundation Model* von Grund auf erfordert *„mehrere Monate, Millionen von Euro und Zugang zu enormen Datenmengen“* — vorbehalten Akteuren mit spezifischen, monetarisierbaren Datensätzen (z. B. **Bloomberg** mit **BloombergGPT** für den Finanzbereich). Für nahezu alle Unternehmen ist es daher nicht der richtige Reflex, Data Scientists einzustellen. **Argument 2 — Kompetenz-Mismatch**: Hauptsächlich benötigt werden **Entwicklungs- und Integrationsingenieure** (Backend/Frontend), **solide Cloud-Kenntnisse** und **DevOps**. Kundenzitat: *„Man muss nicht unbedingt Data Scientist sein, aber man muss die Grundkonzepte verstehen, Backend-Entwicklungskenntnisse und solide Cloud-Kenntnisse mitbringen.“* **Argument 3 — Plattformarchitektur (Orchestratoren + APIs)**: Der Aufbau einer unternehmensinternen **plateforme d'IA générative** über Orchestratoren und APIs macht es *„möglich, mit den besten am Markt verfügbaren LLMs zu arbeiten und zwischen ihnen zu wechseln, sobald sich ihre jeweiligen Fähigkeiten weiterentwickeln, ohne die Anwendungen überarbeiten zu müssen“* (Anti-Vendor-Lock-in). **Argument 4 — vom Projekt zum Produkt**: *„Die Plattform […] muss als eigenständiges Produkt betrachtet werden“*; statt einer einmaligen Investition ist ein **monatlicher Finanzierungsstrom** einzuplanen (kontinuierliche Iteration, fortlaufende Innovation). **Argument 5 — Governance & Shadow AI**: Die beispiellose Demokratisierung generativer KI erzeugt *„ebenso viel Shadow AI wie starke Erwartungen an die CIO-Organisation“* → Governance, um Business-Bedarfe zu erfassen, **Produkte nach Wert zu priorisieren** und den ordnungsgemäßen Betrieb zu überwachen. Angekündigter **Paradigmenwechsel**: *„der Wandel führt von der klassischen algorithmischen Programmierung zu agents Langchain, die einen Teil der Entscheidungen übernehmen“*. **Relevanz für die Veille**: ein **Gründungstext (2 Jahre vorausschauend)** der WeNvision-Doktrin (Produkt > Projekt, Plattform/API, flussbasierte Finanzierung, Governance, Shadow AI), später erweitert durch [[wenvision-ai-agents-enterprise-deployment-2025-10-01]], [[habert-ia-agentique-production-2025-10-29]], und rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04 (FinOps/Token, flussbasierte Finanzierung → finanzielle Governance). Er nimmt zudem den *Harness/die Plattform rund um das Modell* vorweg (Dropbox/Okumura: *systems around the model*) sowie die durch eine Orchestrierungsschicht erreichte **Modellunabhängigkeit**.
#generative KI#Technologieprodukt#Produkt vs. Projekt
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (cabinet de conseil FR). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Auteur déjà présent dans la veille (cf. fiches WeNvision/Atlas/Tokenomics). Publié le **23 février 2024**.