Annuncio di **Meta AI Research** pubblicato il **5 agosto 2026** (tempo di lettura dichiarato: 4 minuti, nessuna firma individuale): **Muse Code** in beta, *"a terminal coding agent"*, e il modello che lo alimenta, **Muse Spark 1.2**. Meta stessa inquadra il lancio: *"This marks our next step toward the frontier, with larger and much more capable models on the way"* — **un passo verso la frontiera, non un'affermazione ambiziosa**. **Tre elementi architetturali** sono descritti sul lato harness: **agenti asincroni in background** che *"remain active throughout each session, rather than being spawned for individual tasks"*, per evitare la raccolta ridondante di informazioni e ridurre la necessità di guida; un **registro eventi locale** in cui *"every model call, tool run, approval, and edit is appended"*, che rende il runtime *"replay-exact and restart-safe"* — capace di riprendere esattamente da dove si era interrotto dopo un crash; e **tre skill fornite di serie** — `/plan` (trasforma un compito in un piano sottoposto ad approvazione), **`/grill`** (mette alla prova il piano *"until it holds up"*), e `/goal`. Sul lato modello, Meta dichiara **co-training del modello con l'harness** (*"to maximize harness compatibility"*, con traiettorie dell'harness campionate tramite rejection sampling e ottimizzazioni di ricetta per obiettivi, compaction e sub-agenti), addestramento **long-horizon** (generazione dell'intero repository, progetti end-to-end, self-research, con planning, goal conditioning e **compaction del contesto**), e un **ciclo di auto-miglioramento** in cui Muse Spark 1.1 genera gli ambienti e i template di istruzioni **e poi valuta le soluzioni candidate**, producendo un set di addestramento per 1.2. ⚠️ **Il fatto più notevole di questo annuncio non è scritto da nessuna parte nel testo**: i quattro grafici pubblicati — Terminal-Bench 2.1, DeepSWE 1.1, un benchmark interno Meta, e il case study di ottimizzazione di kernel GPU — **collocano Muse Spark 1.2 dietro Opus 5 in tutti e quattro i casi**, incluso sul benchmark proprietario di Meta stessa (70,6% contro 79,4%) e sul case study, dove il modello si classifica **quarto su sei** (+68,7% contro +74,0%). ⚠️ **E il guadagno reale del modello è più piccolo di quanto sembri**: sui due benchmark pubblici, 1.1 è misurato con `mini-swe-agent` e 1.2 con Muse Code — il divario di 6,7 punti confonde quindi modello e harness. Sul benchmark interno, l'unico confronto in cui non viene menzionato alcun harness, il divario 1.1 → 1.2 scende a **2,3 punti**.
#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.
Nota di veille tecnologica di **Didier Girard** datata **2 agosto 2026**, nata dalla domanda di un collega ("cos'è ACP?") che si rivela affrontare un problema non terminologico ma **documentale**. **Tre protocolli si contendono l'acronimo**, senza alcuna sovrapposizione tecnica: **Agent Client Protocol** (client ↔ agente — Zed, agosto 2025, JSON-RPC 2.0 su stdio, Apache-2.0, "ciò che LSP ha fatto per i linguaggi"), **Agentic Commerce Protocol** (agente ↔ merchant — OpenAI + Stripe, 29 settembre 2025, contrapposto a **UCP** di Google dell'11 gennaio 2026 sostenuto da **AP2**), e **Agent Communication Protocol** (agente ↔ agente — IBM Research / BeeAI, marginale ma che inquina le ricerche). **Il fulcro della nota non è la disambiguazione ma il suo fallimento osservato**: l'autore cerca "ACP" nella propria base di conoscenza di veille tecnologica e ottiene **dodici risultati, tutti sul protocollo di commercio, zero su quello di Zed** — *"i nostri agenti di veille avevano indicizzato l'acronimo senza disambiguarlo"*. Da cui una regola di knowledge engineering: ***"mai indicizzare un acronimo nudo"*** — l'entità è "Agent Client Protocol", "ACP" è **solo un alias**, portato da tre entità distinte. Segue una precisazione strutturante (**MCP collega un agente ai suoi strumenti, ACP collega un client a un agente, i due si sovrappongono**), poi il caso di scuola: **Buzz**, pubblicato da **Block** il 21 luglio 2026 sotto Apache-2.0 — uno spazio di lavoro auto-ospitabile costruito su **Nostr**, dove ogni partecipante umano o agente è una **keypair** e ogni messaggio, passo di workflow o git push è un **evento firmato** in un log append-only. Un'architettura interamente basata su protocolli (`buzz-acp` un harness ACP su stdio, `buzz-agent` un agente ACP che chiama un LLM, `buzz-dev-mcp` un server MCP per shell + editing), da cui l'agnosticismo verso gli agenti: **Goose, Claude Code e Codex** si collegano tramite lo stesso harness, e **Hermes** (Nous Research) vi si è collegato senza che Block scrivesse una sola riga — *"N+M invece di N×M, in produzione"*. La nota si chiude sulla questione dell'**abbonamento Claude** rispetto agli agenti di terze parti, con una cronologia in cinque tappe del 2026 e una **regola di design** che si applica al di là di questo caso: la linea di demarcazione non è legale ma **architetturale** — ***"chi consuma, e per conto di chi"*** (un agente `owner-only` consuma il tuo abbonamento per te; un agente `anyone` in un canale condiviso instrada le richieste dei tuoi colleghi attraverso il tuo account). ⭐ **Verifica effettuata su questo corpus**: la tesi regge, e in modo più netto di quanto la nota affermi — non solo "Agent Client Protocol" è **completamente assente**, ma l'acronimo nudo `ACP` **è già tipizzato come entità** in due schede, e la pagina KB `Agentic-Commerce-Protocol` **attribuisce già il protocollo a Google** quando in realtà appartiene a OpenAI + Stripe. La collisione descritta non è un rischio ancora a venire: ha **già prodotto un errore di attribuzione** nel grafo.
**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.
Episodio « Phase 5 · Review » della serie SFEIR sull'SDLC aumentato, pubblicato lo stesso giorno del post LinkedIn di Addy Osmani, che traduce in una specifica di fase. Tesi: la qualità ha cambiato indirizzo — non si legge più nel codice (gli agenti ne producono più di quanto chiunque possa revisionare) ma nell'anello di vincoli che circonda l'agente. L'anello di Osmani (sette dimensioni — correttezza, sicurezza, prestazioni, accessibilità, manutenibilità, **efficienza economica**, **comprensibilità** — collegate dalla regola del **back-pressure**: "a un loop si concede solo l'autonomia che si sa verificare in modo economico e affidabile, non un centimetro di più") viene ridisegnato, tradotto e collegato alla fase 5 del ciclo a 11 fasi di SFEIR. Il corollario strutturante: **il collo di bottiglia non è mai stato la generazione, è la verifica** — "la generazione è una bocca larga, la verifica un collo stretto; accelerare la bocca ispessisce l'accumulo al collo." **La decisione di design più interessante è una scelta di architettura del ciclo**: Review è deliberatamente **al di fuori dei tre gate umani** (Define, Plan, Ship), perché porre il gate su Review equivarrebbe a collocare l'attenzione umana — una risorsa finita — come punto di controllo di una capacità di generazione che, essa stessa, scala: "si sarebbe costruita una pipeline il cui throughput massimo è il numero di diff che un senior riesce a leggere prima della fine della giornata." Da qui la separazione: **Review strumenta, Ship decide** — Review fornisce un *corpo di prove opponibile*, Ship decide sulla base delle prove, non sul diff completo. Una posizione presa contro Monperrus (di cui SFEIR conserva la diagnosi — l'ispezione umana di ogni diff non regge alla velocità agentica — ma di cui respinge la conclusione: l'accettazione non può essere delegata). La trappola nominata è la **validazione circolare** (l'agente che scrive il codice scrive i test che lo validano: "si è costruito uno specchio, non un anello"), con cinque contromisure prese in prestito da Anthropic (gate indipendenti in finestre di contesto separate, deterministico + agentico che non si sostituiscono mai l'un l'altro, shadow mode, tiering basato sul rischio, logging verso il SIEM) e l'avvertimento di Compare the Market (**grafo AST ~70% contro RAG vettoriale ~58%**, con il RAG che si comporta peggio dell'assenza totale di contesto). L'estensione propria dell'azienda è **il ratchet**: "ogni fuga diventa un vincolo" — un difetto che ha attraversato l'anello viene richiuso *all'interno dell'anello* (test, regola di lint, rubrica, guardrail dell'harness) al Compound-1, "l'unico asset della catena che si apprezza mentre i modelli si deprezzano" (una misura interna, non verificabile: **− 30% di iterazioni di correzione in meno dopo dieci cicli**). Si chiude riformulando la domanda: "questo codice è buono?" è diventata una domanda senza risposta; ciò che resta è **"cosa rifiuta di lasciar passare il mio sistema?"**
#anello di vincoli#vincoli attorno agli agenti#fase Review
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
Analisi del gabinetto di ingegneria SFEIR ("una lettura da ingegnere") sul lancio, il **16 luglio 2026**, di **Kimi K3** da parte del laboratorio cinese **Moonshot AI**: un modello **open-weights, di livello frontier**, il cui fornitore dichiara **circa 2.800 miliardi di parametri**, un **contesto da un milione di token** e il **rilascio dei pesi prima del 27 luglio 2026** (probabilmente con licenza Modified MIT, come per la linea K2). Tesi: una capacità un tempo ritenuta riservata ai giganti proprietari (Anthropic, OpenAI, Google) diventa disponibile **in open weights, a prezzo scontato, da un laboratorio cinese**. SFEIR — pur essendo **partner di Anthropic e Google Cloud**, e quindi "senza alcun interesse a sopravvalutare un modello cinese" — adotta una **riserva metodologica** cardinale: il giorno del lancio **non esiste alcuna tabella di benchmark ufficiale e completa**; le specifiche (2,8T, Kimi Delta Attention, +25% di efficienza di addestramento) e i punteggi sono **dichiarati dal fornitore** o tratti da **arene comunitarie**, "da trattare come affermazioni, non come fatti misurati." La nuova architettura (**Kimi Delta Attention**, attenzione lineare ibrida; decodifica dichiarata fino a **6,3 volte più veloce** a 1M di token) rompe con la cadenza K2 (K2 lug. 2025 → K2.7 Code giu. 2026, un modello di punta ogni due mesi); due varianti accompagnano il lancio (**K3 Max**, **K3 Swarm Max**), con dismissione forzata della serie kimi-k2.5/moonshot-v1 il **31 agosto 2026**. **La vera arma è il prezzo** (~3$/M in ingresso, 0,30$ in cache, 15$ in uscita secondo fonti secondarie): un modello open-weights di livello frontier a questo livello **trascina verso il basso l'intera curva prezzo-prestazioni** — la commodizzazione del livello modello, accelerata dall'open source. Ma la singolarità decisiva non è un punteggio: è la **reversibilità**. Un modello open-weights di livello frontier trasforma un'API consumata (dipendenza dal fornitore) in un'**opzione** (self-hosting, portabilità, uscita dal lock-in), al prezzo di un'infrastruttura pesante per ospitare 2,8T di parametri. Il punto di vista di SFEIR: **l'open-weights cambia la domanda, non solo la risposta** — non più "quale modello è il migliore/il più economico?" ma "quanta parte del mio sistema sono disposto a rendere dipendente da un fornitore che non controllo?". La postura corretta resta un **portafoglio instradato** (un modello per compito, un modello per vincolo), con Kimi K3 che aggiunge una **colonna "reversibilità"** alla griglia decisionale. La convinzione "AI Only" resta invariata: il modello è una commodity, il vantaggio duraturo risiede nell'ingegneria che lo circonda (Context Engineering, harness, governance dei costi, capacità di cambiare idea). Le cifre restano da validare "in autonomia" — sui propri repository, sui propri dati.
Editoriale di **Olivier Rafal** (Direttore Consulenza Strategia, **WeNvision** — gruppo **SFEIR**; ex caporedattore di *Le Monde Informatique*) pubblicato il **1° giugno 2026** su **CIO-Online**, strutturato attorno a un **paradosso**: nell'era dell'IA, l'ingegneria del software **cambia tutto… e nulla cambia**. **Ciò che cambia = il modello operativo.** I ruoli vengono ridefiniti: il **Product Owner** passa dalla scomposizione del backlog alla **generazione di contesto utilizzabile dall'IA**; lo **sviluppatore** passa dalla scrittura di codice a **inquadrare, dirigere e revisionare** l'esecuzione degli agenti; il **QA** acquisisce la capacità di definire a monte la **prova attesa**. La struttura dei team evolve dai *"double pizza teams"* (catene di passaggio di consegne di ~8 persone) alle ***"sandwich teams"***: un **abbinamento stretto tra un esperto di business e un tech lead, entrambi potenziati dall'IA**, con altre competenze a supporto. Dato interno **Sfeir**: *"questo abbinamento oggi guida circa l'80% della catena di produzione"*, con il restante ~20% (architettura, governance dei dati, sicurezza) centralizzato. Citazione chiave: ***"Il problema non è un problema di strumenti, ma un problema di modello operativo."*** **Ciò che non cambia = la disciplina del ciclo.** Le fasi dell'**SDLC** (definire → costruire → verificare → distribuire → mantenere) restano identiche e non negoziabili; l'IA non ne elimina nessuna, le **intensifica**: ***"tutto il margine che il lavoro a ritmo umano assorbiva, in un modo o nell'altro, diventa, alla velocità dell'IA, difetti di livello industriale"*** (metafora dello sport amatoriale vs professionistico). Da qui **tre *gate* inviolabili** (controllo umano): **specifica, pianificazione, revisione della consegna**; validazione **tramite prova** (non tramite le affermazioni dell'IA stessa); **capitalizzazione sistematica** (ogni ciclo arricchisce il successivo) → risultato misurato: **−30% di iterazioni di correzione dopo circa 10 cicli**. Principio: ***"più veloce è l'esecuzione, più rigoroso deve essere il quadro di riferimento."*** Concetti richiamati: **harness** (regole agentiche adattate al contesto), **vibe-coding** ritenuto insostenibile in azienda. **Terzo pilastro = governance, FinOps e pilotaggio orientato al valore**: costi IA **variabili e ricorrenti** (~**10 €/ora** per postazione potenziata), passaggio da un licensing forfettario a una fatturazione basata sull'uso (un parallelo con il cloud degli anni 2010); il **FinOps** non mira a tagliare i costi ma a *"ottimizzare l'efficienza degli strumenti"* (costo ponderato rispetto al valore); allineamento a monte delle **metriche di business** (time-to-market, funzionalità, performance, eco-design). **Conclusione**: l'accelerazione rende i fondamentali **non negoziabili**; la sfida è **organizzativa e culturale**, non tecnologica — senza consolidare la relazione con il business e la disciplina collettiva, un SDLC potenziato dall'IA si limita ad **amplificare i problemi** (sbattere contro il muro più in fretta). Estende la dottrina WeNvision di [[rafal-wenvision-ia-generative-produit-techno-pas-projet-2024-02-23]] e [[rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04]]; converge con i *systems around the model* [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], l'*harness engineering* [[osmani-agent-harness-engineering-2026-04-19]], Salesforce agentico e il dibattito sull'*agent manager* (BFM/Girard, SFEIR).
#ingegneria del software#IA#tutto cambia niente cambia
**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**.