Video-intervista registrata al **VivaTech** (stand **Scaleway**), diffusa dal media **République**, che riunisce **Damien Lucas** (CEO di Scaleway) e **Franck Le Moal** (Global Technical Officer del gruppo **LVMH**). **Tesi centrale**: l'emergere di una **"geopolitica tech"** costringe le multinazionali ad abbandonare la soluzione globale unica a favore di un **sistema informativo regionalizzato in tre blocchi** (Stati Uniti, Europa, Cina). LVMH (80 miliardi di euro di fatturato, 75 maison, oltre 100 paesi) formalizza una **partnership cloud con Scaleway** per costruire un **blocco europeo autonomo**, accanto a Google Cloud (dati, dal 2021), SAP, Salesforce sul versante occidentale e Alibaba Cloud / Huawei / Tencent sul versante cinese. Il gruppo si definisce **"ibrido"** e **autonomo** piuttosto che **"sovrano"** (termine che rifiuta, giudicato ambiguo). Scaleway si posiziona come **fornitore cloud europeo** immune dalle leggi extraterritoriali e protetto da un **kill switch** ("non è fantascienza", vista l'attualità del fine settimana). L'argomento economico di Damien Lucas: **1 euro speso con Scaleway = 68 centesimi che restano nell'economia europea** (contro meno di 20 centesimi con un hyperscaler americano, anche se ospitato in Francia). Tempistiche: PoC completati, dispiegamento a partire da **Sephora e Louis Vuitton**, presenza significativa prevista entro **12-18 mesi**. Missione dichiarata di Scaleway: concentrarsi su **IaaS/PaaS** (nessuna verticalizzazione come il software di produttività d'ufficio), appoggiandosi a un ecosistema di partner (applicazioni sovrane, chipset e server europei). L'offerta **GPU Nvidia / IA** di Scaleway **non è prevista a breve termine** ma resta aperta (modelli open source per autonomia + performance economica).
**Bertrand** — journaliste / présentateur du média **République** (partenaire de VivaTech) · conduit l'entretien. **Damien Lucas** — CEO de **Scaleway**. **Franck Le Moal** — Global Technical Officer du groupe **LVMH**.
Un paper arXiv (cs.SE) di Martin Monperrus che sostiene una tesi radicale per lo SDLC: gli agenti di codifica hanno superato una soglia di capacità tale per cui **la revisione umana del codice non è più una componente necessaria** di una pipeline di qualità. Due affermazioni: (1) i sistemi autonomi basati su LLM raggiungono tutti gli obiettivi della revisione (individuazione dei difetti, qualità, conformità) a costi inferiori e con un throughput superiore; (2) il modello ibrido "l'agente scrive, l'umano rivede" è insostenibile — non garantisce una qualità reale e non scala con la velocità dell'IA, creando un "falso senso di sicurezza". Monperrus contrappone l'inspection de Fagan (1976) a una **pipeline di verifica avversariale multi-agente** (agente generatore + agenti revisori indipendenti + test/metodi formali + consenso basato su voto). L'essere umano si concentra sulle specifiche, sui compromessi architetturali, sull'approvazione dei domini critici e sui casi limite. Raccomandazioni: fare pilotaggio prima su componenti a basso rischio, misurare agente vs. umano, rendere esplicite le decisioni di rigetto.
#revisione del codice#revisione del codice#inspection de Fagan
Philippe Ensarguet (Orange) sostiene che cinquant'anni di design pattern formano una filiazione continua: in un momento in cui l'IA commoditizza il codice e rompe il modo tradizionale in cui gli architetti vengono formati, la "pattern literacy" (leggere un sistema attraverso le sue forze invarianti) diventa la competenza durevole da insegnare — come una grammatica, non come cataloghi.
#design pattern#filiazione dei pattern#architetto software
Annuncio di prodotto di Stack Overflow (blog ufficiale) che lancia **Stack Overflow for Agents**, una piattaforma di scambio di conoscenza *API-first* pensata per l'era agentica. Tesi fondante: gli agenti di coding lavorano **in isolamento**, senza accesso a una base di conoscenza condivisa e verificata. Da qui il **"Ephemeral Intelligence Gap"** — agenti in tutto il mondo risolvono in modo indipendente gli stessi problemi, sprecando token e calcolo, per poi perdere la soluzione alla fine della sessione; gli stessi pattern architetturali vengono riscoperti in un ciclo continuo. Principio guida: *"generare risposte plausibili è diventato economico, ma verificare quali reggono in produzione no."* Flusso di lavoro in quattro passaggi: **cerca prima** (consuma conoscenza validata) → **contribuisci se esiste una lacuna** (l'agente redige una bozza, l'umano approva prima della pubblicazione) → **verifica** (risultati, modifiche, condizioni di contesto) → **capitalizza i segnali** (voti, risposte, verifiche producono un consenso). Tre formati leggibili dalle macchine: **Questions**, **TIL** (tracce di debug), **Blueprint** (pattern riutilizzabili, standard di qualità più elevato). La fiducia si fonda sulla **moderazione della community** e su **cicli di verifica multi-agente**; gli umani rivendicano la proprietà del proprio agente tramite Stack Overflow SSO (un "ancoraggio comunitario" che lega l'agente a una reputazione umana). Benefici differenziati: sviluppatori (meno cicli di retry), laboratori di IA (dati ad alto segnale per fine-tuning/valutazione), imprese (**Stack Internal**, un livello di conoscenza proprietario senza esfiltrazione di dati).
#Stack Overflow for Agents#coding agents#base di conoscenza
Anthropic lancia Claude Fable 5 (un modello di classe Mythos reso sicuro per l'uso generale) e Claude Mythos 5 (lo stesso modello, con le protezioni rimosse, riservato ai cyberdifensori tramite Project Glasswing): prestazioni allo stato dell'arte in ingegneria del software, visione, memoria a contesto lungo e scienze della vita.
Guida tecnica approfondita (blog dell'agenzia Lushbinary) sul **Loop Engineering**: la progettazione dei sistemi che guidano gli agenti di codifica in un loop, anziché guidarli manualmente tramite prompt. Copre la filiazione prompt → context → loop engineering, la tecnica Ralph (Geoffrey Huntley), i **cinque building block + memoria** di un loop, la loro implementazione in Claude Code e OpenAI Codex, la scrittura di condizioni di arresto verificabili, una scala di maturità dell'adozione e i rischi che peggiorano man mano che i loop diventano più sofisticati. Dominio: ingegneria del software agentica, agenti di codifica, harness/orchestrazione.
#Loop engineering#agenti di codifica#harness engineering
Guida di Augment Code (Paula Hingel) che descrive come gli agenti IA stiano ristrutturando il ciclo di vita dello sviluppo software (SDLC), fase per fase. Tesi: l'IA produce **maggiore throughput in alcune fasi e maggiore rischio di instabilità in altre** — un sintomo di un'adozione disomogenea che non ridisegna i confini della revisione. Si basa su **DORA 2025**: l'adozione dell'IA è correlata positivamente al throughput di delivery e alle prestazioni di prodotto, ma **negativamente alla stabilità**. Sei fasi rilette (Requisiti, Design/Architettura, Implementazione, Testing/QA, Deployment, Manutenzione), tre rischi principali (erosione della pipeline junior, **validazione circolare** dei test generati dall'IA, lacune di governance su larga scala) e tre ruoli emergenti (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Raccomandazioni operative: verificare una fase prima di scalare, sottoporre la governance a stress test, rendere centrale la **specifica**, definire policy di rollback esplicite, ridisegnare il ruolo junior attorno alla revisione.
#SDLC#software development lifecycle#agenti di coding
Post di svago domenicale di **Mark Dembo** (Head of Solutions, Developer Platform & AI presso **Cloudflare**) pubblicato il **7 giugno 2026** sul suo blog personale. **Narrazione**: ispirato da **Steve Ruiz**, l'autore acquista un piccolo dispositivo **M5Stack Stick 3** (~30€) e, approfittando del rilascio di **Opus 4.8**, si costruisce un **agente AI DIY** "per pura curiosità, senza alcun obiettivo". **Iterazione 1 (45 min)**: sottopone la documentazione del dispositivo a **Claude Code**, che genera script Python (~200 righe di codice, *"zero blast radius"*) che mostrano il meteo di Monaco di Baviera, poi di più città; un **backend Cloudflare Workers + Workers AI** aggiunge **sintesi vocale (TTS)**, **push-to-talk** (riconoscimento vocale) e un **piccolo LLM** centrale per rispondere alle domande. **Iterazione 2 (un vero agente)**: passaggio degli endpoint REST al trasporto **WebSocket** tramite il **Cloudflare Agents SDK** + **Dynamic Worker execution** → il pattern ***"Code Mode"*** (l'agente scrive ed esegue codice per portare a termine il suo compito). L'agente risponde quindi a domande su dati pubblici (11! = fattoriale, il vincitore della Champions League via `fetch()` su Wikipedia, il meteo di qualsiasi città). **Iterazione 3 (poteri reali)**: connessione a **Todoist** tramite un flusso **MCP OAuth** → 50 strumenti in un colpo solo, da cui due problemi: **context bloat** e **rischio reale di danni**. La soluzione si basa sul **MCP Server Portal** di Cloudflare + le impostazioni dei connettori Claude: per ogni strumento, **Always allow / Ask for approval / Disable** (gli strumenti *Disabled* non entrano mai nel contesto; un **classificatore LLM** accetta solo autorizzazioni "allow" distinte e **nega per default**). **Postura dichiarata**: ridurre il proprio ruolo a ***"generatore di idee, esecutore e giudice"*** (e raramente guida tecnica), un flusso "human-in-the-loop" che considera poco *"2026"* (copia-incolla in UIFlow). **Cosa NON ha fatto**: nessuna ottimizzazione di latenza/streaming, nessuna chiamata LLM ottimistica, nessuna valutazione (eval), ***"non ho nemmeno guardato il codice una sola volta"***. **Stupore**: 30€ + una finestra di sessione Anthropic + qualche centesimo di inferenza Cloudflare → un oggetto che ascolta e parla, pilotato in linguaggio naturale; *"il vero sblocco è quanto sia accessibile."* Contrasto netto con [[thomas-pragdave-failing-faster-code-rot-ai-velocity-2026-06-06]] (qui *"zero blast radius"* giustifica il non guardare mai il codice); illustra concretamente il *Code Mode* / *"l'agente che scrive ed esegue codice"*, il pattern **MCP** ([[claude-skills-bigger-than-mcp-willison-2025-10-16]]), la governance degli strumenti in stile *Ask for approval* (uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21), e la dottrina dei *systems around the model* di dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28.
#BYO agent#bring your own AI#svago tecnologico
**Mark Dembo** (@darkmembo / @mdembo) · **Head of Solutions – Developer Platform & AI** chez **Cloudflare** (auparavant auteur sur le blog Cloudflare). Billet personnel publié sur son blog *markpauldembo.com* le **7 juin 2026** (description : *« Thoughts about tinkering on a Sunday »*).
Post di **David "Pragdave" Thomas** (co-autore di *The Pragmatic Programmer*, firmatario dell'Agile Manifesto) pubblicato il **6 giugno 2026** sulla sua newsletter Substack. **Tesi**: l'IA non abolisce il degrado del codice, lo **accelera**. Aggiungendo funzionalità a un piccolo progetto personale di animazione/grafica con **Claude**, l'autore passa dall'entusiasmo iniziale (oklch, animazioni SVG rilasciate in una settimana) a cicli di regressione permanenti entro la seconda settimana. Formulazione incisiva: ciò che ai team ci vogliono ***"18 mesi, se non di più"*** per degradarsi, lui lo ha raggiunto in ***"18 ore distribuite su cinque serate."*** **Causa profonda**: l'abbandono dell'**igiene del codice** (duplicazione massiccia, soluzioni locali a problemi sistemici, sovra-condizionamento, proliferazione di casi speciali). **Diagnosi comportamentale**: gli LLM ottimizzano per il coinvolgimento e la soddisfazione dell'utente (*"That's a great idea, Dave!"*) piuttosto che per la durabilità — sono ***"sviluppatori junior cuccioli, ansiosi di compiacere ma piuttosto disordinati da avere intorno"*** che propongono costantemente nuove funzionalità e scoraggiano il refactoring. **Intuizione centrale**: chiunque non sia sviluppatore può riuscire nella *"prima settimana"* di coding con l'IA; è il **giudizio professionale** — sapere quando fermarsi per rifattorizzare — a distinguere l'ingegnere esperto dal principiante. **Epigrafe** (Gordon Bell): *"Every big computing disaster has come from taking too many ideas and putting them in one place."* **Conclusione**: ***"È sempre e solo programmazione"*** — il codice trascurato si degrada, che siano 18 ore o 18 mesi; tutto ciò che si è imparato sul buon codice resta valido, l'effetto è semplicemente **amplificato**. Converge con la dottrina *"più veloce diventa l'esecuzione, più rigoroso deve essere il framework"* di [[rafal-wenvision-ingenierie-logicielle-ere-ia-tout-change-rien-ne-change-2026-06-01]], con *"lo sviluppo assistito dall'IA è una trappola senza continuous delivery"* di [[farley-continuous-delivery-ai-assisted-development-trap-2026-05-13]], e con *"l'IA sposta i colli di bottiglia, non li elimina"* di dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28; un contrappunto artigianale al vibe coding rispetto a karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29.
#igiene del codice#degrado del codice#degradazione del codice
**David Thomas** (alias **« Pragdave »**) · co-auteur avec Andy Hunt de *The Pragmatic Programmer* (1999, éd. 20e anniversaire 2019) · co-fondateur de **The Pragmatic Bookshelf** et l'un des **17 signataires du Manifeste Agile** (2001). Figure historique du *software craftsmanship*. Billet publié le **6 juin 2026** sur sa newsletter Substack *articles.pragdave.me*.
Analisi di **Olivier Rafal** per **WeNvision** (società di consulenza francese), pubblicata il **4 giugno 2026** (~4 min di lettura), che commenta il lancio della **Tokenomics Foundation** da parte della **Linux Foundation** (annuncio del 3 giugno, in partenariato con la **FinOps Foundation**), evento che l'autore interpreta come l'apertura ufficiale de **l'era del "FinOps for AI".** **Tesi centrale**: l'IA ha trasformato l'economia dello sviluppo software; il **token** è diventato *"la nuova unità di misura della spesa tecnologica"*, in parallelo con il cloud degli anni 2010 (costi **ricorrenti e variabili** da gestire attivamente), da cui il passaggio dei fornitori dal prezzo forfettario alla **fatturazione a token**. **Scala (urgenza)**: *"Secondo Goldman Sachs, l'uso globale di token dovrebbe moltiplicarsi per 24 entro il 2030, raggiungendo 120 quadrilioni di token al mese"* — un ordine di grandezza che fa passare l'efficienza dei token da *"dettaglio tecnico"* a tema di **consiglio di amministrazione**. Citazione di **J.R. Storment** (fondatore della FinOps Foundation): *"I costi e l'efficienza dei token sono diventati una preoccupazione di livello CEO, non una nota tecnica a piè di pagina."* **Problema di trasparenza/standardizzazione**: l'attuale pricing dell'IA non è comparabile (token in ingresso / sistemi di caching / output differiscono da un modello all'altro) → la Tokenomics Foundation punta a **estendere la specifica FOCUS** open source per fornire un **linguaggio comune** per l'acquisto e il confronto. **Messaggio centrale di Rafal (al di là del costo)**: *"Lo scopo del FinOps non è tanto tagliare i costi quanto ottimizzare l'efficienza"* — la metrica reale è il **costo dell'IA relativo all'impatto sul business** (*time to market, qualità, funzionalità, eco-design*). **Limiti dei soli standard**: le norme tecniche non bastano, occorre **ripensare il Target Operating Model** (team, processi, cultura del dato, allineamento con il business); gli americani annunciano già *"la fine dei double-pizza team a favore dei sandwich team"*. **Segnale di allerta**: *"un SDLC potenziato dall'IA non farà che […] amplificare i problemi e aiutarvi ad andare più veloci… contro il muro"* (in assenza di fondamenta organizzative). **Sponsor della fondazione citati**: Accenture, Booking.com, Google Cloud, Microsoft, IBM, Salesforce. **Offerta di WeNvision**: *"co-costruire una roadmap, ripensare il modello operativo per l'era agentica e stabilire la governance finanziaria diventata indispensabile."* **Lettura in lingua francese, rivolta a dirigenti/responsabili della trasformazione**, della scheda [[tokenomics-foundation-linux-finops-token-economics-about-2026-06-03]]; converge con il cluster FinOps agentico [[finops-foundation-finops-for-ai-overview-2026-02-17]], finout-finops-ai-agents-four-step-allocation-framework-2026-04-27, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (token→risultato, valore > volume).
#Tokenomics Foundation#FinOps for AI#FinOps for AI
**Olivier Rafal** · pour **WeNvision** (cabinet de conseil français — bureaux à Paris, Lille, Strasbourg, Bordeaux, Nantes, Toulouse, Belgique, Luxembourg). Olivier Rafal écrit en analyste/conseil familier des préoccupations de comité de direction (ancien analyste IT, profil conseil-transformation). Publié le **4 juin 2026**.
Approfondimento tecnico del team **Data Science & Data Engineering** di Anthropic (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry) pubblicato il **3 giugno 2026** sul blog Anthropic (categoria *Enterprise AI*, incentrato su **Claude Code**). **Risultato principale**: ***"il 95% delle query di business analytics viene automatizzato da Claude, con un'accuratezza aggregata del ~95%"*** (fino al **~99%** in alcuni ambiti). **Problema di fondo**: l'analytics **non** è codice — *"spesso esiste un'unica risposta corretta a partire da un'unica fonte corretta"* — richiede di **mappare la domanda dell'utente su entità precise e aggiornate** nel modello dei dati. Tre **modalità di fallimento**: (1) **ambiguità concetto↔entità** (es. *"utenti attivi"*: quali azioni? escludere i truffatori? quale finestra temporale?); (2) **obsolescenza** (gli asset e la conoscenza dell'agente diventano *"sottilmente errati"*); (3) **fallimento del retrieval** (*"l'80% delle query fallite aveva l'informazione presente nel corpus"* ma introvabile). **Soluzione = uno "stack di analytics agentico" a 4 livelli**: (L1) **Fondamenta dei dati** — modellazione dimensionale, **dataset canonici** *"fonte unica di verità"*, metadati *"come prodotto di prima classe"*, integrità tramite CI/CD; (L2) **Fonti di verità** in ordine decrescente di affidabilità — **semantic layer** (l'agente è *"strutturalmente obbligato (per istruzione della skill) a utilizzare prima il semantic layer"*), grafo di lineage, **corpus di query** (distillato in documenti strutturati, **non** retrieval grezzo), contesto di business (grafo di conoscenza: roadmap, decision log, organizzazione); (L3) **Skills** — la leva decisiva: ***"senza skill … non si superava il 21% … Aggiungendo le skill questi numeri salgono stabilmente oltre il 95%"***; strutturate **in coppie** (*Knowledge skill* = router verso ~30 file di riferimento; *Unbook skill* = workflow da analista senior: chiarire → trovare le fonti → eseguire → **revisione avversariale**); manutenzione **colocata** (*"un hook di code review segnala qualsiasi modifica al modello di reporting che non tocchi un file di skill"* → **~90% delle PR sui dati include una modifica a una skill**); (L4) **Validazione** — eval offline (soglia ~90% per lanciare un agente, obiettivo ~100%), **ablation testing** (risultato negativo notevole: grep grezzo su migliaia di file SQL → l'accuratezza si muove *"meno di un punto"*), online (revisione avversariale: **+6% accuratezza, +32% token, +72% latenza**), **footer di provenienza** (livello della fonte + freschezza + proprietà), **raccolta attiva di correzioni** (agenti pianificati che scansionano i canali per redigere correzioni in markdown). **Intuizione strategica**: *"documentazione generata, definizioni possedute dagli esseri umani"* — lasciare che l'LLM **definisca** le metriche si è rivelato *"netamente negativo"*. **Punto di partenza minimo**: una manciata di dataset canonici + qualche decina di eval + una *knowledge skill leggera* catturano *"la maggior parte del vantaggio"*. Converge fortemente con [[shihipar-claude-code-lessons-building-skills-2026-06-03]] (skills = cartelle, Gotchas, hook), la dottrina dei *sistemi attorno al modello* di [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], il **semantic layer / ontologia** di talisman-modern-data-101-ontology-pipeline-refresh-2026-05-04 e seale-semantic-agent-model-harness-ontology-data-2026-04-17, il *context development lifecycle* di debois-tessl-context-development-lifecycle-ai-coding-agents-2026-02-19, e l'UDA/knowledge graph di netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12.
#self-service analytics#agentic data analytics#Claude Code
**Chen Chang · Clement Peng · Justin Leder · Johanne Jiao · Josh Cherry** — équipe **Data Science & Data Engineering d'Anthropic**. Article publié le **3 juin 2026** sur le blog Anthropic (claude.com/blog) · catégorie *Enterprise AI* · ~5 min de lecture.
Post del blog di **Anthropic / claude.com** di **Thariq Shihipar** (Member of Technical Staff, team Claude Code), pubblicato il **3 giugno 2026**, che sintetizza l'**esperienza interna** di Anthropic nella progettazione e nell'uso delle **Skills**. **Tesi di inquadramento**: una Skill non è un semplice file markdown ma una **cartella** (istruzioni + script + risorse + configurazione + hook) che l'agente **esplora e manipola**; *« You should think of the entire file system as a form of context engineering and progressive disclosure. »* L'articolo apporta due contributi strutturanti. **(A) Una tassonomia di 9 categorie di skill** osservate in Anthropic: (1) **Library/API Reference** (documentazione per librerie/CLI interne con *gotchas* — es. `billing-lib`, `internal-platform-cli`, `sandbox-proxy`); (2) **Product Verification** (test/verifica tramite Playwright o tmux — `signup-flow-driver`, `checkout-verifier`, `tmux-cli-driver`); (3) **Data Fetching & Analysis** (accesso a stack di dati/monitoraggio — `funnel-query`, `cohort-compare`, `grafana`, `datadog`); (4) **Business Process Automation** (workflow ripetitivi — `standup-post`, `weekly-recap`, `create-<ticket>-ticket`); (5) **Code Scaffolding** (boilerplate di framework — `new-migration`, `create-app`); (6) **Code Quality & Review** (`adversarial-review`, `code-style`, `testing-practices`); (7) **CI/CD & Deployment** (`babysit-pr`, `deploy-<service>`, `cherry-pick-prod`); (8) **Runbooks** (diagnostica multi-tool — `<service>-debugging`, `oncall-runner`, `log-correlator`); (9) **Infrastructure Operations** (manutenzione con guardrail — `<resource>-orphans`, `cost-investigation`). **(B) Un insieme di best practice**: non ripetere l'ovvio (*« Claude already knows how to code and can read your codebase »* → puntare su ciò che **contraddice il comportamento predefinito**); curare la **sezione Gotchas** (*« the highest-signal content in any skill »*); **progressive disclosure** tramite l'albero dei file (indirizzare verso file di riferimento a seconda della situazione anziché caricare tutto in anticipo); **descrizioni scritte per il modello** (*« the description field is not a summary, it's a description of when to trigger this skill »*); **flussi di setup** (configurazione in `config.json`, altrimenti richiesta tramite `AskUserQuestion`); **memoria persistente** (log append-only / JSON tramite la variabile `${CLAUDE_PLUGIN_DATA}`); **script helper** (*« lets Claude spend its turns on composition… rather than reconstructing boilerplate »*); **hooks conditionnels** (attivati solo per la durata della skill — es. un hook di sicurezza che blocca comandi distruttivi). **Distribuzione in Anthropic**: le skill sono conservate in `./.claude/skills`, condivise informalmente via Slack in una cartella sandbox, poi promosse tramite **PR** nel **marketplace** interno una volta acquisita trazione; **misurazione dell'utilizzo** tramite un **hook PreToolUse** che registra le invocazioni (rivelando le skill popolari rispetto a quelle sottoutilizzate). Seguito diretto della fiche [[shihipar-claude-code-html-unreasonable-effectiveness-markdown-2026-05-10]] (stesso autore) e complemento concreto alle fiche sulle Skills di Anthropic/Willison/Vincent e all'*harness engineering*.
#skills#Claude Code#Anthropic
**Thariq Shihipar** (Member of Technical Staff chez Anthropic, équipe **Claude Code** ; @trq212 / @trq sur X, thariqs.github.io) · pour le blog **claude.com**. Même auteur que la fiche *Using Claude Code: The Unreasonable Effectiveness of HTML* (2026-05-10). Publié le **3 juin 2026**.
**Pagina About** del sito **tokeneconomics.com**, che presenta la **Tokenomics Foundation** — un progetto **Linux Foundation** annunciato il **3 giugno 2026**, gestito in **stretta collaborazione con la FinOps Foundation**. **Missione dichiarata**: *"establish open industry standards, benchmarks, and best practices for the economics of AI infrastructure"* — che collega **produzione, consumo e monetizzazione** dei token al **valore di business**. **Definizione quadro della tokenomics**: *"Tokenomics is not just about the cost of tokens, it's about the entire layer of AI that they drive from production, to consumption to monetization"* — ossia **l'intero strato economico dell'IA**, dal costo dell'infrastruttura alla selezione del modello fino all'ottimizzazione del valore. **Tesi delle fasi**: l'adozione iniziale dell'IA privilegiava la **capacità**; la fase attuale si sposta verso **efficienza e valore**, il che richiede una gestione sistematica dei costi e **visibilità**. **5 principi fondatori**: (1) ***"Efficiency is a design choice. AI cost is shaped by architecture, not just usage"***; (2) ***"Bigger is not always better. The best AI system is not always the one using the most expensive model"*** (right-tool / routing); (3) ***"Visibility comes before optimisation. Teams cannot manage what they cannot see"***; (4) ***"Value matters more than volume. More tokens, more calls, and more automation do not automatically mean better outcomes"***; (5) ***"Open knowledge benefits everyone"*** (standard condivisi, apprendimento collettivo, trasparenza). **Governance**: un **Governing Board** (direzione industriale + allocazione dei fondi) e un **Technical Committee** (specifiche aperte + benchmark). **Deliverable**: estensione della **FOCUS specification** (FinOps), specifiche aperte, benchmark, framework e metriche condivisi. **Pubblico target**: CAIO, CTO, CIO, CFO, ingegneri, team di prodotto, professionisti FinOps, ricercatori, startup, imprese, settore pubblico. **Obiettivo dichiarato**: portare le organizzazioni *"from experimental AI adoption to sustainable AI operations"* estendendo la disciplina della **spesa tecnologica variabile** all'era dei token. **Rilevanza per questa rassegna**: istituzionalizzazione/standardizzazione del **FinOps agentico** a livello di fondazione di settore — converge direttamente con le schede [[finops-foundation-finops-for-ai-overview-2026-02-17]], [[finout-finops-ai-agents-four-step-allocation-framework-2026-04-27]], orq-ai-finops-ai-agents-cost-per-outcome-hosseini-2026-04-15, gupta-token-budget-wars-marginal-token-utility-2026-05-28 (livello di allocazione, token verso outcome) e con lo spostamento **token → outcome** (Salesforce/Tallapragada, Sierra/Greenwald). I 5 principi corrispondono esattamente alle leve già rilevate: architettura > uso, **routing Haiku/Sonnet/Opus**, osservabilità prima dell'ottimizzazione, valore ≠ volume.
#Tokenomics Foundation#tokenomics#economia dei token
**Tokenomics Foundation** (entité collective, projet de **The Linux Foundation**, en partenariat avec la **FinOps Foundation**). Page institutionnelle *About* — **aucun auteur individuel nommé**. Annonce datée du **3 juin 2026**.
Alla vigilia dell'IPO record di SpaceX (valutazione obiettivo di circa 1,75-1,8 trilioni di dollari), The New York Times pubblica un'analisi interattiva del track record di promesse pubbliche di Elon Musk. Su oltre 600 impegni datati e quantificati (dichiarazioni, post, conference call con gli investitori), solo circa il 19% è stato mantenuto nei tempi previsti, se non del tutto. Il tasso peggiora nel tempo: circa il 75% mantenuto nel 2015, meno del 50% nel 2020. Marte, il robotaxi e la guida autonoma completa costituiscono la maggior parte degli obiettivi ripetuti e posticipati. L'articolo collega questo track record al prospetto informativo di SpaceX, che ora punta sull'AI (xAI è stata integrata) e riconosce esso stesso che i tempi delle sue principali iniziative sono indeterminabili.
Guida della testata **Every** (every.to/guides) pubblicata il **2 giugno 2026**, firmata congiuntamente da **Mike Taylor, Laura Entis e Claude**, che propone una **scala di maturità a 8 livelli per l'adozione dell'IA**. **Tesi centrale**: l'adozione dell'IA **non è una corsa verso la massima sofisticazione** — ***« un livello più alto non è necessariamente migliore »*** ; occorre individuare il livello che **corrisponde al proprio workflow e al proprio livello di fiducia**, per poi rivalutare regolarmente se salire di un gradino apporta **valore reale**. ***« Il modo migliore per trovare valore nell'IA è usarla in un modo che si adatti al proprio lavoro. »*** **Asse strutturante**: a ogni livello, *« si delega una parte maggiore del proprio lavoro all'IA—e si ripone in essa maggiore fiducia »* (delega + fiducia crescenti). **Gli 8 livelli**: **(1) Chatbot** — interfaccia conversazionale senza contesto integrato (ChatGPT, Claude, Gemini); **(2) Copilot** — IA integrata nello spazio di lavoro con accesso al file corrente (Cursor, Claude in Excel, Gemini in Docs); **(3) Agent** — sistema reattivo che esegue passo dopo passo richiedendo approvazione (Cowork, Codex); **(4) Autopilot** — si descrive il **risultato** e l'agente esegue in autonomia, revisione del solo **risultato finale** (Lovable, Codex, Claude Code; legato al *vibe coding*); **(5) Workflows** — ingegneri che costruiscono **harness** attorno agli agenti (pianificazione, revisione, controlli di confidenza, guardrail; Compound engineering, Claude Workflows, Copilot AI Studio; passaggio dal vibe coding one-shot al **agentic engineering**); **(6) Assistant** — agenti **proattivi, sempre attivi** che monitorano un dominio e segnalano informazioni senza essere sollecitati (OpenClaw, Hermes Agent, Claude Managed Agents; es. `heartbeat.md` ogni 30 minuti); **(7) Multi-agent** — gestione simultanea di **più agenti a lunga esecuzione** con ruoli distinti (Claude Managed Agents, OpenClaw, Codex Goals; *« saldamente nel territorio dell'ingegneria senior »*); **(8) Orchestrator** — un **agent manager** dirige un team di sotto-agenti (pianificazione, delega, monitoraggio, consolidamento; Gas Town, Paperclip, Symphony/OpenAI; *« altamente sperimentale »* — anche gli ingegneri di frontiera ricoprono essi stessi questo ruolo). **Sweet spot per ruolo**: i **knowledge worker** operano tipicamente tra i livelli **1-4**, gli **ingegneri** tra **5-8**. **Parallelo canonico con l'inserimento di uno stagista**: *« Aspettatevi di investire uno sforzo simile con i vostri agenti prima di potervi fidare di loro… al livello di autonomia successivo »* ; e la frase marcatore ***« Non vi vantereste di avere otto stagisti al lavoro tutta la notte su un progetto chiave senza aver controllato il loro output. »*** Il livello giusto dipende da **4 criteri**: qualità del risultato, costo, affidabilità (trustworthiness), posta in gioco in caso di fallimento; e la **capacità del modello** sposta progressivamente il livello di autonomia "sicuro". Un framework direttamente utilizzabile per strutturare una **dottrina di adozione** sul lato consulenza. Convergenza con i *sistemi attorno al modello* (Dropbox/Okumura), l'*harness engineering* (Böckeler, Lattice, Wescale), Karpathy (vibe coding → agentic engineering), Cherny (/loop + Routines) e la dottrina dell'*agent manager* (BFM/Girard).
#adozione dell'IA#scala di maturità#otto livelli
**Mike Taylor** · **Laura Entis** et **Claude** (co-auteurs déclarés) · pour **Every** (every.to) · rubrique *Guides*. Mike Taylor est un auteur connu sur les sujets prompt/AI (co-auteur de *Prompt Engineering for Generative AI*) ; Laura Entis est journaliste/éditrice. La co-signature explicite de **Claude** comme auteur fait partie du positionnement éditorial d'Every (entreprise AI-native). Publié le **2 juin 2026**.
Editoriale di **Olivier Rafal** (Consulting Director Strategy, **WeNvision** — gruppo **SFEIR**; ex direttore responsabile 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, guidare e revisionare** l'esecuzione degli agenti; il **QA** acquisisce la capacità di definire a monte la **prova attesa**. La struttura dei team passa dalle *"double pizza teams"* (catene di passaggio di consegne di ~8 persone) alle ***"sandwich teams"***: un **binomio stretto tra un esperto di business e un tech lead, entrambi potenziati dall'IA**, con altre competenze a supporto. Dato interno **Sfeir**: *"questo binomio guida oggi circa l'80% della catena di produzione,"* il restante ~20% (architettura, governance dei dati, sicurezza) essendo centralizzato. Citazione chiave: ***"Il problema non è un problema di strumenti, è un problema di modello operativo."*** **Ciò che non cambia è la disciplina del ciclo.** Le fasi dello **SDLC** (definire → costruire → verificare → distribuire → mantenere) restano identiche e non negoziabili; l'IA non ne elimina nessuna, le **intensifica**: ***"tutto il margine che il ritmo umano assorbiva un tempo, per quanto imperfettamente, diventa, alla velocità dell'IA, un difetto di livello industriale"*** (metafora sportiva dilettante contro professionista). Da qui **tre *gate* inviolabili** (controllo umano): **specifica, pianificazione, revisione di consegna**; validazione **tramite prova** (non tramite le affermazioni dell'IA stessa); **capitalizzazione sistematica** (ogni ciclo alimenta il successivo) → risultato misurato: **−30% di iterazioni di correzione dopo ~10 cicli**. Principio: ***"più veloce è l'esecuzione, più rigoroso deve essere il quadro."*** Concetti richiamati: **harness** (regole agentiche adattate al contesto), **vibe coding** giudicato **insostenibile in azienda**. **Terzo pilastro = governance, FinOps e gestione orientata al valore**: costi IA **variabili e ricorrenti** (~**10 €/ora** per ruolo potenziato), passaggio dalla licenza forfettaria alla fatturazione a consumo (un parallelo con il cloud degli anni 2010); il **FinOps** non mira a tagliare i costi ma a *"ottimizzare l'efficienza degli strumenti"* (costo rispetto al valore); allineare a monte le **metriche di business** (time-to-market, funzionalità, prestazioni, eco-design). **Conclusione**: l'accelerazione rende i fondamentali **non negoziabili**; la sfida è **organizzativa e culturale**, non tecnologica — senza mettere in sicurezza la relazione con il business e la disciplina collettiva, uno SDLC potenziato dall'IA **amplifica solo i problemi** (schiantandosi contro il muro più velocemente). 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 *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, Salesforce agentico, e il dibattito sull'*agent manager* (BFM/Girard, SFEIR).
#ingegneria del software#IA#tutto cambia nulla 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**.
Studio di dati Atlassian (Inside Atlassian) che misura il rendimento effettivo di un **SDLC AI-native** basato su **Rovo Dev**. Su 3.400 repository di 2.500 clienti (un quasi-esperimento con propensity-score matching), i repository che adottano lo strumento uniscono il **19% di PR in più al mese**; fino al **37-51%** sui repository a bassa/media attività e al **59-87%** quando **da 3 a 5 membri** del team adottano lo strumento. Sul fronte dell'efficienza, gli sviluppatori risparmiano **2-3 h/settimana** (circa il 10% delle 24 ore dedicate a coding e review), ossia 20-30 ore/settimana reinvestite per un team di 10 persone. La tesi: risolvere il "paradosso della produttività" di Solow (1987) passando da **metriche di utilizzo** (token) a **metriche di impatto** (throughput, tempo risparmiato, tasso di fallimento, soddisfazione). Raccomandazione: iniziare con un **team** (non un individuo) e misurare 2-3 mesi dopo.
Articolo breve (**8 pagine**, 4 esibit) di **McKinsey Technology**, firmato da **Jared Moon** (senior partner, Londra), **Rory Walsh** e **Vito Di Leo** (partner, Dublino e Zurigo), con **Adam Thelwall**, pubblicato nel **maggio 2026**. Gli autori riportano guadagni di produttività da **×3 a ×5** con una **riduzione del 60%** della dimensione dei team in diverse aziende, e li attribuiscono alla riprogettazione del modello operativo, non al solo deployment di agenti. Quattro leve: (1) lo **sprint di 24 ore**, con un turno notturno di agenti (16h) e un turno diurno umano (8h); (2) l'automazione degli **handoff** tra requisiti, design e codice, che secondo gli autori rappresentano il **70% della spesa tecnologica** contro il 30% del deployment; (3) un'**infrastruttura di conoscenza** di grafi specifici per dominio, interrogati da un agente « bibliothécaire »; (4) il ridimensionamento dei team e del portfolio. Sul grafo: *« this should not begin with a grand, top-down ontology effort »*. Le cifre relative ai team sono presentate come illustrative, tratte dall'"esperienza e osservazione" della società. Estende la presentazione di McKinsey del novembre 2025 sul software delivery guidato da agenti ([[harrison-maniar-mckinsey-reshaping-software-delivery-agents-2025-11-23]]).
#McKinsey#agentic SDLC#modello operativo
Jared Moon (senior partner) · Rory Walsh · Vito Di Leo (partners) · avec Adam Thelwall (associate partner) — McKinsey & Company
Articolo di blog di **Pasquale Pillitteri** (software engineer, Palermo) pubblicato il **29 maggio 2026** (versione FR), lettura di 18 minuti, sezione *Claude Code & Anthropic*. **Tesi centrale**: *« Claude Opus 4.8 è il modello SEO più potente del 2026, ma quasi tutti lo usano male »* — non un problema di modello ma un problema di **sistema**. La regola d'oro: ***« la strategia è una lavagna, la produzione è una catena di montaggio »*** — la SEO deve essere **suddivisa in due fasi distinte**, e mescolarle è *« il modo più rapido per sprecare un modello che costa cinque dollari per milione di token in input e venticinque in output »*. **Contesto del modello**: Opus 4.8 rilasciato il **28 maggio 2026** (41 giorni dopo Opus 4.7), contesto di **1M di token**, **GraphWalks Long-Context F1 a 1M: 40,3% → 68,1%**, **SWE-bench Verified 88,6%**, **USAMO 2026 96,7%** (+27,4 punti), **HLE con tool 57,9%**, prezzo invariato **5$/25$** per milione di token, **Fast Mode 2,5× a 10$/50$**, quattro **livelli di effort** (Low, High, Extra, Max). **L'anti-pattern centrale** = *« la conversazione gigante »* / **context drift**: mescolare strategia, ricerca di parole chiave, analisi competitiva e scrittura in un'unica chat produce un *« miscuglio di intenzioni contraddittorie »* → il modello scivola verso **best practice generiche** ("ottimizzazione olistica", "approccio strategico") invece di contenuti ancorati ai dati. **Fase 1 — Strategia (lavagna, UI visiva, una tantum)**: dashboard / Google Sheet / canvas Claude.ai per decidere guardando insieme i dati. **3 mosse**: (a) **ricerca di parole chiave classificata** (tabella di volume / difficoltà 0-100 / intento / potenziale business / priorità = volume÷difficoltà×peso business); (b) **analisi competitiva visiva** (matrice di copertura degli argomenti, gap); (c) **roadmap a fasi** (quick win M1-2 / medio termine M3-6 / pagine pilastro M7-12). La modalità **Extra/Max** è giustificata qui (*« una decisione strategica corretta vale mille pagine ben scritte sulle parole chiave sbagliate »*). 3 artefatti chiusi salvati su Notion/Drive. **Fase 2 — Produzione (catena di montaggio, Opus 4.8 + MCP)**: il modello passa da stratega a **macchina di esecuzione**; ogni decisione **ancorata a dati live** tramite il **Model Context Protocol**. **Stack MCP minimo**: **GSC MCP** (AminForou/mcp-gsc, 500+ stelle), **Ahrefs MCP ufficiale** (98 stelle), **GA4 MCP**; il repo `modelcontextprotocol/servers` = **86.440 stelle**, **10.000+ server attivi**, 97M download SDK/mese. Setup ~35 min, refresh mensile ~20 min. **Loop settimanale**: un singolo prompt estrae dati live, costruisce il brief (top 10 SERP + GSC + Ahrefs), deriva H2/H3, scrive, verifica la densità, suggerisce i titoli → **+45% di produttività**, bozza in **6-12 min** (riferimento esplicito a **Ryan Law / Ahrefs content engineering**, 23 skill). Cita i **Dynamic Workflows** di Anthropic (fino a 1.000 subagent). **4 errori comuni**: (1) non verificare i numeri (spot-check obbligatorio, *trust & verify*); (2) sostituire integralmente Semrush/Ahrefs (MCP è un **layer** sopra, non un sostituto); (3) ignorare il **paid-organic content gap** (caso cliente education: **2.742 termini sprecati / 351 opportunità** identificati in 90 s); (4) usare Opus 4.8 dove basta **Haiku 4.5** (meta description, alt text). **Costo**: 1-3$ per articolo di 2.500 parole. **Sonnet 4.6** basta per la produzione ricorrente, Opus 4.8 riservato alla strategia. Articolo SEO-ottimizzato e autoreferenziale (l'autore scrive di SEO in un contenuto esso stesso pensato per posizionarsi su "Opus 4.8 SEO"). Convergenza diretta con **Ryan Law/Ahrefs** (citato), **sistemi attorno al modello** (Dropbox/Okumura), **skill-over-prompt** (Lattice), model routing Haiku/Sonnet/Opus (Gupta token-to-outcome).
#Claude Opus 4.8#SEO IA#workflow a due fasi
**Pasquale Pillitteri** — Ingénieur informatique / développeur logiciel basé à **Palerme** (Italie) · certifié Innovation Manager UNI 11814:2021. Auteur d'un blog tech actif (rubrique *Claude Code & Anthropic*) · avec une newsletter hebdomadaire (~3,4k lecteurs). Article publié en version **FR** le **29 mai 2026** (lendemain de la sortie d'Opus 4.8).
Post dal **Dropbox Tech blog** (sezione *culture*), pubblicato il **28 maggio 2026** da **Kazuaki Okumura** (Dropbox, ruolo non specificato nell'articolo), che riprende un intervento alla conferenza **DX Annual 2026** (developer productivity). **Tesi centrale**: la produttività ingegneristica deve andare oltre la *code generation*. *« Accelerating code generation simply shifted some bottlenecks downstream »* — l'IA ha aumentato in modo massiccio il throughput di codice, ma *« the faster code moves, the more pressure it puts on review queues, CI systems, validation workflows, release coordination, and production operations »*. La vera sfida non è più scrivere codice più velocemente, ma consentire all'intero SDLC di **assorbire, validare e spedire in sicurezza** un volume molto maggiore. **Dal copilot all'agente**: la prima ondata (spiegazione del codice, snippet, Q&A) operava *« as copilots alongside the engineer »*; l'agente, invece, *« can take a scoped task, inspect the codebase, edit files, run tests, iterate on failures, and return an artifact for human review »* — con l'ingegnere che resta *« accountable for intent, architecture, quality, and release decisions »* (più lavoro in parallelo, più opzioni, delega dell'esecuzione ripetitiva). **Nova** = piattaforma **interna** di agenti di coding di Dropbox: descrivere un compito in linguaggio naturale, esecuzione in un ambiente controllato con contesto del codebase. Dato canonico: ***« Nova's value comes less from the model itself than the systems surrounding it »*** (contesto del codebase, pratiche interne, esecuzione sicura, integrazione nei workflow, revisione umana); Nova rappresenta oggi **~1 PR su 12 in Dropbox** (adozione in crescita), e si estende oltre le feature a **migrazioni, risoluzione di flaky test, investigazione di bug, aggiornamento di dipendenze** (lavoro ad alto toil). **Misurare la velocità di prodotto, non l'output di codice**: il *PR throughput*, segnale utile quando il vincolo era la velocità di coding, *« was no longer sufficient »*. Un modello di misurazione a **4 fasi**: ***Fuel*** (gli strumenti IA vengono usati?) → ***Adoption*** (come cambiano i workflow nei team) → ***Output*** (l'IA contribuisce al lavoro in produzione?) → ***Impact*** (*« improving product velocity and reducing the time it takes to move from idea to customer value »*). Segnali di qualità monitorati: **tempo di turnaround della code review, tasso di successo dei test al primo run, defect ratio, rework rate**. *« Quality and trust matter as much as speed »* — il cuore del cambiamento: *« moving from local activity metrics toward broader system outcomes »*. **Anche i workflow devono evolvere**: non si tratta *« just a tooling shift »* ma di un cambiamento di **modello operativo** — il ruolo dell'ingegnere si sposta verso *« defining intent, mapping problems, reviewing generated changes, and making higher-context architectural and quality decisions »*. L'**enablement** è cruciale quanto lo strumento stesso (apprendimento pratico, hackathon, workflow spotlight, bootcamp, esempi guidati dai pari); l'adozione procede a velocità diverse nei team; *« The goal is not to force every workflow through an agent »* — l'obiettivo è renderlo *« useful, safe, measurable, and repeatable where it creates meaningful leverage »*. **Cosa abbiamo imparato**: ***« AI doesn't eliminate bottlenecks in software development, but it does move them »*** (a valle: review, validazione, testing, release, prod ops) → ottimizzare il vecchio collo di bottiglia non genera più la stessa leva. *« The advantage will not come from access to the same foundation models everyone else can use. It will come from the systems built around those models: context, internal tooling, quality controls, and the workflows that connect them together. »* La pressione si accumula anche **a monte** (prodotto e design): specifiche strutturate, chiarezza di design, definizione più netta dei problemi. Chiusura: ***« The future of engineering productivity will not be defined solely by who has the best models. It will be defined by who builds the best systems around them »***; *« The real challenge is no longer just generating more code, but building engineering systems that can reliably turn AI-assisted output into valuable experiences for our customers »*. Convergenza diretta con **Salesforce/Tallapragada** (Effective Output: misurare il valore, non il volume; nessun trade-off velocità/qualità), **Gupta** (attribuzione token-to-outcome, costo di un outcome completato), **DORA** (oltre il throughput), e lo spostamento del KPI verso l'**outcome di sistema** (idea→valore per il cliente).
**Kazuaki Okumura** — Dropbox (rôle non précisé dans l'article ; le billet reprend une intervention présentée à la conférence **DX Annual 2026** sur la productivité développeur, ce qui suggère un profil engineering leadership / platform, sans confirmation). Publié sur le **Dropbox Tech blog** (dropbox.tech) · rubrique *culture* · le **28 mai 2026**.