Ankündigung von **Meta AI Research**, veröffentlicht am **5. August 2026** (angegebene Lesezeit: 4 Minuten, kein individueller Autorenvermerk): **Muse Code** in der Beta-Phase, *„ein Terminal-Coding-Agent“*, sowie das Modell, das ihn antreibt, **Muse Spark 1.2**. Meta selbst ordnet die Markteinführung ein: *„Dies markiert unseren nächsten Schritt in Richtung der Frontier, mit größeren und deutlich leistungsfähigeren Modellen, die bereits in Vorbereitung sind.“* **Drei architektonische Elemente auf der Harness-Seite.** **Asynchrone Hintergrund-Agenten**, die *„während der gesamten Sitzung aktiv bleiben, statt für einzelne Aufgaben neu erzeugt zu werden“*, wodurch redundante Informationsbeschaffung vermieden und der Steuerungsbedarf verringert wird. Ein **lokales Ereignisprotokoll**, in dem *„jeder Modellaufruf, jede Tool-Ausführung, jede Genehmigung und jede Bearbeitung angehängt wird“*, wodurch die Laufzeitumgebung zu einem System wird, das *„replay-exakt und neustartsicher“* ist und nach einem Absturz genau dort fortsetzen kann, wo es aufgehört hat. Und **drei standardmäßig mitgelieferte Skills**: `/plan` (wandelt eine Aufgabe in einen zur Genehmigung vorgelegten Plan um), **`/grill`** (stellt den Plan auf die Probe, *„bis er standhält“*), und `/goal`. **Auf der Modellseite** beansprucht Meta ein **Co-Training von Modell und Harness** (*„um die Harness-Kompatibilität zu maximieren“*, wobei Harness-Trajektorien per Rejection Sampling erfasst werden und Rezeptoptimierungen für Ziele, Kompaktierung und Sub-Agenten vorgenommen werden), ein Training mit **langem Zeithorizont** (Generierung ganzer Repositories, End-to-End-Projekte, Selbstrecherche, mit Planung, Zielkonditionierung und Kontextkompaktierung) sowie eine **Selbstverbesserungsschleife**, in der Muse Spark 1.1 die Umgebungen und Anweisungsvorlagen generiert und anschließend die Kandidatenlösungen bewertet, wodurch ein Trainingsdatensatz für die 1.2 entsteht. **Was die veröffentlichten Diagramme zeigen**, ohne dass der Text dies kommentiert: Die vier Vergleiche — 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 % gegenüber 79,4 %) und in der Fallstudie, in der das Modell auf dem vierten von sechs Plätzen landet (+68,7 % gegenüber +74,0 %). **Ein Vorbehalt zum Lesen des Versionsgewinns**: Bei den beiden öffentlichen Benchmarks wird 1.1 mit `mini-swe-agent` und 1.2 mit Muse Code gemessen, sodass die Differenz von 6,7 Punkten Modell- und Harness-Fortschritt vermischt. Beim internen Benchmark, dem einzigen Vergleich, bei dem keine Harness genannt wird, 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 ein Problem behandelt, das nicht terminologisch, sondern **dokumentarisch** 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, "das, was LSP für Sprachen war"), **Agentic Commerce Protocol** (Agent ↔ Händler — OpenAI + Stripe, 29. Sept. 2025, in Konkurrenz zu 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 das beobachtete Scheitern**: Der Autor sucht "ACP" in seiner Tech-Watch-Wissensdatenbank und erhält **zwölf Treffer, alle zum Commerce-Protokoll, keinen zu dem von Zed** — *"unsere Watch-Agenten hatten das Akronym indexiert, ohne es zu disambiguieren"*. Daraus folgt eine Regel des Knowledge Engineering: ***"ein nacktes Akronym wird nie indexiert"*** — die Entität ist "Agent Client Protocol", "ACP" ist **nur ein Alias**, getragen von drei verschiedenen Entitäten. Es folgt eine strukturierende Klarstellung (**MCP verbindet einen Agenten mit seinen Tools, ACP verbindet einen Client mit einem Agenten; beide stapeln sich**), dann der Lehrbuchfall: **Buzz**, von **Block** am 21. Juli 2026 unter Apache-2.0 veröffentlicht — ein selbst hostbarer Arbeitsbereich 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 ist. 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-Shell- + Editier-Server), daher Agenten-Agnostizismus: **Goose, Claude Code und Codex** docken über dasselbe Harness an, und **Hermes** (Nous Research) hat sich damit verbunden, ohne dass Block eine einzige Zeile geschrieben hätte — *"N+M statt N×M, im Produktivbetrieb"*. Die Notiz schließt mit der Frage des **Claude-Abonnements** gegenüber Drittanbieter-Agenten, mit einer fünfstufigen 2026er-Zeitleiste und einer **Gestaltungsregel**, die über diesen Fall hinaus gilt: Die Grenze ist nicht rechtlicher, sondern **architektonischer** Natur — ***"wer konsumiert, und in wessen Auftrag"*** (ein `owner-only`-Agent verbraucht Ihr Abonnement in Ihrem Auftrag; ein `anyone`-Agent in einem gemeinsamen Kanal leitet die Anfragen Ihrer Kollegen über Ihr Konto). **Am vorliegenden Korpus durchgeführte Überprüfung**: Die These bestätigt sich, und schärfer noch, als die Notiz behauptet — nicht nur ist "Agent Client Protocol" **vollständig abwesend**, sondern das nackte 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 zukünftiges 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-Reihe zum erweiterten SDLC, veröffentlicht **am selben Tag** wie der LinkedIn-Beitrag von Addy Osmani, 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 — Korrektheit, Sicherheit, Performance, Barrierefreiheit, Wartbarkeit, **wirtschaftliche Effizienz**, **Verständlichkeit** — verbunden durch die **Back-Pressure**-Regel: „einer Schleife wird nur so viel Autonomie zugestanden, wie günstig und zuverlässig verifiziert werden kann, keinen Zentimeter mehr") wird nachgezeichnet, übersetzt und an Phase 5 des 11-Phasen-Zyklus von SFEIR angehängt. Das strukturierende Korollar: **der Engpass war nie die Generierung, es ist die Verifikation** — „Generierung ist ein weiter Trichtermund, Verifikation ein enger Hals; wer den Mund 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 würde man Review zum Gate machen, würde menschliche Aufmerksamkeit — eine endliche Ressource — zum Kontrollpunkt einer Generierungskapazität, 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 *widerlegbaren Beweiskörper*, Ship entscheidet anhand der Evidenz, nicht anhand des vollständigen Diffs. Eine Position, die sich gegen Monperrus stellt (von dem SFEIR die Diagnose übernimmt — menschliche Inspektion jedes Diffs hält der agentischen Geschwindigkeit nicht stand —, aber die Schlussfolgerung ablehnt: 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 Gegenmaßnahmen von Anthropic (unabhängige Gates in getrennten Context-Windows, deterministisch + agentisch ersetzen sich nie gegenseitig, Shadow Mode, risikobasierte Stufung, Logging ans SIEM) und der Warnung von Compare the Market (**AST-Graph ~70 % vs. Vektor-RAG ~58 %**, wobei RAG *schlechter abschneidet als gar kein Kontext*). Die eigene Erweiterung der Firma ist **das Ratschenprinzip**: „jedes Entkommen wird zum Constraint" — ein Defekt, der den Ring durchbrochen hat, wird *innerhalb des Rings* geschlossen (Test, Lint-Regel, Review-Rubrik, Harness-Guardrail) bei Compound-1, „das einzige Asset in der Kette, das an Wert gewinnt, während die Modelle an Wert verlieren" (eine ungeprüfte interne Messung: **−30 % Fix-Iterationen nach zehn Zyklen**). Sie schließt mit einer Neuformulierung der Frage: „Ist dieser Code gut?" ist unbeantwortbar geworden; 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** — 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**.