thekb.eu — Architettura e Costruzione

DuckDB and the changing physics of analytics

Wed, 26 Aug 2026 00:00:00 GMT

Andy Warfield, ingegnere nel team S3 di AWS, ha pubblicato un guest post su All Things Distributed il 26 agosto 2026, introdotto da Werner Vogels. Nel testo, spiega perché i motori analitici incorporati come DuckDB stanno guadagnando importanza, e annuncia che DuckLabs, il team che sviluppa DuckDB, entra a far parte di AWS. La sua griglia di lettura è quella di una «fisica» mobile. Laddove le scienze fisiche esplorano invarianti, l'informatica dei sistemi ricerca il compromesso elegante rispetto a rapporti che si spostano: velocità della memoria contro velocità della rete, ricchezza delle astrazioni contro potenza disponibile. Cita tre momenti — il progetto NOW di Berkeley, il proprio lavoro su Xen, e la ricerca su MonetDB e X100 al CWI di Amsterdam, dove il collo di bottiglia dell'elaborazione delle query si era spostato dal disco alla CPU — e osserva che questi vincoli si ripresentano ciclicamente. Applicata ai dati, questa griglia spiega l'elaborazione distribuita. L'elaborazione è sempre più semplice ed efficiente su un'unica macchina veloce, ma quando il disco o la scheda di rete di un server non riescono più a leggere il volume desiderato, si partiziona. Era questo il vincolo dei primi anni 2000, quello che ha prodotto MapReduce e poi gli RDD di Spark. Warfield rileva due qualità di questi sistemi: hanno innovato molto sull'ergonomia per gli sviluppatori, e hanno accettato un costo fisso di pianificazione e distribuzione, scommettendo sul throughput ottenuto aggiungendo macchine piuttosto che sull'efficienza per unità. Ma i rapporti sono cambiati. Un'istanza attuale offre circa cinquanta volte la memoria, i core e la banda di rete della più grande istanza EC2 del 2007, mentre la crescita dei dataset segue una distribuzione i cui casi estremi ne formano la coda. Il paper del 2015 Scalability! But at what COST? aveva già dimostrato che un'implementazione single-thread accuratamente ottimizzata poteva battere framework distribuiti eseguiti su centoventotto core. DuckDB, lanciato nel 2018 da Hannes Mühleisen e Mark Raasveldt, applica questa logica: un motore analitico a libreria in-process, che gira nello spazio di indirizzamento dell'applicazione, seguendo il modello di distribuzione di SQLite. AWS è diventata cliente di DuckLabs e poi sponsor dell'estensione Iceberg, parallelamente al proprio lavoro su S3 Tables; l'estensione ora supporta Iceberg v2 e v3 e supera 800.000 download a settimana. Warfield non presenta il modello incorporato come una sostituzione: quando un lavoro richiede mille macchine, le richiede. Ciò che sta cambiando, scrive, è che gran parte del lavoro svolto sui dati in realtà non ha mai avuto bisogno di un cluster. DuckLabs entra in AWS come filiale, con il progetto che resta open source sotto licenza MIT e sotto la governance della DuckDB Foundation.

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.

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

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.

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.

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.

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.

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

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.

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

Mon, 20 Jul 2026 00:00:00 GMT

In nove mesi, Amazon, Microsoft e Google hanno ciascuna lanciato o rinominato una piattaforma agent enterprise, e **tutte e tre sono convergenti sulla stessa architettura**: runtime, memoria, tool gateway, identità, osservabilità e governance compaiono ora in **Bedrock AgentCore**, **Microsoft Foundry** e nella **Gemini Enterprise Agent Platform**, sotto nomi diversi. Ciò che 18 mesi fa era una collezione frammentata di librerie sta diventando un **livello di piattaforma** a sé stante. Per leggere dove questo porta, Janakiram MSV richiama l'**inflessione PaaS 2011-2016**. Prima, i team assemblavano VM, load balancer, code, secret store e agenti di monitoraggio, ciascuno con la propria API. **Cloud Foundry** ed **Heroku** hanno unificato questi elementi attorno a un **contratto applicativo**: l'applicazione dichiara ciò di cui ha bisogno e resta agnostica rispetto a dove viene eseguita. Ciò che contava era il **contratto, non l'implementazione**. Cloud Foundry non ha vinto il mercato — lo ha vinto Kubernetes — ma i suoi principi sono sopravvissuti (buildpack → Cloud Native Buildpacks/CNCF; l'astrazione Cloud Foundry ricostruita su K8s tramite Korifi). L'ecosistema degli agenti si sta avvicinando alla stessa inflessione **senza un contratto equivalente**, e nessun progetto open source lo ha rivendicato. Il costo è concreto: stato di sessione, tracce e identità **finiscono tutti presso un unico fornitore**; spostare un agente un anno dopo richiede **ricostruire tutto**. La convergenza non è un complotto ma un comportamento razionale — integrazione verticale, "è lì che sta il margine" — la cui conseguenza ricade sul cliente. L'autore propone una **mappatura** del contratto Cloud Foundry sugli agenti (app source → codice+eval; buildpack → packaging; backing service → modello/memoria; binding → collegamento autenticato; router → MCP/A2A; log → tracce/costo/qualità; promotion → eval/versioning; policy → identità), quindi tre principi: **impacchettare l'agente come una singola unità distribuibile** (AWS si avvicina con il suo *harness export* verso codice Strands, "l'istinto giusto, rivolto a un unico cloud"), **collegare le capacità invece di incorporare i fornitori** (la lezione Twelve-Factor), **integrare il livello operativo nell'astrazione**. Un agente non è un'applicazione web: comportamento probabilistico, autorità delegata, dipendenze che cambiano comportamento senza un deployment. LangGraph lo dimostra in open source, ma il suo control plane risiede in LangSmith (un prodotto commerciale). I protocolli aperti (MCP, A2A, OpenTelemetry, OCI) forniscono quasi tutti i primitivi, ma **non il ciclo di vita**: versioning, promotion, rollback. La **Linux Foundation** ha lanciato l'**Agentic AI Foundation** (dic. 2025, progetti fondatori MCP/goose/AGENTS.md, hyperscaler come membri platinum). Restano tre domande di due diligence — **governance, packaging, stato** — a cui nessun progetto aperto risponde. Chi finirà per possedere il **control plane degli agenti** definirà *cos'è un agente*.

