thekb.eu — Agenti di codifica IA e Skills

When code is abundant

Mon, 24 Aug 2026 00:00:00 GMT

Bill Staples, CEO di GitLab, pubblica il 24 agosto 2026 un saggio che prolunga un memo scritto al proprio consiglio ad amministrazione a gennaio e una prima pubblicazione di maggio, *GitLab Act 2*. L'innesco esplicito è l'AI-native SDLC playbook di Anthropic, pubblicato il 21 agosto, da cui riprende l'affermazione d'apertura: il codice non è più il collo di bottiglia. La sua domanda va un passo oltre: se produrre codice smette di essere il vincolo, cosa diventa scarso, e quale architettura deve avere un'azienda quando umani, agenti e più modelli agiscono simultaneamente a velocità macchina. La sua risposta sta in una frase: quando l'implementazione diventa abbondante, la fiducia diventa scarsa. Per sessant'anni, l'ingegneria del software si è organizzata attorno a un fatto — il codice è prezioso — da cui discendono la conservazione del legacy, l'ottimizzazione della produttività degli sviluppatori e la cerimonia di revisioni, approvazioni e gate di rilascio. Questo vincolo sta cambiando, e il sistema costruito intorno ad esso lo seguirà. L'unità economica che propone 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 il termine di generazione e rende gli altri proporzionalmente decisivi: un'organizzazione dieci volte più veloce nel generare, senza toccare il resto, si limita a spostare la coda. È la teoria dei vincoli, citata per nome. Le esperienze di Stripe, Spotify e Amplitude fungono da materiale. Mostrano soprattutto dove riappaiono i vincoli successivi: ambiente, CI, revisione e governance. Una pipeline da trenta minuti, scrive, sconfigge qualsiasi modello. Ne segue un'architettura: tre modalità di sviluppo coesistenti anziché un'unica curva di maturità; l'inner loop che migra dalla postazione di lavoro alla pipeline, più vicino al repository e produttore di evidenze; un'autonomia governata piuttosto che concessa, tramite gate deterministici, isolamento, policy ed evidenze. Viene poi esposta la tesi del vendor: il modello è un componente di esecuzione sostituibile, non l'architettura durevole. Contesto, identità, policy, provenienza e memoria organizzativa devono persistere attraverso modelli e agenti, il che spinge verso un control plane neutrale rispetto a modello e cloud. Il testo distingue il file Markdown dal record governabile, sostiene che l'agente debba appartenere al cliente, descrive un PDLC in cui il segnale di business diventa software verificato e prevede la crescita della popolazione dei Builder. Il giudizio umano, nel frattempo, non diventa abbondante: si sposta verso l'alto, verso intenti, architettura ed eccezioni.

The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage

Fri, 21 Aug 2026 00:00:00 GMT

Louis Claxton, del team Applied AI di Anthropic, ha pubblicato il 21 agosto 2026 una guida operativa per un ciclo di vita di sviluppo software "AI-native". Il punto di partenza è uno squilibrio: le organizzazioni oggi scrivono codice a una velocità inimmaginabile un anno prima, ma i processi che lo circondano — gate di approvazione, revisioni, passaggi di consegna, policy — non si sono mossi. Il SDLC tradizionale era pensato per un mondo in cui scrivere codice era la fase più lunga e costosa; i suoi controlli presuppongono inoltre che ogni azione sia compiuta da un umano. Ne derivano tre conseguenze. Il collo di bottiglia si sposta verso le fasi che continuano a funzionare a velocità umana, a monte e a valle della scrittura. I controlli smettono di essere applicabili: leggere ogni riga aveva senso quando a scriverla era stata una persona. E il costo della governance aumenta, poiché le eccezioni passano per comitati periodici. La risposta mantiene gli obiettivi di controllo e ne cambia le modalità di esecuzione. Il processo diventa un loop, con l'IA integrata in ogni punto, organizzato in sei fasi — Plan, Design, Build, Test, Deploy, Maintain — scomposte in *plays* che seguono tutte la stessa griglia, fino alle metriche. Il filo conduttore è l'artefatto committato. L'intento viene catturato dal suo autore originale come `intent.md`; requisiti e design confluiscono in un'unica sessione che produce `spec.md`, vincolata dalle skill di brand, sicurezza, compliance e UX; la build inizia in plan mode e blocca `plan.md` prima che venga scritta qualsiasi riga di codice. La catena dei commit funge da traccia di audit. La conoscenza istituzionale diventa file versionati: `CLAUDE.md` per il contesto del repository, le skill per le policy trasversali, `REVIEW.md` per la dottrina di revisione, `bands.yaml` per le soglie di produzione. La governance si divide in due livelli, con la skill come controllo consultivo e l'hook come livello deterministico che blocca o richiede approvazione. Un esempio di *managed settings* dettaglia, chiave per chiave, cosa garantisce ciascuna impostazione in termini di controllo, dal rifiuto di leggere segreti all'imposizione di una versione minima. La fase Maintain chiude il loop: uno script deterministico monitora una metrica, e il superamento di una banda invoca Claude senza alcun umano nella catena di chiamata, con un livello di autonomia fissato dal tier. Ciò che l'agente rileva viene riscritto come `intent.md` e reimmesso nel ciclo. Claude Tag, in beta pubblica su Slack, estende lo schema agli incidenti che arrivano via chat. Non vengono presentati risultati quantificati: la guida fornisce metriche da misurare e ne indica la fonte.

The Claude Code guide for startups

Thu, 20 Aug 2026 00:00:00 GMT

Michael Segner pubblica una guida sul blog claude.com il 20 agosto 2026, tratta da interviste a più di una dozzina di startup in rapida crescita, quindici delle quali nominate, sul modo in cui utilizzano Claude Code. Il documento ne estrae cinque regole operative e si chiude con una checklist di suggerimenti tecnici. Prima regola, "everyone ships": la programmazione agentica abbassa la barriera d'ingresso, per cui la persona che comprende il problema può rilasciare la prima versione della correzione. Parahelp segnala contributi da dipendenti non tecnici, Crosby gli avvocati che possiedono le migliori intuizioni di prodotto, Heidi la scomparsa di un effetto telefono-senza-fili in cui l'idea si degradava passando dall'ideatore al product manager, poi al designer, poi all'ingegnere. La guida restringe subito la portata: la divisione del lavoro resta, si apre solo il passaggio da zero a uno. Tre meccanismi lo rendono sistemico — collegare lo strumento a fonti di verità tramite MCP o CLI, ritualizzare le demo dei prototipi, condividere le skill. Seconda regola, automate the tedium: gli agenti si fanno carico dell'ottanta percento meccanico del ciclo e gli ingegneri conservano le decisioni di giudizio. ClickHouse dichiara di aver trasformato quasi ogni fase in un loop autonomo, con due agenti a scopo unico diventati il secondo e il terzo contributore del proprio repository. In Anthropic, Claude Tag funge da primo responsabile di reperibilità per i fallimenti dell'integrazione continua. Terza regola, trust but verify: un processo non viene automatizzato senza un modo affidabile per verificarlo. Cainex, sulla codifica medica, descrive un loop di auto-miglioramento in cui le correzioni degli auditor confluiscono nelle istruzioni dell'agente, testate su un golden set, secondo una sola regola — corregere il principio, non l'esempio. Zingage racconta di aver concesso all'inizio troppa autonomia, ottenendo codice plausibile ma che deviava dalla propria architettura, per poi scriverne gli invarianti. La guida indica gli hooks per i gate deterministici e insiste sulla manutenzione dei set di valutazione. Quarta regola, build for rebuilding: le capacità dei modelli continuano a evolvere, per cui poco viene trattato come permanente. Commure fissa il criterio di completamento di una ricostruzione — quando il vecchio percorso è scomparso — e i git worktrees rendono l'esercizio sostenibile. Quinta regola, prototype, dogfood, productionize: l'agente interno costruito con Claude Code diventa, se si rivela convincente, un prodotto rivolto ai clienti tramite l'API, l'SDK o Claude Managed Agents. Le quattro cifre principali restano quelle dichiarate dalle aziende intervistate, senza alcuna descrizione del metodo di rilevamento.

Designing AI with character: what we learned building Berd

Tue, 18 Aug 2026 00:00:00 GMT

