Ankündigung von **Meta AI Research**, veröffentlicht am **5. August 2026** (angegebene Lesezeit: 4 Minuten, keine individuelle Autorenangabe): **Muse Code** in der Beta-Phase, *„ein Terminal-Coding-Agent"*, sowie das dahinterstehende Modell, **Muse Spark 1.2**. Meta selbst rahmt den Launch so: *"This marks our next step toward the frontier, with larger and much more capable models on the way"* — **ein Schritt in Richtung Frontier, keine große Behauptung**. Auf der Harness-Seite werden **drei architektonische Elemente** beschrieben: **asynchrone Hintergrund-Agenten**, die *"remain active throughout each session, rather than being spawned for individual tasks"*, um redundante Informationsbeschaffung zu vermeiden und den Steuerungsbedarf zu reduzieren; ein **lokales Event-Log**, in dem *"every model call, tool run, approval, and edit is appended"*, wodurch die Laufzeitumgebung *"replay-exact and restart-safe"* wird — fähig, nach einem Absturz exakt dort fortzusetzen, wo sie aufgehört hat; sowie **drei standardmäßig mitgelieferte Skills** — `/plan` (wandelt eine Aufgabe in einen zur Genehmigung vorgelegten Plan um), **`/grill`** (stresstestet den Plan *"until it holds up"*) und `/goal`. Auf der Modellseite beansprucht Meta ein **gemeinsames Training von Modell und Harness** (*"to maximize harness compatibility"*, wobei Harness-Trajektorien per Rejection Sampling erfasst werden, mit Recipe-Optimierungen für Ziele, Kompaktierung und Sub-Agenten), ein **Long-Horizon**-Training (Generierung ganzer Repositories, End-to-End-Projekte, Self-Research, mit Planung, Zielkonditionierung und **Context Compaction**), sowie eine **Selbstverbesserungsschleife**, in der Muse Spark 1.1 die Umgebungen und Instruction-Templates generiert **und anschließend Kandidatenlösungen bewertet**, wodurch ein Trainingsdatensatz für 1.2 entsteht. ⚠️ **Die bemerkenswerteste Tatsache dieser Ankündigung steht nirgends im Text**: Die vier veröffentlichten Diagramme — Terminal-Bench 2.1, DeepSWE 1.1, ein interner Meta-Benchmark und die Fallstudie zur GPU-Kernel-Optimierung — **platzieren Muse Spark 1.2 in allen vier Fällen hinter Opus 5**, einschließlich auf Metas eigenem proprietärem Benchmark (70,6 % vs. 79,4 %) und in der Fallstudie, wo das Modell **Vierter von sechs** wird (+68,7 % vs. +74,0 %). ⚠️ **Und der tatsächliche Zugewinn des Modells fällt geringer aus, als es scheint**: Bei den beiden öffentlichen Benchmarks wird 1.1 mit `mini-swe-agent` gemessen und 1.2 mit Muse Code — die Differenz von 6,7 Punkten vermengt somit Modell und Harness. Beim internen Benchmark, dem einzigen Vergleich ohne Angabe einer Harness, sinkt die Differenz zwischen 1.1 und 1.2 auf **2,3 Punkte**.
#Meta AI Research#Muse Code#Muse Spark 1.2
**Meta AI Research** — publication institutionnelle sans auteur nommé · sur `research.meta.ai`. Le billet renvoie à un **rapport** pour la méthodologie d'évaluation · non repris ici.
Tech-Watch-Notiz von **Didier Girard** vom **2. August 2026**, ausgelöst durch die Frage eines Kollegen ("was ist ACP?"), die sich als ein Problem herausstellt, das nicht terminologischer, sondern **dokumentarischer** Natur ist. **Drei Protokolle konkurrieren um das Akronym**, ohne jede technische Überschneidung: **Agent Client Protocol** (Client ↔ Agent — Zed, August 2025, JSON-RPC 2.0 über stdio, Apache-2.0, "was LSP für Sprachen war"), **Agentic Commerce Protocol** (Agent ↔ Händler — OpenAI + Stripe, 29. Sept. 2025, im Wettstreit mit Googles **UCP** vom 11. Jan. 2026, gestützt auf **AP2**), und **Agent Communication Protocol** (Agent ↔ Agent — IBM Research / BeeAI, marginal, aber suchverfälschend). **Der Kern der Notiz ist nicht die Entwirrung, sondern deren beobachtetes Scheitern**: Der Autor sucht "ACP" in seiner Tech-Watch-Wissensbasis und erhält **zwölf Ergebnisse, allesamt zum Commerce-Protokoll, null zu Zeds Protokoll** – *"unsere Watch-Agenten hatten das Akronym indexiert, ohne es zu disambiguieren"*. Daraus folgt eine Regel des Knowledge Engineering: ***"niemals ein bloßes Akronym indexieren"*** – die Entität ist "Agent Client Protocol", "ACP" ist **nur ein Alias**, der von drei verschiedenen Entitäten getragen wird. Es folgt eine strukturierende Klarstellung (**MCP verbindet einen Agenten mit seinen Tools, ACP verbindet einen Client mit einem Agenten; beide bauen aufeinander auf**), dann der Lehrbuchfall: **Buzz**, veröffentlicht von **Block** am 21. Juli 2026 unter Apache-2.0 – ein selbst hostbarer Workspace auf Basis von **Nostr**, in dem jeder menschliche oder agentische Teilnehmer ein **Schlüsselpaar** ist und jede Nachricht, jeder Workflow-Schritt oder Git-Push ein **signiertes Ereignis** in einem Append-only-Log darstellt. Eine vollständig protokollbasierte Architektur (`buzz-acp` ein ACP-Harness über stdio, `buzz-agent` ein ACP-Agent, der ein LLM aufruft, `buzz-dev-mcp` ein MCP-Server für Shell und Bearbeitung), daher die Agenten-Agnostizität: **Goose, Claude Code und Codex** docken über denselben Harness an, und **Hermes** (Nous Research) hat sich damit verbunden, ohne dass Block eine einzige Zeile Code geschrieben hätte – *"N+M statt N×M, in Produktion laufend"*. Die Notiz schließt mit der Frage des **Claude-Abonnements** gegenüber Drittanbieter-Agenten, mit einer fünfstufigen Zeitleiste für 2026 und einer **Designregel**, die über diesen Fall hinaus gilt: Die Grenze verläuft nicht rechtlich, sondern **architektonisch** – ***"wer konsumiert, und in wessen Namen"*** (ein `owner-only`-Agent konsumiert dein Abonnement für dich; ein `anyone`-Agent in einem geteilten Kanal leitet die Anfragen deiner Kollegen über dein Konto). ⭐ **In diesem Korpus durchgeführte Verifizierung**: Die These bestätigt sich, und zwar deutlicher als die Notiz behauptet – nicht nur ist "Agent Client Protocol" darin **völlig abwesend**, sondern das bloße Akronym `ACP` **ist bereits als Entität typisiert** in zwei Fiches, und die KB-Seite `Agentic-Commerce-Protocol` **schreibt das Protokoll bereits Google zu**, obwohl es OpenAI + Stripe gehört. Die beschriebene Kollision ist kein erst kommendes Risiko: Sie hat **bereits einen Zuschreibungsfehler** im Graphen erzeugt.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Episode „Phase 5 · Review“ der SFEIR-Serie über den augmentierten SDLC, veröffentlicht **am selben Tag** wie Addy Osmanis LinkedIn-Beitrag, den sie in eine Phasenspezifikation übersetzt. These: **Qualität hat die Adresse gewechselt** — sie wird nicht mehr im Code gelesen (Agenten produzieren mehr davon, als irgendjemand reviewen kann), sondern in **dem Ring von Constraints, der den Agenten umgibt**. Osmanis Ring (sieben Dimensionen — Correctness, Security, Performance, Accessibility, Maintainability, **wirtschaftliche Effizienz**, **Verständlichkeit** — verbunden durch die **Back-Pressure**-Regel: „einer Loop wird nur die Autonomie zugestanden, die man günstig und zuverlässig verifizieren kann, keinen Zentimeter mehr“) wird neu gezeichnet, übersetzt und an Phase 5 des 11-Phasen-Zyklus von SFEIR angehängt. Das strukturierende Korollar: **der Flaschenhals war nie die Generierung, sondern die Verifikation** — „Generierung ist ein weiter Trichter, Verifikation ein enger Hals; wer den Trichter beschleunigt, verdickt den Stau am Hals.“ **Die interessanteste Design-Entscheidung ist eine Wahl der Zyklusarchitektur**: Review liegt bewusst **außerhalb der drei menschlichen Gates** (Define, Plan, Ship), denn das Gate auf Review zu legen würde bedeuten, menschliche Aufmerksamkeit — eine endliche Ressource — als Kontrollpunkt einer Generierungskapazität zu setzen, die selbst skaliert: „man hätte eine Pipeline gebaut, deren maximaler Durchsatz der Anzahl an Diffs entspricht, die ein Senior bis Feierabend lesen kann.“ Daher die Aufteilung: **Review instrumentiert, Ship entscheidet** — Review liefert einen *anfechtbaren Beweiskörper*, Ship entscheidet anhand der Beweise, nicht anhand des vollständigen Diffs. Eine Position gegen Monperrus (dessen Diagnose SFEIR übernimmt — die menschliche Inspektion jedes Diffs hält der agentischen Geschwindigkeit nicht stand —, dessen Schlussfolgerung sie aber zurückweist: Abnahme kann nicht delegiert werden). Die benannte Falle ist die **zirkuläre Validierung** (der Agent, der den Code schreibt, schreibt auch die Tests, die ihn validieren: „man hat einen Spiegel gebaut, keinen Ring“), mit fünf von Anthropic entlehnten Gegenmaßnahmen (unabhängige Gates in getrennten Context-Windows, deterministisch + agentisch ersetzen sich niemals gegenseitig, Shadow Mode, risikobasierte Abstufung, Logging ins SIEM) sowie der Warnung von Compare the Market (**AST-Graph ~70 % vs. Vector-RAG ~58 %**, RAG schneidet *schlechter ab als gar kein Kontext*). Die eigene Erweiterung der Firma ist **die Ratsche**: „jedes Entkommen wird zum Constraint“ — ein Fehler, der den Ring durchbrochen hat, wird *innerhalb des Rings* wieder geschlossen (Test, Lint-Regel, Rubrik, Harness-Guardrail), bei Compound-1, „das einzige Asset in der Kette, das an Wert gewinnt, während Modelle an Wert verlieren“ (ein internes, nicht auditiertes Maß: **− 30 % weniger Korrekturiterationen nach zehn Zyklen**). Der Artikel schließt mit einer Neuformulierung der Frage: „Ist dieser Code gut?“ lässt sich nicht mehr beantworten; was bleibt, ist **„Was lässt mein System nicht durch?“**
#Ring von Constraints#Constraints um Agenten#Review-Phase
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — construit sur Addy Osmani (Google) ; cite Martin Monperrus · Paula Hingel (Augment Code) · DORA/Google Cloud · Jason Clinton (Anthropic) · l'équipe Engineering de Compare the Market
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.
Meinungsbeitrag von **Olivier Rafal** (Consulting Director Strategy, **WeNvision** — **SFEIR**-Gruppe; ehemaliger Chefredakteur von *Le Monde Informatique*), veröffentlicht am **1. Juni 2026** in **CIO-Online**, aufgebaut um ein **Paradox**: Im KI-Zeitalter **verändert sich in der Softwareentwicklung alles … und nichts ändert sich**. **Was sich ändert = das Betriebsmodell.** Die Rollen werden neu definiert: Der **Product Owner** verlagert sich von der Backlog-Zerlegung hin zur **Erzeugung von für KI nutzbarem Kontext**; der **Entwickler** verlagert sich vom Schreiben von Code hin zum **Einrahmen, 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 **Sfeir**-Kennzahl: *„dieses Duo treibt heute rund 80 % der Produktionskette an“*, wobei die verbleibenden ca. 20 % (Architektur, Data Governance, Sicherheit) zentralisiert bleiben. Zentrales Zitat: ***„Es ist kein Tooling-Problem, sondern ein Problem des Betriebsmodells.“*** **Was sich nicht ändert = die Disziplin des Zyklus.** Die **SDLC**-Phasen (Definieren → Bauen → Verifizieren → Bereitstellen → Warten) bleiben identisch und nicht verhandelbar; KI schafft keine davon ab, sie **verschärft** sie: ***„jede Nachlässigkeit, die im menschlichen Tempo irgendwie absorbiert wurde, wird im KI-Tempo zu einem Defekt auf Industrieniveau“*** (Metapher Amateur- vs. Profisport). Daher **drei unverletzliche *Gates*** (menschliche Kontrolle): **Spezifikation, Planung, Delivery Review**; Validierung **durch Nachweis** (nicht durch die bloßen Behauptungen der KI); **systematische Kapitalisierung** (jeder Zyklus bereichert den nächsten) → gemessenes Ergebnis: **−30 % Korrekturiterationen nach ca. 10 Zyklen**. Prinzip: ***„je schneller die Ausführung, desto strenger muss der Rahmen sein.“*** Herangezogene Konzepte: **Harness** (an den Kontext angepasste agentische Regeln), **vibe-coding** gilt im Unternehmenskontext als **nicht tragfähig**. **Dritte Säule = Governance, FinOps & wertorientierte Steuerung**: **variable und wiederkehrende** KI-Kosten (~**10 €/Stunde** pro augmentiertem Arbeitsplatz), ein Wandel von Pauschallizenzierung zu nutzungsbasierter Abrechnung (eine Parallele zur Cloud der 2010er-Jahre); **FinOps** zielt nicht auf Kostensenkung ab, sondern darauf, *„die Effizienz der Tools 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 Fachbeziehung und kollektiver Disziplin **verstärkt** ein KI-gestützter SDLC lediglich bestehende Probleme (man läuft schneller gegen die Wand). 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 *agent manager*-Debatte (BFM/Girard, SFEIR).
#Softwareentwicklung#KI#alles ändert sich nichts ä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**.