Post di annuncio prodotto di **Block Engineering** firmato da **Thomas Petersen** (*Principal Designer & Builder*), pubblicato il **18 agosto 2026**, ~1.800 parole suddivise in tredici brevi sezioni, che presenta **Buzz Projects** — una **forge software ospitata sul proprio relay**: repository Git, branch, pull request, issue, revisione e merge, progetti multi-repo, un feed di attività, il tutto collegato ai canali di conversazione. Il catenaccio e la tesi del post: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Tre contributi. **(A) Una dottrina di fiducia fondata sulla prova *ex post* piuttosto che sull'autorizzazione *ex ante***: da un lato *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, dall'altro *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; la sezione si chiude su una direzione dichiarata — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Interoperabilità Git senza strumenti proprietari**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, con la clé Nostr che funge da identità unica — *« The same npub that signs your messages signs your pushes. »* **(C) Una distinzione tra superficie di esecuzione e presenza in rete**: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* Il post non produce alcuna cifra e non contiene link esterni; si qualifica come preliminare sei volte (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), e Projects risiede sotto la scheda **Experiments** di Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
Nota della stampa specializzata (**Payments Dive**, formato *Dive Brief*, **6 agosto 2026**) sui risultati trimestrali di **Block**: l'azienda ha già distribuito diversi strumenti di IA ai propri clienti — **Moneybot** (Cash App) e **Managerbot** (Square) — e non ha ancora deciso come farli pagare. **Jack Dorsey** durante la call con gli analisti: *"Siamo in una posizione fortunata in cui possiamo sperimentare con diversi modelli, per poi scegliere quello giusto che allineerà tutti i nostri incentivi con quelli dei nostri clienti."* **Il contesto finanziario illumina questa posizione.** Sei mesi prima, Block aveva licenziato circa **4.000 persone, circa il 40% della sua forza lavoro**, in una riorganizzazione esplicitamente motivata dall'IA. Nel Q2 2026: utile lordo **in aumento del 25% a 3,2 miliardi di $**, ricavi **in aumento del 10% a 6,62 miliardi di $**, ma **utile netto a 89 milioni di $, in calo dell'83%** su base annua a causa dei costi di liquidazione che chiudevano la ristrutturazione; le previsioni per il 2026 sono state riviste al rialzo. Il valore dell'IA, dunque, viene catturato attraverso la struttura dei costi prima di essere catturato attraverso il prezzo. **Il fatto più pesante si trova al centro della nota**, tratto dalla lettera agli azionisti: *"A partire da giugno, l'IA agentica ha contribuito a scrivere e revisionare quasi tutte le nostre modifiche al codice di produzione"* — scrivere **e** revisionare quasi tutte le modifiche al codice di produzione, in un'azienda di pagamenti quotata in borsa, sei mesi dopo aver tagliato il 40% della forza lavoro. Un'affermazione autodichiarata agli investitori, senza alcuna definizione di *"quasi tutte"* né di cosa copra la *"revisione"*. **Gli strumenti**: **Goose**, un sistema interno costruito due anni prima, descritto come agnostico rispetto ai modelli (integra diversi modelli commerciali per i dipendenti); **Buzz**, lanciato il mese precedente per *"la collaborazione tra agenti, la comunicazione e i repository di codice."* **Sul lato clienti**: Moneybot monitora l'attività degli utenti di Cash App e mette in evidenza conti, saldi e transazioni — oltre **un milione di conti attivi settimanalmente**; Managerbot gestisce marketing automatizzato, analisi dei margini e suggerisce *"correzioni operative"* ai commercianti di Square. Gli analisti di **Evercore ISI** elencano quattro percorsi di monetizzazione — pacchetti SaaS, abbonamenti diretti, offerte enterprise, tariffazione a consumo — **nessuno dei quali legato ai risultati**. Ordine di priorità dichiarato: **qualità del prodotto → distribuzione → adozione → modello di prezzo**. Due fatti sulla distribuzione completano il quadro: Square sta entrando in **Google Maps** con un'*"esperienza di IA conversazionale,"* descritta come *"il primo passo di una partnership più ampia tra Square e Google"*; e il dispositivo di pagamento **Tags** (portachiavi e bacchette con chip NFC) mostra **tre milioni di persone in lista d'attesa**. Citazioni degli analisti: William Blair (*"Block incarna il cambiamento strutturale verso le aziende di finanza digitale orientate al futuro"*) e Bank of America sul *"modello operativo post-reset."*
#Block#Jack Dorsey#Cash App
**Justin Bachman** — Senior Reporter · **Payments Dive** (groupe Industry Dive). Journaliste sectoriel paiements ; signe ici un **Dive Brief** · format court en deux temps (*Dive Brief* = les faits du jour, *Dive Insight* = le contexte) qui compile une conférence de résultats · une lettre aux actionnaires · un communiqué et trois notes d'analystes.
Decodifica di SFEIR (voce aziendale) del resoconto di Jason Clinton (Deputy CISO, Anthropic) pubblicato cinque giorni prima — già documentato in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **Il valore aggiunto non risiede nei fatti ma nella tesi che li rilegge**: se i controlli di Anthropic reggono, è perché **esiste un ciclo con fasi nominate a cui agganciarli** — "lo SDLC è il fondamento, non una formalità." La dimostrazione procede rileggendo la mappatura (**PSR in fase Plan, CLAUDE.md + egress allowlist in fase Code, agenti di revisione in fase Test, DAST continuo in fase Deploy, triage + instradamento SIEM in fase Monitor**), poi attraverso un'**anafora in quattro parti**: (1) *senza uno SDLC, i guadagni di produttività non si materializzano* — Clinton cita la **legge di Amdahl**: moltiplicare per 8 il volume di codice non moltiplica nulla se la revisione resta sequenziale e umana, e Anthropic ha guadagnato non distribuendo agenti ma **individuando la fase di blocco (Test) e ricostruendola** — "non si ottimizza un collo di bottiglia che non si è mappato" (in eco all'**effetto specchio** del DORA 2025); (2) *senza uno SDLC, la sicurezza non ha un punto di ancoraggio* — un **gate è per definizione un controllo posto tra due fasi**, e le tre minacce di Clinton vengono affrontate in momenti distinti; (3) *senza uno SDLC, nessuna politica di **FinOps dei token** può essere formulata* — la scansione agentica viene fatturata a consumo e cresce con il throughput di codice, quindi **il tiering basato sul rischio È la politica di FinOps** (decide dove pagare tre passaggi agentici e dove basta un SAST), altrimenti "la spesa in token non viene pilotata, viene scoperta a fine mese"; (4) *senza uno SDLC, non c'è nulla da misurare* — gli indicatori (16% → 54% delle PR commentate, un terzo degli incidenti passati intercettati) esistono solo perché ci sono fasi in cui si può collocare un contatore; in loro assenza, si producono solo **cifre di utilizzo** (licenze, token) che non dicono nulla sulla qualità o sul rischio. Due punti di forza oltre la tesi: la lettura dell'**incident agent-à-agent** ("un perimetro di sicurezza che si fonda su un'istruzione in un prompt non è un perimetro"; **l'accesso di un agente ad altri agenti fa parte della sua superficie di attacco**) e un **avvertimento metodologico esplicito** — le cifre di Anthropic su Anthropic, non verificate, pubblicate dal fornitore del modello descritto, nel contesto di una codebase giovane senza mainframe: **ciò che si traspone è il metodo, non le cifre**.
#SDLC#SDLC nativo per l'IA#ciclo di sviluppo
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
Messaggio di **Linus Torvalds** sulla mailing list **linux-media** (thread "Linking Patchwork with Sashiko?", relativo a uno strumento LLM per l'assistenza ai maintainer), in cui il creatore e **top-level maintainer** del kernel Linux **fissa ufficialmente la posizione del progetto sull'IA**. Rispondendo a Roman Gushchin, che aveva fatto notare come un messaggio ostile esprimesse una posizione "molto anti-LLM in generale", Torvalds concorda ("Yes") e poi **nega categoricamente che questa sia la posizione del kernel** ("And no, that's not the position of the Linux kernel"). **Batte i pugni sul tavolo** come maintainer supremo: **"Linux is not one of those anti-AI projects"**; chi non è d'accordo può **"do the open source thing: fork it"** — "or just walk away". **Tesi centrale**: **"AI is a tool, like the other tools we use, and clearly a useful tool"**; forse non era "così 'chiaramente' vero un anno fa, ma oggi non è in discussione". Distingue le questioni **ancora aperte** ("what the AI economy will actually look like in the end") dalla questione che è **risolta** ("is it useful?") — "anybody who doubts that clearly hasn't actually tried it". **Ammette** che lo strumento può essere **"painful"** — carico per i maintainer, e il fatto che "continua a trovare bug imbarazzanti" — ma rifiuta la postura da struzzo ("put your head in the sand going 'La La La, I can't hear you'"). **La risposta giusta**: fare in modo che gli **strumenti LLM aiutino i maintainer** invece di causare loro dolore. **Non coercizione, deliberatamente**: "nobody is forced to use it, but **I will very loudly ignore those who try to prevent others from using it**". Sull'imperfezione: "AI isn't perfect, but hell, anybody who points at its problems had better also point at the mirror" — "**natural intelligence isn't always all that great either**". **Quadro di governance**: il progetto kernel "has always been and will remain about **technology**"; l'aspetto sociale dell'open source è un "side benefit, not the _point_"; **"this is *NOT* some kind of 'social warrior' project, never has been, never will be"**; "we do open source because it results in **better technology**, not for religious reasons". Conclusione programmatica: **"we decide based on technical merit first. Not on fear of new tools."** Da leggere come una **dichiarazione di posizione dottrinale** da parte di una delle figure più influenti del software — in eco alla controtestimonianza pro-LLM di ESR (un altro pilastro dell'open source, [[raymond-llm-coding-empowering-2026-07-08]]).
#Linus Torvalds#Linux#Linux kernel
Linus Torvalds ([email protected]) — ingénieur logiciel finlando-américain · **créateur et mainteneur suprême du noyau Linux** (depuis 1991) et de **Git** (2005). Employé de la **Linux Foundation**. Figure centrale et notoirement franche de l'open source · dont la parole sur les mailing lists du kernel fait autorité et jurisprudence dans la communauté. S'exprime ici en sa qualité de **top-level maintainer** pour fixer la position officielle du projet vis-à-vis des outils d'IA. Autres participants au thread cités : Roman Gushchin (linux.dev) · Laurent Pinchart · Mauro Carvalho Chehab · Konstantin Ryabitsev (Linux Foundation) · Steven Rostedt · Stephen Finucane · Jason Gunthorpe · entre autres. (Message de mailing list linux-media ; date : 2026-07-14 ; date d'ajout à la veille : 2026-07-17.)
Un paper arXiv (cs.SE) di Martin Monperrus che sostiene una tesi radicale per lo SDLC: gli agenti di codifica hanno superato una soglia di capacità tale per cui **la revisione umana del codice non è più una componente necessaria** di una pipeline di qualità. Due affermazioni: (1) i sistemi autonomi basati su LLM raggiungono tutti gli obiettivi della revisione (individuazione dei difetti, qualità, conformità) a costi inferiori e con un throughput superiore; (2) il modello ibrido "l'agente scrive, l'umano rivede" è insostenibile — non garantisce una qualità reale e non scala con la velocità dell'IA, creando un "falso senso di sicurezza". Monperrus contrappone l'inspection de Fagan (1976) a una **pipeline di verifica avversariale multi-agente** (agente generatore + agenti revisori indipendenti + test/metodi formali + consenso basato su voto). L'essere umano si concentra sulle specifiche, sui compromessi architetturali, sull'approvazione dei domini critici e sui casi limite. Raccomandazioni: fare pilotaggio prima su componenti a basso rischio, misurare agente vs. umano, rendere esplicite le decisioni di rigetto.
#revisione del codice#revisione del codice#inspection de Fagan