Beyond Zero: Enterprise security for the AI era

Mon, 20 Jul 2026 00:00:00 GMT

Articolo di ricerca pubblicato su **ACM Queue** (vol. 24, n. 3 — numero tematico "LLM") il **20 luglio 2026**, a firma di **Joseph Valente** (Director of Product Management, Alphabet Security) e **Michal Zalewski** (Distinguished Engineer, stratega di Alphabet Security — il *lcamtuf* della sicurezza offensiva). Licenza **CC BY 4.0**, **29.143 download** in dieci giorni, **un solo riferimento bibliografico**: il whitepaper **BeyondCorp** del 2014. Non è un dettaglio secondario — l'articolo si posiziona esplicitamente come **successore generico di BeyondCorp** e ne assume la funzione: *"pubblicare la visione affinché l'industria possa allinearvisi."* **Tesi**: il **modello a perimetro applicativo è a fine vita**. Le tre ipotesi su cui si fondava BeyondCorp — *chi accede è umano, le azioni avvengono a velocità umana, l'applicazione è il perimetro di fiducia corretto* — sono tutte e tre obsolete ora che gli agenti IA accedono ai dati a **10 volte la velocità degli umani** e ragionano su vasti corpus non strutturati. **Beyond Zero** sposta quindi il perimetro di fiducia **dall'applicazione alla singola azione sulla singola risorsa**, e l'indagine **dal post-mortem al tempo reale**. **Architettura a quattro componenti che formano un ciclo**: *governance autonoma* (che usa l'IA per costruire un **enterprise world model** vivente — Chi / Cosa / Come — per analogia esplicita con il world model di un'auto a guida autonoma), *raccolta eventi* (segnali server, client e **attività degli agenti**: prompt, piani di esecuzione, invocazioni di strumenti), *reasoning engine* (IA gerarchica, **rapida** per l'ABAC al momento dell'accesso e **lenta** per l'inferenza su una sequenza di azioni; verdetto *allow / deny / challenge*), e *infrastruttura di challenge* (**challenge** reversibili — giustificazione, tocco della chiave di sicurezza, approvazione, **selfie** — contro **contenimenti** durevoli, talvolta revocati solo dopo che il team di sicurezza ha interrogato il dipendente e il suo responsabile). **La mossa progettuale centrale è la separazione floor/ceiling**: **politiche statiche** (il floor, verificabile staticamente) sotto un **reasoning engine dinamico** (il ceiling) — un rifiuto esplicito di un modello *"completamente dinamico, difficile da verificare staticamente."* **Il vettore d'attacco nominato**: l'**ambient authority**, l'agente che eredita i permessi completi, spesso sovradimensionati, del proprio umano. **Tre riserve segnalate**: si tratta di un **vision paper, non di un war story** — zero metriche di produzione, zero tasso di falsi positivi, zero scala di deployment, mentre [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] aveva pubblicato un P99 < 40 ms e migliaia di agenti in produzione due mesi prima; un'**incoerenza interna di ordine di grandezza** (decine di milioni di azioni/s nella definizione del problema contro migliaia di decisioni/s nell'abstract e nella conclusione); e un **enorme punto cieco europeo** — il sistema descritto è anche un apparato di sorveglianza dei dipendenti (selfie, segnali lato client, baselining rispetto al gruppo di pari), senza una riga su GDPR, proporzionalità o organismi di rappresentanza dei lavoratori.

Gregor Hohpe et le rôle de l'architecte à l'ère de l'IA

Wed, 15 Jul 2026 00:00:00 GMT

Questo digest di tech-watch consolida, da fonti primarie (libri, il blog architectelevator.com, abstract di conferenze, post LinkedIn, podcast), la posizione di Gregor Hohpe sul ruolo dell'architetto nell'era dell'IA generativa. Tesi centrale: l'IA non svaluta l'architetto, ne sposta il valore dal codice a ciò che l'IA non fa — prendere e assumersi decisioni, arbitrare i trade-off, "vendere opzioni," e comunicare con gli esseri umani. La sua formulazione più incisiva (Craft Conference 2026): "developers mainly interact with machines (compilatori, interpreti, GenAI); architects, meanwhile, communicate with humans — sponsor, stakeholder, regolatori. L'IA genera codice e diagrammi standard, ma gli architetti si affidano ad astrazioni potenti che distillano decisioni critiche, rimuovono l'incertezza e allineano gli stakeholder." La sua tesi distintiva — l'architetto non deve essere la persona più intelligente della stanza, deve "rendere più intelligenti tutti gli altri" (QCon SF 2024) condividendo modelli decisionali e rivelando punti ciechi — si rafforza man mano che il codice diventa abbondante: il vantaggio deriva dalla disciplina decisionale, non dal volume di output. La metafora delle "opzioni" (2016) guadagna anch'essa valore: tramite un'analogia con Black-Scholes, Hohpe sostiene che più alta è la volatilità tecnologica, più alto è il valore delle opzioni che l'architettura vende — quindi bisognerebbe investire di più in architettura in momenti di incertezza come l'attuale fase dell'IA. Sul codice, Hohpe privilegia il "debug" delle decisioni rispetto alla produzione di righe: il codice generato incorpora decisioni architetturali per default, ed è compito dell'architetto renderle consapevoli. Avverte che "un SDLC guidato dall'IA punisce le cattive abitudini molto più rapidamente": l'IA amplifica tutto, incluse le disfunzioni (debito, incoerenze); i vincitori si distingueranno per la velocità con cui passano dalla sperimentazione alla "produzione governata". Per ruolo: l'enterprise architect deve passare da cartografo a esploratore ed evitare "l'illusione della prevedibilità"; il platform architect deve fornire astrazioni, non illusioni; il chief architect è un moltiplicatore (comunicazione × tecnologia × organizzazione). Abbraccia l'automazione mirata e deliberata (Amazon Q Code Transformation: 1000 applicazioni Java 8→17 migrate in due giorni) piuttosto che l'IA come oracolo decisionale, e smonta le cifre di marketing. Due avvertenze nel digest: la formula "gli architetti che usano l'IA sostituiranno chi non la usa" NON è di Hohpe; alcune citazioni LinkedIn sono accessibili solo come estratti.

