Post di **Ethan Mollick** pubblicato il **31 agosto 2026** su *One Useful Thing* (~2.200 parole). Parte da un incidente di sicurezza per sollevare una questione organizzativa: quando dovrebbe un'IA chiedere aiuto a un essere umano?
#agency#agency#agenti autonomi
Ethan Mollick — professeur à la Wharton School (University of Pennsylvania) · auteur du blog *One Useful Thing* sur Substack.
Saggio di **Bill Staples**, CEO di **GitLab**, pubblicato il **24 agosto 2026** sul blog about.gitlab.com: una lettura annunciata di **31 minuti**, circa **39.000 caratteri**, presentato come il seguito di un memo scritto al consiglio di amministrazione nel gennaio 2026 e in parte pubblicato a maggio con il titolo *GitLab Act 2*. Il testo si presenta come una risposta all'AI-native SDLC playbook di **Anthropic**, pubblicato tre giorni prima, da cui riprende la frase d'apertura — "Code is no longer the bottleneck" — per porre la domanda che lo guida: cosa diventa scarso quando il codice diventa abbondante. (A) La diagnosi economica: l'unità utile non è il costo per riga ma il **costo per modifica accettata**, che aggrega generazione, ambiente, contesto, verifica, revisione, correzione e governance; l'IA fa crollare solo il termine di generazione, il che rende gli altri proporzionalmente più pesanti — un'organizzazione dieci volte più veloce nel generare "si limiterà a spostare la coda". (B) La risposta architetturale: quattro capacità — piattaforma agentica, esecuzione su scala macchina, contesto durevole, governance — che formano un livello enterprise che sopravvive al modello, "The model should be replaceable. The agent should belong to the customer." (1) Tre modalità coesistono in modo duraturo, dal legacy guidato dall'uomo allo sviluppo autonomo, contro l'idea di un'unica curva di maturità. (2) La pipeline CI/CD diventa il luogo in cui gira l'inner loop, invece di essere un gate di fine catena. Le cifre citate sono quelle di Stripe, Spotify e Amplitude; GitLab ne produce una sola, relativa al proprio contrôle de source nouvelle génération. Il corpus contiene già [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], la fonte a cui questo testo risponde, e [[sfeir-sdlc-pdlc-articulation-2026-07-22]] sull'articolazione SDLC/PDLC che Staples fa propria.
#abbondanza di codice#costo per modifica accettata#teoria dei vincoli
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Guida di ampio respiro di **Anthropic** a cura di **Louis Claxton** (team Applied AI), pubblicata il **21 agosto 2026** sul blog claude.com: una lettura dichiarata di **40 minuti**, circa **64.000 caratteri**, presentata come una raccolta di *plays* tratti dal lavoro del team con i propri clienti. (A) La diagnosi: con il codice non più il collo di bottiglia, lo spostamento avviene verso le fasi a monte e a valle della scrittura (piano, revisione/test, deploy), i controlli riga per riga smettono di reggere quando è l'agente a scrivere la maggior parte del diff, e il costo della governance aumenta perché le eccezioni continuano a passare per comitati periodici. (B) La risposta: sei fasi (Plan, Design, Build, Test, Deploy, Maintain) organizzate come un **loop** piuttosto che una catena, ciascuna conclusa da un **artefatto committato** che la fase successiva legge — `intent.md`, `spec.md`, `plan.md`, il diff e i suoi test, la PR e i suoi findings, il record dell'incidente. (1) La conoscenza istituzionale diventa file versionati: `CLAUDE.md`, skill, `REVIEW.md`, `bands.yaml`. (2) La governance si divide in due livelli, con la skill posizionata come controllo consultivo e l'hook come livello deterministico dietro di essa. La separazione dei compiti è posta come invariante — l'agente che scrive il codice non può approvarlo — e il pezzo si chiude con *"The loop keeps running. Human judgement stays above it."* Il corpus contiene già [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] sul versante sicurezza dello stesso ciclo, e [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] sulla stessa scomposizione in sei fasi vista da un concorrente.
#AI-native SDLC#software development lifecycle#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Guida firmata da **Michael Segner**, pubblicata il **20 agosto 2026** sul blog claude.com nella categoria *Claude Code*: una lettura di **5 minuti** annunciata per circa **31.500 caratteri** di testo, offerta anche in PDF. Materiale dichiarato: interviste a **più di una dozzina** di startup, quindici delle quali nominate — **Artemis Security**, **Cainex**, **Clay**, **ClickHouse**, **Cognition**, **Commure**, **Crosby**, **Emergent**, **Harvey**, **Heidi**, **Higgsfield**, **Omni**, **Parahelp**, **Translucent**, **Zingage**. (A) Cinque regole operative: *everyone ships*, *automate the tedium*, *trust, but verify*, *build for rebuilding*, *prototype, dogfood, productionize*, ciascuna chiusa da suggerimenti sui prodotti e riunite in una checklist finale. (B) Un corpo composto da citazioni attribuite, ogni regola illustrata da dirigenti nominati piuttosto che da una metrica aggregata. Le quattro cifre in evidenza sono quelle delle aziende intervistate: **+30%** di funzionalità rilasciate in più (ClickHouse), **da 2 a 3×** produttività ingegneristica (Omni), **100%** del bug triage automatizzato (Clay), **più di 6.000 PR a settimana** (Artemis Security). Due passaggi si discostano dal registro testimoniale: il ciclo di autocorrezione di **Cainex** sulla codifica medica, descritto passo per passo, e l'uso interno di **Claude Tag** in **Anthropic** come primo responsabile per la reperibilità CI/CD. La domanda posta in apertura — *"what would it look like if an organization built their product development lifecycle with Claude Code from the ground up?"* — si collega a [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], pubblicato il giorno successivo dallo stesso editore, e prolunga [[cherny-wu-reflecting-year-claude-code-2026-07-17]].
#Claude Code#startup#everyone ships
Michael Segner · auteur du guide sur le blog claude.com (fonction non affichée par la page) ; entretiens avec les dirigeants de quinze entreprises nommées.
Post X di **Andrew Ng** del **14 agosto 2026** (16:29 UTC), ripreso dalla lettera "Dear friends" di ***The Batch* #366** (DeepLearning.AI, stessa data), ~900 parole. Ng presenta **The AI Engineering Skills Map** e pubblica **quattro competenze** ritenute le più importanti. **(1) Costruire e distribuire applicazioni IA** — la specificità viene nominata: *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, da cui l'enfasi su *evals* e cicli di error-analysis. **(2) Fondamenti di ingegneria del software**, perché *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — lo sviluppatore inesperto fallisce *« because they don't know what context to give their coding agent »*, da cui l'obiettivo di *« steering coding agents using the precise language of software engineering »*. **(3) Uso di agenti di coding**, in una formulazione operativa: *« help the agent autonomously close loops by providing verifiers or evals »*, e *« knowing how much to intervene and how much to leave them alone »*. **(4) *Shaping the build***: *« 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 »*, accostato a *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* Una **nota terminologica** porta la maggior parte dell'inquadramento: Ng parla di **competenze** nell'ingegneria IA e **non del ruolo** "AI Engineer", con un'analogia esplicita — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* Il tutto è sostenuto da *« an analysis of more than 10,000 job postings, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data »*, di cui **non viene pubblicato alcun risultato numerico**: Ng descrive il proprio processo come *« informally… akin to running clustering »* e annuncia una mappa dettagliata in post futuri. Egli enuncia l'interesse nella penultima frase: *« 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).
Articolo di attualità analizzato, pubblicato su **VentureBeat** l'**11 agosto 2026** da **Michael Nuñez**, basato su un'**intervista esclusiva con Timothée Lacroix**, co-fondatore e CTO di **Mistral AI**, realizzata prima dell'annuncio, ~2.000 parole. Mistral amplia la propria offerta infrastrutturale in tre parti: i **Mistral Regional Endpoints** in disponibilità generale (che ancorano l'inferenza e il trattamento associato all'Europa o agli Stati Uniti), un **Priority Tier** in anteprima pubblica (livelli di servizio garantiti, quote personalizzate, SLA di disponibilità) e una **coalizione di imprese europee** i cui impegni pluriennali sono destinati a finanziare **200 MW entro fine 2027** e **1 GW entro fine 2030**. Il veicolo si chiama **European Compute Unit (ECU)**: un diritto su una capacità costruita da Mistral, fungibile tra inferenza, addestramento, adattamento di modelli o Kubernetes gestito, su un orizzonte target di cinque anni. Lacroix descrive il meccanismo senza mezzi termini — *"The whole point of compute units is to have commitment"* — e, sull'uscita anticipata: *"There is no getting out."* L'articolo mette in scala l'ambizione: Mistral dichiara di operare *"less than 200 MW"* e dettaglia tre siti per un totale di **77 MW** (44 MW vicino a Parigi, 23 MW in Svezia con EcoDataCenter, 10 MW a Les Ulis); **Epoch AI** stima il capex iniziale per un data center IA da un gigawatt a **~38 miliardi di dollari**, e **Goldman Sachs Research** stima le strutture di nuova generazione a **15-20 milioni di dollari/MW esclusi i chip**, a fronte dei **~4 miliardi di dollari** raccolti in totale da Mistral (PitchBook). A questo si aggiunge una decisione che *"is likely to raise a few eyebrows among sovereignty purists"*: Mistral inizia a **ospitare modelli aperti di terze parti**, a partire da **GLM-5.2** di **Z.ai**, un laboratorio cinese — *"It's a great model. Everyone loves it. It's open-weight, so there was no good reason for us not to do it."* L'articolo entra nel dettaglio della documentazione di Mistral, che menziona *"limited, controlled transfers"* verso subappaltatori al di fuori della regione; interpellato sui dettagli, Lacroix rimanda alle **chiamate a strumenti** (tool calls), in particolare la ricerca web, e afferma che la **restrizione selettiva è la funzionalità, non il difetto**. L'inquadratura dell'autore: *"full regional control is available, but the moment an AI agent reaches out to the open web, sovereignty becomes a configuration decision, not a default."* Restano due dipendenze: le **GPU** provengono da Nvidia, e **Microsoft** — cliente-ancora dei data center europei di Mistral da luglio — viene presentato come ciò che riduce il rischio della costruzione.
#Mistral AI#sovranità digitale#sovranità IA
**Michael Nuñez** — journaliste **VentureBeat** · couvre l'IA et l'infrastructure ; déjà présent au corpus. L'article est bâti sur un **entretien exclusif avec Timothée Lacroix** · cofondateur et CTO de Mistral AI · conduit **avant l'annonce** · et fait suite à un entretien de juin avec le même interlocuteur. Publié le **11 août 2026**.
Lungo articolo pubblicato su **X** il **11 agosto 2026** da **Jesse Zhang**, CEO di **Decagon** (agenti IA per il servizio clienti), sotto un titolo a forma di dilemma — *« To FDE, or not to FDE? »* — dedicato al **Forward Deployed Engineer**, diventato *« la risposta a quasi ogni domanda difficile nel go-to-market dell'IA »*. Osservazione di partenza: Anthropic e OpenAI hanno costruito bracci di deployment enterprise esplicitamente modellati su Palantir, *« ogni azienda a stadio seed »* pubblicizza un'offerta FDE, e le offerte di lavoro per questo titolo sarebbero aumentate di diverse centinaia di punti percentuali in un anno. **(A) La genealogia Palantir** fornisce il quadro di riferimento: la formula di **Shyam Sankar** (CTO), *« FDEs eat pain and excrete product »*, e il richiamo di **Joe Lonsdale** secondo cui Palantir ha trascorso quasi vent'anni a essere definita una *« glorified consultancy »* sulla base di un'osservazione accurata. Le implementazioni su misura di **Gotham** (CIA, NSA, intelligence militare) sono state codificate in primitive di piattaforma — ontologia, modelli di oggetti, permessi, motori di workflow, tracciamento della provenienza — che sono diventate **Foundry**, poi Apollo e AIP; la standardizzazione ha portato il margine lordo intorno all'80% e Palantir è passata da un modello basato su FDE a una vendita account-based, con molti FDE migrati verso l'ingegneria core. *« The pain was the input to the product, not a cost of sale. »* **(B) Il criterio proposto** non è rinunciare agli FDE ma sapere quando fermarsi: partire presto, poi chiedersi se si sta ancora **scoprendo** — *« The trap is not starting. It's not stopping. »* **(C) Una distinzione che pochi fanno: FDE ≠ implementazione.** *« Building that integration into their ticketing system »* è lavoro reale, ma è esecuzione contro una specifica nota, non scoperta di una specifica ignota; confondere le due cose *« is how a company convinces itself that a growing services org is a product investment »*. Frase di chiusura: *« If your FDEs are eating pain and excreting more pain, you don't have an FDE team. You have a services business. »* Vengono avanzate due cifre riguardo a Decagon — *« two-thirds of deployment work is now done autonomously via Duet »* e *« a few days on average to launch the first AOP, even for large banks, airlines, telcos »* — senza che venga definito il denominatore del "deployment work" né sciolto l'acronimo AOP.
#Forward Deployed Engineer#FDE#ingegnere integrato presso il cliente
**Jesse Zhang** — cofondateur et **CEO de Decagon** (agents IA de service client, San Francisco) · 85 000 abonnés sur X · site personnel `jessezhang.org`. Il cite son cofondateur **Ashwin Sreenivas** · **ex-Palantir** · d'où la profondeur du récit Palantir. Publié le **11 août 2026**.
Manifesto dottrinale pubblicato su **meta.com** il **10 agosto 2026**, firmato con il solo nome di battesimo (*"– Mark"*) da **Mark Zuckerberg**, con il titolo *"The Future is for Everyone: The Path to a Positive AI Future"*, ~6.500 parole. Fin dall'inizio vengono annunciati tre principi: l'empowerment individuale come fonte di prosperità, l'invenzione come scopo primario della superintelligenza, l'equilibrio di potere come fondamento della sicurezza. **(A) L'argomento centrale è un argomento politico**, formulato come una breve catena: *"Humanity is not a monoculture"* — i valori delle persone codificano trade-off contrapposti, nessuna soluzione tecnica può allinearsi simultaneamente a interessi in conflitto, quindi qualsiasi superintelligenza singolare dovrebbe dare priorità ad alcuni valori rispetto ad altri e sarebbe perciò incapace di essere benevola verso tutti. Da qui la formula: *"There is no such thing as a singular benevolent superintelligence."* La sicurezza viene riformulata come un problema di distribuzione del potere, illustrato da un esperimento mentale ripetuto tre volte (un unico avvocato superintelligente contro tutti che ne hanno uno; lo stesso per la cybersicurezza, poi per il business). **(B) Una ridefinizione dell'allineamento**: *"Solving alignment is necessary for billions of people to adopt personal superintelligence agents. But it also implies that if we reach a state where billions of people are using and scrutinizing personal superintelligence agents, then we will have solved alignment with their interests."* Il corollario prende di mira il resto del settore senza nominarlo: *"the most dangerous scenario would be leading labs training powerful models and keeping them for themselves."* **(C) Impegni databili**: una modalità **totalmente privata** in cui *"even Meta"* non può vedere né concedere l'accesso (un'analogia con WhatsApp); versioni **gratuite** per miliardi di persone abbinate a un **meccanismo di offerta dinamica** per il calcolo a pagamento; l'annunciata **ripresa** delle pubblicazioni open source — *"we will soon resume releasing some open source models"*; e una struttura che conferisce al **consiglio indipendente** il potere di approvare i criteri di sicurezza per il rilascio e verificare la conformità di ciascuna pubblicazione, con l'autore che riconosce che Meta è un'azienda controllata dal suo fondatore. **(D) Due proposte di politica pubblica**, ripetute tre volte: che i laboratori condividano con il governo i **checkpoint intermedi di addestramento** e degli ingegneri, anziché una revisione a fine ciclo, e che la **produzione fisica** di materiali pericolosi sia regolamentata piuttosto che la diffusione della conoscenza. Il testo presenta un apparato di fonti pressoché inesistente.
#Mark Zuckerberg#Meta#Meta Superintelligence Labs
**Mark Zuckerberg** — fondateur et PDG de **Meta**. Texte signé du seul prénom (*« – Mark »*) · publié le **10 août 2026** sur un domaine dédié de meta.com. La signature n'est pas « Meta » · et l'alternance des pronoms est régulière : **« we » pour les engagements de l'entreprise** (*« we will offer free versions »*, *« Meta is implementing a governance structure »*) · **« I » pour les affirmations normatives ou contestables** (*« I think this view of alignment is fundamentally flawed »*, *« I propose that companies developing frontier AI should… »*, *« My honest guess, and it is a guess »*). Les engagements produits et de gouvernance sont au « nous » · les propositions de politique publique au « je ».
Editoriale approfondito pubblicato su **sfeir.com** il 1° agosto 2026, a firma di **SFEIR** (la voce editoriale dell'azienda). Riunisce **due pubblicazioni del luglio 2026** dalle metodologie opposte — l'esperimento sul campo preregistrato **"The Cybernetic Teammate"** presso **Procter & Gamble** (Dell'Acqua, Ayoubi, Lifshitz, Sadun, **Ethan Mollick** et al., *Organization Science* 37(4), 2026) e il primo report della serie **"Work at the Frontier"** di **OpenAI Economic Research** (27 lug. 2026, oltre 800.000 messaggi di utenti ChatGPT statunitensi) — in un'unica tesi: *"l'IA generativa non si limita ad accelerare il lavoro esistente, ridistribuisce chi fa cosa."* L'architettura si sviluppa in quattro tappe: **il meccanismo** (P&G: l'IA agisce come dispositivo di *boundary-spanning*, cancellando i silos funzionali — un individuo + IA raggiunge il livello di una coppia senza IA, **+0,37 σ**), **la scala** (OpenAI: il **43,5%** dei messaggi specifici a una professione esce dalla professione dell'utente stesso), **l'agenda** (Mollick: le barriere si stanno assottigliando, la divisione del lavoro va ripensata, e una ricomposizione ben orchestrata "ripaga ampiamente"), poi **la risposta dell'azienda** — la **Skill Based Organisation (SBO)**, adottata in SFEIR su impulso di **Rosalie Zandona** (VP People & Culture): la **competenza effettivamente operativa** sostituisce la job description come unità di organizzazione (**fino a 13 competenze individuate per ruolo**), passando da un'**identità basata sullo status** ("sono un manager") a un'**identità operativa** ("so progettare architetture complesse"). La mossa retorica è la prova per esempio interno: *"abbiamo fatto il passaggio internamente prima di raccomandarlo."* **Vengono segnalate tre riserve**: il passaggio alla SBO risale a **febbraio 2026**, quindi *precede* la diagnosi che dovrebbe risolvere (l'ordine argomentativo inverte l'ordine cronologico); **nulla nei dati dimostra** che un'organizzazione basata sulle competenze assorba il crossover meglio di una basata sui ruoli (un'ipotesi di design non testata); il risultato P&G circola **dal marzo 2025** (NBER w33641) — il "qualche settimana prima" si applica alla pubblicazione sottoposta a peer review, non al risultato in sé.
#Skill Based Organisation#SBO#organizzazione basata sulle competenze
**SFEIR** — ESN française « AI Only » (~850 ingénieurs, 8 agences France & Benelux). Voix éditoriale du cabinet (byline « SFEIR »).
Episodio "Fase 5 · Review" della serie SFEIR sul 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 viene concessa solo l'autonomia che può essere verificata in modo economico e affidabile, non un millimetro di più") viene ridisegnato, tradotto e ancorato 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 riguarda l'architettura del ciclo**: la Review è deliberatamente **fuori dai tre gate umani** (Define, Plan, Ship), perché fare della Review il gate metterebbe l'attenzione umana — una risorsa finita — come punto di controllo di una capacità di generazione che a sua volta scala: "si sarebbe costruita una pipeline il cui throughput massimo è il numero di diff che un senior può leggere prima della fine della giornata." Da qui la separazione: **la Review istruisce, lo Ship decide** — la Review fornisce un *corpo di prove opponibile*, lo Ship decide sulla base delle prove, non sull'intero diff. Una posizione presa contro Monperrus (di cui SFEIR conserva la diagnosi — l'ispezione umana di ogni diff non può reggere alla velocità agentica — ma respinge la conclusione: l'accettazione non può essere delegata). La trappola citata è 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 tratte da Anthropic (gate indipendenti in finestre di contesto separate, deterministico e agentico che non si sostituiscono mai a vicenda, 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 di nessun contesto*). L'estensione propria dell'azienda è **il cricchetto**: "ogni fuga diventa un vincolo" — un difetto che ha attraversato l'anello viene chiuso *all'interno dell'anello* (test, regola di lint, rubrica di review, guardrail dell'harness) a Compound-1, "l'unico asset della catena che si apprezza mentre i modelli si deprezzano" (una misura interna non verificata: **−30% di iterazioni di fix dopo dieci cicli**). Si chiude riformulando la domanda: "questo codice è buono?" è diventata una domanda senza risposta; ciò che resta è **"che cosa il mio sistema si rifiuta di lasciar passare?"**
#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
Decodifica di SFEIR (voce aziendale) del resoconto di Jason Clinton (Deputy CISO, Anthropic) pubblicato cinque giorni prima — già documentato in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **Il valore aggiunto non risiede nei fatti ma nella tesi che li rilegge**: se i controlli di Anthropic reggono, è perché **esiste un ciclo con fasi nominate a cui agganciarli** — "lo SDLC è il fondamento, non una formalità." La dimostrazione procede rileggendo la mappatura (**PSR in fase Plan, CLAUDE.md + egress allowlist in fase Code, agenti di revisione in fase Test, DAST continuo in fase Deploy, triage + instradamento SIEM in fase Monitor**), poi attraverso un'**anafora in quattro parti**: (1) *senza uno SDLC, i guadagni di produttività non si materializzano* — Clinton cita la **legge di Amdahl**: moltiplicare per 8 il volume di codice non moltiplica nulla se la revisione resta sequenziale e umana, e Anthropic ha guadagnato non distribuendo agenti ma **individuando la fase di blocco (Test) e ricostruendola** — "non si ottimizza un collo di bottiglia che non si è mappato" (in eco all'**effetto specchio** del DORA 2025); (2) *senza uno SDLC, la sicurezza non ha un punto di ancoraggio* — un **gate è per definizione un controllo posto tra due fasi**, e le tre minacce di Clinton vengono affrontate in momenti distinti; (3) *senza uno SDLC, nessuna politica di **FinOps dei token** può essere formulata* — la scansione agentica viene fatturata a consumo e cresce con il throughput di codice, quindi **il tiering basato sul rischio È la politica di FinOps** (decide dove pagare tre passaggi agentici e dove basta un SAST), altrimenti "la spesa in token non viene pilotata, viene scoperta a fine mese"; (4) *senza uno SDLC, non c'è nulla da misurare* — gli indicatori (16% → 54% delle PR commentate, un terzo degli incidenti passati intercettati) esistono solo perché ci sono fasi in cui si può collocare un contatore; in loro assenza, si producono solo **cifre di utilizzo** (licenze, token) che non dicono nulla sulla qualità o sul rischio. Due punti di forza oltre la tesi: la lettura dell'**incident agent-à-agent** ("un perimetro di sicurezza che si fonda su un'istruzione in un prompt non è un perimetro"; **l'accesso di un agente ad altri agenti fa parte della sua superficie di attacco**) e un **avvertimento metodologico esplicito** — le cifre di Anthropic su Anthropic, non verificate, pubblicate dal fornitore del modello descritto, nel contesto di una codebase giovane senza mainframe: **ciò che si traspone è il metodo, non le cifre**.
#SDLC#SDLC nativo per l'IA#ciclo di sviluppo
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
**Rapporto di Ricerca Interno SFEIR** (documento di preparazione editoriale, basato su deep research — ~70 riferimenti) sull'**AI Kill Switch Act** americano, inquadrato attorno alla **sovranità europea** e al **"so what" per le imprese**. È la **base fattuale** per un futuro articolo di blog — espone dove la tesi della "soglia molto bassa" **regge** e dove necessita di **sfumature**. **Contributo chiave rispetto alla copertura stampa** (incluso [[arstechnica-ai-kill-switch-act-2026-07-23]]): (1) una lettura **del testo stesso della legge** (nuova **sezione 2220F**, "Shutdown-Capability Standard and Graduated Deployment-Corrections Framework", presentata il 23 luglio 2026, 119° Congresso) — autorità conferita al **Segretario del DHS tramite CISA** (il "Direttore"), in consultazione con Commerce + DNI; (2) **due soglie CUMULATIVE** — ≥ **500 milioni di $** di ricavi AI (affiliate incluse) **E** compute di addestramento > **100 milioni di $** — il che significa che **oggi poche aziende sono coperte**, il che **contraddice nettamente** la tesi della "soglia bassa"; (3) ma una **portata reale molto ampia** attraverso il **meccanismo di espansione** (aggiornamenti annuali delle soglie da parte del DHS, clausola "affiliate", compute indicizzato al prezzo del cloud, crescita dei ricavi) e soprattutto attraverso l'**effetto domino** sui clienti; (4) **sanzioni graduate**: fino a **2 milioni di $/giorno** (violazione generale), **20 milioni di $/giorno** (violazione dell'autorità di emergenza); (5) **sfumatura critica**: poiché l'incidente **OpenAI/Hugging Face** si è verificato durante il **red-teaming/valutazione interna**, esso **NON attiverebbe** l'autorità di emergenza così come scritta (il testo esclude il red-teaming). L'angolo di **sovranità** si basa sul **precedente Anthropic** (Fable 5 / Mythos 5 disattivati per **19 giorni** nel giugno 2026) come **prova operativa** di un "kill switch de facto", e conduce a **raccomandazioni per i CTO** (architettura multi-modello testata, clausole di continuità, mappatura dell'esposizione, opzioni sovrane).
#AI Kill Switch Act#section 2220F#Shutdown-Capability Standard
**SFEIR** (recherche interne / deep research). Document non signé nominativement — préparation éditoriale pour le blog SFEIR · dans la ligne souveraineté/adoption du cabinet (cf. [[sfeir-mistral-microsoft-souverainete-strategie-industrielle-2026-07-22]]). Base factuelle équilibrée (arguments **et** contre-arguments) · références numérotées.
Analisi SFEIR (voce dell'azienda, "una lettura da ingegneri") dell'accordo annunciato il **21 luglio 2026** tra **Mistral** e **Microsoft**: una **partnership industriale del valore di diversi miliardi di dollari**, strutturata in tre parti — (1) **compute in Europa** (capacità Azure riservata sul continente, datacenter in Francia, sistemi **NVIDIA Vera Rubin** di ultima generazione, per "colmare il deficit europeo di compute"); (2) **i modelli di Mistral negli strumenti di Microsoft** (**Mistral Medium 3.5** e **Mistral OCR 4** in **Microsoft Foundry**, accessibili in **Copilot Studio** per costruire agenti aziendali); (3) soprattutto **Azure Local fino alla modalità disconnessa** (cloud pubblico, cloud connesso supervisionato e **air-gapped** completamente isolato dalla rete esterna — per il segreto della difesa, la sanità, il settore bancario critico). **Fatto notevole, confermato da Brad Smith: nessuna nuova partecipazione azionaria** di Microsoft nel capitale di Mistral — una partnership massiccia **senza legame di capitale**. SFEIR — partner di Anthropic e Google Cloud, "senza alcun interesse a sopravvalutare il campione francese" — considera Mistral **"la migliore scommessa europea sul livello modello"** e propone una lettura in tre parti. **Cosa porta l'accordo a un CIO**: un modello europeo all'avanguardia, eseguibile in un ambiente disconnesso e controllato dal cliente (cifratura in memoria, chiavi gestite localmente), spunta caselle che pochissime offerte spuntano. **La tensione**: questa sovranità è dispiegata **sull'infrastruttura di un hyperscaler americano**; occorre distinguere quattro sovranità — **modello, esecuzione, infrastruttura, relazione commerciale** — di cui se ne possono "ottenere tre su quattro, ma occorre comunque sapere quale manca". L'unico elemento che rende la sovranità **realmente portabile** è la **natura open-weights** dei pesi di Mistral (la stessa logica di reversibilità descritta per **Kimi K3**). L'assenza di una partecipazione azionaria non è un dettaglio: preserva la governance di Mistral **e** riduce al minimo il rischio di un esame antitrust (FTC, Commissione Europea) — **arbitraggio regolatorio assunto**, non solo una scelta tecnica. **Il vero punto cieco**: la **leggibilità della strategia industriale di Mistral**, presente simultaneamente su quasi ogni fronte (B2C con Le Chat, B2B tramite la distribuzione Azure, modello open-weights **e** ambizione frontier, infrastruttura ad altissima intensità di capitale — 200 MW garantiti, un tetto di 1 GW entro il 2030 —, partnership con una manciata di grandi account, verticalizzazione Robostral/OCR, servizio a settori regolamentati): full-stack sovrano (lettura ottimistica) oppure la dispersione di un'azienda di tre anni valutata circa 20 miliardi di euro su business con modelli economici divergenti (lettura prudente). Per la leadership tecnica: **separare il modello dal canale**, **progettare per l'uscita** (Design to Exit — l'open-weights rende credibile la porta d'uscita), **instradare piuttosto che scommettere** (architettura multi-LLM sovrana, RAISE). Conclusione: **la sovranità è una proprietà architetturale, non un'etichetta** — va qualificata dipendenza per dipendenza; la leggibilità industriale mancante resta la vera questione aperta, risolta non dai comunicati stampa ma dai "compromessi dei prossimi dodici mesi".
Analisi SFEIR (voce di una società di consulenza, "la lettura di un ingegnere") che articola due framework troppo spesso confusi: lo **SDLC** (Software Development Life Cycle — *costruire il software in modo corretto e affidabile*) e il **PDLC** (Product Development Life Cycle — *costruire il prodotto giusto e avere successo sul mercato*). Tesi centrale: i due cicli non sono concorrenti ma **annidati** — lo SDLC è il sottoinsieme del PDLC **ospitato nella sua fase di sviluppo**; quando un team di prodotto raggiunge la fase di "build", al suo interno gira un ciclo SDLC completo (progettazione → costruzione → test → revisione → deployment). Lo SDLC è standardizzato (**ISO/IEC/IEEE 12207**, edizioni 2017 e 2026), con la sua genealogia di modelli (Waterfall 1970, modello a V, iterativo/spirale, **Agile 2001**, **DevOps/DevSecOps 2009+**) e le sue metriche **DORA** (throughput, stabilità, MTTR, change failure rate). Il PDLC, essendo il ciclo ombrello, si estende dall'**ideazione/discovery** al **ritiro dal mercato** (da non confondere con il **PLC** di marketing di Theodore Levitt, 1965, che descrive una *curva commerciale*, non un *lavoro organizzato*: "il PLC osserva una curva; il PDLC organizza il lavoro"). **Punto di svolta**: lo SDLC affronta nativamente **un solo rischio su quattro** — tramite il framework dei **"Four Big Risks" di Marty Cagan** (Valore → PM, Usabilità → Designer, Fattibilità → Lead Engineer, Sostenibilità economica → PM) — un'organizzazione eccellente sullo SDLC ma cieca sul PDLC produce "software che nessuno vuole" — la **"feature factory"** di John Cutler (successo misurato sull'output, non sull'outcome). **Perché l'IA cambia tutto**: l'IA generativa **comprime lo SDLC** (dati Google/JetBrains, maggio 2026: **~85% degli sviluppatori** usa regolarmente agenti di coding, **~41% del nuovo codice** è generato dall'IA; l'implementazione passa da settimane a ore), quindi il **collo di bottiglia si sposta a monte** — decidere *cosa* costruire (Marty Cagan, aprile 2026: "quando il costo della delivery crolla, il collo di bottiglia si sposta sulla discovery"). Conseguenze: DORA 2025 (~5.000 professionisti, 90% di adozione dell'IA) mostra una **correlazione positiva con il throughput ma negativa con la stabilità** (più funzionalità non validate significa più instabilità e rework); Andrew Ng (AI Startup School, luglio 2025) segnala team che **invertono il rapporto "1 PM per 4 ingegneri" in "2 PM per 1 ingegnere"**; e con lo **spec-driven development**, il confine PDLC/SDLC diventa **poroso** (la specifica di prodotto diventa direttamente eseguibile dagli agenti). **Cosa dovrebbe trarne un CIO**: uno SDLC potenziato diventa uno **standard di mercato, non un elemento di differenziazione** — bisogna strumentare la giunzione con il prodotto, esigere **specifiche eseguibili** come input, incrociare le metriche tecniche con le metriche di outcome, e **rifiutare** il ruolo di "fornitore di feature". Per un CPO: lo spostamento del collo di bottiglia verso la discovery è al tempo stesso una **promozione** (il giudizio di prodotto torna a essere una risorsa scarsa) e un **avviso ad agire** (industrializzare la discovery per raggiungere la parità con lo SDLC). Il framework interno di SFEIR ("Progettare e costruire nell'era agentica" — **ciclo a 11 fasi** + **Software Factory 10x**) si posiziona come la risposta sul lato ingegneristico, con l'**articolazione dei due cicli** come prossima leva. Conclusione: "man mano che il codice diventa una commodity, il margine si sposta verso il giudizio di prodotto e la governance."
Analisi di Janakiram MSV (The New Stack, 20 luglio 2026) sulla **convergenza architetturale** delle piattaforme agent enterprise dei tre hyperscaler: in nove mesi, **Amazon Bedrock AgentCore**, **Microsoft Foundry** e **Gemini Enterprise Agent Platform** sono convergenti sugli **stessi sei primitivi** — runtime, memoria, tool gateway, identità, osservabilità, governance — sotto nomi commerciali diversi. Ciò che 18 mesi fa era una collezione frammentata di librerie sta diventando un **livello di piattaforma** a sé stante. La tesi: questa convergenza ripercorre l'**inflessione PaaS 2011-2016**, in cui **Cloud Foundry** ed **Heroku** hanno unificato VM, load balancer, code e secret store attorno a un **contratto applicativo** portabile — salvo che qui **non esiste ancora un contratto equivalente**, e **nessun progetto open source lo ha rivendicato**. Conseguenza: un'impresa non può **spostare un agente da un cloud all'altro** (stato di sessione, tracce e identità finiscono tutti presso un unico fornitore; migrare significa ricostruire tutto). L'autore propone una **mappatura riga per riga** del contratto Cloud Foundry sugli agenti, definisce tre principi di design (impacchettare l'agente come **una singola unità distribuibile**, **collegare** le capacità invece di incorporare i fornitori, integrare il livello **operativo** nell'astrazione), indica ciò che i protocolli aperti (MCP, A2A, OpenTelemetry) lasciano fuori campo — il **ciclo di vita** — e formula tre domande di due diligence: **governance** (fondazione neutrale vs. fornitore), **packaging** (lo stesso artefatto su due cloud senza riscriverlo), **stato** (memoria esportabile). Verdetto: chi finirà per possedere il **control plane degli agenti** definirà *cos'è un agente*.
**Boris Cherny** (Creator & Head of Claude Code @Anthropic) pubblica su LinkedIn una tabella-framework, **« Steps of AI Adoption »**, che mappa l'adozione dell'IA agentica da parte di un team di ingegneria lungo **5 stadi (0→4)**, ciascuno caratterizzato da un **ordine di grandezza di agenti guidati** e da una **trasformazione del ruolo dell'ingegnere**: **0 Gated** (0 agenti, accesso bloccato), **1 Assisted** (~1 agente — "tu + un agente", pair programming supervisionato), **2 Parallel** (~10 agenti — **orchestrator**), **3 Supervised autonomy** (~100 agenti — **manager of managers**, un albero organizzativo), **4 AI-native** (~1.000+ agenti — **VP steering by intent**). La tabella incrocia cinque colonne: numero di agenti, *a cosa assomiglia*, *il collo di bottiglia*, *i prodotti che aiutano*, *i guardrail*. **Tesi centrale**: consumare più token non fa salire di livello — avanzare allo stadio successivo richiede **identificare e rompere il prossimo collo di bottiglia** E **costruire il prossimo set di guardrail**. Concretamente: dare a Claude un **loop di auto-verifica** affidabile (test + build + lint + e2e su un ambiente reale), attivare **Auto mode** (evitando prompt di permesso bloccanti), rendere **il code review e il security review predefiniti**, adottare interfacce multi-agente (Agent view CLI, Desktop, app iOS/Android, Tag), poi `/loop`, `/batch`, `/goal`, **dynamic workflows** e **worktree isolation** per i subagenti. Sullo steering: l'utilizzo (dashboard) misura **l'attività, non il ritorno**; la domanda giusta è *"avremmo comunque speso sforzo ingegneristico su questo? se sì, quante ore-ingegnere manuali sarebbero costate?"* — questo è il ROI. Il vero guadagno arriva quando **la correzione e la manutenzione avvengono in background** e i team si concentrano sul *costruire*. Anthropic si colloca allo **stadio 3, diretta verso il 4**; Boris Cherny dichiara di aver raggiunto personalmente il **livello 4**.
#Boris Cherny#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)
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.
Digest di tech-watch da fonti primarie sulla posizione di **Gregor Hohpe** (autore di *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; ex Enterprise Strategist per AWS e Google Cloud, ex Chief Architect di Allianz) riguardo al ruolo dell'architetto nell'era dell'IA generativa. Tesi: l'IA **non svaluta** l'architetto, ne **sposta il valore** dal codice a ciò che l'IA non fa — **prendere e assumersi decisioni, arbitrare i trade-off, "vendere opzioni," comunicare con gli esseri umani, produrre astrazioni solide**. Formula chiave (Craft Conference 2026): "*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*". La sua tesi distintiva (l'architetto non dovrebbe essere la persona più intelligente della stanza, dovrebbe **rendere più intelligenti tutti gli altri**) si rafforza man mano che il codice diventa abbondante: il vantaggio deriva dalla **disciplina decisionale** e dal **far emergere trade-off nascosti**, non dal volume. Il digest analizza inoltre le sue posizioni per ruolo (enterprise architect: da **cartografo a esploratore**; software architect: **debug** delle decisioni piuttosto che scrittura di codice; platform architect: **astrazioni, non illusioni**), la sua metafora delle **opzioni reali** (valore crescente con la volatilità tecnologica, analogia con Black-Scholes) e i suoi avvertimenti ("*An AI-driven SDLC punishes bad habits much faster*"; i vincitori dell'IA si distingueranno per la velocità con cui passano dalla sperimentazione alla **produzione governata**). ⚠️ La formula ampiamente diffusa "gli architetti che usano l'IA sostituiranno chi non la usa" **non è di Hohpe**. Dominio: architettura del software, ruolo dell'architetto, processo decisionale, opzioni reali, piattaforme, GenAI nell'SDLC.
Nota di analisi SFEIR che ripercorre il ruolo dell'architetto software nell'era dell'IA generativa attraverso il framework di **Gregor Hohpe** (*The Software Architect Elevator*). Tesi centrale: l'architetto « **Oracolo** » — il supremo custode della conoscenza che emette regole dalla torre d'avorio — è superato, poiché l'IA genera codice e proposte su richiesta; l'architetto moderno diventa un **amplificatore di intelligenza (IQ Amplifier)** che fornisce ai team i modelli mentali, il contesto di business e gli strumenti decisionali per sfruttare l'IA garantendo al contempo la coerenza del sistema. Il documento scompone l'impatto **piano per piano dell'"Architect Elevator"** (Enterprise / Solution / Platform / Software architect) e argomenta a favore del **Domain-Driven Design (DDD)** come salvaguardia indispensabile: il **linguaggio ubiquo** sottende i *system prompt* (un dizionario di dominio iniettato tramite `.clinerules`/template, che riduce le allucinazioni e le interpretazioni errate del business), e i **bounded context** limitano l'ambito affidato all'IA per massimizzare l'affidabilità della generazione. Conclusione: l'IA non è una minaccia ma un catalizzatore che solleva l'architetto dai compiti tecnici di input per mettere in primo piano la sintesi, la visione strategica, la modellazione e il legame umano tra tecnologia e business. Dominio: architettura software, ruolo dell'architetto, DDD, prompting strutturato, governance dell'IA aziendale.
Terzo capitolo della serie di Ashish Singh « New Engineering Disciplines for the AI Era », dedicato al **KDLC — Knowledge Development Life Cycle**: un ciclo di vita in **8 fasi** per trasformare la conoscenza aziendale in un **asset ingegnerizzato**, al pari del codice o dei dati. Tesi: le iniziative di IA falliscono non per la scelta sbagliata dell'LLM o per un sistema RAG mal distribuito, ma perché **non affrontano la struttura sottostante della conoscenza** — « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust ». Il KDLC concatena Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Contrappone il **RAG tradizionale** (documenti isolati, parole chiave) all'**Enterprise Knowledge Fabric** (Knowledge Graph + Semantic Search + Vector DB + Hybrid Search), in cui gli agenti comprendono « relationships, context, and business meaning ». Frase distintiva: « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Tre esempi (finanza/compliance, ingegneria del software, sanità) illustrano l'impatto.
#KDLC#knowledge development life cycle#knowledge life cycle
Saggio lungo di **Shubham Saboo** (X/Twitter) che sostiene una tesi sul ruolo del Product Manager nell'era degli agenti: la prossima competenza chiave **non è il prompt engineering** ma il **Loop Engineering** — progettare un *sistema che migliora a ogni esecuzione* anziché scrivere il prompt perfetto ogni volta. Un **loop** è un ciclo ripetuto: modificare ciò che modella il comportamento dell'agente → eseguirlo → valutare l'output → mantenere la modifica se la qualità aumenta, altrimenti annullarla → **capitalizzare l'apprendimento** in modo che la versione successiva parta avvantaggiata. Per un PM, il punto d'ingresso non è il codice ma gli **artefatti durevoli** che codificano il suo giudizio: skill di PRD-review, *summarizer* di chiamate con i clienti, griglia di valutazione, checklist di lancio, workflow di ricerca, `CLAUDE.md`, template di prompt, framework di prioritizzazione. Poiché vengono riutilizzati, questi artefatti **si accumulano in entrambe le direzioni** — e **degradano** silenziosamente (un CLAUDE.md che continua a crescere, una checklist ignorata…): il modello non è peggiorato, sono gli artefatti a essere degradati senza sorveglianza. Un loop ha **5 componenti**: trigger, azione, **prova**, memoria, **condizione di arresto** (la più critica). Gli **eval** diventano lavoro del PM (testare l'artefatto su esempi noti: 3 PRD buoni / 3 cattivi, 5 chiamate comprese, 2 lanci passati). La **memoria** risiede su **GitHub** (il repository diventa "memoria di prodotto": commit, diff, risultati degli eval, registro delle decisioni, rollback). Primo loop consigliato: un **loop settimanale di segnale di prodotto** (ogni venerdì). Il gusto/istinto resta centrale — ma ora richiede una **prova**. Cita Boris (creatore di Claude Code): "non scrive più prompt, scrive loop".
Rapporto interno di teardown sulla release open-source **`xai-org/x-algorithm`** (15 maggio 2026) — l'algoritmo del **For You feed** di **X (ex Twitter)** nel 2026, con quattro filoni di raccomandazioni di crescita calibrati per pubblico (personale/founder, brand/azienda, framework generalizzato, deliverable per clienti/consulenza). **Tesi centrale**: ***« La celebre tabella dei pesi del 2023 — le risposte contano più dei like con un moltiplicatore elevato — descrive un sistema che non esiste più in questa forma. »*** L'algoritmo 2026 è un **transformer (Phoenix, derivato da Grok-1)** che apprende i pesi dalla cronologia di engagement personale, valutato su una **superficie multi-azione a 19 dimensioni**, filtrato da un servizio offline di comprensione dei contenuti (**Grox**). **La forma dello scoring conta ormai molto più dei numeri — e i numeri stessi non sono presenti nella release pubblica**. **Architettura a 4 componenti**: (1) **Home Mixer** (Rust, orchestratore a tempo di richiesta, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, archivio in memoria alimentato da Kafka dei post recenti, lookup sub-millisecondo per i candidati in-network); (3) **Phoenix** (ML in JAX, transformer a due torri per retrieval + ranking, derivato ~da Grok-1); (4) **Grox** (offline, classificatori spam/safety/PTOS/banger + embedder multimodale v5). **Le 19 azioni predette da Phoenix** (cambiamento chiave rispetto al 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (visualizzazione video di qualità filtrata da una durata minima), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continua). **Punteggio finale** = `Σ (weight × P(action))` modificato da **3 moltiplicatori strutturali**: (a) **OON_WEIGHT_FACTOR < 1** (penalità out-of-network), (b) **decadimento della diversità autore** `(1-floor) × decay_factor^position + floor` (attenuazione esponenziale dei post ripetuti dello stesso autore in un singolo render), (c) **soglia sulla durata video** (vqv contribuisce solo se `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Avvertenza chiave**: **nessun valore numerico di peso** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) è presente nella release — tutto è `crate::params::*`, gestito da un servizio interno di feature-switch di X per l'A/B testing. ***« Chiunque affermi che 'le risposte valgono N,N× più dei like nel 2026' sta inventando un numero che non è derivabile dalla release OSS. »*** **Differenze chiave rispetto al 2023**: (1) eliminazione di ogni feature ingegnerizzata a mano (*« Abbiamo eliminato dal sistema ogni singola feature ingegnerizzata a mano e la maggior parte delle euristiche »*); (2) un unico modello che predice 19 azioni contro modelli singoli per azione; (3) Grox separa la comprensione dei contenuti dal ranking; (4) nuovi segnali di prima classe (dwell continuo, vqv filtrato, follow_author, 3 varianti di share); (5) retrieval OON a due torri (vs. SimClusters+euristiche) con embedding multimodali testo+immagine+video-ASR. **Tre livelli di reach** (framework generalizzato): Eligibility (binaria, Grox+filtri) → Retrieval (probabilistica, ANN a due torri) → Ranking (continua, somma pesata + moltiplicatori). **Due leggi della crescita meccanica**: (1) L'in-network è moltiplicativo, l'OON è additivo; (2) Il compito del modello è predire te, non premiarti. **Confine di onestà deliberato**: il checkpoint Phoenix rilasciato = mini (2 layer, 4 head, 256 dimensioni, corpus di 537K post sportivi), non il modello di produzione; integrazioni Thrift stub (`panic!("Not implemented")` in `candidate_features.rs`); liste di brand-safety, mappature degli ID di topic, penalità linguistiche, regole di ad-blending assenti dalla release pubblica.
#algoritmo X 2026#xai-org/x-algorithm#For You feed
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
Nota d'analista di **Mitch Ashley**, VP e Practice Lead per *CIO & Technology Buyers* e *Software Lifecycle Engineering* presso **The Futurum Group**, pubblicata il **29 aprile 2026** nella sezione *Market Coverage News*: formato breve, circa **9.500 caratteri**, che si apre con cinque punti di sintesi e si chiude con cinque voci da tenere d'occhio. Argomento: l'accordo annunciato il **21 aprile 2026** in base al quale **SpaceX** ottiene il diritto di acquisire **Cursor** per **60 miliardi di dollari** entro l'anno, oppure di pagare **10 miliardi di dollari** per una partnership di calcolo sostenuta dal cluster **Colossus** di **xAI** a Memphis, descritto come equivalente a **1 milione di GPU H100**. (A) La lettura dei due bisogni: Cursor portava sia un tetto di potenza di calcolo sia una compressione dei margini — l'azienda paga a prezzo di mercato i modelli di **Anthropic** e **OpenAI**, che instrada verso i propri clienti pur competendo con loro tramite la propria linea **Composer**; SpaceX cercava ricavi legati all'IA e una narrazione in vista di una IPO prevista per giugno. (B) La lettura della struttura: un pavimento di 10 miliardi di dollari e un'opzione di acquisto da 60 miliardi di dollari esercitabile in azioni quotate dopo la quotazione, che, scrive Ashley, *"alloca il rischio in modo più onesto di un'acquisizione diretta."* (1) Per gli acquirenti, fissa una finestra di **sei mesi** per riverificare le clausole di zero-data-retention e l'identità del fornitore. (2) Per i fornitori, distingue tre esposizioni — **Google** protetta da **Antigravity**, **AWS** dipendente da Anthropic, **IBM** lievemente esposta ma ben posizionata sull'angolo della governance. Il corpus contiene già [[beck-starving-genies-usage-limits-ai-coding-2026-04-03]] sul vincolo di risorse imposto agli strumenti di coding e [[nyt-musk-promises-spacex-ipo-track-record-2026-06-02]] sugli annunci di SpaceX.
#SpaceX#Cursor#Anysphere
Mitch Ashley · VP et responsable des pratiques CIO & Technology Buyers et Software Lifecycle Engineering chez The Futurum Group · ancien CIO et CTO.
Deep Research - Rivoluzione AI4* - 6 pilastri della produzione software - Transizione da Copilot ad Agenti - Paradosso Vibe vs Check - Crisi del FinOps for AI - Governance come percorso critico - GenAI Landing Zone
Framework strategico IA générative - 4 quadranti di implementazione - Paradosso dell'accesso - Dati come fossato competitivo - Differenziazione strategica - Harvard Business Review - Bharat N. Anand - Andy Wu
#strategia dell'IA generativa#vantaggio competitivo#framework a quattro quadranti
Bharat N. Anand (NYU Stern School of Business Dean) · Andy Wu (Harvard Business School)