Brief „Dear friends“ von Andrew Ng in *The Batch* (DeepLearning.AI, Ausgabe 359) über **loop engineering**, angewendet auf die **0-to-1**-Produktentwicklung. Ng stellt seine **3 zentralen Loops** vor — agentic coding loop (~Minuten), developer feedback loop (~Stunden), external feedback loop (~Tage) — verschachtelt nach zunehmender Zeitskala, verbunden über *coding agent → product spec/evals → developer vision → external feedback*. Zentrale These: Menschen behalten einen **context advantage** (statt eines „taste“), der human-in-the-loop unverzichtbar macht; Ingenieure übernehmen eine partielle Rolle im Produktmanagement. Themenfeld: coding agents, Produktentwicklung, agentische Methodik.
Langform-Essay von **Shubham Saboo** (X/Twitter), der eine These zur Rolle des Product Managers im Zeitalter der Agenten vertritt: Die nächste entscheidende Fähigkeit ist **nicht Prompt Engineering**, sondern **Loop Engineering** — die Gestaltung eines *Systems, das sich mit jedem Durchlauf verbessert*, statt jedes Mal den perfekten Prompt zu schreiben. Ein **Loop** ist ein wiederholter Zyklus: das ändern, was das Verhalten des Agenten prägt → ausführen → das Ergebnis bewerten → die Änderung beibehalten, wenn die Qualität steigt, sonst zurücksetzen → **das Gelernte kumulieren**, sodass die nächste Version einen Vorsprung hat. Für einen PM ist der Einstiegspunkt nicht Code, sondern die **dauerhaften Artefakte**, die sein Urteilsvermögen kodieren: PRD-Review-Skill, *Summarizer* für Kundengespräche, Bewertungsraster, Launch-Checkliste, Research-Workflow, `CLAUDE.md`, Prompt-Vorlage, Priorisierungsrahmen. Da sie wiederverwendet werden, **kumulieren sich diese Artefakte in beide Richtungen** — und **driften** unbemerkt ab (eine CLAUDE.md, die immer weiter wächst, eine Checkliste, die ignoriert wird…): Das Modell hat sich nicht verschlechtert, die Artefakte sind unbeobachtet abgedriftet. Ein Loop besteht aus **5 Teilen**: Trigger, Aktion, **Nachweis**, Gedächtnis, **Abbruchbedingung** (die wichtigste). **Evals** werden zur PM-Arbeit (das Artefakt anhand bekannter Beispiele testen: 3 gute / 3 schlechte PRDs, 5 verstandene Gespräche, 2 vergangene Launches). Das **Gedächtnis** liegt auf **GitHub** (das Repo wird zum "Produktgedächtnis": Commits, Diffs, Eval-Ergebnisse, Entscheidungsprotokoll, Rollback). Empfohlener erster Loop: ein **wöchentlicher Product-Signal-Loop** (jeden Freitag). Der Geschmack bleibt zentral — braucht jetzt aber **Nachweis**. Zitiert Boris (Schöpfer von Claude Code): "er schreibt keine Prompts mehr, er schreibt Loops."
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**.