Le Rôle de l'Architecte à l'Ère de l'Intelligence Artificielle

Wed, 15 Jul 2026 00:00:00 GMT

Questa nota di analisi SFEIR ripercorre il ruolo dell'architetto software alla luce dell'IA generativa, basandosi sul framework concettuale di Gregor Hohpe (*The Software Architect Elevator*). Il punto di partenza è un cambio di paradigma: l'architetto « Oracolo », detentore della conoscenza suprema che emette regole rigide dalla torre d'avorio, è ormai superato, poiché l'IA genera codice e proposte di design su richiesta. Il valore dell'architetto non risiede più nella memorizzazione della sintassi o nella scrittura dell'"idraulica software", ma in un nuovo ruolo di **amplificatore di intelligenza (IQ Amplifier)**: fornire ai team i modelli mentali, il contesto aziendale e gli strumenti di supporto decisionale per sfruttare al meglio l'IA, garantendo al contempo la coerenza complessiva del sistema. Il documento scompone questo impatto attraverso la metafora dell'"Architect Elevator", che va dalla sala macchine (tecnica) al penthouse (strategia). L'**Enterprise Architect** gestisce l'hype, arbitra le decisioni Build vs Buy sui modelli (proprietari, open-source affinati, API di terze parti) e struttura l'etica e la governance dei dati. Il **Solution Architect** "progetta per l'incertezza" — architetture modulari e disaccoppiate che permettono di sostituire gli LLM senza riscritture — e "acquista opzioni" attraverso sistemi estensibili. Il **Platform Architect** standardizza le capacità IA come API robuste e sicure, trattando la piattaforma come un prodotto (con riferimento a *Platform Engineering is Domain-Driven Design*). Il **Software Architect / Tech Lead** mette in atto dei guardrail (architetture esagonali/Clean) per impedire che il codice generato dall'IA inquini il nucleo di business, e documenta il "perché" delle decisioni, poiché l'IA genera solo il "come". Il nucleo metodologico è il **Domain-Driven Design**, presentato come il miglior strumento per incanalare l'IA. Due leve: il **linguaggio ubiquo**, un dizionario di dominio non ambiguo iniettato nel contesto dell'IA (tramite `.clinerules` o template di prompt), che riduce le allucinazioni e le interpretazioni errate del business; e i **bounded context**, che confinano l'IA a un ambito ristretto per massimizzare l'affidabilità della generazione, con l'architetto che progetta le interfacce e gli anti-corruption layer (ACL) e delega l'idraulica di integrazione. In conclusione, l'IA non è una minaccia ma un catalizzatore: solleva l'architetto dall'input tecnico ripetitivo e rivaluta le sue competenze più nobili — sintesi, visione strategica, modellazione di concetti complessi ed empatia umana per collegare la tecnologia alle esigenze di business.

Your Browser Does Math Differently on Every OS, and Anti-Bot Systems Read the Bits

Sun, 12 Jul 2026 00:00:00 GMT

Articolo tecnico pubblicato il **12 luglio 2026** da **Scrapfly Engineering**, su un canale di *fingerprinting* del browser poco conosciuto: **gli ultimi bit di un numero in virgola mobile tradiscono il sistema operativo**. **Il meccanismo**: lo standard IEEE 754 definisce come viene memorizzato un `double`, ma **non impone** che `sin`, `cos`, `tanh` o `exp` siano correttamente arrotondati; ogni sistema distribuisce quindi una **libm** che scambia una frazione di ULP contro la velocità, con i propri coefficienti minimax, tabelle e costanti di riduzione. Ne risulta che `Math.tanh(0.8)` restituisce **tre valori diversi** a seconda di glibc (Linux), libsystem_m (macOS) e UCRT (Windows) — *« una singola chiamata a tanh sull'input giusto è una firma per-OS. Dichiara macOS, restituisci bit matematici di Linux, e hai contraddetto il tuo stesso User-Agent. »* **L'indizio è recente e datato con precisione**: fino a **Chrome 147**, V8 calcolava `tanh` con una porta **fdlibm** integrata, identica ovunque e senza alcuna fuga; il commit V8 `c1486295ae5` l'ha sostituita con `std::tanh`, distribuito in V8 14.8.57, ossia **Chrome 148** — 148, 149 e 150 presentano la fuga, 147 e le versioni precedenti no. **Tre superfici concentrano le fughe**: `Math.tanh` (l'**unica** funzione `Math.*` interessata, poiché V8 integra e collega staticamente il resto), **tutte le funzioni trigonometriche CSS** (Blink chiama direttamente la libm dell'host, dopo una riduzione dell'angolo in gradi che non condivide codice con `Math.sin`), e **Web Audio** (dove il compressore resta sulla libsystem_m scalare mentre le fasi FFT e vettoriali passano attraverso **Accelerate**). **Quattro trappole** rendono difficile la contromisura: solo alcune funzioni presentano la fuga — quindi **falsificare le altre crea un'incoerenza rilevabile**; JavaScript e CSS sono percorsi di codice distinti; **macOS integra due librerie matematiche che divergono tra loro** (scalare vs. Accelerate, dal 10 all'89% degli input a seconda della funzione: `cos(0)` restituisce `1.0` da un lato, `0.9999999999999999` dall'altro); e **anche l'architettura presenta una fuga** (la propagazione FMA e del segno di NaN differisce tra ARM e x86). **La contromisura scartata e quella scelta**: aggiungere rumore fallisce due volte — il valore non corrisponde a **nessun** OS reale, e il non-determinismo a ogni chiamata è a sua volta un indizio. L'unica via è la **riproduzione bit a bit**: estrarre i coefficienti della libm target, trascriverli **in esadecimale** (una trascrizione decimale arrotonderebbe in modo diverso), scrivere ogni fused multiply-add esplicitamente come `fma()`, e compilare con `-ffp-contract=off` affinché il compilatore non ne inventi né ne ometta alcuno. **Nota sulla trasparenza**: l'editore dichiara fin dall'inizio che *« i post qui presenti sono redatti con l'IA, »* mentre i meccanismi, i dati e il codice restano propri.

New Engineering Disciplines for the AI Era Part 3: KDLC — Knowledge Development Life Cycle

