Slide deck di **Dorra Bartaguiz** (CTO, **Arolla**), presentato alla conferenza **Dev With AI** e pubblicato in PDF su LinkedIn il **15 ottobre 2026**; **61 slide**, in francese con esempi in inglese. Tesi: quando l'IA fa esplodere la velocità, la qualità si riconquista attraverso pratiche di *craft* strumentate costruite attorno al modello — *harness engineering*.
#harness engineering#velocità#code review
Dorra Bartaguiz — CTO d'Arolla (conseil et formation, « agentic software crafters ») ; slides de son talk Dev With AI publiées sur LinkedIn.
Articolo tecnico di **Addy Osmani**, **Morgan Westlee Lunt** e **Qing Wang** (il team di **Claude Code**, **Anthropic**) sul blog *claude.dev*, pubblicato il **15 ottobre 2026**; ~3.200 parole. Descrive il flusso di code review del team, in cui Claude scrive circa il **90%** del codice per Claude Code. Da giugno a settembre, le PR unite sono **più che raddoppiate** e la quota di revert è scesa di **oltre il 40%**; nel monorepo di Anthropic, le modifiche giornaliere sono passate da **~2.500** (maggio) a **oltre 30.000** (settembre).
#code review#code review#agentic code review
Addy Osmani · Morgan Westlee Lunt · Qing Wang — équipe Claude Code (Anthropic) ; blog *claude.dev* · catégorie Engineering.
Post di **Rachel Laycock**, CTO di **Thoughtworks**, pubblicato il **2 settembre 2026** su *Rachel's Ramblings*, la sezione di martinfowler.com che dirige, circa **8.000 caratteri**. Il testo è una **risposta deliberata** a [[houck-dx-what-are-code-reviews-for-2026-08-05]], in seguito a un disaccordo pubblico tra i due autori durante un panel **Code Remix** ospitato da **Moderne**. Laycock accetta la diagnosi quantificata di Houck (+**106%** di righe per diff in **Meta**, +**64%** di dimensione mediana delle PR sul lato DX) e l'elenco delle funzioni della revisione che non riguardano l'individuazione di difetti, poi sposta la domanda: *« perché aspettiamo la code review per fare tutte queste cose? »* (A) Il principio guida è l'accorciamento dei cicli di feedback appreso in Thoughtworks — se il feedback ha valore, non eliminarlo, spostalo più vicino alla decisione che informa. Ogni funzione attribuita alla revisione viene riassegnata a monte: esplorazione delle alternative prima dell'implementazione, trasferimento di conoscenza tramite **pair programming**, ownership collettiva tramite **mob programming** e sessioni di design in team, allineamento architetturale tramite design condiviso seguito da **fitness functions**, e automazione di tutto ciò che è deterministico — *« Non dovremmo più discutere di spazi bianchi nel 2026. »* (B) La revisione basata sulle eccezioni sostituisce la revisione sistematica: un cambiamento architetturale fondamentale, un confine di sicurezza sensibile, un ampio blast radius, un'area non familiare di un sistema critico, o semplicemente una mancanza di confidenza dichiarata da un team. (1) L'automazione della revisione tramite un agente che imita il revisore umano viene respinta come *« automatizzare la cerimonia piuttosto che interrogarsi sul perché la cerimonia esista »*. (2) Il debito cognitivo di Houck viene riconosciuto come reale, ma la PR obbligatoria viene giudicata una difesa debole: *« Abbiamo bisogno che gli ingegneri comprendano i sistemi, non i diff. »*
#code review#revisione basata sulle eccezioni#pull request
Rachel Laycock · CTO de Thoughtworks · sur *Rachel's Ramblings* (martinfowler.com).
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.
Numero della newsletter **Engineering Enablement** di **DX** firmato da **Brian Houck**, pubblicato il **5 agosto 2026**, circa **13.000 caratteri**. Il testo si apre con un'osservazione quantificata: in **Meta**, le righe significative per diff unite da un umano sono aumentate del **106%** in un anno e i diff per sviluppatore al mese del **51%**, con più dell'**80%** di questa crescita attribuibile all'IA agentica, mentre la quota di diff revisionati entro 24 ore diminuisce; l'analisi di DX misura invece una dimensione mediana delle pull request in aumento del **64%**, mentre gli sviluppatori vorrebbero dedicare circa il **7%** del loro tempo alla revisione. (A) Prima di affidare la revisione all'IA, Houck riformula la questione dell'uso: *"Quale problema risolveva la revisione del codice prima dell'arrivo dell'IA?"* Se la risposta è l'individuazione dei difetti, l'automazione completa diventa inevitabile; lo studio **Bacchelli & Bird** (*Modern Code Review*, ICSE 2013) mostra che i commenti relativi ai difetti rappresentano solo il **14%** dei commenti effettivamente scritti. (B) Parte dell'onere è *autoimposto*: lo studio Microsoft del 2016 su **911 sviluppatori** aveva già individuato il tempo di turnaround, la dimensione della revisione e la comprensione della motivazione del cambiamento come i primi tre ostacoli, e solo il **26%** scriveva ancora una descrizione dettagliata. (1) **RADAR** in Meta costituisce il dispiegamento di riferimento per la stratificazione del rischio. (2) Tre mosse ordinate: correggere le fondamenta, progettare l'IA attorno al giudizio umano, proteggere ciò che la revisione produce in modo invisibile. Il corpus include già [[monperrus-end-of-code-review-agents-supersede-2026-06-11]], che spinge l'automazione fino alla sostituzione, e [[laycock-thoughtworks-reviewing-all-this-code-2026-09-02]], la risposta diretta a questo testo.
#code review#code review#coda di revisione
Brian Houck · signataire de l'édition · sur la newsletter Engineering Enablement de DX ; fonction non affichée par la page.
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 (torvalds@linuxfoundation.org) — ingénieur logiciel finlando-américain · **créateur et mainteneur suprême du noyau Linux** (depuis 1991) et de **Git** (2005). Employé de la **Linux Foundation**. Figure centrale et notoirement franche de l'open source · dont la parole sur les mailing lists du kernel fait autorité et jurisprudence dans la communauté. S'exprime ici en sa qualité de **top-level maintainer** pour fixer la position officielle du projet vis-à-vis des outils d'IA. Autres participants au thread cités : Roman Gushchin (linux.dev) · Laurent Pinchart · Mauro Carvalho Chehab · Konstantin Ryabitsev (Linux Foundation) · Steven Rostedt · Stephen Finucane · Jason Gunthorpe · entre autres. (Message de mailing list linux-media ; date : 2026-07-14 ; date d'ajout à la veille : 2026-07-17.)
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