Post del blog aziendale di **Block** (`block.xyz/inside`), **non firmato**, pubblicato il **18 agosto 2026**, che annuncia **l'apertura open source di Berd** ed espone la tesi progettuale che l'ha guidata. **Cos'è Berd.** *"Berd is a desktop application our teams use to work with AI agents across projects, skills, tools, and models."* Nato da un problema interno: Block aveva accesso ad agenti capaci — **goose**, **Claude Code**, **Codex** — ma ciascuno imponeva *"different interfaces, configuration systems, and ways of managing context"*. La conclusione tratta: *"we didn't need another model or agent harness, **we needed a consistent environment around them**"*. Berd riunisce conversazioni, file, cartelle, istruzioni, agenti e skill attorno a **progetti persistenti**, per smettere di ricostruire il contesto ad ogni task. **La tesi progettuale.** Dare **carattere** agli agenti — non solo attraverso ruoli, istruzioni, skill e strumenti, ma attraverso **identità visive distinte**, inclusa una collezione di personaggi animati, i *"Gloopies"*. Il problema invocato è quello della casella di prompt vuota: *"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"*. Il post colloca l'approccio nella tradizione di **Square** e **Cash App** — portare il design dove la categoria non ne aveva. **Ma il problema enunciato è un problema di leggibilità della configurazione, e l'avatar risolve la distinguibilità**; il testo lo riconosce in una riga che non sviluppa: *"The avatars make the agent recognizable. **Its role, skills, and tools make it useful.**"* **L'architettura.** Berd discende da **goose**, il framework di agenti open source lanciato da Block nel **gennaio 2025**, conferito all'**Agentic AI Foundation** (Linux Foundation, dicembre 2025) accanto a **MCP** e **AGENTS.md**. Divisione esplicita: *"goose remains the open agent framework and runtime. Berd is a desktop application built around it. **Berd connects to goose through the Agent Client Protocol.**"* goose sostiene l'agent loop, Berd sostiene l'esperienza. **Il seguito è Buzz.** Berd è servito a esplorare il lavoro **solitario**; *"But work rarely stays private"*. Ciò che Berd ha mostrato — *"private space, durable context, recognizable agent identities, reusable skills, visible configuration"* — alimenterà **Buzz**, lo spazio condiviso umano+agente. *"Start alone, then go multiplayer."* **Riserve.** **Nessuna cifra, nessun test utente, nessuna licenza indicata**; un'affermazione isolata eccessiva (*"create custom agents to do any task they want"*); e un post il cui titolo annuncia un consuntivo pur mantenendo il prodotto al presente — **Berd non è dichiarato deprecato, ma la roadmap punta verso Buzz**.

Securing Software at the Speed of AI: What Four Years of Data Reveal

Tue, 18 Aug 2026 00:00:00 GMT

Sonatype pubblica, a firma della sua *technical writer* Aaron Linskens, una sintesi di uno studio longitudinale condotto dai suoi research labs su quarantanove mesi, da giugno 2022 a giugno 2026. Il metodo è dichiarato fin dall'inizio: una coorte fissa di applicazioni monitorate in continuo, in modo che le variazioni misurate riflettano l'evoluzione del parco software piuttosto che quella del portafoglio clienti. Il risultato centrale è presentato come una contraddizione: le organizzazioni rimediano più rapidamente di prima, eppure le loro applicazioni accumulano più rischio. Quattro misure inquadrano il risultato. Le vulnerabilità *Critical* e *High* per applicazione sono state moltiplicate per 4,31, passando da una media di 14,14 a giugno 2022 a 54,3 nel 2026; l'effetto non è dovuto al solo legacy, poiché escludendo le applicazioni legacy portate di recente sotto gestione resta comunque un fattore di 3,91. Le nuove versioni di componenti interessate avanzano a quarantasei volte il tasso pre-IA. L'età mediana delle vulnerabilità è scesa del 59% dal suo picco di gennaio 2024. Infine, la creazione mensile media di applicazioni è stata moltiplicata per 4,84, e con essa le decisioni di dipendenza. I progressi nel rimedio sono reali: oltre la metà delle violazioni risolte lo è in meno di un giorno, e l'età mediana delle vulnerabilità *Critical/High* non risolte scende da 228 a 126 giorni, poi a 103 giorni a maggio 2026. Tra le coorti che hanno avuto almeno dodici mesi per agire, il 52,6% è risolto, il 44,3% resta aperto e il 3,1% è sotto waiver. Il cambiamento proposto riguarda il monte. I ricercatori hanno esaminato le dipendenze vulnerabili entrate nelle applicazioni del periodo e posto una domanda semplice: al momento della selezione, esisteva già una versione sostanzialmente meno rischiosa? La risposta è sì nel 62,2% dei casi su Maven, nel 46,9% su npm, nel 34,3% su PyPI. Il testo rifiuta di leggere questo dato come colpa dello sviluppatore: alcune vulnerabilità sono inevitabili, altre derivano da un gap informativo al momento della scelta — un punto che diventa sensibile quando un assistente IA può introdurre un componente in pochi secondi senza disporre di intelligence aggiornata sul suo rischio e sulla politica organizzativa. Il post riconosce che l'IA non è l'unica causa dell'espansione del panorama delle vulnerabilità e cita quattro fattori concorrenti. Conclude su Sonatype Guide, che porta questa intelligence fino al punto di selezione, e rimanda al report completo, *The AI-Era Software Assembly Line*, per i dati sottostanti.

Projects in Buzz

Tue, 18 Aug 2026 00:00:00 GMT