Sun, 28 Jun 2026 00:00:00 GMT

Terzo capitolo della serie « New Engineering Disciplines for the AI Era », questo articolo di Ashish Singh istituisce il **KDLC — Knowledge Development Life Cycle** come disciplina ingegneristica a pieno titolo. La sua tesi ribalta la diagnosi dominante: se tante iniziative di IA aziendale falliscono, non è per la mancata scelta del modello giusto o per la mancata distribuzione di un sistema RAG, ma perché ignorano la **struttura sottostante della conoscenza**. La frase chiave riassume la posta in gioco: « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust. » La conoscenza deve quindi essere trattata come un **asset ingegnerizzato**, al pari del codice (SDLC) o dei dati. Il KDLC organizza questo lavoro in **otto** fasi ordinate. La **Discovery** individua la conoscenza dispersa tra database, SharePoint, wiki, CRM, ERP e artefatti di ingegneria. L'**Extraction** estrae le informazioni significative preservando il contesto di business, i metadati, le relazioni e la proprietà (ownership). Lo **Structuring** converte l'informale in oggetti di conoscenza standardizzati e riutilizzabili. La **Knowledge Graph Creation** mappa le interconnessioni tra clienti, prodotti, progetti, team, normative e applicazioni. L'**Embedding** produce rappresentazioni semantiche che consentono la comprensione per significato. L'**Index Optimization** affina gli indici vettoriali e le pipeline di retrieval. La **Retrieval Evaluation** misura pertinenza, precisione, completezza e impatto di business. Infine, il **Knowledge Refresh** mantiene l'insieme aggiornato rispetto a nuove policy, normative e release. Il nucleo argomentativo contrappone due architetture. Il **RAG tradizionale** recupera documenti isolati tramite ricerche basate su parole chiave. L'**Enterprise Knowledge Fabric** — una combinazione di Knowledge Graph, Semantic Search, Vector Database e Hybrid Search — punta a una comprensione interconnessa: anziché recuperare documenti, gli agenti IA colgono « relationships, context, and business meaning ». Una seconda triade inquadra i ruoli rispettivi dei livelli: « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Tre illustrazioni settoriali rendono concreto l'impatto: un assistente per la **compliance finanziaria** che collega normative aggiornate e policy interne; un assistente per l'**ingegneria del software** che consulta architettura, contratti API, standard e incidenti prima di formulare raccomandazioni; un assistente **clinico** che incrocia linee guida terapeutiche, protocolli, letteratura e cartelle cliniche dei pazienti. Singh conclude che, nell'era dell'IA agentica, l'ingegneria della conoscenza diventa critica quanto l'ingegneria del software e l'ingegneria dei dati. Il limite dell'articolo risiede nella sua natura **concettuale, non quantificata**: nessun benchmark né dato di costo, e i veri punti dolenti — governance e manutenzione continua della fase Refresh — restano fuori campo.

Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)

Tue, 16 Jun 2026 00:00:00 GMT

