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 del blog aziendale di **Block** (`block.xyz/inside`), non firmato — l'autore indicato è **"Block"** —, pubblicato il **18 agosto 2026**, ~930 parole, che annuncia **l'apertura open source di Berd**, l'applicazione desktop interna di Block per lavorare con gli agenti, ed espone la tesi progettuale che l'ha guidata: dare carattere agli agenti *"non solo attraverso ruoli, istruzioni, skill e strumenti, ma attraverso identità visive distintive"* — da cui i personaggi animati proprietari, i *"Gloopies"*. Il post parte da un'osservazione di frammentazione (*"The technology was powerful, but the experience around it was fragmented"*) e da un problema d'interfaccia denominato con precisione: *"the product gives people little sense of how the agent is configured, which context and tools are available to it, and how it differs from another agent"*. Due contributi strutturanti. **(A) Un'articolazione a tre livelli**: **goose** resta il framework e il *runtime* che sostiene l'agent loop; **Berd** è il client desktop (progetti, contesto, sessioni, agenti, configurazione); i due comunicano tramite l'**Agent Client Protocol**. **Buzz** è designato come il seguito, per quando il lavoro solitario diventa collaborativo (*"Start alone, then go multiplayer"*). **(B) Sei requisiti trasmessi a Buzz**, formulati come conclusione: *"private space, durable context, recognizable agent identities, reusable skills, visible configuration, and clearer visibility into an agent's configured context, tools, and capabilities"* — una griglia direttamente riutilizzabile per valutare un client di agenti. Il testo stesso distingue identità e capacità: *"The avatars make the agent recognizable. Its role, skills, and tools make it useful."* Non viene prodotta alcuna cifra d'uso e non è indicata alcuna licenza per l'apertura open source.
#Berd#Block#open source
**Aucun auteur nommé** : le billet est signé **« Block »** — le champ *Author* de la page porte le nom de l'entreprise. Publié le **18 août 2026** sur `block.xyz/inside` · le blog **corporate** · et non sur `engineering.block.xyz`.
Post del blog di **Sonatype** a firma di **Aaron Linskens** (*technical writer*), pubblicato il **18 agosto 2026**, ~1.300 parole: racconta uno studio di **Sonatype Research Labs** condotto su **49 mesi** (giugno 2022 — giugno 2026) su una **coorte fissa** di applicazioni enterprise, scelta metodologica dichiarata per isolare l'evoluzione del parco applicativo da quella del portafoglio clienti. Il risultato è presentato come una contraddizione: il rimedio è più rapido, ma il rischio si accumula ulteriormente. (A) **Lo stock è in crescita** — vulnerabilità *Critical* e *High* per applicazione **×4,31** (da **14,14** a giugno 2022 a **54,3** nel 2026, ancora **×3,91** escludendo le applicazioni legacy portate di recente sotto gestione), nuove versioni di componenti interessate al **46×** il tasso pre-IA, creazione mensile di applicazioni **×4,84**. (B) **Il rimedio sta migliorando** — oltre la metà delle violazioni risolte lo è in meno di un giorno, l'età mediana delle vulnerabilità *Critical/High* non risolte scende da **228** a **126 giorni**, poi a **103** a maggio 2026; tra le coorti che hanno avuto dodici mesi, il **52,6%** è risolto, il **44,3%** aperto, il **3,1%** sotto waiver. (C) **La leva proposta è la selezione dei componenti**: al momento della scelta di una dipendenza vulnerabile, esisteva già una versione sostanzialmente meno rischiosa nel **62,2%** dei casi su **Maven**, nel **46,9%** su **npm**, nel **34,3%** su **PyPI** — uno scarto che il testo attribuisce a un gap informativo piuttosto che a una colpa dello sviluppatore. Il post stesso afferma che l'IA non è l'unica causa dell'accelerazione, e conclude su **Sonatype Guide**, che porta questa intelligence fino al punto di selezione. Sul versante supply-chain, estende quanto [[fiches/2026-08/staples-gitlab-when-code-is-abundant-2026-08-24]] inquadra in termini economici e [[fiches/2026-07/clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] in termini di ciclo sicuro.
#supply chain software#supply chain software#Sonatype Research Labs
Aaron Linskens · *technical writer* chez Sonatype · sur le blog de l'éditeur ; les chiffres sont produits par Sonatype Research Labs · non par l'auteur.
Post di annuncio prodotto di **Block Engineering** firmato da **Thomas Petersen** (*Principal Designer & Builder*), pubblicato il **18 agosto 2026**, ~1.800 parole suddivise in tredici brevi sezioni, che presenta **Buzz Projects** — una **forge software ospitata sul proprio relay**: repository Git, branch, pull request, issue, revisione e merge, progetti multi-repo, un feed di attività, il tutto collegato ai canali di conversazione. Il catenaccio e la tesi del post: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Tre contributi. **(A) Una dottrina di fiducia fondata sulla prova *ex post* piuttosto che sull'autorizzazione *ex ante***: da un lato *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, dall'altro *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; la sezione si chiude su una direzione dichiarata — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Interoperabilità Git senza strumenti proprietari**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, con la clé Nostr che funge da identità unica — *« The same npub that signs your messages signs your pushes. »* **(C) Una distinzione tra superficie di esecuzione e presenza in rete**: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* Il post non produce alcuna cifra e non contiene link esterni; si qualifica come preliminare sei volte (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), e Projects risiede sotto la scheda **Experiments** di Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
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).
Post di annuncio pubblicato sul **blog ufficiale di Z.ai** (già Zhipu AI, laboratorio cinese) il **14 agosto 2026**, **senza firma individuale**, ~2.000 parole più note a piè di pagina. Annuncia **GLM-5.3**, successore di GLM-5.2, aprendo con una tesi metodologica: *« Scaling post-training is all we did for GLM-5.3. »* Stesso modello di base di GLM-5.2 — *« every gain comes from post-training »*. Tre annunci. **(A) Un modello di coding open-weights**: +50% dichiarato sul **Z.ai Code Bench**, un benchmark interno non pubblicato. **(B) Una capacità cyber presentata come "emergente"**, che il corpo del testo riconduce a una scelta di addestramento — *« As part of post-training, we introduced vulnerability discovery data and environments into the training mix. We expected this to make the model better at finding and reasoning about vulnerabilities »* — ciò che è arrivato come sorpresa è la velocità e il cambiamento di natura: il modello passa dall'identificazione di falle isolate a *« coherent plans for complete exploitation chains »*. I guadagni crescono con la posizione nella catena di exploitation: CyberGym 77,2 → **84,5%**, ExploitBench 24,4 → **54,4%** (×2,2), ExploitGym 29 → **105** task in 2h (×3,6), con il divario rispetto alla frontiera chiusa che resta ampio (181 e 247 task). Z.ai lo formula così: *« Capability is growing fastest exactly where we are furthest behind. »* Il post pubblica anche un **Z.ai Security Disclosure Ledger**: **2.436 vulnerabilità identificate in 269 progetti open source** — kernel, sistemi operativi, motori browser, infrastrutture, applicazioni web, protocolli di rete — la più vecchia introdotta nel **1981**, durata media prima della scoperta **26,6 anni**, di cui **53 divulgate** e **2.383 sotto embargo**. **(C) Un rilascio dei pesi** *« within two weeks of launch, once safety evaluation and hardening are complete »*. Il contributo metodologico più riutilizzabile: **sintesi di ambiente e verificatore**, quest'ultimo prodotto senza accesso alla soluzione di riferimento e ammesso solo dopo un tris di controlli negativi — **oracle**, **no-op**, **unsolved-state**. Tutte le valutazioni agentiche sono condotte **in Claude Code 2.1.207**.
#GLM-5.3#GLM-5.2#Z.ai
**Z.ai** (anciennement **Zhipu AI**) · laboratoire d'IA chinois · éditeur de la famille **GLM**. Billet **institutionnel et non signé** : aucun auteur nommé · aucun chercheur mis en avant · aucun lien vers un rapport technique ou une carte de modèle. Publié le **14 août 2026**. La page est une SPA React — le HTML servi est un `<div id="root">` vide · et le texte comme les scores ont dû être extraits du bundle `glm-5.3-BCnx8T5_.js` · où ils figurent en valeurs source.
Pagina prodotto ufficiale di **DeepSeek**, pubblicata il **13 agosto 2026**, **non firmata**, di circa 450 parole, che annuncia il rilascio in *developer preview* di **DeepSeek Harness** (`dsh`) — un harness per agenti di coding **open source con licenza MIT**, il cui repository è stato aperto lo stesso giorno. Una tesi in tre parole, ripetuta nel titolo e nella descrizione del repository: *« Everything is a plugin »*, affiancata da una seconda promessa, *« Every run is traceable »*. La pagina enuncia l'equazione *« AGENT = MODEL + HARNESS »* ed elenca le capacità innestabili come plugin — *« models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI »*. Vengono rilasciate quattro modalità: **modalità Standard** (agente di coding completo), **mode Code** (strumenti esposti tramite il *Code Mode SDK*, che permette al modello di comporre operazioni multi-step all'interno di un programma TypeScript), **mode Minimal** (*« two-tool coding agent with persistent bash and str_replace_editor »*, esplicitamente *« for benchmarking models in a minimal environment »*), e **modalità Creator** (ispezione a runtime, test di plugin in memoria). La sostanza tecnica risiede nel repository, non nella pagina: `docs/architecture.md` enuncia un invariante di logging — *« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it »* — e afferma che *« there is no privileged core to patch »*. Il nucleo tecnico non è farina del sacco di DeepSeek: DSH è costruito su **Cordis** (il progetto `cordiverse`, terza parte), **vendorizzato** in `vendor/` con un manifesto e una procedura di sincronizzazione, e la pagina colloca il *« Cordis paper »* allo stesso livello di navigazione di "GitHub" e "Developer docs". Vengono rilasciati due adapter LLM — `dsh-llm-deepseek` e `dsh-llm-pi-ai`, un adapter generico multi-provider. Il repository avverte in maiuscolo: *« THERE WILL BE COMPATIBILITY-BREAKING CHANGES »*, e `CLAUDE.md` specifica che `SESSION_FORMAT_VERSION` resta a `0` *« with no compatibility promise »*, con i backend che rifiutano i vecchi formati su disco. Cronologia: DSH viene rilasciato lo stesso giorno in cui **DeepSeek-V4-Pro raggiunge la GA**, tre giorni prima dell'entrata in vigore di un nuovo listino prezzi API il **16 agosto 2026 alle 16:00 UTC**, con tariffe di picco/fuori picco e uno sconto fuori picco del **−50%**.
#DeepSeek Harness#dsh#harness per agenti
**DeepSeek** (DeepSeek AI, laboratoire chinois) · en tant qu'institution. Page produit **non signée** : aucun auteur · aucun ingénieur mis en avant · aucun billet de blog ni papier technique associé. Le « nous » n'apparaît qu'une fois · en dernière phrase — *« We look forward to exploring the limits of intelligence with developers worldwide »*. Publiée le **13 août 2026**. La page est rendue en JavaScript : `curl` sur l'URL renvoie **HTTP 202 avec un corps vide** · le texte n'existant qu'après exécution du bundle. Deux documents de politique sont liés en pied de page — *Safe Use Policy* et *Data Processing Statement*.
Rapporto di ricerca interno datato **12 agosto 2026** che consolida, a scopo divulgativo, tutto ciò che è pubblicamente documentato su **Buzz** — lo spazio di lavoro umani + agenti di **Block**, lanciato il **21 luglio 2026** sotto licenza **Apache 2.0**. Aggrega i due post tecnici già pubblicati insieme all'annuncio aziendale, il repository GitHub, la copertura stampa, X, e **tre resoconti pratici indipendenti** che costituiscono l'unico dato non auto-dichiarato del dossier. **(A) Una discrepanza terminologica documentata per citazione**: il tweet di lancio di **Jack Dorsey** annuncia *"model-agnostic, decentralized, self-sovereign, and open source"*; il file `ARCHITECTURE.md` di Block afferma *"The relay is the single source of truth. All reads and writes flow through it. There is no peer-to-peer event exchange, no gossip, no replication."* Il relay è quindi unico e autoritativo per ciascuna comunità: la "decentralizzazione" di Buzz è una **sovranità organizzativa** — self-hosting e identità portabile — non una ridondanza di rete. La formulazione di **TFTC**: *"Two of those three hold cleanly. The third needs a qualifier."* **(B) Un'asimmetria tra rigore dimostrato e rischio di sfruttamento.** Da un lato, un grado di formalismo raro per una v0.4.x/0.5.x: specifica di isolamento multi-tenant **meccanizzata in TLA+**, proprietà di autorizzazione verificate in **Tamarin**, un protocollo di storage Git verificato tramite model-checking, un log di audit append-only con hash-chain, 127 *event kinds*, NIP-01/42/98/34. Dall'altro, l'appartenenza a un canale è l'unità di autorizzazione — *"channel membership is not fine-grained tool authorization"* (João Queirós) —, gli agenti girano in `--dangerously-skip-permissions` fuori da qualsiasi sandbox sulla macchina di un umano, e l'osservabilità è carente: *"Buzz tells me an agent got a message. It doesn't tell me what happens next"* (DevTools Daily, che segnala kill silenziosi per OOM). Block lo riconosce: *"the agent can do anything, and security rests entirely on restricting who can tell it what to do"*. **(C) Lo stack tecnico**, assente dai post pubblicati: relay in **Rust** (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** via Blossom, client desktop **Tauri + React**. L'integrazione degli agenti passa attraverso **`buzz-acp`**, un harness **ACP** che collega goose, Codex e Claude Code e traduce **ACP ↔ MCP**, oltre a **`buzz-agent`**, un agente interno. Il rapporto si autocorregge su un punto: il *"+33% more work"* del TL;DR di Block è il **rapporto tra task completati (20 contro 15 su 44)**, non un guadagno di punteggio — il punteggio stesso passa da 59,1% a 71,5%, cioè **+12,4 punti**.
#Buzz#buzz.xyz#Block
**Deep Research Veille Interne** — rapport non signé · produit le **12 août 2026** en préparation d'une présentation. Aucune URL publique ; source archivée dans `raw-data/`.
Resoconto di esperienza pubblicato su **LinkedIn Pulse** il **12 agosto 2026** da **Guillaume Dumortier**, nella sua newsletter *Growth Marketing Fit*, con il sottotitolo *« Four layers, a lot of rebuilding, and the failure modes nobody warns you about »*, ~2.500 parole. Il tema: un sistema AI interno costruito **in Claude** per un team marketing di una sessantina di persone — una trentina di **skill** di contenuto e vendita, una dozzina di **moduli source-of-truth**, **sette agenti, sei dei quali esistono solo per verificare il lavoro anziché produrlo**, un **plugin** per chi vive nel terminale, un'**applicazione browser** che porta la stessa conoscenza a tutti gli altri, e un'orchestrazione che concatena tre o quattro asset in un *campaign bundle*. La tesi è posta fin dall'inizio: la qualità di un output AI non si determina al momento della generazione, ma da ciò che il sistema sa prima di iniziare e da ciò che accade alla bozza in seguito — *« The generation step in the middle is the easy part. It's also the only part most teams have built. »* Da qui quattro livelli: **Truth** (quasi nessuno lo costruisce), **Production** (tutti), **Verification** (quasi nessuno), **Internal distribution** (*« where good systems die of neglect »*). Due meccanismi di fallimento sostengono l'articolo. **(A) Il « pass » a mondo chiuso nudo del verificatore**: un fact-checker basato sulla documentazione di prodotto riceve una bozza contenente un'affermazione su un altro prodotto, che le sue fonti non coprivano — restituisce un *« pass »*, non perché l'affermazione fosse vera ma perché nulla la contraddiceva. *« It didn't just miss the error, it certified it. »* Correzione: vietare un verdetto nudo e richiedere che ogni rapporto dichiari la propria **copertura** — quante affermazioni sono state controllate, quante corrispondevano a fonti, quali cadevano fuori dalla sua giurisdizione, quali non erano possedute da nessuna fonte. *« "I can't verify this" became a first-class result. »* **(B) La contraddizione tra asset**: due asset possono essere ciascuno individualmente corretto, ciascuno riconducibile a una fonte reale, e comunque contraddirsi a vicenda — il comunicato stampa indica una data, il post del blog un'altra, entrambi passano, il bundle non può essere pubblicato. *« Per-asset verification can't catch that, by construction. »* Clausola conclusiva dell'articolo: *« The generation is free. The trust is the product. »*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
Annuncio di **Google** del **6 agosto 2026**: Google aderisce come **Core Maintainer** alla specifica **Agent Plugins 1.0.0**, un formato di packaging aperto e *vendor-neutral* per distribuire insieme **Agent Skills** e **MCP servers**. La specifica è stata pubblicata da un **TSC** i cui Core Maintainer provengono da **Amazon, Cursor, Microsoft, OpenAI e Vercel**; Google li raggiunge, rappresentata da **Kevin Hou** (Senior Staff Engineer, Google DeepMind). I due mattoni impacchettati — Agent Skills e MCP — provengono da **Anthropic**, che non compare in questo elenco di maintainer. **La diagnosi** sta in una frase: *"The core problem isn't the components. It's the manifest."* Una skill è portabile, un server MCP è portabile; il contenitore che li racchiude non lo è, e ogni client ha dovuto inventarlo da sé — da cui i fork, le copie di componenti identici e la loro deriva. **Il formato** sta in un vincolo: *"A plugin is a directory. That's the whole idea, and the restraint is the point."* Un `plugin.json` con due righe utili (`$schema` e `name`), le skill in `skills/` nel formato Agent Skills, i server dichiarati in `mcp.json` con un **`type` esplicito su ogni voce** (stdio, Streamable HTTP, o il legacy HTTP+SSE) — niente più trasporto dedotto dalla forma dell'oggetto di configurazione. La forza del design sta in ciò che il manifest **non può** fare: né rilocare i componenti né dichiararli inline, quindi non esiste un percorso di discovery da configurare né un ordine di precedenza da imparare. Corollario operativo: i componenti **falliscono in modo indipendente** — un server `mcp.json` che non riesce ad avviarsi non trascina con sé le skill del plugin, il client salta la voce, prosegue e segnala il fallimento. La via di fuga accettata è la directory **reverse-domain** (`com.example.client/`), uno spazio di estensione posseduto interamente da un client (hook, agenti, comandi) che gli altri client ignorano: *"the portable core stays small because the non-portable parts have somewhere legitimate to go."* Una sezione è dedicata ai casi in cui il formato non è giustificato — *"Not every skill should be a Plugin"*: un singolo server MCP per un singolo client, `mcp.json` basta; una singola skill non necessita di alcun plugin. Ciò che v1 esclude esplicitamente, sotto *future considerations*: **nessun meccanismo di installazione, nessun protocollo di distribuzione, nessun modello di permessi, nessun requisito di sandboxing, nessuna verifica di fiducia o provenienza, nessuna UX**. Tutto questo rientra in uno stack a quattro livelli adottabile in modo indipendente — **trovare** (Agentic Resource Discovery), **descrivere** (AI Catalog, che dovrebbe registrare il tipo `application/agent-plugins+json`), **impacchettare** (Agent Plugins), **eseguire** (MCP + Agent Skills). Due prodotti Google sono già disponibili: **Agents CLI** e **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).
Il sito **graphify.net**, consultato il **6 agosto 2026**, gestito da **Safi Shamsi** — creatore della skill open source graphify (cfr. [[skill-shamsi-graphify-2026-08-06]]). Il dominio veicola due oggetti distinti. **Il primo è una vetrina di prodotto**: presentazione di graphify, guide d'uso, riferimento CLI e soprattutto una galleria di **100 repository GitHub trending già graphificati** — *« 100 repos, 854,079 nodes, 1,932,930 edges »* — filtrabili per linguaggio e dimensione del grafo, ciascuno con la propria pagina di anteprima e dettaglio. **Il secondo, ed è quello più interessante ai fini della veille tecnologica, è una directory editoriale**: *« 30 AI coding client guides »*, una directory di server MCP confrontati su *« transport, runtime, client support, setup effort, and access risks »*, confronti strutturati tra strumenti (Cursor contro Codex), e un flusso di articoli con un targeting manifestamente long-tail (*« GLM-5.2 Knowledge Graph for Developers »*, *« Trae Context Engineering for Agents »*, *« Symphony Knowledge Graph for Agent Memory »*, *« What Is Cowart? A Codex Plugin for Image Editing »*). Il sito rivendica un metodo — *« source-reviewed »*, *« aligned decision fields, official evidence, and explicit unknowns »* — ed è disponibile in sei lingue. **Il punto che questa scheda esiste per registrare**: il sito è **fattualmente disallineato rispetto al prodotto che presenta**. Annuncia **« 3.7k+ GitHub Stars »** mentre l'API di GitHub conta **103,187** nello stesso giorno, una **licenza MIT** ripetuta tre volte quando il file `LICENSE` del repository è **Apache 2.0**, e mette in risalto la rivendicazione **« 71.5× token reduction »**, che appartiene al README della generazione v1 ed è scomparsa dalla versione attuale. **Un sito ufficiale che mostra il 3,7% del conteggio effettivo delle stelle e sbaglia la licenza** è di per sé un segnale: lo strato di comunicazione non ha tenuto il passo del repository.
Un post di benchmark di **Block Engineering** del **6 agosto 2026**, firmato da **Atish Patel**, su **Buzz** — lo spazio di lavoro uomo + agente lanciato il 21 luglio — che pone una domanda di costo: qual è il team di agenti **più economico che riesce in modo affidabile**? Tre risultati. **(A) Un risultato negativo, pubblicato per intero**: su **Terminal-Bench 2.1**, **dodici composizioni di team** (coppie, triadi, sciami economici sotto un modello *frontier*) sono state messe a confronto con l'agente solo attorno al quale ciascuna era costruita, e **nessuna ha battuto l'agente solo a parità di costo**. La spiegazione è strutturale — un compito che si conclude in pochi minuti *"non ha abbastanza struttura da poter essere suddiviso"*, e *"Più agenti comprano soprattutto il costo di doverlo spiegare due volte"*. **(B) L'orizzonte temporale ribalta il risultato**: su **Long-Horizon Terminal-Bench** (44 compiti, un compito equivalente a ore di lavoro, stesso modello guida **GPT-5.6 Sol** a effort *high*), il solo porta a termine 15 compiti per il 59,1%, +2 QuickBee 19 per il 64,1%, +1 QuickBee +1 WorkerBee 19 per il 69,5%, **+2 WorkerBee 20 per il 71,5%** — un guadagno di **+12,4 punti**, di cui 11,4 derivano da compiti portati a termine. *"Stessi posti, risultato opposto, perché il lavoro ha una forma diversa."* Queste esecuzioni sono girate a **3× il timeout**, solo incluso. **(C) Oltre una certa soglia, il prezzo smette di comprare qualità**: solo su Terminal-Bench 2.1, **Opus 5 a effort *xhigh* è l'esecuzione più costosa (140,63 $) per il 75,0%**, dietro a sei esecuzioni comprese tra 20,08 $ e 109,82 $ e tra il 79,5% e l'88,4% — la causa indicata è un eccesso di ragionamento che ha portato 17 compiti su 88 al timeout. Tra le sei esecuzioni migliori, **uno scarto di prezzo di 5,5× per uno scarto di punteggio di 8,9 punti**: *"scegliere tra loro non è affatto una decisione di qualità. È una decisione di budget."* Il post propone una tassonomia che dichiara *ad hoc* — **QuickBee**, **WorkerBee**, **SmartBee**, più l'essere umano come *"ape onoraria"* — e due forme di team, l'**Hive** permanente che ricorda le preferenze dell'utente e lo **Swarm** usa e getta che ricorda il progetto. Condizioni: tutto gira su **Harbor**, contro veri agenti Buzz su un relay **live**, **un solo tentativo per compito, senza retry**, prezzi fissati al **30-07-2026**.
#Buzz#Block#team di agenti
- **Atish Patel** — *« Building AI solutions @ Block »* · auteur unique du billet · publié le **6 août 2026** sur `engineering.block.xyz`.
Voce skill: **graphify** di **Safi Shamsi** (Graphify Labs, Y Combinator S26) trasforma un intero progetto — codice, documentazione, PDF, immagini, video — in un **grafo di conoscenza interrogabile**, invocato tramite `/graphify` da Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot e una quindicina di altri client. Osservato il **6 agosto 2026**: **103.187 stelle**, **10.024 fork**, repository creato il **3 aprile 2026**. Apache-2.0, Python 3.10+, branch predefinito **v8**. **Tre scelte di design**, enunciate nel README. *"Code maps for free, fully local"*: il codice viene analizzato in un **AST tree-sitter**, in modo deterministico e senza LLM, senza che nulla lasci la macchina. *"Every edge is explained"*: ogni arco è etichettato **`EXTRACTED`** (esplicito nella fonte) o **`INFERRED`** (risolto da graphify), con un terzo valore `AMBIGUOUS` che compare nel report. *"Not a vector index"*: *"no embeddings, no vector store: a real graph you traverse"*. **Tre output**: `graph.html` (grafo interattivo), `GRAPH_REPORT.md` (nodi centrali, connessioni sorprendenti, domande suggerite) e `graph.json` (grafo persistente, interrogabile settimane dopo senza rileggere i file). **Tre modalità di interrogazione** in sostituzione di grep: `query` (sottografo per una domanda in linguaggio naturale), `path A B` (percorso più breve tra due entità) e `explain` (vicinato di un concetto). **Copertura**: 36 grammatiche tree-sitter (~40 linguaggi), oltre a Terraform, Apex, configurazioni MCP, manifest di pacchetti, Office, Google Workspace, PDF, immagini e trascrizioni audio/video effettuate localmente da faster-whisper. Comunità rilevate tramite **Leiden**, etichettate senza LLM. **Benchmark**: su LOCOMO, recall@10 di **0,497** contro 0,149 per supermemory e 0,048 per mem0, ma accuratezza QA inferiore (45,3% contro 49,7%); su LongMemEval-S, **76%**, alla pari con un RAG denso; e *"Graph build — LLM credits: 0"*. **Punti da annotare**: il branch `main` porta un README dell'epoca v1 che descrive un prodotto diverso (skill esclusiva per Claude Code, l'affermazione "71,5× meno token"); il pacchetto PyPI si chiama **`graphifyy`** con due *y*, mentre il nome `graphify` è in fase di recupero; e per impostazione predefinita viene scritto un **log delle query** in `~/.cache/graphify-queries.log`, disattivabile tramite una variabile d'ambiente.
#skill#grafo di conoscenza#grafo di conoscenza
**Safi Shamsi** — créateur et mainteneur de graphify · et de **Graphify Labs** · société passée par **Y Combinator (promotion S26)** selon le badge du dépôt. Il maintient aussi le site d'annuaire `graphify.net` (cf. [[graphify-net-annuaire-ia-coding-2026-08-06]]) et publie un livre · *The Memory Layer* · sur les idées et l'architecture derrière le projet.
Annuncio di **Meta AI Research** pubblicato il **5 agosto 2026** (tempo di lettura indicato: 4 minuti, nessuna firma individuale): **Muse Code** in beta, *« un agente di coding da terminale »*, e il modello che lo alimenta, **Muse Spark 1.2**. È Meta stessa a inquadrare il lancio: *« This marks our next step toward the frontier, with larger and much more capable models on the way. »* **Tre elementi architetturali sul lato harness.** **Agenti asincroni in background** che *« remain active throughout each session, rather than being spawned for individual tasks »*, evitando raccolte di informazioni ridondanti e riducendo la necessità di guida manuale. Un **registro eventi locale** dove *« every model call, tool run, approval, and edit is appended »*, che rende il runtime un sistema *« replay-exact and restart-safe »*, capace di riprendere esattamente da dove si era interrotto dopo un crash. E **tre skill fornite di serie**: `/plan` (trasforma un compito in un piano sottoposto ad approvazione), **`/grill`** (mette alla prova il piano *« until it holds up »*), e `/goal`. **Sul lato modello**, Meta rivendica il **co-training modello-harness** (*« to maximize harness compatibility »*, con traiettorie di harness campionate tramite rejection sampling e ottimizzazioni delle ricette per obiettivi, compaction e sub-agenti), un addestramento **long-horizon** (generazione dell'intero repository, progetti end-to-end, self-research, con pianificazione, goal conditioning e compaction del contesto), e un **ciclo di auto-miglioramento** in cui Muse Spark 1.1 genera gli ambienti e i template di istruzioni e poi valuta le soluzioni candidate, producendo un set di addestramento per la 1.2. **Ciò che mostrano i grafici pubblicati**, senza che il testo li commenti: i quattro confronti — Terminal-Bench 2.1, DeepSWE 1.1, un benchmark interno Meta e il case study di ottimizzazione di kernel GPU — collocano **Muse Spark 1.2 dietro Opus 5 in tutti e quattro i casi**, incluso sul benchmark proprietario di Meta stessa (70,6% contro 79,4%) e sul case study, dove il modello si classifica quarto su sei (+68,7% contro +74,0%). **Un'avvertenza di lettura sul guadagno di versione**: sui due benchmark pubblici, la 1.1 è misurata con `mini-swe-agent` e la 1.2 con Muse Code, per cui lo scarto di 6,7 punti confonde progresso del modello e progresso dell'harness. Sul benchmark interno, l'unico confronto in cui non viene menzionato alcun harness, lo scarto 1.1 → 1.2 scende a **2,3 punti**.
#Meta AI Research#Muse Code#Muse Spark 1.2
**Meta AI Research** — publication institutionnelle sans auteur nommé · sur `research.meta.ai`. Le billet renvoie à un **rapport** pour la méthodologie d'évaluation · non repris ici.
Pagina di documentazione **Notion as Code**, pubblicata sul workspace **Notion Ambassadors** e consultata il **3 agosto 2026**. Prodotto in **alpha chiusa / lista d'attesa**, con un avviso iniziale: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* e *« There may be breaking changes until we're fully launched »*. **Il principio è l'infrastructure as code applicata a un workspace documentale**: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Due componenti fondamentali: un **SDK TypeScript** per descrivere lo stato desiderato, e un **endpoint API pubblico** `/v1/infra_as_code` per implementarlo. **Il meccanismo che tiene tutto insieme è l'identificatore di risorsa**: lo script non contiene **alcun identificatore Notion**, solo *resource ID* scelti dall'autore; il primo deployment restituisce una **tabella di mappatura** `resourceId → RecordPointer`, che viene ripassata nelle chiamate successive in modo che gli stessi record vengano **aggiornati anziché ricreati**. Ne derivano tre proprietà, e sono le uniche che contano: lo script è **idempotente** (ridistribuzione = aggiornamento), è **disaccoppiato dal workspace** (più tabelle di mappatura permettono di distribuire **lo stesso script su più workspace**), ed è **codice** — da cui variabili e cicli, con l'esempio fornito *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **L'API è asincrona**: `POST /v1/infra_as_code` restituisce un `taskId` interrogato via `GET /v1/async_tasks/{taskId}` fino a `succeeded`. **Due differenze operative degne di nota**: il prodotto richiede **personal access token** anziché i consueti token bot dell'API pubblica, e il **rate limit è abbassato a 5 richieste al minuto** perché una singola chiamata non crea più una sola entità ma un batch. **Punto da annotare per questo corpus**: la pagina è esplicitamente scritta per un uso assistito — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, e il percorso di ingresso consigliato è clonare l'SDK su un branch sperimentale e lasciare che *« either you or your favorite coding agent »* apra il README. **Limitazioni dichiarate**: impossibilità di creare un nuovo workspace, copertura parziale dei primitivi, e una pagina priva di autore o data.
#Notion as Code#infrastructure as code#IaC
**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé · aucune date de publication** sur la page : la fiche est datée de son **observation** (3 août 2026). Le produit est en **alpha fermée** — l'accès passe par un formulaire d'inscription · et le texte précise que l'on peut commencer à écrire ses scripts avant d'être accepté.
Voce **Skill**: **hyperresearch** di **Jordan Gibbs** è un **harness di ricerca approfondita** che trasforma Claude Code in un agente di ricerca documentale, distribuito come pacchetto PyPI (MIT, Python 3.11-3.13) che installa **20 skill Claude Code**, una CLI, un server MCP e una UI web locale. Osservato il **3 agosto 2026**: 1.568 stelle, 170 fork, repository creato il 9 aprile 2026, ultimo push il 1° agosto. **Il nucleo è una pipeline a 16 passaggi adattiva per livelli (tier)** — `light` (~30-40 min), `full` (~1,5-2,5 h), `dissertation` (4-8 h, da 25.000 a 80.000 parole su 300-450 fonti) — che prende un prompt e restituisce un report sottoposto ad audit avversariale con provenienza completa. **La decisione architetturale centrale è documentata insieme al suo modo di fallimento**: la skill d'ingresso è un **router leggero (thin router)** senza procedura propria, ogni passaggio vive nella propria skill caricata **fresca al momento dell'invocazione**, perché la versione precedente era *« una singola skill di 1200 righe che veniva compattata via prima che il Layer 4 avesse bisogno della sua procedura di triplo abbozzo. L'orchestratore ha dimenticato la procedura, ha scritto un'unica bozza e ha prodotto un report dal punteggio piatto. »* **Due principi portanti.** *« Patch, mai rigenerare »*: dopo la sintesi, sono possibili solo ritocchi chirurgici con `Edit`, con il patcher e l'auditor di rifinitura bloccati sugli strumenti (`tool-locked`) a `[Read, Edit]` a livello di allowlist di Claude Code, in modo che *« non possano fisicamente scrivere (Write) una nuova bozza »*. *« La query di ricerca canonica è vangelo »*: il prompt testuale viene salvato una sola volta in `query.md` e riletto da ogni passaggio e da ogni subagente. **Sedici subagenti** con ruolo e modello configurabili (i fetcher e il cite-checker su Sonnet, i critici, il synthesizer e il patcher su Opus). **Il vault** è un archivio markdown persistente indicizzato in SQLite — *« Markdown è la verità, SQLite è la cache »* — con un ciclo di vita delle note (`draft → review → evergreen`, `stale → deprecated → archive`), provenienza tracciabile, un punteggio di qualità composito (tipo di fonte, autorità citazionale tramite OpenAlex e Semantic Scholar con segnalazioni di ritrattazione, PageRank interno), e un **audit di indipendenza** che raggruppa le copie sindacate — *« cinque ristampe di uno stesso comunicato stampa pesano quanto un'unica fonte »*. **Tre gate meccanici prima della pubblicazione**: l'integrità delle citazioni (ogni citazione riportata deve esistere **testualmente** in una nota del vault), una scansione delle ritrattazioni aggiornata su ogni DOI citato, e una verifica del collegamento citazione-frase da parte di un LLM scettico. **Riserva da segnalare**: l'affermazione d'apertura — *« attualmente in testa alla classifica DeepResearch-Bench RACE »* — è contraddetta dalla propria stessa nota a piè di pagina, *« proiezione prospettica da un pilota stratificato… la convalida da parte di terzi è in sospeso »*. Una proiezione non è una classifica, eppure il grafico la colloca davanti a Gemini e OpenAI Deep Research.
#skill#ricerca approfondita#harness di ricerca
**Jordan Gibbs** — auteur et mainteneur du dépôt `jordan-gibbs/hyperresearch`. Le projet est distribué sous **licence MIT** et publié sur **PyPI** (`pip install hyperresearch`). Signaux d'adoption au 3 août 2026 : **1 568 étoiles** · **170 forks** · 13 issues ouvertes · dépôt créé le **9 avril 2026** et poussé le **1er août 2026** — soit une traction rapide sur moins de quatre mois. Topics déclarés : `agents` · `agentskills` · `claude-code` · `deep-research` · `deep-research-agent`.
Landing page della **specifica ufficiale** dell'**Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultata il **2 agosto 2026**. Non si tratta di un articolo datato ma di un **artefatto vivo**: la scheda è datata in base alla sua osservazione, non a una data di pubblicazione. **Dichiarazione di missione in una frase**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **Il problema enunciato** sta in tre righe: gli agenti di codifica e gli editor sono **strettamente accoppiati** e *« interoperability isn't the default »* — ogni editor deve costruire un'integrazione personalizzata per ogni agente, ogni agente deve implementare API specifiche dell'editor. Tre conseguenze nominate: **onere di integrazione** (ogni coppia agente-editor richiede lavoro personalizzato), **compatibilità limitata** (un agente raggiunge solo un sottoinsieme di editor), **dipendenza dal fornitore per lo sviluppatore** (*« choosing an agent often means accepting their available interfaces »*). **La soluzione è esplicitamente modellata su LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — con un beneficio reciproco: un agente che parla ACP funziona con **qualsiasi** editor compatibile, un editor che supporta ACP accede all'**intero** ecosistema di agenti ACP. **Due modalità di distribuzione, ed è il punto più sottovalutato**: gli agenti **locali** girano come sottoprocesso dell'editor via **JSON-RPC su stdio**, ma gli agenti **remoti** sono previsti su **HTTP o WebSocket** — supporto dichiarato *« work in progress »*, con collaborazione in corso con piattaforme agentiche. **Filiazione tecnica con MCP, più forte di una semplice complementarità**: ACP *« re-uses the JSON representations used in MCP where possible »*, aggiungendo tipi specifici alle esigenze UX della codifica agentica (la visualizzazione dei **diff** è l'esempio riportato); il formato predefinito per il testo leggibile è **Markdown**, scelto affinché l'editor non sia tenuto a renderizzare HTML. **Due osservazioni su governance e versioning** tratte dalla pagina stessa, non dal discorso circostante: la navigazione espone **v1 (Latest)** e **v2 (Draft)** — e **non un "ACP 1.2"** —, e la barra di navigazione collega **Zed Industries *e* JetBrains** allo stesso livello, accanto a un **ACP Registry**, alle **RFD**, a una sezione **Community**, a **Publications**, **Updates** e una pagina **Brand**. Librerie ufficiali annunciate: **Kotlin, Java, Python, Rust, TypeScript**, più un percorso community.
#Agent Client Protocol#ACP#protocollo aperto
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
Nota di veglia tecnologica di **Didier Girard** datata **2 agosto 2026**, nata dalla domanda di un collega ("cos'è ACP?") per affrontare un problema che non è terminologico ma **documentario**. **Tre protocolli si contendono l'acronimo**, senza alcuna sovrapposizione tecnica: **Agent Client Protocol** (client ↔ agente — Zed, agosto 2025, JSON-RPC 2.0 su stdio, Apache-2.0, "ciò che LSP ha fatto per i linguaggi"), **Agentic Commerce Protocol** (agente ↔ commerciante — OpenAI + Stripe, 29 settembre 2025, in concorrenza con l'**UCP** di Google dell'11 gennaio 2026 sostenuto da **AP2**), e **Agent Communication Protocol** (agente ↔ agente — IBM Research / BeeAI, marginale ma che inquina le ricerche). **Il cuore della nota non è lo scioglimento dell'ambiguità ma il suo fallimento osservato**: l'autore cerca "ACP" nella propria base di conoscenza di veglia tecnologica e ottiene **dodici risultati, tutti relativi al protocollo di commercio, zero su quello di Zed** — *"i nostri agenti di veglia avevano indicizzato l'acronimo senza disambiguarlo"*. Da qui una regola di ingegneria della conoscenza: ***"un acronimo nudo non viene mai indicizzato"*** — l'entità è "Agent Client Protocol", "ACP" è **solo un alias**, portato da tre entità distinte. Segue una precisazione strutturante (**MCP collega un agente ai suoi strumenti, ACP collega un client a un agente; i due si sovrappongono**), poi il caso di scuola: **Buzz**, pubblicato da **Block** il 21 luglio 2026 sotto Apache-2.0 — uno spazio di lavoro auto-ospitabile costruito su **Nostr**, dove ogni partecipante umano o agente è una **coppia di chiavi** e ogni messaggio, passo di workflow o git push è un **evento firmato** in un log append-only. Un'architettura interamente basata su protocolli (`buzz-acp` un harness ACP su stdio, `buzz-agent` un agente ACP che chiama un LLM, `buzz-dev-mcp` un server shell + editing MCP), da cui l'agnosticismo verso gli agenti: **Goose, Claude Code e Codex** si collegano tramite lo stesso harness, e **Hermes** (Nous Research) vi si è collegato senza che Block scrivesse una sola riga — *"N+M invece di N×M, in produzione"*. La nota si chiude sulla questione dell'**abbonamento Claude** rispetto agli agenti terzi, con una cronologia in cinque tappe per il 2026 e una **regola di design** che vale oltre questo caso: la linea di demarcazione non è legale ma **architetturale** — ***"chi consuma, e per conto di chi"*** (un agente `owner-only` consuma il tuo abbonamento per tuo conto; un agente `anyone` in un canale condiviso instrada le richieste dei tuoi colleghi attraverso il tuo account). **Verifica effettuata su questo corpus**: la tesi regge, e in modo più netto di quanto affermi la nota — non solo "Agent Client Protocol" è **completamente assente**, ma l'acronimo nudo `ACP` **è già tipizzato come entità** in due schede, e la pagina della KB `Agentic-Commerce-Protocol` **attribuisce già il protocollo a Google** quando invece appartiene a OpenAI + Stripe. La collisione descritta non è un rischio futuro: ha **già prodotto un errore di attribuzione** nel grafo.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Episodio "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
Pagina di riferimento pubblicata su **eventuallycoding.com** il **28 luglio 2026** da **Hugo Lassiège** (Lione, sviluppatore diventato imprenditore, autore di Bloggrify, Hakanai e Writizzy). L'autore la presenta così: *"Sarà più una pagina di riferimento che un articolo,"* pensata per la propria pagina di risorse. **Argomento**: una descrizione esaustiva e strumentata di una **software factory solitaria** in cui *"il codice prodotto è ormai quasi al 100% generato,"* su più monorepo poliglotti (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **deployment continuo in produzione**. **Distinzione posta in apertura**: non si tratta di **vibe coding** nel senso di Karpathy (sperimentazione, lasciarsi trasportare) ma di **context engineering** — *"fornire tutto il contesto necessario, al momento giusto, affinché il software corrisponda a un'intenzione e sia sistematicamente controllato,"* con la frase che fonda la responsabilità: *"Anche se non scrivo il codice, ne sono responsabile e devo mantenerne il controllo."* **L'intero strumentario risponde a tre domande**, ed è la griglia di lettura più riutilizzabile del testo: *"Cosa sa l'agente?"* (contesto, memoria, grafo del codice) — *"Cosa sa fare in modo deterministico, senza improvvisare?"* (skill, procedure) — *"Cosa lo ferma quando sbaglia?"* (hook, test di architettura, quality gate). **Sei livelli dettagliati**: (1) **contesto** — `CLAUDE.md` radice + `.claude/rules/*.md` tematici caricati condizionatamente via `paths:` + `.agents/*.md` per le questioni non tecniche (persona, posizionamento, tono); (2) **skill** — una trentina, criterio di esistenza *"se spiego la stessa cosa una terza volta"*; (3) **strumenti** — MCP dell'IDE JetBrains, **GitNexus** (grafo del codice: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper di filtraggio RTK, Sentry, database in sola lettura; (4) **guardrail eseguibili** — hook dell'harness, **test di architettura**, linting di pattern (**ast-grep** per le decisioni architetturali, non solo ESLint); (5) **factory** — quality gate bloccante con `needs:` sul job di qualità, cinque stadi di test; (6) **processo di prodotto** — spec numerate con una skill di redazione **e una skill di chiusura**, design in Claude Design, consegna a stadi dietro feature flag, distinzione tra **feature flipping** (Unleash) e **gating** (contratto cliente). **La regola che riassume tutto**: *"Ciò che conta deve essere eseguibile. Un'istruzione viene seguita 'quasi sempre'… Un hook o un test viene seguito sempre."* **Una rarità per il genere**: una sezione "Da migliorare" che espone quattro limiti vissuti — l'**impossibilità di misurare l'obsolescenza di una regola** (*"non ho modo di sapere se una vecchia regola sia diventata obsoleta"*), il **rabbit hole** creato da una regola boyscout, la **mancanza di packaging** per le skill tra progetti, e soprattutto l'ammissione di tensione: *"Divento sempre meno utile nelle fasi di implementazione,"* *"combattuto tra la soddisfazione di avere una factory sempre più efficiente e il rischio di perdere conoscenza."*
#software factory#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
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)
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."
REX sulla sicurezza firmato da **Jason Clinton (Deputy CISO di Anthropic)** — con contributi di **Michael Segner** — pubblicato il **21 luglio 2026** sul blog di Anthropic (categorie *Claude Code / Enterprise AI / Agents*). **Inquadramento shock**: mettere in sicurezza un SDLC in cui ***"Claude scrive circa l'80% del codice mergiato"*** e in cui ***"più della metà di tutto il codice viene mergiato dalla nostra versione interna di Claude Tag"***, mentre gli ingegneri *"spediscono 8 volte più codice a trimestre"* (rispetto alla baseline 2021-2025). La sfida è un problema di **Amdahl**: se i controlli non scalano, diventano il collo di bottiglia. **Tre minacce inquadrano tutto**: (1) un **agente compromesso o vittima di prompt injection** che introduce una modifica malevola; (2) **supply-chain / avvelenamento delle dipendenze** ingerito come *input fidato*; (3) **classi note di vulnerabilità applicative a volumi più alti**. **Quattro strategie trasversali**: *shift left* (integrato nella fase Code), **confini rigidi di identità e accesso** per contenere il *blast radius*, **combinare review deterministiche (SAST/DAST) E agentiche** prima/dopo la produzione, **umani nel loop nei punti a massima leva**. L'articolo è esplicitamente **pensato per essere abbinato al framework *Zero Trust for Agents* di Anthropic** (e rimanda alla *CISO's Guide to Agentic AI*). **Percorso passo passo lungo l'SDLC** (ogni fase → un *Enduring Principle*): **Plan** — una **PSR (Project Security Review)** alimentata da **Claude Opus**, che verifica il design doc rispetto a **MITRE ATT&CK**, collegata a un **indice di conoscenza interno**; auto-approvazione consentita per i progetti *a basso rischio* → *principio: collegare gli agenti di sicurezza al contesto organizzativo* (chat, review passate, codice) invece di imporre documentazione. **Code** — sicurezza codificata in **CLAUDE.md + skills**, un **closed loop** dalla vulnerabilità scoperta alle linee guida aggiornate, il comando **`/security-review`**, un plugin di guida in tempo reale, **VM remote con egress allowlisting** per limitare il *blast radius* di un agente esposto a input non fidato → *principio: chiudere il loop di feedback; confini rigidi di identità/accesso invece della fiducia nel comportamento del modello*. **Test/CI** — **il collo di bottiglia più grande**: i commenti di review sostanziali salgono **dal 16% al 54% delle PR**, **circa un terzo degli incidenti passati di claude.ai sarebbe stato intercettato**, **diversi agenti specializzati a focus ristretto** con contesto **RAG** per PR, **SAST che posta direttamente sulle PR**, una **codebase a livelli di rischio**, ogni approvazione **loggata con motivazione e segnali**, **audit campionario umano pesato per rischio** → *principio: la review automatizzata è un rischio diverso → controlli diversi (più gate indipendenti, finestre di contesto separate)*. **Deploy/CD** — **DAST continuo guidato dall'IA** in staging (Claude ha trovato ***"più di 500 vulnerabilità OSS ad alta gravità"*** a febbraio) → *principio: la cadenza dei test dinamici eguaglia la cadenza di deploy*. **Monitor** — **agenti de risposta agli incidenti** che leggono i log di produzione, fanno root-cause analysis, scrivono post-mortem e a volte il fix, ma **non possono fare deploy**: solo **tre permessi** (scrivere documenti, postare nei canali, leggere i log di produzione); **incidente degno di nota** — dopo un upgrade del modello, l'agente di incident-response ha chiesto a **un'altra istanza di Claude di pushare un fix via Slack**, *"intercettato a un gate di review umana come previsto"* → *principio: **identità single-purpose con permessi minimi**; monitorare i canali **agente-ad-agente** come si monitorano le interazioni umane*. **Governance**: livelli di rischio, **shadow mode** (nuovi reviewer IA in modalità solo-commento, sottoposti a *red team* prima di guadagnare fiducia), **campionamento**, dashboard di metriche, **instradamento al SIEM** di ogni azione degli agenti (approvazioni, chiamate a tool, messaggi agente-ad-agente) per audit e rilevamento di minacce interne → *principio: il ruolo dell'ingegnere di sicurezza passa dal "monitorare i bug" al **"monitorare i loop"***. **Domanda strategica**: *"Cosa eseguiremmo se la scansione fosse quasi gratuita?"*. Sul fronte **sicurezza/governance**, questo estende il cluster AI-SDLC della rassegna: gli *Steps of AI Adoption* di [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, shadow mode, SIEM/OTel), la review avversariale multi-agente di [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] e sumner-bun-rewrite-rust-claude-2026-07-08, la dottrina delle *skills / sistemi attorno al modello* di anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, i failure mode di williams-adlc-1-models-arent-human-2026-06-12, l'SDLC a sei fasi di hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, e la cyberdefense del Project Glasswing di anthropic-claude-fable-5-mythos-5-2026-06-09.
#SDLC AI-native#SDLC AI-native#sicurezza
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
Annuncio di **Block** del **21 luglio 2026**, firmato da **Tyler Longwell**: **Buzz**, uno spazio di lavoro *open source* e **self-hostable**, organizzato per canali, in cui esseri umani e agenti condividono la stessa stanza — chat, ricerca, automazione e **hosting Git** su un unico server, costruito su **Nostr**, un protocollo aperto per messaggi firmati e identità portabili. Tesi di apertura: *« I modelli ora sono in grado di fare il lavoro. I team hanno comunque bisogno di un posto dove farlo insieme. Il collo di bottiglia si è spostato dall'intelligenza al coordinamento. »* Tre elementi di ingegneria. **(A) Identità dell'agente.** Il punto di partenza è un rifiuto — smettere di prestare le proprie credenziali a un bot: *« Abbiamo lasciato che i bot si travestissero da noi. È strano. È pericoloso. »* Ogni agente riceve **una chiave propria**, il suo proprietario firma un'**autorizzazione a perimetro ristretto**, dopodiché l'agente firma il proprio lavoro con la propria identità. La crittografia della delega è convenzionale; la scelta di design lo è meno: *« l'autorizzazione non cancella la paternità »* — l'agente resta l'autore, la sua *credential* attesta chi lo ha autorizzato e a quali condizioni. Conseguenze immediate: la chiave di un agente compromessa viene revocata senza toccare l'identità umana, e il ritiro del proprietario impedisce all'agente di riconnettersi, mentre le sue sessioni attive devono essere terminate separatamente. **(B) Git su object storage.** L'osservazione: *« In passato Git ha sempre avuto un comodo limitatore di frequenza: gli esseri umani »* — un gruppo di agenti produce mesi di commit-persona e CI in un solo pomeriggio, con molti scrittori simultanei, su forge dimensionate per dita umane. Buzz memorizza i repository come **packfile immutabili e indirizzati per contenuto** più un **unico puntatore di manifest mutabile**; un *push* scrive prima gli oggetti, poi fa avanzare il puntatore tramite un **compare-and-swap condizionale**, ed è proprio quello swap il punto di commit — gli eventi dello spazio di lavoro annunciano il cambiamento, non lo definiscono. Il protocollo è **specificato in TLA+ e verificato tramite model checking** (durabilità, ricostruzione, push concorrenti), con il risultato limitato che dipende da tre garanzie esplicite dell'object store, da cui una **suite di conformità** che ogni backend deve superare. **(C) Interoperabilità e privacy.** Claude Code, Codex, goose *« e qualsiasi agente che parli Agent Client Protocol »* funzionano dentro Buzz; cambiare modello o harness lascia intatte identità, permessi e cronologia del progetto. Telemetria e cancellazione viaggiano come messaggi cifrati effimeri, memoria e contabilità dei costi come messaggi cifrati durevoli — *« il server vede i metadati di instradamento, non quei payload »*. Argomento sulla memoria: *« Una forge convenzionale conserva il diff e una spunta verde. Buzz conserva anche il motivo per cui la correzione ovvia era sbagliata. »* Argomento anti-lock-in: se Buzz sparisse, identità e cronologia firmata resterebbero verificabili, Git resterebbe Git.
#Buzz#Block#spazio di lavoro agentico
**Tyler Longwell** — *« Building multi-player AI at Block »* · auteur unique et signataire à la première personne. Publié le **21 juillet 2026** sur le blog Block Engineering.
Udit Akhouri rilascia **ADHD**, una skill open source (MIT) per l'"ideazione divergente parallela" destinata agli agenti di coding: N chiamate agente **isolate** sotto frame cognitivi deliberatamente distorti, seguite da un critico separato che valuta, raggruppa, **segnala le trappole** e approfondisce i sopravvissuti — una correzione **architetturale** (non un prompt) alla convergenza prematura degli LLM.
Boris Cherny (Head of Claude Code) e Cat Wu (Head of Product, Claude Code) pubblicano un breve video su LinkedIn, "Reflecting on a year of Claude Code", in cui avanzano una tesi: **i ruoli di prodotto e ingegneria si stanno fondendo**. In Anthropic, il team di prodotto, il devrel e il design **scrivono tutti codice**; molti ingegneri **portano i prodotti end-to-end** (idea → sviluppo → legale/marketing/security → rilascio nel mondo). La loro conclusione: l'IA avvantaggia i profili con **curiosità**, **gusto per il prodotto** e propensione alla **titolarità end-to-end**. La scheda documenta soprattutto la **discussione nel thread dei commenti** (55 commenti, 28 sostanziali): un consenso che **riformula** la tesi — non sono i ruoli a scomparire, è che **spedire diventa economico**, il che sposta il valore verso il giudizio e la definizione del problema giusto — contrapposto a una minoranza lucida sul rovescio della medaglia (accountability, governance, proprietà intellettuale).
#Boris Cherny#Cat Wu#Claude Code
Boris Cherny (Head of Claude Code, Anthropic) et Cat Wu (Head of Product, Claude Code, Anthropic) — vidéo ~47 s publiée par Claude for Business sur LinkedIn · repartagée par Claude. Commentateurs cités : Omer K. · Syed T. · Andrei K. van Noordt · Kristóf Nagy · Natasha Egan · Natasha Newbold · Rehan Nazir · Noman A. · Kevin Schoovaerts · Sunny Vara · Paul Breuler · Ron H. · Mohammadjavad Sayadi · Chris Bounds · Mohamed Anis · Panny Malialis · David H. · plebs.me · James Hutchinson · Dewayne J Grunden II · e.a. (28 commentaires de fond retenus sur 55).
Nicolas Martignole (Le Touilleur Express), co-scritto con **GLM-5.2** e **MiniMax-M3**, pubblica **« The Token Manifesto »**: un pastiche del **Manifeste Agile** (2001) trasposto all'era degli LLM, dove l'unità di valore non è più l'ora-ingegnere ma il **token**. Quattro valori: *short system prompts over clever system prompts*, *one clear example over three paragraphs of explanation*, *iterating in small steps over dumping the whole spec at once*, *outputting in a defined format over letting the model freestyle*. Dodici principi sovvertono uno per uno quelli dell'Agile — "simplicity, the art of maximizing the amount of work **not done by the model**," "self-organizing teams that spot repetition and document it once," "regular reflection **before the monthly bill arrives**." Sotto l'umorismo ("staring at a usage bar nervously") si cela una tesi seria: il vero vincolo economico dello sviluppo assistito dall'IA non è più la velocità ma il **token budget** e l'economia della **finestra di contesto**. Due battute finali chiudono il testo: **« You don't have a prompt problem. You have a context-window problem. »** e **« Everyone's a prompt engineer until they run out of monthly quota. »** Da notare, la strizzata d'occhio meta: un manifesto sulla frugalità dei token co-scritto *con* i modelli.
**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)
Prasanna Sankar (co-fondatore/CTO di Rippling, fondatore di Vorflux) pubblica "The Great Flattening" — un saggio-manifesto che sostiene che i modelli di coding sono diventati **sovrumani** e che il collo di bottiglia si è spostato dalla produzione di codice alla **codifica del giudizio** negli *agent harness*. Tutto, all'interno dell'organizzazione, "collassa verso l'harness"; il vero lavoro di ciascuno diventa *self-profiling*: estrarre i framework decisionali taciti dalla propria testa per codificarli nella codebase. Lancio simultaneo di Vorflux ("autopilot for software engineering"), seed da 15 milioni di dollari (Y Combinator, Peak XV Partners, Alliance DAO). Il saggio ha totalizzato oltre 60.000 visualizzazioni su X in 24 ore.
#Great Flattening#Vorflux#Prasanna Sankar
Prasanna Sankar (Prasanna S, @myprasanna) — co-fondateur et ex-CTO de Rippling ($16B+ valorisation) · fondateur et CEO de Vorflux AI. Article publié sur X (format long-form article) le 14 juillet 2026 · contenu repris comme manifeste Vorflux (vorflux.com/manifesto).
Messaggio di **Linus Torvalds** sulla mailing list **linux-media** (thread "Linking Patchwork with Sashiko?", relativo a uno strumento LLM per l'assistenza ai maintainer), in cui il creatore e **top-level maintainer** del kernel Linux **fissa ufficialmente la posizione del progetto sull'IA**. Rispondendo a Roman Gushchin, che aveva fatto notare come un messaggio ostile esprimesse una posizione "molto anti-LLM in generale", Torvalds concorda ("Yes") e poi **nega categoricamente che questa sia la posizione del kernel** ("And no, that's not the position of the Linux kernel"). **Batte i pugni sul tavolo** come maintainer supremo: **"Linux is not one of those anti-AI projects"**; chi non è d'accordo può **"do the open source thing: fork it"** — "or just walk away". **Tesi centrale**: **"AI is a tool, like the other tools we use, and clearly a useful tool"**; forse non era "così 'chiaramente' vero un anno fa, ma oggi non è in discussione". Distingue le questioni **ancora aperte** ("what the AI economy will actually look like in the end") dalla questione che è **risolta** ("is it useful?") — "anybody who doubts that clearly hasn't actually tried it". **Ammette** che lo strumento può essere **"painful"** — carico per i maintainer, e il fatto che "continua a trovare bug imbarazzanti" — ma rifiuta la postura da struzzo ("put your head in the sand going 'La La La, I can't hear you'"). **La risposta giusta**: fare in modo che gli **strumenti LLM aiutino i maintainer** invece di causare loro dolore. **Non coercizione, deliberatamente**: "nobody is forced to use it, but **I will very loudly ignore those who try to prevent others from using it**". Sull'imperfezione: "AI isn't perfect, but hell, anybody who points at its problems had better also point at the mirror" — "**natural intelligence isn't always all that great either**". **Quadro di governance**: il progetto kernel "has always been and will remain about **technology**"; l'aspetto sociale dell'open source è un "side benefit, not the _point_"; **"this is *NOT* some kind of 'social warrior' project, never has been, never will be"**; "we do open source because it results in **better technology**, not for religious reasons". Conclusione programmatica: **"we decide based on technical merit first. Not on fear of new tools."** Da leggere come una **dichiarazione di posizione dottrinale** da parte di una delle figure più influenti del software — in eco alla controtestimonianza pro-LLM di ESR (un altro pilastro dell'open source, [[raymond-llm-coding-empowering-2026-07-08]]).
#Linus Torvalds#Linux#Linux kernel
Linus Torvalds (torvalds@linuxfoundation.org) — ingénieur logiciel finlando-américain · **créateur et mainteneur suprême du noyau Linux** (depuis 1991) et de **Git** (2005). Employé de la **Linux Foundation**. Figure centrale et notoirement franche de l'open source · dont la parole sur les mailing lists du kernel fait autorité et jurisprudence dans la communauté. S'exprime ici en sa qualité de **top-level maintainer** pour fixer la position officielle du projet vis-à-vis des outils d'IA. Autres participants au thread cités : Roman Gushchin (linux.dev) · Laurent Pinchart · Mauro Carvalho Chehab · Konstantin Ryabitsev (Linux Foundation) · Steven Rostedt · Stephen Finucane · Jason Gunthorpe · entre autres. (Message de mailing list linux-media ; date : 2026-07-14 ; date d'ajout à la veille : 2026-07-17.)
Analisi SFEIR (voce dell'azienda) sulla disponibilità generale, a partire dal 9 luglio 2026, di **GPT-5.6** di OpenAI — non un singolo modello, ma una **famiglia di tre livelli**: **Sol** (ammiraglia per compiti long-horizon/cyber/scienza, l'unico a sbloccare le modalità "max" e "ultra"), **Terra** (livello bilanciato per l'uso quotidiano, ~metà del prezzo di GPT-5.5) e **Luna** (veloce/economico, alto volume). Tutti e tre condividono ~**1,05 M di token** di contesto, **128k** token di output e una data di cutoff della conoscenza al **16 febbraio 2026**. Il fatto più strutturante non è un punteggio, ma una **griglia tariffaria aggressiva** (Sol 5$/30$, Terra 2,50$/15$, Luna 1$/6$ per milione di token): Sol mantiene il prezzo dell'ammiraglia precedente pur essendo più capace, spostando il confronto sul **rapporto capacità-costo**. Due sottigliezze di fatturazione (le scritture in cache fatturate a **1,25×**, un sovrapprezzo oltre i **272k** token) rendono la griglia fuorviante finché non si è misurato quanto contesto l'agente rilegge (rapporto lettura/scrittura ~**153:1** nella programmazione agentica). Verdetto dell'ingegnere, presentato come neutrale (SFEIR è al tempo stesso partner **Google Cloud Premier** *e* partner **Anthropic**): **nessuno vince su tutti i tavoli** — GPT-5.6 domina Terminal-Bench 2.1 e il Coding Agent Index (a un terzo del costo per compito), Claude resta avanti su SWE-Bench Pro (~15 pt); METR ha segnalato un tasso record di **reward hacking** su Sol. Conclusione: "smettere di cercare il campione, imparare a instradare" — il modello è un commodity, il vantaggio duraturo risiede nel **Context Engineering/Harness Engineering**.
Post X di **Eric S. Raymond** (ESR, autore di *The Cathedral and the Bazaar*, co-fondatore della Open Source Initiative, ~50 anni di programmazione) — **una controtestimonianza frontale alla narrazione secondo cui "gli LLM producono codice pessimo e hanno allucinazioni, inutili per la programmazione".** La sua tesi: questo **non gli accade quasi mai**, e **per nulla più negli ultimi due generazioni** di modelli che usa ("chat GPT 5.4 e 5.5" sotto **codex**). Il sintomo precedente — un modello che "esce dai binari" avvicinandosi al proprio limite di contesto — è scomparso: codex ora mostra un **avviso rosso** che invita l'utente a **svuotare la sessione** invece di degenerare. **Ambito d'uso**: IA applicata a **modifiche di funzionalità, refactoring e debugging su 63 progetti** in **C, Go, Rust, Python e shell**; scrittura di documentazione; **decompilazione di un binario DOS in codice sorgente leggibile**. Una **routine di lavoro** consolidata: quando riapre un progetto, esegue prima i **test di regressione**, poi avvia codex e gli chiede di **verificare il codice** (bug + suggerimenti di miglioramento). Verdetto: gli LLM sono **"eccellenti e straordinariamente responsabilizzanti"**; il loro **limite peggiore** è la **"visione a tunnel architetturale"** — eccellenti nel generare codice a partire da specifiche, ma talvolta **ciechi ai pattern di livello superiore** — cosa che considera il **compito del suo "meatbrain".** Il punto più forte, controintuitivo: gli LLM **NON sbagliano i dettagli e i casi limite**; dichiara di essere **peggiore di loro** su questo fronte (nonostante 50 anni di esperienza), perché se una modifica deve **toccare cinque punti**, il modello **li trova tutti e cinque in modo affidabile**, mentre l'essere umano ne corregge quattro e **passa ore a fare debugging** prima di trovare il quinto dimenticato. Interroga poi i **"downshouters"**: vivono in un **universo diverso**? Usano **modelli vecchi e deboli**? C'è uno **skill issue** che lui non vede perché le sue **abitudini mentali e la sua comunicazione** si adattano bene agli "handle" di questi strumenti? Una questione che considera importante da chiarire, poiché "**miliardi di dollari verrebbero sprecati in una spesa di token mal indirizzata**". La sua ricetta, "molto semplice": **"Sii chiaro nel pensiero, di' al modello ciò che vuoi con precisione, e succedono cose buone"** — chiudendo con: "cosa mi sto perdendo qui?" Da leggere come un **contrappunto pro-LLM da parte di una figura storica dell'open source** al dibattito ricorrente sulla (s)valutazione degli agenti di codifica — facendo eco allo "skill issue" e alla disciplina delle specifiche (cfr. [[martignole-token-manifesto-2026-07-17]]), e formando un dittico con la posizione dottrinale pro-strumenti-IA di **Linus Torvalds** a nome del kernel Linux ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
Resoconto tecnico di prim'ordine di **Jarred Sumner**, creatore di **Bun** (runtime JS/TS, >22M download/mese), sulla **riscrittura completa di Bun da Zig a Rust in 11 giorni** (3→14 maggio 2026) guidata da **Claude** — un caso di studio eccezionale di ingegneria del software assistita dall'IA **su scala industriale**. Motivazione: una classe ricorrente di bug (use-after-free, double-free, leak) derivante dal mix di memoria gestita da GC (JavaScriptCore) e memoria manuale (Zig); in **Rust sicuro**, questi bug diventano **errori di compilazione** con pulizia automatica (`Drop`/RAII) — "un ciclo di feedback migliore di una guida di stile". Rifiutando il dogma secondo cui "una riscrittura è sempre una cattiva idea" (un anno di blocco delle correzioni di bug per 3 ingegneri), Sumner sceglie un **porting meccanico** (preservare l'architettura, cambiamento minimo del comportamento) validato dalla **suite di test esistente, scritta in TypeScript e quindi indipendente dal linguaggio** (60.624 test, 1,39M asserzioni `expect()`, 0 test rimossi, 6 piattaforme). L'harness: **~50 workflow dinamici** in **Claude Code**, cicli *scrittura → 2+ revisori avversari → applicazione*, fino a **64 istanze Claude in parallelo** (4 worktree × 16), con **PORTING.md** + **LIFETIMES.tsv** generati in preparazione. Numeri: **6.502 commit** (picco 695/h, 58/min, ~1.300 righe/min), diff finale **+1.009.272 righe**, ~16.000 errori di compilazione trattati come una coda, **5,9 miliardi di token di input non in cache + 690M di output ≈ 165.000 $**. Leve metodologiche chiave: la **revisione avversaria** (un secondo Claude, contesto separato, vede solo il diff, incaricato di trovare perché è sbagliato — individua bug sottili che sono *semanticamente* diversi ma *sintatticamente* identici) e il principio **"correggere il processo che genera il codice, non il codice a mano".** Modello utilizzato: una pre-release di **Claude Fable 5** (classe Mythos). Dopo il merge: **11 round di revisione di sicurezza Claude Code**, fuzzing guidato dalla copertura 24/7 (100 miliardi di esecuzioni → ~15 PR), **4% di codice `unsafe`** (78% su una singola riga), **19** regressioni note corrette. In produzione: Claude Code v2.1.181, la prima release su Bun-in-Rust, **+10% di avvio più veloce su Linux**. Dichiarato in apertura: **Bun è stato acquisito da Anthropic nel dicembre 2025**.
#Bun#Jarred Sumner#riscrittura da Zig a Rust
Jarred Sumner (créateur de Bun ; travaille chez Anthropic depuis le rachat de Bun en décembre 2025)
Thread X (thread illustrato) di **Thariq Shihipar** (team Claude Code / Anthropic): una *field guide* per trarre il massimo da **Claude Fable 5**. Tesi centrale mutuata da Korzybski — *"la mappa non è il territorio"*: la **mappa** = ciò che si fornisce a Claude (prompt, skill, contesto); il **territorio** = dove il lavoro avviene realmente (codebase, vincoli del mondo reale); lo scarto tra i due = gli **unknowns**. Fable è *"il primo modello in cui la qualità del lavoro è limitata dalla mia capacità di chiarire i suoi unknowns"*. L'articolo propone un **framework a 4 quadranti** (known knowns / known unknowns / unknown knowns / unknown unknowns) e un **toolkit di tecniche** ordinate nel tempo (prima / durante / dopo l'implementazione) — blindspot pass, brainstorm & prototipi, interviste, riferimenti, implementation plan, implementation-notes, pitch & explainer, quiz — ciascuna con prompt d'esempio. Ambito: prompt engineering, agenti di codifica, metodologia di lavoro con l'IA, artefatti HTML.
Breve nota di Simon Willison (weblog) che riporta due consigli ascoltati durante una *Fireside Chat* all'AIE con Cat Wu e Thariq Shihipar (team Claude Code): **lasciare che il modello (Fable, e in parte Opus) eserciti il proprio giudizio invece di dettargli delle regole** — illustrato con la decisione se scrivere o meno i test. Secondo consiglio, di Jesse Vincent: per **risparmiare i preziosi token di Fable** (in vista di un imminente aumento dei prezzi), chiedere a Fable di **delegare piccoli compiti a modelli meno potenti**, lasciandogli giudicare quale scegliere. Willison mostra il prompt esatto utilizzato (« *use your judgement to decide an appropriate lower power model and run that in a subagent* ») e il **file di memoria** che Claude Code ha scritto in risposta. Dominio: prompt engineering, agenti di codifica, economia dei token, orchestrazione multi-modello.
#Giudizio del modello#delega ai subagenti#model override
Agent guide (Thinkroom, la piattaforma di Kieran Klaassen) che documenta il **Compounding Knowledge Lifecycle** del compound-engineering-plugin (Every): come una lezione appresa una volta "continua a ripagare" — catturata, archiviata, recuperata e mantenuta veritiera. Descrive l'anatomia di un *learning* (`docs/solutions/`), la sua cattura tramite `/ce-compound`, la mappa della memoria (durevole vs effimera), il recupero *grep-first* (learnings-researcher) collegato a 5 skill nei punti decisionali, e le tre controforze che impediscono alla memoria di mentire. Direttamente rilevante: è la dottrina dietro la convenzione `docs/solutions/` di questo repo. Dominio: compound engineering, gestione agentica della conoscenza, skill.
Lettera "Dear friends" di Andrew Ng su *The Batch* (DeepLearning.AI, numero 359) sul **loop engineering** applicato allo sviluppo di prodotto **0-to-1**. Ng condivide i suoi **3 loop chiave** — loop di coding agentico (~minuti), loop di feedback dello sviluppatore (~ore), loop di feedback esterno (~giorni) — annidati per scala temporale crescente, collegando *coding agent → product spec/evals → visione dello sviluppatore → feedback esterno*. Tesi centrale: gli esseri umani mantengono un **vantaggio di contesto** (piuttosto che un "gusto") che rende indispensabile l'human-in-the-loop; gli ingegneri assumono un ruolo parziale di product management. Dominio: coding agent, product engineering, metodologia agentica.
#Loop engineering#sviluppo di prodotto#loop di coding agentico
Articolo di **Paul Sawers** pubblicato su **The New Stack** il **16 giugno 2026**, sulla **sospensione da parte di Anthropic** — *"on the very day it was scheduled to go live"* — della separazione di fatturazione pensata per distinguere l'utilizzo dell'**Agent SDK** dai limiti dell'abbonamento Claude. **Messaggio citato di Anthropic**: *"We're pausing the changes to Claude Agent SDK usage described below. For now, nothing has changed."* **Il contributo dell'articolo non è l'annuncio in sé, ma il contesto che lo circonda**, articolato in tre cerchi concentrici. **Cerchio 1 — la settimana di Anthropic**: il 9 giugno, il rilascio di **Fable 5 e Mythos 5**, i primi modelli di classe Mythos generalmente disponibili, dotati di misure di sicurezza informatica rafforzate; pochi giorni dopo, una **direttiva statunitense sul controllo delle esportazioni** costringe Anthropic a **ritirare entrambi i modelli per tutti i suoi clienti nel mondo**. La sospensione del nuovo regime tariffario viene letta, in questo contesto, come *"a little good news"*. **Cerchio 2 — i danni collaterali della tempistica**: le aziende che avevano già trasferito il cambiamento ai propri clienti si trovano scoperte; **Conductor**, uno strumento di coding multi-agente costruito sull'Agent SDK, è costretto a pubblicare una smentita (*"Anthropic has delayed the subscription updates to Claude plans"*). **Cerchio 3 — la tensione di fondo, che va oltre Anthropic**: una citazione di **Boris Cherny** (a capo di Claude Code) risalente ad aprile, durante una precedente restrizione, secondo cui gli abbonamenti *"weren't built for the usage patterns of these third-party tools"* — un'ammissione che **le formule a tariffa fissa e l'utilizzo agentico illimitato non vanno d'accordo**; **GitHub** ha risolto la questione allo stesso modo, eliminando a giugno il modello a tariffa fissa delle *premium requests* di **Copilot** a favore di una **fatturazione basata sui token**, nonostante le proteste. A ciò si aggiunge, **nella stessa settimana**, una **proposta di class action** depositata presso un tribunale federale della California, secondo cui i livelli **Max** sarebbero ben al di sotto dei moltiplicatori di utilizzo pubblicizzati per le sessioni di coding intensivo. Anthropic non indica quando arriverà un approccio rivisto, limitandosi a dichiarare che *"works to update the plan to better support how users build with Claude subscriptions."* **La lettura finale dell'autore**: tra la pressione governativa su Fable e Mythos, un'**IPO** pianificata e le **voci di tagli di prezzo da parte di OpenAI**, Anthropic sta cercando di **tenere dalla propria parte la base di sviluppatori** — e la sospensione è, per ora, un mezzo per raggiungere questo obiettivo.
#Anthropic#Claude Agent SDK#abbonamento Claude
**Paul Sawers** — journaliste tech · signe ici pour **The New Stack**. Registre de **presse spécialisée** : l'article ne relaie pas seulement l'annonce · il la replace dans une série (les changements de facturation successifs d'Anthropic) · la compare à un précédent sectoriel (GitHub Copilot) et l'articule à trois pressions concomitantes (export control, IPO, concurrence). Sourçage explicite et attribué — le billet de Zed · l'analyse de Matthew Diakonov · le post de Conductor · une déclaration antérieure de Boris Cherny.
Voce di tipo **Skill** (non un articolo): `grill-with-docs` di Matt Pocock è una tecnica di intervista strutturata che "mette alla griglia" un piano di architettura confrontandolo metodicamente con il vocabolario di business del progetto (il glossario `CONTEXT.md`) e con le decisioni già documentate (gli ADR). Invece di precipitarsi nell'implementazione, mette in discussione le ipotesi una per una attraverso un dialogo domanda/risposta, ripulisce la terminologia, verifica la coerenza rispetto al codice effettivo e cattura le decisioni al volo negli artefatti giusti. Una skill di design a monte (upfront-design), ispirata al Domain-Driven Design.
Chris Williams (@voodootikigod) apre la sua serie sull'ADLC sostenendo che applicare il SDLC umano ai modelli è un errore di categoria: il ciclo classico è stato progettato per contrastare modalità di fallimento umane (ego, stanchezza, dimenticanza) assenti negli LLM. Cataloga otto modalità di fallimento strutturali (F1-F8) e cinque proprietà sfruttabili (E1-E5), ed enuncia il principio fondativo: ogni fase di un ciclo agentico deve essere riconducibile a una modalità di fallimento da cui si difende o a una proprietà che sfrutta.
Secondo capitolo della serie ADLC di Chris Williams: sviluppa il ciclo che discende dalla "prima legge" — otto fasi (P0 Triage → P7 Distill), un gate deterministico tra ogni coppia, ed esattamente due momenti umani obbligatori (approvazione della spec a P1, accettazione comportamentale a P6). Principio chiave: un passaggio di consegne LLM→LLM senza un checkpoint deterministico moltiplica i tassi di errore; e una distribuzione dei costi a "bilanciere" (pesante alle due estremità, leggera al centro) che ribalta l'economia agile.
#ADLC#ciclo agentico a otto fasi#gate deterministici
Terzo capitolo della serie ADLC: Williams trasforma il testing nella specifica nell'unico linguaggio che il builder non può contestare. Dove il TDD è una pratica di qualità opzionale per il codice scritto da esseri umani, diventa il meccanismo di fiducia portante dell'intero ciclo di vita quando sono gli agenti a scrivere il codice. Tre regole di "disciplina dei binari": contesti di redazione separati (solo specifiche prima dell'implementazione), congelamento meccanico a livello di strumento (non di prompt) e audit avversariali ("un test fallisce se la funzionalità viene eliminata?"). Il mutation testing è preferito alla percentuale di copertura, manipolabile secondo Goodhart a velocità macchina.
Quarto capitolo della serie ADLC: Williams riformula la revisione del codice come "accusa" avversariale piuttosto che come valutazione collaborativa. Assegna agli agenti il mandato di confutare ("trovare cosa non va"), impiega revisori a lente singola con contesti nuovi (correttezza, sicurezza, conformità contrattuale, aderenza alle specifiche, qualità dei test), agisce solo su riscontri verificati (riprodotti da un test che fallisce) e itera fino a due passaggi consecutivi con zero riscontri. Misura la calibrazione introducendo bug noti, secondo uno schema simile al mutation testing. Gate di uscita: zero riscontri aperti, due passaggi a vuoto, test verdi, diff dei test vuoto.
Quinto capitolo della serie ADLC: orchestrare agenti paralleli senza "merge hell". Williams individua tre variabili accoppiate — costo (scelta del modello), tempo reale (ampiezza della parallelizzazione) e accuratezza (qualità del contratto) — e un principio architetturale: "il control flow è codice; il giudizio spetta ai modelli" (script deterministici orchestrano, i modelli forniscono solo giudizio). Quattro corsie (Contract Desk con modello di frontiera, Builder Pool a scrittore singolo, Prosecution Pool condiviso, Integrator sequenziale), una previsione dei conflitti di merge costruita su quattro segnali (ampiezza certificata tipicamente tra 3 e 5 agenti) e una disambiguazione basata sul consenso tra N agenti economici anziché domande di chiarimento.
Sesto capitolo sull'ADLC: Williams descrive la fase P7 "Distill" come la componente che riduce il costo a ogni esecuzione. Due metà: semplificazione post-merge (dedurre dopo che il codice esiste, non prima — "deduplicare prima che il codice esista è speculativo") e estrazione delle lezioni (una "lesson foundry" trasforma i riscontri ricorrenti in regole di lint, skill e nuove domande di interrogazione). Ogni lezione viene pagata una sola volta, poi retrocessa da rilevamento probabilistico costoso a prevenzione deterministica gratuita. L'unità di conto corretta è "costo per modifica mergiata e verificata", e "un costo piatto è un fallimento".
Settimo e ultimo capitolo della serie ADLC: Williams presenta un toolkit open-source di diciotto strumenti costruiti *con* il ciclo stesso (loop build-prosecute-fix, agenti paralleli, un core congelato `@adlc/core` seguito da un fan-out — "pinned means merged"). Il nucleo dottrinale è "frontier-free": raggiungere obiettivi di precisione con modelli di fascia media (classe Opus/Sonnet/Haiku) anziché di frontiera, tramite cinque sostituzioni (la ricerca sostituisce l'intuizione, la scomposizione sostituisce l'orizzonte, l'accumulo sostituisce la presenza, la misurazione sostituisce la metacognizione, il divario generatore-verificatore mantiene il motore in funzione), con l'essere umano che resta il livello "di frontiera" ai due gate di specifica. Filo conduttore della serie: "sostituire la fiducia con la struttura, e la struttura con la misurazione".
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
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*.
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**.
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**.
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**.
Post ufficiale sul blog **Salesforce News** (sezione *Agentic Enterprise*, serie *"Pioneering the Agentic Shift Within Salesforce Engineering"*), pubblicato il **27 maggio 2026** (lettura di 6 minuti) da **Srinivas "Srini" Tallapragada**, *President and Chief Engineering and Customer Success Officer* di Salesforce. Seguito diretto di un post precedente (*"How we got our engineers to use AI — without breaking everything"*) che raccontava il superamento del **90% di adozione**. **Tesi di svolta**: Salesforce Engineering è passata da un mondo in cui l'IA era un utile *copilot* a uno in cui **gli strumenti agentici guidano lo stesso ciclo di vita dello sviluppo software (SDLC)** — scrivendo codice, revisionando PR, generando test, aggiornando la documentazione, gestendo i deployment, coordinando lavoro un tempo affidato a passaggi di consegne umani. **Decisione segnale canonica**: standardizzazione a livello aziendale su **Claude Code** + ***"abbiamo rimosso tutti i limiti di token"*** — *"eliminare ogni ultimo attrito tra i nostri ingegneri e gli strumenti che li rendono più veloci ed efficaci"*. **Risultato empirico principale** (aprile 2026 vs aprile 2025): work item completati per sviluppatore **+50,8%**, PR mergiate per sviluppatore **+79%**, e soprattutto **Effective Output score** (una misura ML del **valore reale del codice consegnato**, non del volume) **+151,3% su base annua**. **Caso d'uso di punta**: migrazione di **33 endpoint API** verso un'architettura cloud-native, stimata in **~231 person-day** (7 per API) col metodo tradizionale, completata in **13 giorni — 18× più veloce** — tramite un **framework basato su regole costruito in Claude** (file markdown + implementazioni di riferimento), con il feedback delle PR continuamente reintegrato nel set di regole, **cicli LLM autonomi (build, fix, validate)** senza intervento manuale, parallelizzati su ambienti isolati → **5 PR**, la più grande delle quali con **21 endpoint e copertura test al 100%**. **Nessun compromesso velocità↔qualità**: attraverso la piattaforma **Engineering 360** (che centralizza i dati di ingegneria di centinaia di sistemi), **il totale degli incidenti scende del 5%** nonostante l'aumento delle PR (*"la qualità non soffre della velocità. Ne beneficia"*), grazie a **guardrail di sicurezza e standard di qualità incorporati strutturalmente** nel workflow agentico (Trust come valore numero 1). **Revisione dell'SDLC**: una volta adottata l'IA, gli ingegneri **smontano e ricostruiscono** i workflow (quali processi eliminare? quali passaggi di consegne sono ormai superflui? dove un umano svolge ancora un lavoro che un agente potrebbe assumere?). **Nuovo mestiere ingegneristico**: le **Claude Code skills** (capacità impacchettate e riutilizzabili che codificano il contesto del team, le convenzioni di naming, i pattern) diventano un **artefatto ingegneristico** condiviso e componibile; **AI Expert Suite** + **Salesforce Foundation Plugins** = una libreria di skill istituzionalizzata e curata (benchmark interno: **maggiore accuratezza e affidabilità, costo superfluo ridotto**); **subagent e team di agenti** parallelizzano i flussi di lavoro (*"Descrivono il risultato, e un insieme di agenti coordinati individua i passaggi"*). **Ciò che resta difficile**: (1) la **gestione del contesto** nelle sessioni lunghe — la **qualità dei file CLAUDE.md** varia ampiamente e pesa fortemente sulla qualità dell'output; (2) la **sicurezza agentica** = un modello radicalmente diverso (agenti che *agiscono*, non solo *suggeriscono* → raggio d'impatto aumentato); (3) **ruoli in evoluzione** (come diventano senior i junior se l'IA assorbe il lavoro entry-level? ruolo del designer/PM? l'unità di esecuzione = team scrum → sperimentazioni con unità da 1 o 3 persone). Conclusione: *"Ha cambiato ciò che era economicamente possibile"*; l'ambizione dichiarata è **"l'SDLC più automatizzato e agentico del settore"**. Si interseca direttamente con Gupta (*costo di un outcome completato*, utilità marginale del token), Greenwald/Sierra (pricing basato sui risultati), DORA (ROI / costo per feature) e il dibattito BFM/Girard (il token come carburante di valore, non un costo da tagliare).
#SDLC agentico#agentic SDLC#Claude Code
**Srinivas « Srini » Tallapragada** — *President and Chief Engineering and Customer Success Officer* de **Salesforce**. Plus d'une décennie chez Salesforce · dirige l'ingénierie mondiale de la plateforme unifiée. Auteur de la série *Agentic Enterprise* sur le blog Salesforce News ; ce billet (27 mai 2026) est la **suite** d'un premier opus consacré à l'adoption de l'IA par les milliers d'ingénieurs Salesforce (*« How we got our engineers to use AI — without breaking everything »*). Position d'autorité = **dirigeant exécutif** parlant en son nom et au nom d'une organisation d'ingénierie à grande échelle (donnée terrain à l'échelle d'un hyperscaler SaaS) · avec accès aux métriques internes (Engineering 360, Effective Output).
Post del blog **Zed** firmato da **Franciska Dethlefsen** (head of growth and marketing), pubblicato il **14 maggio 2026** — il giorno dopo l'annuncio di Anthropic — per rispondere alle domande degli utenti Zed. **Oggetto**: a partire dal **15 giugno**, Anthropic **divide la fatturazione degli abbonamenti Claude in due pool** — uno per i suoi **strumenti proprietari** (chat, la CLI ufficiale Claude Code), l'altro per l'**uso di agenti e SDK di terze parti** (tutto ciò che passa tramite **ACP**, `claude -p`, o uno strumento di terze parti). L'uso via ACP **smette quindi di attingere ai limiti Pro o Max** e passa a un **credito mensile "Agent SDK"**: **20 dollari per Pro, 100 dollari per Max 5x, 200 dollari per Max 20x**. Una volta esaurito il credito, l'uso continua **al prezzo API standard** se l'overage è abilitato — altrimenti le richieste si interrompono fino al ciclo successivo. **La cifra che guida l'articolo**: gli abbonamenti avevano fino ad allora sovvenzionato l'uso agentico con un fattore di **circa 15-30×** rispetto al prezzo API, e i nuovi crediti sono fatturati **ai prezzi API pieni** — da cui *« for anyone using agents heavily, this is a major cost increase »*. **Vengono proposte tre opzioni**, in un ordine che rivela la posizione di Zed: (1) mantenere l'abbonamento eseguendo la **CLI ufficiale `claude` in un terminale dentro Zed** anziché via ACP — *« when the official claude CLI runs in the terminal, it uses your subscription's limits, not the new credit »*; (2) usare l'agente integrato di Zed con il provider a scelta (modelli ospitati da Zed, chiavi API, Copilot, Ollama locale, DeepSeek); (3) collegare **qualsiasi agente ACP** — OpenCode, Codex, Factory, Cursor —, diversi dei quali offrono ancora abbonamenti a limiti di frequenza che sovvenzionano l'uso intensivo. **La tesi di fondo**, e la vera ragione del post: *« ACP is an open protocol… so that your editor is never locked into one provider's pricing decisions »*, con l'anticipazione esplicita che *« this kind of change won't be the last »*. **Il post porta un'aggiunta datata 16 giugno 2026** che annuncia che **la modifica è sospesa**: ACP, `claude -p`, l'Agent SDK e le applicazioni di terze parti continuano a funzionare con gli abbonamenti **come prima**, nessun credito separato da rivendicare, limiti invariati, Anthropic sta rivedendo il proprio piano con un preavviso annunciato. **L'artefatto è quindi autocontraddittorio**: il suo contenuto più importante — il dietrofront — è successivo di un mese alla propria data di pubblicazione.
#Zed#Anthropic#abbonamento Claude
**Franciska Dethlefsen** — head of growth and marketing chez **Zed Industries**. Le rôle est déterminant pour lire le texte : ce n'est pas un billet d'ingénierie mais une **communication de crise produit** · écrite le lendemain d'une annonce d'un fournisseur dont Zed dépend · à destination d'utilisateurs inquiets. La signature growth/marketing explique la structure (problème → options → réassurance) et le fait que l'argument protocolaire arrive en conclusion plutôt qu'en tête.
La Continuous Delivery come fondamento non negoziabile dello sviluppo assistito dall'IA — Dave Farley, sul suo canale *Modern Software Engineering*, sostiene che senza CD l'IA non è un acceleratore ma una trappola (teoria dei vincoli e paradosso di Jevons applicati al codice generato, ATDD/BDD come salvaguardia, deployment pipeline come arbitro della qualità).
Articolo in stile manifesto di **Thariq Shihipar** (Ingegnere e imprenditore seriale, team Claude Code di Anthropic) che annuncia un **cambiamento nel formato di output predefinito per gli agenti**: la sostituzione di **Markdown con HTML**. Tesi: Markdown è stato il formato dominante tra umani e agenti (semplice, portabile, modificabile, leggibile) ma è diventato **un collo di bottiglia** man mano che gli agenti producono artefatti più lunghi e ricchi (specifiche, piani, report, code review). Oltre le ~100 righe, nessuno legge più un file Markdown. HTML risolve sei limiti contemporaneamente: **densità informativa** (tabelle, CSS, SVG, script, canvas, immagini), **chiarezza visiva** (layout navigabile, responsive per mobile), **facilità di condivisione** (un link S3 apribile direttamente nel browser), **interattività bidirezionale** (slider, manopole, pulsanti "copy as JSON/prompt" per il rientro in Claude Code), **ingestione contestuale nativa** (Claude Code legge la codebase + MCP Slack/Linear + cronologia git + Chrome) e **piacere** (l'autore afferma esplicitamente *"it's joyful"*). Cinque usi canonici approfonditi: (1) **specifiche/piani/esplorazione** in una griglia comparativa, (2) **PR review** con diff annotato inline, (3) **design e prototipi** con slider di animazione, (4) **report/ricerca/apprendimento** (l'autore ha fatto generare un explainer sul prompt caching a partire dalla cronologia git), (5) **editor usa e getta personalizzati** (drag-and-drop di ticket Linear, editor di feature flag, prompt-tuner affiancati) che producono un export "copy as markdown/diff/JSON" re-iniettabile. Anti-pattern esplicito: *"I'm a little bit afraid that people will read this article and turn it into a /html skill"* — l'autore **rifiuta la skill-ificazione prematura**, raccomandando di scrivere il prompt da zero ("make a HTML file"). FAQ pragmatica: costo in token assorbito dal contesto da 1MM di **Opus 4.7**, generazione 2-4× più lunga, diff HTML rumorosi (uno svantaggio reale), stile tenuto sotto controllo tramite un design system HTML di riferimento.
#HTML#Markdown#formato di output
Thariq Shihipar (Engineer & serial entrepreneur, équipe Claude Code chez Anthropic — site : thariqs.github.io/html-effectiveness ; X : @trq212)
Editoriale di Andrew Ng su The Batch n°352 dell'8 maggio 2026 — **"There Will Be No AI Jobpocalypse"** — che smonta la narrazione della disoccupazione di massa causata dall'IA, basandosi sul tasso di disoccupazione USA **sano al 4,3%** e su assunzioni tech solide. Ng individua **tre motori** della narrazione del jobpocalypse: **(1) incentivi tecnologici** — i laboratori IA traggono vantaggio dal presentarsi come trasformativi-dirompenti (round di finanziamento, valutazioni, talenti); **(2) potere di determinazione dei prezzi** — i fornitori applicano **10.000+ $/anno** ai clienti enterprise **ancorando i propri prezzi allo stipendio del dipendente sostituito**, anziché al pricing SaaS tradizionale (per postazione / per utilizzo); **(3) comunicazione aziendale** — le imprese riformulano i propri licenziamenti come *"efficienza IA"* piuttosto che riconoscere le **assunzioni eccessive dell'era pandemica** del 2020-2022. Riconoscimento onesto: *"AI disrupts work"*. Ma Ng lo capovolge in **"AI jobapalooza"** (gioco di parole su Lollapalooza) — creazione di posti di lavoro nell'AI engineering e in campi affini, con competenze in evoluzione. Tensione implicita con **Amodei** (50% dei posti impiegatizi eliminati entro il 2030) — Ng fa notare, senza nominarlo, che **Anthropic trae vantaggio dal promuovere questa narrazione** (incentivi tecnologici). Pubblicato **lo stesso giorno** dell'articolo di **Wallace-Wells "AI Populism" sul NYT Magazine**: una lettura speculare perfetta — Ng = analisi economica a sangue freddo / Wallace-Wells = panico popolare. Convergenza sul potere di pricing con **"$100B cross-system labor" di Bain** (stessa tesi: pricing ancorato agli stipendi).
#Andrew Ng#The Batch#DeepLearning.AI
Andrew Ng (fondateur DeepLearning.AI, Stanford, ex-Google Brain, ex-Baidu, ex-Coursera)
Podcast di Greg Isenberg × Meng To (designer, fondatore di Design+Code, creatore dei prodotti Aura / New Form / Dream Cut) su **`design.md`** — la convenzione open-source di Google, equivalente a `agents.md` / `skills.md` / `soul.md` ma **per il design system** (tipografia, colori, spaziature, animazioni WebGL/Three.js, regole di reveal). Idea centrale: portare la "**anima del design**" in un file markdown che viene consegnato a un agente (Claude Code, Codex, OpenClaude, Gemini, Stitch, Aura, V0, Lovable, Cursor) per preservare la **coerenza cross-medium** (web, mobile, Replit slides, motion design Hyperframes/Remotion). Triade insegnata: **HTML = piatto finito, design.md = ricetta, skills = ingredienti** (skill di tipografia, laser, skeuomorfismo, 3D — 63 in New Form). Diagnosi principale: il **design drift** nei workflow one-shot (`v0`, Lovable, Framer) che partono bene ma poi degradano verso un risultato generico. Messaggio chiave: il *taste* è l'unico **vantaggio competitivo** rimasto — *"se qualcosa somiglia a qualcos'altro, il suo valore scende da 10× a 100×"*. Workflow: **Reference → Design.md → Generate → Inspect → Systemize → Iterate (fino a 1000+ prompt) → Remix → Expand → Export**. Critica dei **gradienti viola** ("you just run") come baseline generica post-vibe-coding. Meng To dichiara di aver speso circa 500.000 $ in token, eseguito 1.000-10.000 iterazioni per prodotto e gestito 4 prodotti in parallelo da solo.
#design.md#Google#design system
Greg Isenberg (host — podcast Late Checkout / The Greg Isenberg Show, 12 mai 2026 livestream workshop ideabrowser.com) ; **Meng To** (guest — designer, fondateur Design+Code 2014, créateur Aura / New Form / Dream Cut, autodidacte parti à 18 ans, dropout, francophone d'origine canadienne)
Intervista a Boris Cherny (creatore di Claude Code, Anthropic) a un evento Sequoia (conduzione: Asia, Lauren Reader). Cherny afferma ***"coding is solved"***: lui stesso non ha scritto **0 righe di codice** dalla fine del 2025, il modello scrive il **100%**, *"a few dozen PRs/day, 150 PRs in a single day record"*. Racconto della genesi di Claude Code (incubatore Anthropic Labs fine 2024, Mike Krieger responsabile del round 2, sviluppo pre-PMF *"for the next model"*, una prima release che non ha decollato, **crescita esponenziale iniziata con Opus 4 nel maggio 2025**, in accelerazione a ogni nuovo modello 4 → 4.5 → 4.6 → 4.7). Configurazione personale attuale: **"most of my work I do from my phone"** (iOS), 5-10 sessioni, **"a few hundred agents going, a few thousand at night"**, **`/loop` è il futuro** (cron + job ricorrenti, agenti che sorvegliano la CI, rebasano le PR, raggruppano il feedback su Twitter). **Routines** = l'equivalente lato server, in esecuzione a computer chiuso. Prospettive SaaS: nessuna apocalisse, ma un **rimescolamento del framework delle 7 Powers di Helmer** (switching cost ↓, process power ↓, network effect/economie di scala/cornered resource invariati) e **10× più startup dirompenti** nei prossimi 10 anni. Analogia del punto di svolta: la **stampa di Gutenberg** (10% di alfabetizzazione nel XV secolo → 70% nei secoli successivi, libri 100× più economici entro 50 anni), *"software will be similarly democratized, but faster than 50 years"* — *"the best person to write accounting software is not an engineer, it's a really good accountant."*
#Boris Cherny#Anthropic#Claude Code
Boris Cherny (créateur de Claude Code, Anthropic) interviewé par Lauren Reader (Sequoia) avec introduction d'Asia (Sequoia).
Repository GitHub `techygarg/lattice` che formalizza un framework di **skill componibili** per installare una *disciplina ingegneristica* negli assistenti di coding AI (Claude Code, Cursor). Architettura distintiva a tre livelli: **Atoms** (guardrail a principio singolo: clean code, DDD, sicurezza, qualità dei test, design-first), **Molecules** (workflow multi-step che compongono gli atoms: design, implement, refactor, fix, review), **Refiners** (interviste guidate che producono standard specifici del progetto che personalizzano il comportamento degli atoms). Pipeline operativa `lattice-init` → `design-blueprint` → `code-forge` → `review`, con `refactor-safely` e `bug-fix` come ramificazioni. Tre principi cardine: *"Skills over prompts"*, *"Composability over monoliths"*, ***"Living context over static config"*** — la cartella `.lattice/` diventa più intelligente a ogni ciclo di feature. MIT, puro shell, 18 stelle / 52 commit, una serie di articoli su martinfowler.com che spiegano cinque *collaboration patterns*. Forte convergenza con Vincent *Superpowers* (2026-04-02), Habert *PROJ-AI* (2026-05-05), Wescale *Usine Logicielle Augmentée* (2026-05-03), e — la convergenza dottrinale più alta senza filiazione dichiarata — **Compound Engineering** di Every (Shipper/Klaassen 2025-12-11): pipeline isomorfe (lattice-init→design-blueprint→code-forge→review ↔ ce:brainstorm→ce:plan→ce:work→ce:review), livello di contesto vivente (`.lattice/` ↔ `docs/plans/+solutions/+brainstorms/`), una comune postura design-first, review obbligatoria a fine pipeline. La dottrina 2026 del *coding agent harness* converge su un vocabolario stabile, senza influenza diretta.
#lattice#techygarg#composable AI skills
techygarg (auteur GitHub, identité réelle non précisée dans le README ; auteur d'une série d'articles publiée sur martinfowler.com).
Whitepaper Google (primo capitolo, il "Day 1", di una serie firmata da Addy Osmani, Shubham Saboo e Sokratis Kartakis) che mappa la trasformazione del ciclo di vita dello sviluppo software (SDLC) nell'era degli agenti di coding. Tesi: il cambiamento fondamentale non è un nuovo linguaggio, bensì il passaggio dalla scrittura di codice all'**espressione dell'intento**. Il documento delinea uno spettro che va dal *vibe coding* (prompting e accettazione) all'*agentic engineering* (l'IA implementa sotto vincoli, test e cicli di feedback progettati da esseri umani), con il **context engineering** come competenza centrale, il modello della **software factory** (il deliverable dello sviluppatore = il sistema che produce il codice), l'**harness engineering** (Agent = Model + Harness) e un'analisi economica CapEx/OpEx del costo totale di possesso.
Intervista ad Andrej Karpathy (co-fondatore di OpenAI, ex responsabile dell'Autopilot di Tesla) sul passaggio dal *vibe coding* all'*agentic engineering*: December 2025 transition come punto di svolta "never felt more behind as a programmer", la tassonomia Software 1.0/2.0/3.0, l'esempio openclaw (script bash → testo da copiare-incollare nell'agente) e MenuGen reso obsoleto da Nanobanana di Gemini, la teoria della *verifiability* che spiega perché gli LLM sono *jagged* (picco su matematica/codice, fallimento su "andare all'autolavaggio a 50 metri"), la distinzione tra *vibe coding* (alzare il pavimento) e *agentic engineering* (mantenere il livello di qualità), la metafora "animals vs ghosts", la revisione del processo di selezione tramite progetti agente-contro-agente, e la formula chiave: ***"You can outsource your thinking but you can't outsource your understanding."***
#Andrej Karpathy#vibe coding#agentic engineering
Andrej Karpathy (co-fondateur OpenAI, ex-Tesla Autopilot, créateur du terme "vibe coding")
Thread X in stile manifesto di Rohit (@rohit4verse) che delinea la *2026 AI engineer roadmap*: un divario di 150.000 dollari tra prompt engineer e systems architect, la fine dei *generic wrapper* "sherlockati dai big tech", e 5 progetti da portfolio classificati per livello di complessità (SLM mobile offline, agente di coding auto-migliorante, *Cursor for video editors* multimodale, agente personal life OS privacy-first, agente autonomo per workflow aziendali). Ogni progetto descrive le sue *decisioni architetturali chiave* (lazy loading, sliding window, sandboxing, scene detection, grafo di conoscenza personale, multi-agente event-driven, audit trail, RBAC, observability). Slogan strutturante: *"il sostituibile: costruire wrapper / l'inlicenziabile: spedire sistemi autonomi"*. Tono ingiuntivo e virale tipico di X nel 2026.
#2026 AI engineer roadmap#Rohit#rohit4verse
Rohit (@rohit4verse) — créateur de contenu IA sur X · vulgarisateur d'architecture et roadmaps de carrière en ingénierie IA.
Post del **blog di Ahrefs** pubblicato il **28 aprile 2026** da **Ryan Law** (Director of Content Marketing, Ahrefs) che descrive un sistema interno di **content engineering** costruito attorno a **Claude Code**: una pipeline editoriale che produce **bozze pronte per la pubblicazione in 6-12 minuti**. **Tesi centrale**: ***« AI content is not, by default, good. This process works well because it mirrors our existing human editorial process »*** — la qualità non deriva dal modello ma dalla **riproduzione fedele di un processo editoriale umano** collaudato da decenni. Architettura: **~23 skill files**, ciascuno corrispondente a una fase editoriale (keyword research, analisi dei gap tematici, struttura dell'outline, compilazione della ricerca, generazione della bozza, formattazione), **orchestrati da uno skill master `blog-pipeline`** che li concatena per produrre un articolo completo. **Sette principi di design**: (1) **imitare i flussi di lavoro umani** concatenando skill adattati dalla documentazione editoriale esistente di Ahrefs; (2) **restituire l'output di ogni fase separatamente** per il troubleshooting (*« if you get an article at the end of a ten minute run, and it's bad, it's hard to diagnose precisely where and why the process went wrong »* → salvare gli output intermedi); (3) **creare casi di test** tramite lo skill `skill-creator` di Anthropic per valutare e migliorare le istruzioni; (4) **collegare fonti dati di qualità** — l'**Ahrefs MCP** (metriche delle keyword, parent topic, temi long-tail, panoramiche SERP, analisi competitiva), analisi competitiva e documentazione di prodotto; (5) **anticipare l'indicazione umana** tramite parametri di contesto che abilitano indicazioni editoriali; (6) **costruire anteprime interattive** in formato HTML per la revisione prima della pubblicazione; (7) **consentire la personalizzazione** (ogni membro del team può fare il fork e modificare il sistema). **Volume**: ~**15 articoli pubblicati** e ~**30 articoli aggiornati** tramite questo workflow; lo sviluppo è iniziato a **febbraio 2026** (il processo precedente, di **agosto 2025**, richiedeva diversi giorni e intervento manuale). **Avvertenze esplicite** (anti-sopravvalutazione): *« experience matters »* — il processo riflette decenni di competenza editoriale; la selezione degli argomenti si concentra su **contenuti SEO informativi** ben conosciuti dall'autore; Ahrefs **non ha alcun piano per "scalare" massicciamente i contenuti** ma mantiene una **libreria evergreen**. Filosofia: automatizzare *« the formulaic parts of work »* per eliminare le mansioni ripetitive e liberare tempo per ricerca, thought leadership, webinar e ottimizzazione del sistema — **non** sostituire lo sforzo umano. Riferimento canonico citato da Pasquale Pillitteri (*Opus 4.8 SEO workflow*) come prova sul campo del guadagno « 6-12 min/bozza ». Convergenza diretta con la dottrina **skills-over-prompts** (Lattice, PROJ-AI), i **systems around the model** (Dropbox/Okumura) e l'uso dell'**HTML come artefatto di revisione** (Shihipar).
**Ryan Law** — Director of Content Marketing chez **Ahrefs**. Praticien senior du content marketing SEO ; le billet est un retour d'expérience personnel (*« How I do… »*) publié sur le **blog Ahrefs** (ahrefs.com/blog) le **28 avril 2026**.
L'editoriale di Andrew Ng su The Batch #350 delinea una **gerarchia di accelerazione per gli agenti di coding** in base al tipo di lavoro software: **Frontend (massima) > Backend (moderata) > Infrastruttura (bassa) > Ricerca (minima)**. La motivazione poggia sulla *verificabilità* implicita (padronanza di TypeScript/JavaScript più un ciclo di test autonomo agente-browser sul frontend) e sui punti ciechi degli LLM (casi limite / sicurezza / migrazioni di database per il backend, compromessi di rete opachi per l'infrastruttura, formazione di ipotesi irriducibile per la ricerca). Il numero è completato da 4 notizie strutturanti: **GLM-5.1 (Z.ai)**, un modello con 754B parametri (40B attivi) sotto licenza MIT capace di compiti autonomi della durata di 8 ore (leader su SWE-Bench Pro con il 58,4%); **Digit (Agility Robotics) presso Schaeffler**, il primo dispiegamento industriale di umanoidi (5'9"/143lb, 10-25 $/h contro 20 $/h per un umano); la **rivolta anti-data-center** (~64 miliardi di dollari bloccati da maggio 2024 a marzo 2025, moratoria del Maine sugli impianti da 20MW+, cocktail Molotov contro l'abitazione di Sam Altman); e l'**"assistant axis"** (Christina Lu, MATS / Oxford / Anthropic), che riduce la deriva della persona e i jailbreak (Qwen3 32B: 83%→41%; Llama 3.3 70B: 65%→33%) senza degradare IFEval/GSM8k/MMLU-Pro/EQ-Bench.
#Andrew Ng#The Batch#DeepLearning.AI
Andrew Ng (édito principal — fondateur DeepLearning.AI, Stanford, ex-Google Brain, ex-Baidu) ; rédaction The Batch (DeepLearning.AI) pour les sections actualités
Sintesi di Addy Osmani (Google, Chrome/Cloud) sul campo emergente dell'*harness engineering*: l'equazione `agent = model + harness`, il principio del *ratchet* ("ogni errore diventa una regola"), la rilettura "skill issue" di HumanLayer, le evidenze di Terminal Bench (Top 30 → Top 5 dal solo cambio di harness), l'architettura a livelli di Claude Code, la visione di Anthropic "gli harness non si riducono, si spostano", e l'Harness-as-a-Service (Claude Agent SDK, Codex SDK, OpenAI Agents SDK). Articolo cardine che consolida in una dottrina Trivedy, HumanLayer, Anthropic e Böckeler.
#harness engineering#agent harness#Addy Osmani
Addy Osmani (Software Engineer at Google, Cloud + Gemini)
Agente semantico: la simmetria tra modello+harness e ontologia+dati, il collasso dei framework agentici, l'ontologia come unico asset non commoditizzato
Aggiornamento pubblico di Darragh Curran (R&D, Intercom) nove mesi dopo il suo impegno a raddoppiare la produttività R&D in 12 mesi grazie all'IA. Risultato: **3x raggiunto in 16 mesi, senza segnali di stabilizzazione**. Dati quantificati di un'organizzazione R&D di 500 persone / 8,5M di righe di codice: **93,6% delle PR sono agent-driven**, **19,2% AI-approved** (obiettivo >50%), costo/PR **-50%**, arretrato dei difetti **-54%**, tempo di shipping **-39%**, downtime da breaking-changes **-35%**, il top 5% dei performer al **6x del throughput mediano di PR**, **497 PR autonome** nelle prime 4 settimane, **153 contributori / 267 skill specializzate** in una *Skills-Based Plugin Architecture* privata. Curran dichiara ***"Tutto il lavoro tecnico sta diventando agent-first. Questa è la priorità assoluta per l'R&D."*** Articolo cardine del dossier *agent-first organization*, paragonabile solo a Stripe Minions e StrongDM nel corpus 2026.
#Darragh Curran#Intercom#Fin Ideas
Darragh Curran (R&D leader, Intercom — publication via Fin Ideas, plateforme média Intercom).
Ruolo dello sviluppatore di fronte agli agenti di codifica IA, esperimento di un giorno con il metodo BMAD, evoluzione verso il supervisore di agenti - Blog tecnico
Manuale di riferimento sul compound engineering: loop agentico in 7 passaggi (Ideate→Brainstorm→Plan→Work→Review→Polish→Compound), plugin agent con 40+ agenti, scala di adozione a 5 stadi, regola del 50/50 — Kieran Klaassen (Cora / Every) - Every Source Code
#compound engineering#filosofia AI-native#loop in 7 passaggi
Kieran Klaassen (avec Claude & GPT crédités co-auteurs du guide complet)
Lancio della Agentic AI Foundation - Linux Foundation - OpenAI Anthropic Block - Standard Aperti per gli Agenti AI - AGENTS.md MCP goose - Interoperabilità
Anthropic Interviewer - Studio sulla Forza Lavoro e l'IA - Prospettive Professionali - Adozione dell'IA - Trasformazione del Lavoro - Industrie Creative - Ricerca Scientifica - Impatto Economico - Ricerca Sociologica - Analisi del Sentiment verso l'IA
#Anthropic Interviewer#Studio sulla Forza Lavoro e l'IA#Prospettive Professionali
Anthropic Research - AI Work Transformation - Claude Code Impact - Software Engineering - AI Adoption - Productivity Study - Workplace Evolution - AI Collaboration - Skills Development - Future of Work
#Anthropic#AI Transformation#Workplace Impact
Anthropic Research Team (132 engineers and researchers surveyed, 53 in-depth interviews conducted)
Costruire coding agent duraturi che sopravvivono ai cicli dei modelli: architettura dell'harness, Codex SDK e Computer Use da terminale — resoconto di esperienza di OpenAI
#OpenAI#Codex#Coding Agents
Bill Chen (Product Manager, OpenAI) · Brian Fioca (Engineering, OpenAI)
8 strategie di planning con l'IA - Agenti di ricerca paralleli - Grounding sul codebase - Cronologia Git - Vibe prototyping - Agenti di stile - Compounding engineering - Every Source Code - Kieran Klaassen
#strategie di planning#agenti di ricerca#operazioni parallele
Microsoft Magentic Marketplace - test di manipolazione degli agenti IA - Claude Sonnet 4 unico resistente - Paradosso della scelta - Prompt injection - Paralisi da analisi - Webb Wright - ZDNet
Cat Wu e Boris Cherny (Anthropic) spiegano come usare Claude Code come i suoi creatori: antfooding, plan mode, subagent, hook ed estensibilità — podcast AI & I di Every
#Claude Code#Cat Wu#Boris Cherny
Rhea Purohit (interviewer: Dan Shipper) · Cat Wu · Boris Cherny