Post di annuncio di **Block Engineering** firmato da **Thomas Petersen** (*Principal Designer & Builder*), pubblicato il **18 agosto 2026**, che presenta **Buzz Projects** — il mattone forge di **Buzz**, lo spazio di lavoro umani+agenti di Block costruito su **Nostr**. **Il problema enunciato.** *« Software development tools are fragmented in ways the work itself is not. »* La segnalazione di bug sta in uno strumento, la discussione in un altro, la correzione su un branch, la CI altrove, la revisione in un thread di commenti, le note di rilascio ricostruite a posteriori. **La tesi: tutto questo è una sola conversazione, e la storia deve far parte del progetto.** **Ciò che Projects offre.** Una **forge ospitata sul proprio relay**: repository Git standard accessibili tramite `fetch/clone/pull/push` su **Smart HTTP**, *« with no custom tooling or wrapper CLI required »*; **la clé Nostr come identità unica** — *« the same npub that signs your messages signs your pushes »*, senza token separato né account GitHub; **progetti multi-repo** che possono includere repository non posseduti (*« you just won't have authority over it »*); issue, pull request, diff, commenti inline, revisione e merge; un **feed di attività** a livello di server; e il **collegamento di qualsiasi progetto a un numero qualsiasi di canali**, affinché *« the context around a change doesn't disappear the moment agents start writing code »*. Da un canale, un'issue può essere affidata a un agente oppure si può chiedere all'agente di aprire una PR, che rimanda alla conversazione che l'ha generata; l'agente si rivolge all'essere umano tramite l'**Inbox**. **La dottrina, in due parti che il post non assembla mai.** Da un lato, **nessun vincolo preventivo**: *« No forced guardrails, no limitations on what your agents are allowed to help you with. »* Dall'altro, **una registrazione firmata di ogni atto**: *« Every push, review, approval, and merge is a signed Nostr event »*, con una traccia di **quale agente** ha prodotto una patch e **quale essere umano** l'aveva autorizzato. Da qui la proiezione conclusiva: la storia dei contributi diventa *« more than a set of colored squares on a profile »*, una **storia verificabile associata a una chiave**, e Block dichiara di **esplorare *« agent trust protocols informed by past behavior »***. **La fiducia si sposta dall'autorizzazione *ex ante* alla prova *ex post*.** L'inquadramento associato è esplicito: *« 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. »* **Riserve.** **Nessuna cifra, nessun link esterno, nessuna specifica** in tutto il testo; **CI e note di rilascio sono promesse ma assenti dall'inventario**; Projects risiede sotto la **scheda Experiments**, e il post si autosqualifica sei volte — *« Buzz is still in beta and Buzz Projects is still under experiments, so treat it accordingly. »*

The AI Engineering Skills Map

Fri, 14 Aug 2026 00:00:00 GMT

Post X di **Andrew Ng** del **14 agosto 2026**, ripreso dalla lettera "Dear friends" di ***The Batch* #366** (DeepLearning.AI). **Cosa viene annunciato.** *The AI Engineering Skills Map*: **quattro competenze** presentate come le più importanti per uno sviluppatore, sostenute da *« an analysis of more than 10,000 job postings »*, decine di interviste strutturate con esperti, responsabili delle assunzioni e recruiter, sondaggi e altri dati online. Doppio pubblico esplicito: aiutare gli sviluppatori a **dare priorità a ciò che imparano** e i datori di lavoro ad **assumere**. **Le quattro competenze.** **(1) Costruire e distribuire applicazioni IA** — la loro differenza risiede nell'**imprevedibilità degli output**, occorre conoscere i building block (LLM, context engineering, RAG, workflow agentici, machine learning, deep learning) e soprattutto le **tecniche statistiche per misurare, guidare e governare**, incluso *« disciplined evals and error-analysis loops »*. **(2) Fondamenti di ingegneria del software** — comprenderli permette di *« recognize what tradeoffs exist »* (costo, scalabilità, affidabilità, velocità, sicurezza, privacy) e quindi di guidare l'agente *« in the precise language of software engineering »*; il vibe coder inesperto fallisce perché *« they don't know what context to give their agent »*. **(3) Uso di agenti di coding** — un modello mentale dei loro limiti, gestione del contesto, compromessi tra pianificazione ed esecuzione, **fornire verificatori o evals affinché l'agente chiuda da solo i propri cicli**, lavorare con una specifica chiara *« and when not to bother doing so »*, orchestrazione multi-agente, guardrail. **(4) *Shaping the build*** — poiché gli agenti eseguono bene a fronte di una specifica chiara, il lavoro si sposta verso **decidere cosa deve contenere la specifica**: senso del prodotto, contesto di business, ownership del progetto. **Alla base delle quattro: una mentalità di apprendimento continuo**, con *« routines for trying new tools »*. **La vera tesi, infilata in una nota terminologica.** Ng parla di **competenze** nell'ingegneria IA e non del **ruolo** "AI Engineer": *« all developers should know how to work with the cloud, only a small number carry the "Cloud engineer" title »*. **L'ingegneria IA diventa una base comune, non una specialità** — non si assume, si riqualifica. **Due riserve.** **Non viene pubblicato alcun risultato numerico**: nessuna ponderazione, nessuna sotto-competenza, un clustering descritto come un'analogia *« informale »*, e la mappa dettagliata rimandata a post futuri. **Questo è l'annuncio di una mappa, non la mappa.** E l'autore dichiara il proprio interesse: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*

GLM-5.3: Frontier Coding with Emergent Cyber Capabilities

Fri, 14 Aug 2026 00:00:00 GMT

Post di annuncio pubblicato il **14 agosto 2026** sul blog di **Z.ai** (già Zhipu AI), **non firmato**, per il lancio di **GLM-5.3**. **La tesi metodologica.** *« Scaling post-training is all we did for GLM-5.3. »* Stesso modello di base di GLM-5.2: **tutto il guadagno viene dal post-training**, costruito sullo stack del ciclo precedente — **IndexShare** (contesto lungo), **SAO** (RL a lungo orizzonte) e **slime** (addestramento asincrono, Megatron + SGLang). Il collo di bottiglia si è spostato dal modello **all'ambiente**: Z.ai descrive pipeline che **sintetizzano** ambienti e segnale di ricompensa — un agente giudice verifica la risolvibilità, **i verificatori sono sintetizzati senza accesso alla soluzione di riferimento**, e sono ammessi solo dopo un tris di controlli **oracle / no-op / unsolved-state**. Il lavoro resta *« human-in-the-loop »*. Il throughput RL end-to-end è migliorato di **oltre 2,3×**. **I risultati sul coding.** Terminal-Bench 3.0 passa da **4,6 a 28,3**, DeepSWE v1.1 da **46,2 a 66,9**, Agents' Last Exam da **23,8 a 28,5**. Sullo **Z.ai Code Bench**, un benchmark **interno e privato**, +50% rispetto a GLM-5.2, con un guadagno simultaneo in **efficienza dei token**: 34,5% a ~75K token di output a effort Max (contro 23,4% a 96K per GLM-5.2), e 31,4% a ~50K a effort High — davanti a Claude Opus 4.8 (29,5% a 120K). **Claude Fable 5 resta davanti al 39,5%.** L'affermazione *« most capable open-weights model for coding »* **non discende dalla tabella**: contro **Kimi K3**, il punteggio è di **3–3 con un pareggio**. **La capacità cyber.** Presentata come *« emergente »*, è stata **addestrata deliberatamente** — il post scrive *« we expected this to make the model better »*. Ciò che è arrivato come sorpresa è stata la **velocità**, e il passaggio da falle isolate alla **catena di exploitation completa**. CyberGym **84,5%** (il migliore in tabella), ExploitBench **54,4%** (×2,2), ExploitGym **105/130 task** (×3,6 rispetto a GLM-5.2, budget normalizzati per throughput). Frase chiave: ***« Capability is growing fastest exactly where we are furthest behind. »*** **Il numero più pesante.** Lavorando con team di sicurezza cinesi, il modello ha identificato **2.436 vulnerabilità in 269 progetti open source** — kernel, sistemi operativi, motori browser, protocolli di rete — la più vecchia introdotta nel **1981**, durata media **26,6 anni**. Il **Security Disclosure Ledger** mostra **53 divulgate** e **2.383 sotto embargo**: **2,2% pubblicate**. **Governance.** Rilascio dei pesi annunciato *« in two weeks, once safety evaluation and hardening are complete »* — **una data, non un criterio**: nessuna definizione di hardening, nessuna condizione di non rilascio, nessun valutatore terzo. **Varie.** `thinking.type: "disabled"` **non è più supportato** (migrazione richiesta); quote del GLM Coding Plan in punti, **50% fuori dalla fascia 14:00–18:00 UTC+8**; **quasi tutte le valutazioni sono condotte in Claude Code 2.1.207**.

DeepSeek Harness developer preview: Everything is a plugin

Thu, 13 Aug 2026 00:00:00 GMT

Pagina di lancio prodotto pubblicata il **13 agosto 2026** da **DeepSeek**, **non firmata**, per 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. **Cosa dice la pagina.** Due promesse, in quattrocento parole e senza una sola cifra. **« Everything is a plugin »**: ogni capacità — modelli, strumenti, skill, sessioni, sandbox, storage, loop, scheduling, interfaccia — è un plugin **sostituibile tramite configurazione, senza modificare il codice sorgente**. **« Every run is traceable »**: tutto ciò che il modello vede viene registrato in un **session log append-only** — system prompt, ragionamento, chiamate agli strumenti e risultati, scheduling dei subagent, ogni iniezione di contesto — e *« resume, fork, search and replay all operate on the same event stream »*. Il nucleo è **Cordis**, un framework di terze parti vendorizzato, descritto in un paper esterno e accreditato in modo prominente. Vengono rilasciate quattro modalità di esecuzione: **modalità Standard** (tooling completo), **mode Code** (strumenti esposti tramite un SDK TypeScript per combinare più operazioni in un unico programma), **mode Minimal** (due strumenti, bash persistente e `str_replace_editor`, *« for benchmarking models in a minimal environment »*), e **modalità Creator** (ispezione a runtime, test di plugin in memoria, composizione di nuove modalità). Per iniziare: `npx @deepseek-ai/dsh web`. **Cosa non dice la pagina.** L'affermazione più forte si trova in `docs/architecture.md`: ***« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it. »*** **Una garanzia asserita a runtime**, non un'affermazione da vetrina — è questa la proprietà che davvero distingue DSH, ed è assente dal materiale promozionale. Lo stesso repository fornisce la confutazione: `SESSION_FORMAT_VERSION` resta a **`0` senza alcuna promessa di compatibilità**, *« backends reject old on-disk formats »*, e il README avverte in maiuscolo che ci saranno breaking change. **Tracciabile oggi non significa archiviabile domani.** **Il modello di business è nella cronologia.** DSH viene rilasciato il giorno della **GA di DeepSeek-V4-Pro** e **tre giorni prima** dell'entrata in vigore di un nuovo listino prezzi API (16 agosto, 16:00 UTC; tariffe fuori picco al **−50%**). **Harness regalato, inferenza resa più cara** — l'esatto opposto del modello di Anthropic. **Ciò che regge alla verifica.** La sostituibilità tiene almeno a livello di modello: oltre all'adapter DeepSeek, **`dsh-llm-pi-ai`** rende accessibile qualsiasi gateway compatibile con OpenAI *« by configuration, not by code change »*. E il mode Minimal integra nel prodotto l'**harness di benchmarking** — un tentativo di sottrarre a Claude Code la definizione del benchmark, anche se il repository di DSH stesso contiene un `CLAUDE.md` e una `.claude/skills`.

Buzz (buzz.xyz) — Rapport de recherche pour présentation

Wed, 12 Aug 2026 00:00:00 GMT

Rapporto di ricerca interno datato **12 agosto 2026** che consolida, a scopo divulgativo, lo stato pubblico di **Buzz**, lo spazio di lavoro umani+agenti di **Block** lanciato il **21 luglio 2026** sotto licenza **Apache 2.0**. Aggrega i due post tecnici di Block, l'annuncio aziendale, il repository GitHub, la copertura stampa, X e **tre valutazioni indipendenti** — quest'ultimo strato porta la maggior parte del valore aggiunto. **Il concetto.** Buzz fonde chat di team, una forge Git e workflow automatizzati in un unico spazio dove gli agenti sono **membri a pieno titolo, non bot**. La tesi è quella di Tyler Longwell: *"The bottleneck moved from intelligence to coordination."* Bradley Axen (Head of AI Capabilities) inquadra la posta in gioco di mercato: *"Every company is going to need a place where humans and agents work together. The question is whether that place is proprietary or open."* **L'architettura.** Un relay in **Rust** su **Nostr** (NIP-01/42/98/34, 127 *event kinds*), **Postgres**, **Redis**, **S3/MinIO**, desktop **Tauri+React**. Ogni partecipante detiene una keypair; ogni messaggio, review, passo di workflow ed evento Git è **firmato** in un log di audit append-only con hash-chain. Un grado di formalismo raro per una **v0.4.x/0.5.x**: isolamento multi-tenant meccanizzato in **TLA+**, proprietà di autorizzazione verificate in **Tamarin**. L'integrazione degli agenti passa attraverso **`buzz-acp`**, un harness **ACP** che collega goose, Codex e Claude Code e **traduce ACP ↔ MCP** — *"They compose through protocols, not imports."* **Il divario centrale.** Jack Dorsey annuncia *"decentralized, self-sovereign"*; il file `ARCHITECTURE.md` di Block afferma: *"The relay is the single source of truth… There is no peer-to-peer event exchange, no gossip, no replication."* Un relay unico per comunità, dunque un **punto singolo di guasto**: la decentralizzazione è **sovranità organizzativa**, non ridondanza. **I limiti, documentati.** L'unità di autorizzazione è l'**appartenenza al canale** — *"channel membership is not fine-grained tool authorization"*; gli agenti girano in **`--dangerously-skip-permissions`**, fuori da qualsiasi sandbox; **l'osservabilità è carente** (*"It doesn't tell me what happens next"*, kill silenziosi per OOM). Gli eventi firmati sono *tamper-evident*, non *tamper-resistant*: un operatore di relay compromesso può cancellarli. Sul relay ospitato, non c'è **cifratura end-to-end**. **Una correzione di dati.** Il "+33% more work" è il **rapporto tra task completati (20 su 44 contro 15)**, non un guadagno di punteggio — che passa da 59,1% a 71,5%, cioè **+12,4 pt**. **Accoglienza**: ~25.900 stelle GitHub, un tweet di Dorsey a ~2,3-2,7M visualizzazioni, l'endorsement di Sundar Pichai, e la formulazione di Justin Waldron: *"the first proper multiplayer agent harness"*. Riserve riconosciute: benchmark **auto-valutati da Block**, nessun prezzo di hosting pubblicato, nessun dato di adozione.

I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

Wed, 12 Aug 2026 00:00:00 GMT

Resoconto di esperienza pubblicato su **LinkedIn Pulse** il **12 agosto 2026** da **Guillaume Dumortier** (newsletter *Growth Marketing Fit*), su un sistema AI marketing interno costruito **in Claude** per un team di una sessantina di persone: una trentina di skill, una dozzina di moduli di verità, **sette agenti, sei dei quali si limitano a verificare il lavoro**, un plugin da terminale, un'applicazione browser e l'orchestrazione multi-asset delle campagne. **La tesi.** *« I thought I was building a content machine. I was building a trust machine. »* La qualità di un output AI non si determina alla generazione, ma da **ciò che il sistema sa in anticipo** e da **ciò che accade alla bozza in seguito**. La generazione è la parte facile — e l'unica che la maggior parte dei team ha costruito. **Quattro livelli.** *Truth*: documenti di fatti separati da tutto ciò che produce contenuto, ciascuno con un proprietario, versionato e datato. Lasciare i fatti dentro le skill ha prodotto **quattro versioni di una data di lancio in quattro file diversi**, ciascuna individualmente plausibile. *Production*: la skill del blog ha passato settimane a scrivere **descrizioni di articoli** invece di articoli, superando ogni revisione, perché la revisione controllava la struttura. Oltre le trenta skill, il problema diventa il **routing** — metà di ogni descrizione di skill deve dichiarare a cosa non serve. *Verification*: il livello che separa una demo da un sistema. *Internal distribution*: dove i progetti muoiono per essere eccellenti e usati da quattro persone. **I due fallimenti centrali.** Un fact-checker riceve un'affermazione che nessuna delle sue fonti copre: restituisce un « pass ». *« It didn't just miss the error, it certified it. »* Correzione: un verificatore è un **sistema a mondo chiuso**; **gli è vietato restituire un « pass » nudo** e deve dichiarare la propria copertura — quante affermazioni controllate, quante effettivamente corrisposte, quali cadevano fuori dalla sua giurisdizione, quali non erano possedute da nessuna fonte. *« An unverifiable claim is a finding, not a silence. »* Secondo fallimento: **due asset individualmente corretti possono contraddirsi a vicenda**; la verifica per singolo asset non può coglierlo, per costruzione. **Cinque regole trasversali.** Non chiedere mai a un modello qualcosa che si può far rispettare nel codice. I **fallimenti silenziosi** sono l'intero rischio — una costante svuotata ha eliminato ogni numero da ogni prompt, e il colpevole individuato era il modello per aver « allucinato ». Testare la pipeline, non solo l'output. La propria validazione ha le stesse lacune del proprio sistema. **Insegnare al sistema a rifiutare.** **L'adozione segue la fiducia, non la capacità**: un output che ammette ciò di cui non è sicuro viene usato. Clausola conclusiva: ***« The generation is free. The trust is the product. »***

Agent Plugins package your skills, tools, and more

Thu, 06 Aug 2026 00:00:00 GMT

Post tecnico di **Google** del **6 agosto 2026** che annuncia l'adesione dell'azienda 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**. **Prima il fatto di governance.** La specifica è stata pubblicata da un TSC di Core Maintainer provenienti da **Amazon, Cursor, Microsoft, OpenAI e Vercel**. Google li raggiunge, rappresentata nominalmente da **Kevin Hou** (Google DeepMind). Sei concorrenti concordano su un livello di packaging. **Anthropic non compare nell'elenco dei maintainer**, pur essendo all'origine dei due mattoni impacchettati. **La diagnosi.** Una skill è portabile, un server MCP è portabile — *"The core problem isn't the components. It's the manifest."* Ciò che non è mai stato portabile è il contenitore: la struttura delle directory, i metadati del manifest, la forma della configurazione MCP e l'inferenza del trasporto differiscono da un client all'altro. Si fa fork, si mantengono due copie di componenti identici, e queste divergono nel tempo. **Il formato.** *"A plugin is a directory. That's the whole idea, and the restraint is the point."* Un `plugin.json` ridotto a `$schema` e `name`; le skill in `skills/`, nel formato Agent Skills; i server in `mcp.json`, **con un `type` esplicito** su ogni voce (stdio, Streamable HTTP, legacy HTTP+SSE). La forza del design sta in ciò che il manifest **non può** fare: né rilocare un componente né dichiararlo inline. Quindi non esiste un percorso di discovery da configurare, né un ordine di precedenza da imparare. Corollario: **i componenti falliscono in modo indipendente** — un server che non riesce ad avviarsi non trascina con sé le skill. Una directory **reverse-domain** (`com.example.client/`) funge da spazio di estensione proprietario, ignorato dagli altri client: il nucleo portabile resta piccolo perché le parti non portabili hanno un posto dove andare. **I limiti, dichiarati apertamente.** Un'intera sezione spiega **quando non creare un plugin** (un singolo server MCP, una singola skill: superfluo). Un'altra elenca ciò che v1 esclude: **installazione, distribuzione, permessi, sandboxing, verifica di fiducia e provenienza, UX**. Giustificazione: gli obblighi di un IDE, di una CLI e di una piattaforma enterprise differiscono realmente. **Lo stack.** Trovare (**Agentic Resource Discovery**), descrivere (**AI Catalog**), impacchettare (**Agent Plugins**), eseguire (**MCP + Agent Skills**) — ogni livello adottabile in modo indipendente. **Disponibili da subito**: **Agents CLI** (utilizzabile da Antigravity, Gemini CLI, Claude Code o Cursor) e **Data Agent Kit** (BigQuery, Spanner, Cloud SQL). *"Those skills were already distributable. Now they're distributable in a format that isn't ours alone."* Riga di chiusura: *"Packaging is unglamorous infrastructure,"* ed è esattamente ciò che va condiviso invece di essere reinventato cinque volte.

Graphify — Knowledge Graphs for AI Coding Assistants (site graphify.net : vitrine, annuaire d'outils et galerie de dépôts graphifiés)

Thu, 06 Aug 2026 00:00:00 GMT

Il sito **graphify.net**, consultato il 6 agosto 2026, ufficialmente di proprietà di **Safi Shamsi**, creatore della skill open source graphify. Il dominio veicola tre elementi distinti dalla piattaforma commerciale `graphify.com` e dal repository GitHub. **Una vetrina di prodotto**, anzitutto: presentazione di graphify, guide d'uso, riferimento CLI, pagine su tree-sitter e sul clustering di Leiden. **Una galleria di demo**, poi, ed è la parte più convincente: **100 repository GitHub Trending già graphificati**, per un totale di **854,079 nodi e 1,932,930 archi**, filtrabili per linguaggio e dimensione, ciascuno con il proprio conteggio di nodi, archi e comunità, corredato da un'anteprima del grafo e da una pagina di dettaglio. Mostrare lo strumento all'opera su repository già noti vale più di un pitch, e produce, come sottoprodotto, un dataset pubblico di grafi comparabili. **Una directory editoriale**, infine, che ha un valore indipendente dal prodotto che promuove: **30 AI coding client guides** confrontate su workflow, agenti, prezzi, sicurezza e idoneità alla delivery; una **directory di server MCP** valutata su transport, runtime, client supportati, sforzo di configurazione e **rischi di accesso**; confronti a coppie su campi allineati. Il sito rivendica un metodo — *« source-reviewed »*, evidenze ufficiali, incognite esplicite — ed è disponibile in sei lingue. **Questa scheda esiste principalmente per registrare una discrepanza.** Nello stesso giorno, il sito annuncia **« 3.7k+ GitHub stars »** mentre l'API ne conta **103,187**; afferma **tre volte** una licenza **MIT** 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 a favore dei benchmark LOCOMO e LongMemEval. Il sito descrive quindi un prodotto vecchio di più generazioni. **L'errore sulla licenza è il più grave**: MIT e Apache 2.0 non comportano gli stessi obblighi, in particolare in materia di brevetti e di divulgazione delle modifiche. Resta un'osservazione strategica: **un fornitore di uno strumento che costruisce la directory della propria stessa categoria** occupa la query di valutazione prima dei concorrenti. La rivendicazione di neutralità non rimuove il conflitto d'interessi — graphify compare tra le skill in evidenza del sito. Un punto d'ingresso utile, non un arbitro.

Efficient Tokens & Effective Teams in Buzz

Thu, 06 Aug 2026 00:00:00 GMT

Un post di benchmark di **Block** firmato da **Atish Patel**, pubblicato il **6 agosto 2026**, che estende il lancio di **Buzz**: dal momento in cui assemblare un team di agenti è diventato banale, *qual è il più economico che riesce in modo affidabile?* **Prima il vocabolario.** Il post propone quattro livelli: **QuickBee** (veloce ed economico — build, screenshot, test, triage di prima battuta: GPT-5.6 Luna, DeepSeek V4 Flash, modelli locali, **eseguito a effort high**), **WorkerBee** (versatile, porta avanti un intero sottoinsieme senza supervisione: GPT-5.6 Terra, Gemini 3.6 Flash, modelli open), **SmartBee** (visione d'insieme, trade-off, escalation: Claude Opus 5, Kimi K3, GPT-5.6 Sol, **a effort *medium***), e l'essere umano, *"l'ape più costosa del team, e la più lenta. Anche se resta la più intelligente"*. Due forme di team: l'**Hive** permanente, che ricorda le preferenze **dell'utente**, e lo **Swarm** usa e getta, che ricorda **il progetto** e poi scompare. **Il risultato in solo.** Su **Terminal-Bench 2.1**, aumentare l'effort di un **modello economico** è il miglior investimento: Luna passa da 1,61 $ / 57,3% (*medium*) a 4,98 $ / 75,0% (*high*). All'estremo opposto, **Opus 5 a effort *xhigh* è l'esecuzione più costosa (140,63 $) e ottiene solo il 75,0%**, avendo **raggiunto il timeout su 17 dei 88 compiti** a causa di un eccesso di ragionamento. Tra le sei esecuzioni migliori: **uno scarto di prezzo di 5,5×, uno scarto di punteggio di 8,9 punti**. Conclusione: *"scegliere tra loro non è affatto una decisione di qualità. È una decisione di budget."* **Il risultato di team, in due atti.** Su Terminal-Bench 2.1, sono state testate **dodici composizioni** e **nessuna ha battuto il solo a parità di costo** — un compito breve non ha abbastanza struttura da poter essere suddiviso. Su **Long-Horizon Terminal-Bench** (44 compiti pluriorari, modello guida GPT-5.6 Sol, **3× il timeout**), il ribaltamento è netto: solo **15 compiti / 59,1%**, +2 WorkerBee **20 / 71,5%** — **+12,4 punti, di cui 11,4 provengono da completamenti aggiuntivi**. Il team costa di più per compito, il che si ripaga *"quando l'alternativa è un essere umano che riprende un lavoro non finito"*. **La regola operativa.** Instradare le escalation dei worker verso un **coordinatore SmartBee** piuttosto che verso l'essere umano: *"ogni ambiguità diventa una notifica"* è la vera modalità di guasto. Un ingegnere di Block afferma di aver **migrato oltre 2.000 app** con uno Swarm (coordinatore, 1-10 migratori, verificatore indipendente), con il coordinatore che memorizza le risposte umane. **Avvertenze**: n=1 per compito, nessun intervallo di confidenza, costi del team non pubblicati, e un'ammissione — *"questo potrebbe cambiare se i modelli venissero addestrati a una collaborazione migliore."*

graphify — « Turn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store. »

Thu, 06 Aug 2026 00:00:00 GMT

**graphify** (Safi Shamsi, Graphify Labs, Y Combinator S26) trasforma un intero progetto in un **grafo di conoscenza interrogabile**, invocato tramite `/graphify` da Claude Code, Cursor, Codex, Gemini CLI e una quindicina di altri client. Osservato il 6 agosto 2026: **103.187 stelle** per un repository creato il 3 aprile, Apache-2.0, Python. **Tre scelte di design sostengono il progetto.** **Il codice viene analizzato localmente** in un AST tree-sitter, senza LLM: deterministico, nulla lascia la macchina, nessuna chiave API richiesta per un corpus composto solo da codice. **Ogni arco porta con sé la propria provenienza** — `EXTRACTED` se esplicito nella fonte, `INFERRED` se risolto da graphify —, *"so you can tell what was read directly from what was inferred"*. E il progetto si definisce **in opposizione al RAG vettoriale**: *"Not a vector index. No embeddings, no vector store: a real graph you traverse."* **L'uso sostituisce grep.** `query` restituisce un sottografo per una domanda in linguaggio naturale, `path A B` traccia il percorso tra due entità, `explain` dispiega un concetto. Tre output: un grafo interattivo, un report leggibile (nodi centrali, connessioni sorprendenti, domande suggerite) e un `graph.json` persistente, interrogabile settimane dopo. **La copertura va oltre il codice**: 36 grammatiche tree-sitter, ma anche SQL, Terraform, Apex, **configurazioni MCP**, manifest di pacchetti, Office, PDF, immagini e video trascritti localmente. I commenti `# WHY:` e le motivazioni di design diventano **nodi di prima classe collegati al codice che spiegano**. **I benchmark richiedono una lettura attenta.** Su LOCOMO, graphify domina in recall (0,497 contro 0,149 e 0,048) ma **perde in accuratezza QA** (45,3% contro 49,7%); su LongMemEval-S **eguaglia un RAG denso** al 76%. La riga che conta è altrove: *"Graph build — LLM credits: 0"*. Il differenziatore difendibile è **il costo e la tracciabilità, non la qualità delle risposte**. **Tre avvertenze.** Il branch `main` porta un README obsoleto dell'epoca v1 che descrive un prodotto diverso: leggere `v8`. Il pacchetto PyPI si chiama `graphifyy`, mentre il nome è in fase di recupero. E un **log delle query locale** è attivo per impostazione predefinita, disattivabile tramite una variabile d'ambiente. La skill funge anche da punto d'ingresso a una piattaforma commerciale con lista d'attesa su graphify.com, che applica in continuo lo stesso approccio all'intero contesto di lavoro.

Introducing Muse Code and Muse Spark 1.2

Wed, 05 Aug 2026 00:00:00 GMT

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**.

How to use Notion as Code

Mon, 03 Aug 2026 00:00:00 GMT

Documentazione **Notion as Code**, un prodotto in **alpha chiusa**, consultata il 3 agosto 2026 sul workspace Notion Ambassadors — senza autore né data, e con un avviso che raccomanda di provarlo su un workspace nuovo e mette in guardia su possibili breaking changes. **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 l'endpoint **`/v1/infra_as_code`** per implementarlo. **Il meccanismo che regge tutto** è l'indirezione tramite identificatore. Lo script **non contiene alcun identificatore Notion**: dichiara valori `resourceId` scelti dall'autore. Il primo deployment restituisce una **tabella di mappatura** tra questi identificatori logici e i record effettivamente creati; ripassata nelle chiamate successive, garantisce che gli stessi record vengano **aggiornati anziché ricreati**. **Ne derivano tre proprietà.** Lo script diventa **idempotente**. Diventa **disaccoppiato dal workspace** — più tabelle di mappatura permettono di distribuire **lo stesso script su più workspace**. E trattandosi di codice, supporta variabili e cicli: l'esempio fornito è la costruzione di dieci team di struttura identica cambiando solo alcuni nomi. **Il contratto API è asincrono**: una `POST` restituisce un `taskId`, interrogato fino al completamento; la risposta porta le tabelle di mappatura da conservare — l'equivalente di un file di stato. **Due differenze operative**: il prodotto richiede **personal access token** anziché i consueti token bot, il che attribuisce le azioni a una persona anziché a un'integrazione; e il **rate limit scende a 5 richieste al minuto**, una chiamata essendo ormai un batch anziché una singola entità. **Il prodotto presuppone l'agente.** L'SDK è presentato come costruito *« for you or your coding agent »*, e il percorso di onboarding consiste nel lasciare che un agente legga il README dell'SDK. Un descrittore di stato tipizzato è effettivamente uno strumento migliore per un agente rispetto a una serie di chiamate imperative: l'errore vi è replicabile anziché cumulativo. **Cosa manca**: nessuna menzione dell'eliminazione degli elementi rimossi dallo script, nessuna modalità di anteprima prima dell'applicazione, nulla sulla concorrenza, e nessuna data su una documentazione destinata a cambiare.

hyperresearch — « The Most Powerful Deep Research Harness » / « Agent-driven research knowledge base. Agents collect, search, and synthesize web research into a persistent, searchable wiki. »

Mon, 03 Aug 2026 00:00:00 GMT

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.

Agent Client Protocol — Introduction

Sun, 02 Aug 2026 00:00:00 GMT

Pagina introduttiva della specifica dell'**Agent Client Protocol**, consultata il 2 agosto 2026. Un artefatto vivo senza data di pubblicazione: la scheda è datata in base alla sua osservazione. **Il problema.** *« AI coding agents and editors are tightly coupled but interoperability isn't the default. »* Ogni editor deve costruire un'integrazione personalizzata per ogni agente che vuole supportare, e ogni agente deve implementare le API specifiche di ogni editor. Ne derivano tre costi distinti: **onere di integrazione** (ogni combinazione agente-editor richiede lavoro specifico), **compatibilità limitata** (un agente raggiunge solo una frazione degli editor) e **dipendenza dal fornitore per lo sviluppatore** — *« choosing an agent often means accepting their available interfaces »*. **La soluzione.** ACP standardizza la comunicazione agente-editor *« similar to how the Language Server Protocol (LSP) standardized language server integration »*. Il beneficio è reciproco ed è ciò che tiene insieme l'ecosistema: un agente che implementa ACP funziona con qualsiasi editor compatibile; un editor che supporta ACP accede all'intero ecosistema di agenti ACP. *« This decoupling allows both sides to innovate independently. »* **L'architettura.** ACP presuppone che l'utente sia **principalmente nel proprio editor** e ricorra a un agente per un compito specifico. Due modalità di distribuzione: gli agenti **locali** girano come sottoprocesso dell'editor e comunicano via **JSON-RPC su stdio**; gli agenti **remoti**, ospitati nel cloud o su infrastrutture separate, comunicano via **HTTP o WebSocket** — supporto dichiarato *« a work in progress »*, con collaborazione attiva con piattaforme agentiche. La seconda modalità viene regolarmente omessa dalla copertura secondaria, pur tracciando la traiettoria enterprise del protocollo. **Il legame con MCP** è più stretto di una complementarità architetturale: ACP *« re-uses the JSON representations used in MCP where possible »*, aggiungendo al contempo tipi specifici all'UX della codifica agentica — la visualizzazione dei **diff** è l'esempio riportato. Il formato predefinito per il testo leggibile è **Markdown**, scelto proprio affinché l'editor non sia tenuto a renderizzare HTML. **Due osservazioni sulla fonte stessa.** La navigazione espone **v1 (Latest)** e **v2 (Draft)** — non l'"ACP 1.2" che circola altrove. E collega **Zed Industries e JetBrains allo stesso livello**, accanto a un **ACP Registry**, alle **RFD**, a una sezione Community, Publications, Updates e una pagina Brand: la struttura di un progetto co-governato con un processo. Librerie ufficiali in Kotlin, Java, Python, Rust e TypeScript.

ACP : deux protocoles, un sigle, zéro rapport

Sun, 02 Aug 2026 00:00:00 GMT

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.

Code review dans le SDLC augmenté : l'anneau de contraintes autour des agents

Thu, 30 Jul 2026 00:00:00 GMT

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?"**

Mon usine logicielle à l'heure de l'IA

Tue, 28 Jul 2026 00:00:00 GMT

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."*

Anthropic sécurise un SDLC où l'IA écrit 80 % du code : le cycle redevient le socle

Sun, 26 Jul 2026 00:00:00 GMT

Cinque giorni dopo il resoconto di Jason Clinton (Deputy CISO di Anthropic) sulla messa in sicurezza di un ciclo di sviluppo diventato AI-native, SFEIR pubblica una decodifica che non contesta nulla e non aggiunge alcun fatto: **sposta il soggetto**. Il lettore viene a cercare controlli di sicurezza; gli viene mostrato che ciò che manca prima di tutto è un ciclo. Il resoconto è fedele. Tre misure di partenza, autodichiarate da Anthropic: ×8 di codice spedito per ingegnere a trimestre, ~80% del codice mergiato scritto da Claude, oltre la metà mergiato dalla versione interna di Claude Tag. Un problema posto dalla **legge di Amdahl**: se la revisione e il monitoraggio non scalano allo stesso ritmo della produzione, l'accelerazione diventa un collo di bottiglia. Un modello di minaccia esplicito (agente compromesso o vittima di prompt injection, avvelenamento delle dipendenze, aumento del volume di vulnerabilità classiche). Poi un controllo mappato per fase: **PSR** in fase Plan, **CLAUDE.md** ed **egress allowlist** in fase Code, **agenti di revisione specializzati** in fase Test, **DAST continuo** in fase Deploy, **triage e instradamento SIEM** in fase Monitor. La tesi si regge su un'anafora in quattro parti. **Senza uno SDLC, i guadagni non si materializzano**: moltiplicare per 8 il volume di codice non moltiplica nulla se la revisione resta sequenziale — 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." **Senza uno SDLC, la sicurezza non ha un ancoraggio**: un gate è per definizione un controllo posto tra due fasi. **Senza uno SDLC, nessuna politica di FinOps dei token può essere formulata**: la scansione 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." **Senza uno SDLC, non c'è nulla da misurare**: il passaggio dal 16% al 54% delle PR commentate presuppone una fase in cui si può collocare un contatore; in sua assenza, si producono solo cifre di utilizzo, mute su qualità e rischio. Due contributi oltre la tesi. La lettura dell'incident agent-à-agent — un agente di risposta agli incidenti che chiede a un'altra istanza di Claude, via Slack, di spingere una correzione, bloccato da un gate umano: "un perimetro che si fonda su un'istruzione in un prompt non è un perimetro," e l'accesso di un agente ad altri agenti fa parte della sua superficie di attacco. E un avvertimento chiaro: queste cifre provengono dal fornitore del modello, su una codebase giovane senza mainframe. **Ciò che si traspone è il metodo, non le cifre.**

SDLC vs PDLC : quelle différence, et pourquoi l'IA change tout

Wed, 22 Jul 2026 00:00:00 GMT

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."

How Anthropic secures its AI-native software development lifecycle

Tue, 21 Jul 2026 00:00:00 GMT

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.

Buzz!

Tue, 21 Jul 2026 00:00:00 GMT

Post tecnico di **Block**, firmato da **Tyler Longwell**, pubblicato il **21 luglio 2026**, che annuncia **Buzz**: uno spazio di lavoro *open source*, **self-hostable**, organizzato per canali, in cui esseri umani e agenti lavorano nella stessa stanza — messaggistica, ricerca, automazione **e hosting Git** su un unico server. **Il punto di partenza è un fallimento vissuto.** L'autore ha costruito il primo agente Slack di Block; funzionava, ma lasciava senza risposta questioni operative: ognuno ha un proprio bot? Se un bot è condiviso, **di chi sono le credenziali**? Cosa succede quando un team cambia modello o *runtime*? Da qui la tesi: *« 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. »* **Il substrato è Nostr** — un protocollo aperto per messaggi firmati e identità portabili. Un'identità è una **keypair**, ogni azione è firmata: la stessa identità invia un messaggio, autorizza un agente, approva un *workflow*, firma un commit, esegue il merge di una modifica. **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. **Il cuore del post è l'identità dell'agente.** Anziché prestare le proprie credenziali a un bot — *« Abbiamo lasciato che i bot si travestissero da noi »* — ogni agente riceve **una chiave propria**. Il suo proprietario firma un'**autorizzazione ristretta**; l'agente firma poi il proprio lavoro **a proprio nome**. La scelta semantica è esplicita: ***« l'autorizzazione non cancella la paternità »***. La chiave di un agente compromesso viene revocata **senza toccare l'identità umana**; il ritiro del proprietario disconnette l'agente. **Secondo elemento di ingegneria: Git su object storage.** Gli agenti eliminano il limitatore di frequenza che un tempo erano gli esseri umani; un gruppo produce mesi di commit-persona in un solo pomeriggio. Buzz memorizza i repository come **packfile immutabili e indirizzati per contenuto** più **un puntatore di manifest mutabile**, fatto avanzare tramite **compare-and-swap condizionale** — quello *swap* è il punto di commit, gli eventi del canale lo annunciano senza definirlo. Il protocollo è **specificato in TLA+** e verificato tramite model checking; il risultato dipende da **tre garanzie dell'object store**, da cui una **suite di conformità** per ogni *backend*. **Il valore promesso è mnemonico**: un canale effimero per attività aggrega discussione, patch, CI, revisione e decisione firmata. *« Una forge convenzionale conserva il diff e una spunta verde. Buzz conserva anche il motivo per cui la correzione ovvia era sbagliata. »* **E l'open source viene argomentato così**: *« siamo nel 2026: il software è diventato economico. Il gusto no. »* Se Buzz sparisse, identità e cronologia firmata resterebbero comunque verificabili. Nessuna cifra, nessun benchmark: il post è un'esposizione di design, non una prova di effetto.

ADHD — a skill for agents (Parallel Divergent Ideation for Coding Agents)

Mon, 20 Jul 2026 00:00:00 GMT

Udit Akhouri rilascia **ADHD** ("a skill for agents"), un progetto open source (MIT, v0.1.4, ~1.000 stelle) che affronta la **convergenza prematura** del ragionamento autoregressivo: un LLM si ancora alla sua prima idea, e i metodi ad albero non sfuggono davvero a questo fenomeno — "Tree-of-Thought amplia la ricerca ma attraversa un unico contesto condiviso, per cui l'ancoraggio persiste tra i rami." La posizione del progetto: si tratta di un **problema architetturale, non di prompting**. La meccanica consiste in due fasi **a tenuta stagna**. *Diverge*: N chiamate agente parallele, **isolate** — nessun contesto condiviso — ciascuna riceve il problema attraverso uno dei **15 frame cognitivi** deliberatamente distorti (con logica di selezione e frame personalizzati), sotto un system prompt che **vieta di valutare**. *Focus*: un critico **separato**, con un system prompt opposto, valuta le idee (originalità, fattibilità, pertinenza), le raggruppa per angolazione sottostante, **segnala le trappole con le relative motivazioni** e approfondisce i migliori sopravvissuti. La separazione generatore/critico è "meccanica": chiamate LLM distinte, non ruoli simulati all'interno di un unico contesto — la stessa intuizione della revisione avversariale a contesto separato del progetto Bun ([[sumner-bun-rewrite-rust-claude-2026-07-08]]). La demo caratteristica confronta, su "una CLI che chiama un LLM e talvolta si blocca per 90s", la baseline (4 pattern da manuale: timeout progressivi, backoff esponenziale, richieste hedged, streaming — "la risposta che un senior dà in 30 secondi") con ADHD: oltre 30 idee suddivise in 6 cluster, **20 trappole nominate**, e una scelta non ovvia — il pulsante **"rage-quit"** che si anima con l'attesa e reindirizza istantaneamente la richiesta verso un modello più veloce ed economico, perché "il modello lento potrebbe semplicemente essere il modello sbagliato per questo prompt." Su 6 problemi aperti, la valutazione dell'autore (giudice LLM) assegna ampiezza 9,00 contro 4,83, novità 7,83 contro 2,67, **rilevamento delle trappole 9,50 contro 1,83**, applicabilità 9,50 contro 6,50 — cifre autodichiarate, da leggere come affermazioni. La distribuzione passa attraverso l'ecosistema **skills** (stesso canale di [[skill-pocock-grill-with-docs-2026-06]]): `npx skills add UditAkhourii/adhd` rileva automaticamente ~50 agenti (Claude Code, Cursor, Codex, Cline, Gemini CLI, Windsurf…), invocazione tramite `/adhd` o attivazione automatica sugli intenti di ideazione, una CLI e una libreria npm, il tutto costruito sugli Agent SDK di Claude e Codex. La trazione è tangibile: un servizio su The New Stack, un preprint, l'adozione da parte di repowire (PR #313 mergiata — i frame diventano "peer" del mesh-orchestrator), mstack (plugin `think`), zk-flow-oss, e una revisione di ricerca indipendente (testdouble/han) i cui risultati proseguono in issue pubbliche. Insegnamento: una divergenza utile non si ottiene con il prompting, si **architetta** — tramite l'isolamento del contesto e l'opposizione meccanica generatore/critico.

Reflecting on a year of Claude Code

Fri, 17 Jul 2026 00:00:00 GMT

Boris Cherny (**Head of Claude Code**) e Cat Wu (**Head of Product, Claude Code**) pubblicano su LinkedIn, tramite Claude for Business, un breve video (~47 s) intitolato **"Reflecting on a year of Claude Code".** La loro tesi: nell'era degli agenti di codifica, **i ruoli di prodotto e ingegneria si stanno fondendo**. "Diventeranno tutti PM oppure tutti ingegneri? Diventeranno entrambe le cose." **Prova per esempio: il caso interno.** Cherny descrive come Anthropic opera come dimostrazione: il team di prodotto, il devrel e il design **scrivono tutti codice**; al contrario, molti ingegneri **portano i prodotti end-to-end** — hanno un'idea di cosa costruire, la costruiscono, poi lavorano con il legale, il marketing e la security per comunicare e garantire la sicurezza. Conclusione: l'IA **avvantaggia i profili** con **curiosità**, **gusto per il prodotto** e appetito per la **titolarità end-to-end**. **Il vero contenuto: il thread dei commenti.** Su 55 commenti, 28 apportano un'idea sostanziale, formando una peer review pubblica lungo otto assi. La riformulazione **dominante**: non sono i ruoli a scomparire, è l'**accorciamento del ciclo di feedback**. Rehan Nazir — quando un PM valida un'idea con un prototipo in giornata, "gli organigrammi smettono di contare"; Noman A. — le idee vengono testate in ore anziché settimane, cambiando *il modo in cui le aziende imparano*; Kevin Schoovaerts — Claude Code costruisce l'80% del prodotto, il potere sta nel ciclo stretto con l'utente. Secondo asse, più profondo: la **competenza scarsa si sposta** da "saper costruire" verso il **giudizio** e la **definizione del problema giusto** (Omer K., commento più apprezzato: "scegliere i problemi giusti, sapere cosa NON costruire"; Syed T.; Andrei van Noordt: l'assunzione scarsa diventa la persona con gusto su *cosa* costruire che sa anche costruirlo; Natasha Newbold: si diventa **architetti** che scrivono le specifiche eseguite da squadre di agenti). Sunny Vara sposta la posta in gioco dal prompt al **contesto**. **Il contrappunto.** Uno strato solleva le domande che il video elude: Paul Breuler e Ron H. — la titolarità aumenta, quindi aumenta anche l'**accountability**; "quando tutti possono costruire, qualcuno deve comunque poter dire di no." Mohammadjavad Sayadi — il **divario demo/produzione** resta significativo nei domini regolamentati (sanità). Gli **scettici** (Chris Bounds, Mohamed Anis, Panny Malialis, David H.) mettono in guardia contro la generalizzazione di un modo di operare tipico delle startup. Infine, due **critiche frontali** (James Hutchinson, Dewayne J Grunden II) denunciano il **furto di proprietà intellettuale** e chiedono di rendere open source i modelli e di compensare i creatori. In una frase: il consenso convalida la tesi ma la riformula — **spedire diventa economico**, il che sposta il valore verso il **giudizio, il gusto per il prodotto e il problema giusto**, mentre accountability, governance e affidabilità non si sono ancora adeguate.

The Token Manifesto

Fri, 17 Jul 2026 00:00:00 GMT

**Nicolas Martignole** pubblica su *Le Touilleur Express* **« The Token Manifesto »**, un breve testo satirico co-scritto con due modelli (**GLM-5.2** e **MiniMax-M3**). Il meccanismo è chiaro: prendere la struttura esatta del **Manifeste Agile** del 2001 — il suo preambolo, i suoi quattro valori nella forma "X over Y", i suoi dodici principi — e trasporla nel mondo degli LLM, dove l'unità di conto non è più l'ora-ingegnere ma il **token**. Il preambolo dà il tono: "We are uncovering better ways of consuming context by doing it… Through the work of producing tokens, deleting tokens, and **staring at a usage bar nervously**, we have come to value… ". **I quattro valori** delineano un'estetica del prompt frugale: *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*. Ognuno contrappone una pratica economica (concisione, esempio, iterazione, formato vincolato) a una tentazione costosa (sofisticazione, verbosità, una spec massiccia, una risposta non vincolata). **I dodici principi** sovvertono uno per uno quelli dell'Agile. La priorità diventa consegnare "**la risposta, non la scalata verso la risposta**"; il manifesto "welcomes changing requirements, even late in the conversation"; costruisce "around motivated individuals with an **adequate context window**"; "working prompts measure progress **and credit the bills**." Il principio più citato ribalta il celebre decimo dell'Agile: "**Simplicity — the art of maximizing the amount of work not done by the model**." Altri prendono di mira il debito di contesto ("spot repetition and document it once") e la sostenibilità economica ("a prompting pace that can be sustained indefinitely," "regular reflection **before the monthly bills arrive**"). Due battute finali chiudono il manifesto e ne portano la tesi seria sotto l'umorismo: **« You don't have a prompt problem. You have a context-window problem. »** — spostando l'attenzione dal *prompt engineering* verso l'**economia della finestra di contesto** — e **« Everyone's a prompt engineer until they run out of monthly quota. »** — un promemoria ironico che la vera competenza si misura al contatore dei consumi. Al di là della battuta, il testo cristallizza uno spostamento culturale: nell'era dello sviluppo assistito dall'IA, il vincolo strutturante non è più la **velocità** (l'ossessione dell'Agile) ma il **token budget** e la gestione del contesto. La co-autorialità uomo-più-modelli funge da meta-firma: un argomento a favore della frugalità dei token, scritto con l'aiuto degli stessi modelli a cui insegna a risparmiare.

Steps of AI Adoption (tableau/artifact + post LinkedIn « I talk to engineers at other companies every day… »)

Thu, 16 Jul 2026 00:00:00 GMT

Boris Cherny, Creator & Head of Claude Code presso Anthropic, pubblica una tabella-framework — **« Steps of AI Adoption »** — nata da un'osservazione ricorrente: in molte aziende, *una sola* persona moltiplica per dieci il proprio output con Claude, ma il resto dell'organizzazione non segue. Da qui deriva una **scala di maturità a 5 stadi (0→4)**, strutturata attorno all'**ordine di grandezza di agenti guidati da un ingegnere** — e alla trasformazione di ruolo che questo impone. **0 — Gated (0 agenti)**: accesso bloccato, modelli più vecchi, nessuna governance MCP né infrastruttura per ospitare il codice di Claude; collo di bottiglia = sicurezza/approvazioni legacy e un'ossessione per il costo per token. **1 — Assisted (~1)**: "tu + un agente", pair programming supervisionato, lavoro sincrono; collo di bottiglia = la tua attenzione, poiché senza auto-verifica rivedi tutto. **2 — Parallel (~10)**: diventi l'**orchestrator** di 5-10 agenti su worktree separati; Claude si auto-verifica (test/build/lint/sicurezza), Auto mode e review automatizzate per default; collo di bottiglia = rivedere più flussi. **3 — Supervised autonomy (~100)**: **manager of managers**, Claude scrive quasi tutto, la manutenzione gira in background; collo di bottiglia = fiducia nel loop e throughput decisionale. **4 — AI-native (~1.000+)**: **VP steering by intent**, un loop chiuso in cui Claude lancia la maggior parte degli agenti, monitoraggio per eccezione. **Tesi centrale**: i token non fanno salire di livello. Ogni livello ha il proprio collo di bottiglia; il progresso viene dal **romperlo** e dal **costruire il prossimo set di guardrail** che rende l'output affidabile. Le leve nominate: loop di auto-verifica (test + build + lint + e2e su un ambiente reale), **Auto mode** contro i prompt bloccanti, **code review + security review per default**, interfacce multi-agente (Agent view, Desktop, mobile, Tag), poi `/loop`, `/batch`, `/goal`, **dynamic workflows**, **worktree isolation**, **CLAUDE.md + Skills** per codificare gli standard, e infine il **Claude Agent SDK** per programmare/pianificare flotte di agenti. Sullo steering, Cherny respinge la metrica di vanità: l'utilizzo misura **l'attività, non il ritorno**. La domanda giusta — *avremmo comunque speso questo sforzo, e quante **ore-ingegnere manuali** sarebbero costate?* — dà il vero ROI. Il guadagno decisivo arriva quando la correzione/manutenzione passa in background, liberando i team per *costruire* ciò che prima non era nemmeno alla portata. Un benchmark onesto: Anthropic è allo stadio 3 e spinge verso il 4; lui stesso ha appena raggiunto il livello 4.