Questo articolo SFEIR formalizza un ciclo di sviluppo software guidato dall'IA in **undici fasi (da 0 a 10)** e sostiene che il settore stia convergendo verso questo tipo di modello. Il punto di partenza è una diagnosi: nel 2025 le organizzazioni hanno implementato strumenti di IA senza trasformare il proprio modello operativo, generando un paradosso riassunto dalla frase « tutto cambia… e nulla cambia » — la velocità di esecuzione si moltiplica senza un guadagno proporzionale. La vera sfida non è quindi scegliere gli strumenti giusti, ma **ripensare il ciclo di vita del software** stesso per un'esecuzione guidata dalla macchina. Il ciclo SFEIR concatena: **0 Setup** (rilevamento dello stack, memoria di progetto), **1 Define** (specifica — gate umano), **2 Plan** (arbitraggio architetturale — gate umano), **3 Build** (sviluppo da parte dell'agente), **4 Verify** (test automatizzati e copertura), **5 Review** (quattro audit paralleli: codice, sicurezza, test, performance), **6 Compound-1** (raccolta delle lezioni prima del deployment), **7 Ship** (accettazione in produzione — gate umano), **8 Ops** (monitoraggio e rollback), **9 Compound-2** (lezioni dal runtime) e **10 Deprecation** (ritiro e capitalizzazione). Tre **gate umani inamovibili** — Define, Plan, Ship — inquadrano un insieme di fasi altrimenti automatiche; due **momenti di capitalizzazione** (Compound-1 e Compound-2) trasformano le lezioni in regole riutilizzabili che alimentano i cicli successivi. Tre principi strutturano l'approccio. Primo, **l'IA esegue, non assiste**: gli agenti producono artefatti completi (codice, test, documentazione) su intere fasi, e una disciplina di **prova di esecuzione** cattura gli output effettivi — il sistema non si fida mai delle affermazioni dell'agente stesso. Poi, **l'essere umano mantiene il controllo dell'intento** tramite i tre gate: decide cosa costruire, la macchina ottimizza l'esecuzione. Infine, **il sistema apprende in modo cumulativo**, ogni ciclo arricchendo il successivo. I risultati presentati sostengono la tesi: una riprogettazione di sito passata da sei mesi a un giorno, **−30% delle iterazioni di correzione dopo dieci cicli** (un bug segnalato due volte diventa una regola automatizzata), revisioni secondo quattro angolazioni parallele, un costo di aumento di circa 10 €/ora, e un obiettivo di 850 consulenti pienamente aumentati dall'IA entro la fine del 2026. L'articolo rivendica una **convergenza a livello di settore** con l'ADLC (due gate, « l'intento è verificato esattamente due volte »), il whitepaper di Google sul nuovo SDLC (41% di codice generato dall'IA, 85% degli sviluppatori su agenti), e DORA 2025 (l'IA come « amplificatore »). Delimita infine gli usi appropriati (back-office, API, migrazioni, output verificabili automaticamente) e quelli non appropriati (design nuovo e non vincolato, sistemi safety-critical in attesa di standard, ambienti dati non governati), e raccomanda di partire da un gate di specifica rigoroso e da una prova di esecuzione. Primo episodio di una serie di sette.

The End of Code Review: Coding Agents Supersede Human Inspection

Thu, 11 Jun 2026 00:00:00 GMT

In questo position paper pubblicato su arXiv (categoria software engineering), Martin Monperrus difende una tesi che si scontra frontalmente con una pratica fondante dello SDLC: gli agenti di codifica hanno raggiunto un livello di capacità tale per cui **la revisione umana del codice non è più una componente necessaria di una pipeline di qualità**. L'argomentazione si basa su due affermazioni. Primo, una **parità — o persino una superiorità — di capacità**: i sistemi autonomi basati su LLM soddisfano tutti gli obiettivi tradizionali della revisione (individuare difetti, migliorare la qualità, garantire la conformità, condividere conoscenza) a costi inferiori e con un throughput superiore, senza affaticamento o incoerenza umana. Secondo, un **problema di scalabilità**: il modello ibrido dominante — l'agente scrive il codice, l'umano lo rivede — non garantisce né una reale assicurazione di qualità né la capacità di tenere il passo con la velocità di produzione assistita dall'IA; soprattutto, genera un **falso senso di sicurezza**. Monperrus colloca storicamente il proprio bersaglio, puntando all'inspection de Fagan (1976), e si basa sul lavoro di Bacchelli & Bird che dimostra come la revisione colga, in pratica, meno bug di quanto gli sviluppatori immaginino. I benchmark (SWE-bench, con circa il 20-40% dei problemi risolti a seconda del modello, con curve di progressione rapide) fungono da prova di capacità. Al posto della revisione umana, propone una **pipeline di verifica avversariale multi-agente**: un agente genera il codice; uno o più agenti revisori indipendenti lo ispezionano (difetti, sicurezza, stile); uno strato di verifica aggiunge test automatizzati e metodi formali; un meccanismo di consenso fa votare più agenti per accettare o rifiutare. Il collo di bottiglia di un singolo revisore umano viene sostituito da un'ispezione distribuita e instancabile. L'essere umano non scompare: si concentra su specifiche e requisiti di alto livello, compromessi architetturali, supervisione dei domini critici, casi limite, e resta il gate di approvazione finale per i sistemi sensibili. L'autore affronta esplicitamente le obiezioni — allucinazioni e prompt injection, i limiti dei test automatizzati (da cui il property-based testing), la perdita di competenza di dominio (compensata da fine-tuning e RAG) — senza eluderle. Sul versante SDLC, collega la revisione alle metriche DORA: accelerare il throughput della revisione accelera il deployment. Le sue raccomandazioni sono pragmatiche: fare pilotaggio prima su componenti a basso rischio, mantenere inizialmente un flusso di lavoro ibrido (gli agenti segnalano, gli umani approvano), misurare i tassi di individuazione agente-contro-umano, rendere esplicite le decisioni di rigetto e costruire cicli di feedback. Un testo deliberatamente provocatorio, ma una preziosa controtesi al dogma del "gate di revisione umana inviolabile".

The pattern lineage: Why fifty years of design patterns may hold the key to growing the architects AI cannot replace

Wed, 10 Jun 2026 00:00:00 GMT

Philippe Ensarguet (Orange) parte da una domanda apparentemente amministrativa — progettare un percorso di upskilling verso il ruolo di architetto — per articolare un'intuizione più profonda. Questo ruolo è critico per la "platformizzazione" di un operatore telecom (riunire i mondi IT e network, separati da decenni, in piattaforme programmabili). Eppure diventa critico proprio nel momento in cui la sua pipeline di formazione si sta rompendo: la domanda di architetti è in aumento (platforming, cloud-native, lo shift dell'IA agentique sposta la complessità dai componenti alle relazioni tra di essi), mentre la catena di approvvigionamento dei talenti si sta smantellando da sola. Il percorso tradizionale passava per anni di scrittura di codice; l'IA ora assorbe una quota crescente di quel lavoro. Se il lavoro di livello base che un tempo forgiava gli architetti viene delegato alle macchine, da dove verrà la prossima generazione? La risposta, secondo Ensarguet, è rimasta sullo scaffale per cinquant'anni. Egli ritorna al significato originale di un pattern, così come definito dall'architetto edile Christopher Alexander (1977): una soluzione nominata e ricorrente a un problema all'interno di un contesto, incluse le forze in tensione e le conseguenze. Non è una ricetta — è giudizio trasmissibile. Il libro della Gang of Four (1994), nato dall'Hillside Group riunito da Kent Beck e Grady Booch, ha dato all'industria il suo primo vocabolario condiviso — il suo valore duraturo risiede nel formato (problema, contesto, forze, soluzione, conseguenze), non nei 23 pattern in sé. Ensarguet traccia un albero genealogico: POSA (1996), Fowler (2002), Hohpe & Woolf (2003), Nygard (2007, Circuit Breaker), i cataloghi cloud (2012+), microservizi e Kubernetes (2018-2019), fino ai corpora agentici che si stanno ora formando ("Building Effective Agents" di Anthropic, i quattro pattern di Andrew Ng, il framework a due assi di Huang & Zhou nel 2026 — che riecheggia i due assi della GoF trent'anni prima). Sotto i cataloghi, persistono sei forze invarianti: accoppiamento/coesione, confine di astrazione, isolamento dei guasti, governo dello stato, indirezione, ciclo di feedback — a cui si aggiunge una settima, il non-determinismo introdotto dai sistemi agentici. Questa "pattern literacy" è la competenza resiliente, e l'unica che infine collega IT e network (control plane / user plane = indirezione; network slicing = Bulkhead; intent-based networking = ciclo di feedback). L'IA diventa allora un'alleata: liberata dall'implementazione, la formazione può diventare deliberata — la macchina produce opzioni, l'essere umano fornisce il giudizio. Ciò che va insegnato è la grammatica, non i cataloghi: i cataloghi invecchiano; il modo di pensare che essi codificano no. Ensarguet pubblica questa tesi proprio per metterla alla prova attraverso il dibattito.

How AI Changes the SDLC: A Six-Stage Guide

Mon, 08 Jun 2026 00:00:00 GMT

Questa guida di Augment Code, a cura di Paula Hingel, propone un modello a **sei fasi** per comprendere come gli agenti IA stiano ristrutturando il ciclo di vita dello sviluppo software. Tesi centrale: l'IA non migliora l'SDLC in modo uniforme — aumenta il throughput in alcune fasi mentre eleva il rischio di instabilità in altre. Questo squilibrio non è una fatalità tecnologica, ma il sintomo di un'adozione disomogenea condotta **senza ridisegnare i confini della revisione**. L'articolo si basa sul **rapporto DORA 2025**, che stabilisce una correlazione positiva tra adozione dell'IA e throughput/prestazioni di prodotto, ma una **correlazione negativa con la stabilità del delivery**: la maturità del processo conta più dello strumento. Le sei fasi vengono rilette secondo questa chiave. (1) **Requisiti e pianificazione**: la specifica diventa il meccanismo di controllo che guida l'agente; gli esseri umani si concentrano sulla qualità dei requisiti e sulla risoluzione delle ambiguità. (2) **Design e architettura**: un numero maggiore di decisioni richiede una revisione umana esplicita, per evitare il "vibe architecting" — scelte infrastrutturali o di integrazione prese in pochi secondi, più veloci di quanto la governance riesca a seguire. (3) **Implementazione**: lo sviluppatore passa dalla scrittura di codice all'orchestrazione, alla validazione e all'approvazione. (4) **Testing e QA**: il rischio principale è la **validazione circolare**, in cui i test generati dall'IA confermano il codice generato dall'IA invece di verificare il requisito effettivo; una specifica precisa costituisce la salvaguardia. (5) **Deployment**: i guadagni di throughput creano rischi di stabilità, da cui la necessità di controlli di rollback più solidi. (6) **Manutenzione e operazioni**: gli agenti gestiscono il rilevamento e la correzione, gli esseri umani gestiscono le eccezioni e l'hardening. Vengono individuati tre rischi strutturali: **erosione della pipeline junior** (automatizzare i compiti fondamentali più rapidamente di quanto vengano ridisegnati i ruoli junior riduce il futuro bacino di senior), la validazione circolare e le lacune di governance su larga scala. In parallelo emergono tre ruoli: **Intent Engineering** (tradurre obiettivi ambigui in specifiche verificabili), Agentic DevOps/Infra (orchestrare gli agenti) e AI Governance/Assurance. La guida è supportata da dati: il 70% del tempo degli sviluppatori speso a comprendere codice esistente, uno studio della CMU (807 repository) che mostra +30% di problemi rilevati dall'analisi statica e +40% di complessità, e il sistema DRS di Meta (oltre 10.000 modifiche applicate durante un code freeze). Si conclude con cinque raccomandazioni operative: verificare una fase prima di scalare, sottoporre la governance a stress test, rendere centrale la specifica, definire policy di rollback esplicite e ridisegnare il ruolo junior attorno alla revisione.

Solving the Identity Crisis for AI Agents

Thu, 21 May 2026 00:00:00 GMT

Articolo di engineering pubblicato sul blog Engineering di **Uber** da sei ingegneri (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) il **21 maggio 2026**, che espone la **dottrina di identità e controllo degli accessi per agenti IA** dispiegata in produzione in Uber per diverse migliaia di agenti interni. **Tesi cardine**: i modelli di identità esistenti (umani + workload) non riescono a descrivere l'**agency** — *"an agent is best defined as an entity that is authorized to act for or in the place of another"* — e perdono la **provenance** attraverso gli hop di un workflow agentico. **Due problemi operativi identificati**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delega è la modalità predefinita, i workflow sono composizionali (agenti che chiamano agenti che chiamano tool), il comportamento è dinamico (i piani evolvono in base ai risultati intermedi); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"Execution context (originating user, intermediate agents) is dropped across agent hops."* **Architettura proposta** come estensione della Zero Trust Architecture di Uber: **Agent Registry** (fonte di verità per le mappature agente↔workload) + **AI Agent Mesh** (data plane inter-agente) + **STS (Security Token Service)** (emissione di JWT a scope ristretto) + **MCP Gateway** (punto di enforcement delle policy per l'invocazione dei tool) + **AI Gateway** (mediazione delle chiamate LLM esterne con guardrail) + **SPIRE** (fornitore di credenziali per i workload). **Meccanica crittografica**: i workload recuperano **SVID (SPIFFE Verifiable IDs)** firmati crittograficamente da SPIRE → l'SDK richiede un JWT all'STS tramite l'identità del workload → l'STS verifica l'autorizzazione dell'agente rispetto all'Agent Registry → viene emesso un token a breve durata (TTL dell'ordine di minuti) per una **destinazione specifica a singolo hop** (claim `Audience` mirato). **Dottrina cardine**: ***"Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes."*** **Preservazione della catena di attori**: un esempio multi-hop con l'ingegnere di guardia `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; il JWT finale porta una **catena di attori verificabile `[user1, oncall-agent, investigation-agent]`**, che consente decisioni di accesso a livello di tool basate sulla **storia completa della richiesta**. **Standardizzazione**: un **Standardized A2A (Agent-to-Agent) Client** che automatizza gli scambi con l'STS e la propagazione della catena di attori — *"the secure path is also the easiest path for developers to implement A2A calls"* — con migrazione graduale degli agenti legacy. **Metriche di produzione**: ***"P99 latency for the STS Token Exchange API is consistently below 40 milliseconds,"*** migliaia di agenti interni onboardati, una dashboard di osservabilità in tempo reale che traccia le sessioni multi-agente. **Visione a lungo termine — framework a tre livelli**: (1) Identity & Trust Foundation (identità verificabile dell'agente + catene di delega), (2) Dynamic Access Control (permessi basati sul contesto + human-in-the-loop), (3) Unified Enforcement Plane (policy centralizzata e osservabile). **Allineamento agli standard**: il working group IETF **WIMSE** + la draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, fondata concettualmente su **OAuth 2.0 Token Exchange (RFC 8693)** e **SPIFFE/SPIRE** (graduato CNCF). La prima pubblicazione di riferimento da parte di un hyperscaler non-AI-lab (logistica/mobilità) che industrializza la sicurezza degli agenti a livello infrastrutturale, che chiude il vuoto dottrinale tra i framework di skill/harness (Vincent, Lattice, PROJ-AI) e le questioni di identità enterprise-grade.

How the X Algorithm Actually Works in 2026 — and What That Means for Growth

Sat, 16 May 2026 00:00:00 GMT

Rapporto interno di teardown sulla release open-source **`xai-org/x-algorithm`** (15 maggio 2026) — l'algoritmo del **For You feed** di **X (ex Twitter)** nel 2026, con quattro filoni di raccomandazioni di crescita calibrati per pubblico (personale/founder, brand/azienda, framework generalizzato, deliverable per clienti/consulenza). **Tesi centrale**: ***« La celebre tabella dei pesi del 2023 — le risposte contano più dei like con un moltiplicatore elevato — descrive un sistema che non esiste più in questa forma. »*** L'algoritmo 2026 è un **transformer (Phoenix, derivato da Grok-1)** che apprende i pesi dalla cronologia di engagement personale, valutato su una **superficie multi-azione a 19 dimensioni**, filtrato da un servizio offline di comprensione dei contenuti (**Grox**). **La forma dello scoring conta ormai molto più dei numeri — e i numeri stessi non sono presenti nella release pubblica**. **Architettura a 4 componenti**: (1) **Home Mixer** (Rust, orchestratore a tempo di richiesta, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, archivio in memoria alimentato da Kafka dei post recenti, lookup sub-millisecondo per i candidati in-network); (3) **Phoenix** (ML in JAX, transformer a due torri per retrieval + ranking, derivato ~da Grok-1); (4) **Grox** (offline, classificatori spam/safety/PTOS/banger + embedder multimodale v5). **Le 19 azioni predette da Phoenix** (cambiamento chiave rispetto al 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (visualizzazione video di qualità filtrata da una durata minima), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continua). **Punteggio finale** = `Σ (weight × P(action))` modificato da **3 moltiplicatori strutturali**: (a) **OON_WEIGHT_FACTOR < 1** (penalità out-of-network), (b) **decadimento della diversità autore** `(1-floor) × decay_factor^position + floor` (attenuazione esponenziale dei post ripetuti dello stesso autore in un singolo render), (c) **soglia sulla durata video** (vqv contribuisce solo se `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Avvertenza chiave**: **nessun valore numerico di peso** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) è presente nella release — tutto è `crate::params::*`, gestito da un servizio interno di feature-switch di X per l'A/B testing. ***« Chiunque affermi che 'le risposte valgono N,N× più dei like nel 2026' sta inventando un numero che non è derivabile dalla release OSS. »*** **Differenze chiave rispetto al 2023**: (1) eliminazione di ogni feature ingegnerizzata a mano (*« Abbiamo eliminato dal sistema ogni singola feature ingegnerizzata a mano e la maggior parte delle euristiche »*); (2) un unico modello che predice 19 azioni contro modelli singoli per azione; (3) Grox separa la comprensione dei contenuti dal ranking; (4) nuovi segnali di prima classe (dwell continuo, vqv filtrato, follow_author, 3 varianti di share); (5) retrieval OON a due torri (vs. SimClusters+euristiche) con embedding multimodali testo+immagine+video-ASR. **Tre livelli di reach** (framework generalizzato): Eligibility (binaria, Grox+filtri) → Retrieval (probabilistica, ANN a due torri) → Ranking (continua, somma pesata + moltiplicatori). **Due leggi della crescita meccanica**: (1) L'in-network è moltiplicativo, l'OON è additivo; (2) Il compito del modello è predire te, non premiarti. **Confine di onestà deliberato**: il checkpoint Phoenix rilasciato = mini (2 layer, 4 head, 256 dimensioni, corpus di 537K post sportivi), non il modello di produzione; integrazioni Thrift stub (`panic!("Not implemented")` in `candidate_features.rs`); liste di brand-safety, mappature degli ID di topic, penalità linguistiche, regole di ad-blending assenti dalla release pubblica.

The Ontology Pipeline™, Refresh: Where We Were, Where We Are, and Where We're Headed

Mon, 04 May 2026 00:00:00 GMT

**Jessica Talisman MLS** (Semantic Engineer + Information Architect, oltre 25 anni di esperienza, in precedenza Adobe RDF knowledge graphs + in precedenza Amazon information architecture, fondatrice di **Ontology Pipeline Framework** + **Contextually LLC**) pubblica su **Modern Data 101** (Substack, ~20.000 membri) il **4 maggio 2026** una revisione importante del suo framework **Ontology Pipeline™** pubblicato inizialmente a gennaio 2025. **Tesi centrale**: dal novembre 2022 (ChatGPT), la domanda di *semantic infrastructure* è esplosa ma ha generato **confusione massiccia** — *"vendors offering shortcuts that bypass essential foundational work, creating liabilities disguised as assets"*. La pipeline originale a **5 stadi** (controlled vocabulary → metadata standards → taxonomy → thesaurus → ontology → knowledge graph) resta valida ma **deve essere completata con 2 aggiunte critiche**: **(1) Governance** come pratica ingegneristica continua (non documentazione post-progetto); **(2) AI Partnership** con una distinzione netta tra augment e replace. **Diagnosi di mercato**: *"a structurally invalid taxonomy is not a taxonomy"*, *"lists are not knowledge infrastructure"*, tassonomie generate dall'AI vendute come strategia, vendor che abusano del termine *"ontology"*, soluzioni standardizzate presentate come metodologia. **Crisi formativa**: la domanda di semantic engineer supera nettamente l'offerta di professionisti formati; il divario viene colmato da persone *"who know vocabulary without methodology"*. **Posizione normativa esplicita**: *"AI that generates a taxonomy wholesale is producing a liability disguised as asset; AI that assists trained engineers is just plain smart."* **Ruoli accettabili per l'AI**: estrazione di entità, gap analysis, redazione di vocabolari candidati da sottoporre a revisione, supporto a popolamento/validazione. **Ruoli inaccettabili per l'AI**: *generazione integrale di tassonomie senza validazione umana rispetto agli standard*. **Standard citati**: SKOS, OWL, RDF, SPARQL. **Credibilità**: framework validato su **6 istituzioni in 10 anni**. **Raccomandazioni per 3 pubblici**: (a) Organizzazioni — investire nella formazione formale, trattare l'infrastruttura di conoscenza come la spina dorsale dell'AI, governance come pratica continua, AI come acceleratore e non sostituto; (b) Professionisti — competency question prima della modellazione, validare rispetto a SKOS/OWL/RDF, la difficoltà definizionale segnala una pausa, la manutenzione è continua; (c) Leader — upskilling della forza lavoro senza formazione autofinanziata, allocare risorse all'infrastruttura di conoscenza come necessità strategica, governance prima del deployment. **Citazioni salienti**: *"the work cannot be skipped"*, *"governance is the engineering practice that keeps an ontology coherent across change"*, *"teaching this is hard. Learning it is harder."* **Rilevanza elevata** per data leader / CDO / architetti che costruiscono le fondamenta semantiche dei loro agenti AI. Da leggere insieme a: Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — ontology as the only moat*; Foundation Capital Context Graphs (2025-12-22); Bain parte 2/5 *redesign data foundations for agent readiness* (2026-05); DORA ROI 2026 *AI-accessible internal data + healthy data ecosystems* (2026-04-21); Habert PROJ-AI six-zone doctrine (2026-05-05). Convergenza con il corpus 2026 su *"data foundations as moat"*.

There is a growing disconnect in the way people think about building AI agents

Fri, 17 Apr 2026 00:00:00 GMT

Tony Seale, The Knowledge Graph Guy, individua una crescente disconnessione nel modo in cui il settore costruisce agenti IA. Da un lato, il settore investe pesantemente in framework di orchestrazione: LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAI Agents SDK, AWS Bedrock, Google ADK — ciascuno con i propri grafi di orchestrazione, macchine a stati e logiche di routing. Dall'altro, i practitioner più all'avanguardia sono passati al paradigma del "modello potente in un harness potente" (Claude Code, Codex, OpenClaw, Hermes). **Il collasso dei framework.** I primi framework erano necessari quando i modelli non riuscivano a gestire da soli attività multi-step. Citazione di Anthropic: "Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions can quickly go stale as models improve." Un'impalcatura costruita per un modello limitato penalizza un modello intelligente. Dovrebbe diminuire nel tempo, non accumularsi. Ciò che resta è semplice: un modello potente in un harness potente. Molti, che interagiscono, che collaborano. Nessun framework richiesto. **Gli agenti isolati non bastano.** Accesso al computer ≠ comprensione. Dare a un agente 1000 documenti: cerca, spera, indovina. Moltiplicare questo per 50 agenti senza un modello del mondo condiviso produce un'intelligenza isolata ma incoerente nella combinazione. Su scala enterprise, l'ambiente informativo necessita di struttura — un modello di dominio condiviso, con l'essere umano nel loop. **La simmetria.** La risposta è applicare la stessa semplificazione sul lato dei dati. Il modello si trova in un harness che gli dà accesso al computer; i dati si trovano in un'ontologia che dà loro struttura e significato. L'ontologia definisce cosa esiste, le sue proprietà, le sue relazioni — l'interfaccia attraverso cui gli agenti comprendono i dati. Due pattern simmetrici: (modello potente + harness potente) e (dati potenti + ontologia potente). **Il Semantic Agent.** La loro combinazione produce il Semantic Agent: (Model + Harness) + (Ontology + Data). Non si limita a generare, inizia a comprendere. Tutto il resto è impalcatura — utile per un certo tempo, ma destinata a essere smontata. **Ciò che si possiede.** Tutti hanno accesso agli stessi modelli di frontiera; chiunque può costruire un harness. Questo è commodity, e si assottiglia ogni giorno. Ciò che NON è commodity: la propria ontologia, il proprio modello di dominio, la conoscenza strutturata e collegata che cattura come la propria organizzazione comprende il mondo. I framework sono una fase transitoria. I modelli sono affittati. L'unica cosa che resta da costruire — e che si possiede — è la conoscenza.

Building for trillions of agents

Sat, 07 Mar 2026 00:00:00 GMT

Aaron Levie, CEO di Box, pubblica un saggio strategico sulla trasformazione fondamentale del software in un mondo in cui gli agenti IA diventano gli utenti primari di ogni applicazione. Osserva che, dalla fine del 2025, gli agenti hanno superato una soglia decisiva: dispongono ormai di un proprio ambiente di calcolo sandboxed, possono scrivere ed eseguire codice, interagire con API e CLI, e gestire i propri file e la propria memoria a lungo termine. Questa architettura, inizialmente definita dagli agenti di coding (Claude Code, Devin, Codex, Cursor, Replit), si è estesa a tutto il lavoro della conoscenza con agenti come Claude Cowork, Perplexity Computer, Manus e OpenClaw, quest'ultimo in esecuzione 24/7 in un ambiente persistente. Levie prevede che ogni dipendente disporrà di numerosi agenti, con un numero di agenti da 100 a 1000 volte superiore a quello delle persone all'interno di un'azienda, per un totale di trilioni di agenti a livello globale. Adattando il celebre consiglio di Paul Graham ("Make something people want"), Levie propone un nuovo paradigma: "Make something agents want". Gli agenti sceglieranno da soli gli strumenti più adatti, senza essere influenzati dal marketing tradizionale. La conseguenza principale: tutto deve diventare API-first. Senza un'API, una funzionalità non esiste per gli agenti. Le CLI e i server MCP diventano indispensabili. Levie cita Jared Friedman di YC, che avverte che gli strumenti che non consentono l'iscrizione via API sono "morti per gli agenti". Anche i modelli di business devono evolversi: il modello per postazione (per seat) non è più sufficiente quando un agente può realizzare ore di lavoro umano in poche righe di testo. Saranno necessari modelli basati sul consumo e sul volume, che potrebbero persino consentire agli agenti di gestire autonomamente i propri pagamenti. Levie descrive quindi l'ecosistema infrastrutturale necessario: ambienti sandbox (E2B, Daytona, Modal, Cloudflare), gestione dei file (Box), identità ed e-mail per gli agenti (Agentmail), ricerca web (Parallel, Exa), pagamenti (Stripe, Coinbase), e potenzialmente microtransazioni. Sicurezza, conformità e governance diventano questioni centrali quando gli agenti gestiscono dati sensibili in flussi di lavoro regolamentati (farmaceutico, bancario). Gli agenti avranno bisogno di identità proprie con controlli rigorosi sulle loro azioni e sull'accesso ai dati. In conclusione, Levie afferma che stiamo entrando in una nuova era del software, in cui gli strumenti devono essere progettati specificamente per agenti che operano su una scala senza precedenti.