Saggio pubblicato su **Gates Notes** il **26 agosto 2026** da **Bill Gates**, co-fondatore di **Microsoft** e presidente della **Gates Foundation**, ~4.500 parole, annunciato come il primo di una serie. Il testo pone un'alternativa — l'IA sarà il più grande fattore di equità mai inventato, oppure la peggiore fonte di ingiustizia — e una constatazione: non esiste alcun piano per affrontare questo periodo. **(A) Tre rischi**: la scomparsa duratura dei posti di lavoro di inizio e metà carriera, tanto colletti bianchi quanto colletti blu, nell'arco di un decennio anziché di più generazioni, perché questa volta la sostituzione riguarda la **cognizione**; la militarizzazione da parte di attori malintenzionati (attacchi informatici, bioterrorismo, frodi, deepfake), unita a una concentrazione di potere in mano a chi già lo detiene; l'effetto dei compagnons IA sullo sviluppo dei bambini e sul pensiero critico. **(B) I benefici**, individuati in cinque ambiti — ricerca, salute, agricoltura nei paesi a basso reddito (l'impatto che l'autore definisce il più rapido), servizi pubblici, istruzione — con una riserva veicolata dal verbo: *"la parola chiave è 'può'"*. **(C) Tre proposte** aprono la serie: costruire un quadro istituzionale nazionale e internazionale senza precedenti, ispirandosi al regime di ispezione nucleare, alla regolamentazione dell'aviazione e agli accordi sull'ozono; riservare alcune professioni agli esseri umani, un ambito denominato **Human Reserved**; **tassare i token IA e i robot** per riequilibrare la tassazione tra lavoro e capitale. Gates dichiara i propri legami finanziari con il settore e il trasferimento dei suoi profitti alla fondazione. Il testo si inserisce nel filone dei saggi di dirigenti sulla distribuzione del valore dell'IA — [[nadella-frontier-ecosystem-human-token-capital-2026-06-12]], [[zuckerberg-meta-future-is-for-everyone-superintelligence-2026-08-10]] — concentrandosi sul potere pubblico piuttosto che sull'impresa.
#IA ed equità#transizione all'era dell'IA#sostituzione della cognizione#scomparsa dei posti di lavoro#lavori di inizio carriera
Bill Gates — cofondateur de Microsoft · président du conseil de la Gates Foundation. Blog personnel Gates Notes. Page non capturable par `curl | lynx` (403 Akamai) : extraction navigateur.
Guest post di **Andy Warfield**, ingegnere nel team **S3** di **AWS**, pubblicato il **26 agosto 2026** su *All Things Distributed*, il blog di **Werner Vogels**, che lo introduce in poche righe firmate «--W» : **3.554 parole** secondo la pagina. Il testo funge da veicolo per l'annuncio secondo cui **DuckLabs**, il team dietro **DuckDB**, entra a far parte di **AWS**. (A) La tesi: l'informatica dei sistemi consiste nel ricercare il compromesso elegante rispetto a una «fisica» mobile — i rapporti tra velocità della memoria, rete e calcolo — e quella fisica è cambiata. Warfield quantifica lo scarto: un **m1.xlarge** del 2007 offriva **15 GB di RAM**, **4 core virtuali** e **~1 Gb/s** di rete; un **m8g.48xlarge** oggi offre circa **50×** in più su ciascuno dei tre parametri. La crescita dei dataset, nel frattempo, segue una distribuzione la cui coda è costituita da volumi molto grandi. (B) La conseguenza: l'elaborazione distribuita — **MapReduce**, gli **RDD** di **Spark** — è stata concepita sotto i vincoli di I/O dei primi anni 2000, e gran parte del lavoro ad essa affidato non ha più bisogno di uscire dall'applicazione. Da qui il motore-libreria incorporato, in-process, che gira nello spazio di indirizzamento dell'applicazione, di cui **DuckDB** è l'esempio. Warfield àncora questo al paper *Scalability! But at what COST?* (2015) e all'epigrafe di **Paul Barham**: «Puoi avere un secondo computer una volta dimostrato di saper usare il primo.» Formula una riserva esplicita: «Quando un lavoro ha davvero bisogno di mille macchine, ha bisogno di mille macchine.» Il corpus contiene già [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] dallo stesso blog e [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] sull'analytics self-service.
#DuckDB#DuckLabs#acquisizione AWS
Andy Warfield · ingénieur du service S3 chez AWS · en billet invité sur *All Things Distributed* ; introduction de Werner Vogels · CTO d'Amazon.
Saggio di **Bill Staples**, CEO di **GitLab**, pubblicato il **24 agosto 2026** sul blog about.gitlab.com: una lettura annunciata di **31 minuti**, circa **39.000 caratteri**, presentato come il seguito di un memo scritto al consiglio di amministrazione nel gennaio 2026 e in parte pubblicato a maggio con il titolo *GitLab Act 2*. Il testo si presenta come una risposta all'AI-native SDLC playbook di **Anthropic**, pubblicato tre giorni prima, da cui riprende la frase d'apertura — "Code is no longer the bottleneck" — per porre la domanda che lo guida: cosa diventa scarso quando il codice diventa abbondante. (A) La diagnosi economica: l'unità utile non è il costo per riga ma il **costo per modifica accettata**, che aggrega generazione, ambiente, contesto, verifica, revisione, correzione e governance; l'IA fa crollare solo il termine di generazione, il che rende gli altri proporzionalmente più pesanti — un'organizzazione dieci volte più veloce nel generare "si limiterà a spostare la coda". (B) La risposta architetturale: quattro capacità — piattaforma agentica, esecuzione su scala macchina, contesto durevole, governance — che formano un livello enterprise che sopravvive al modello, "The model should be replaceable. The agent should belong to the customer." (1) Tre modalità coesistono in modo duraturo, dal legacy guidato dall'uomo allo sviluppo autonomo, contro l'idea di un'unica curva di maturità. (2) La pipeline CI/CD diventa il luogo in cui gira l'inner loop, invece di essere un gate di fine catena. Le cifre citate sono quelle di Stripe, Spotify e Amplitude; GitLab ne produce una sola, relativa al proprio contrôle de source nouvelle génération. Il corpus contiene già [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], la fonte a cui questo testo risponde, e [[sfeir-sdlc-pdlc-articulation-2026-07-22]] sull'articolazione SDLC/PDLC che Staples fa propria.
#abbondanza di codice#costo per modifica accettata#teoria dei vincoli
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Guida di ampio respiro di **Anthropic** a cura di **Louis Claxton** (team Applied AI), pubblicata il **21 agosto 2026** sul blog claude.com: una lettura dichiarata di **40 minuti**, circa **64.000 caratteri**, presentata come una raccolta di *plays* tratti dal lavoro del team con i propri clienti. (A) La diagnosi: con il codice non più il collo di bottiglia, lo spostamento avviene verso le fasi a monte e a valle della scrittura (piano, revisione/test, deploy), i controlli riga per riga smettono di reggere quando è l'agente a scrivere la maggior parte del diff, e il costo della governance aumenta perché le eccezioni continuano a passare per comitati periodici. (B) La risposta: sei fasi (Plan, Design, Build, Test, Deploy, Maintain) organizzate come un **loop** piuttosto che una catena, ciascuna conclusa da un **artefatto committato** che la fase successiva legge — `intent.md`, `spec.md`, `plan.md`, il diff e i suoi test, la PR e i suoi findings, il record dell'incidente. (1) La conoscenza istituzionale diventa file versionati: `CLAUDE.md`, skill, `REVIEW.md`, `bands.yaml`. (2) La governance si divide in due livelli, con la skill posizionata come controllo consultivo e l'hook come livello deterministico dietro di essa. La separazione dei compiti è posta come invariante — l'agente che scrive il codice non può approvarlo — e il pezzo si chiude con *"The loop keeps running. Human judgement stays above it."* Il corpus contiene già [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] sul versante sicurezza dello stesso ciclo, e [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] sulla stessa scomposizione in sei fasi vista da un concorrente.
#AI-native SDLC#software development lifecycle#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Guida firmata da **Michael Segner**, pubblicata il **20 agosto 2026** sul blog claude.com nella categoria *Claude Code*: una lettura di **5 minuti** annunciata per circa **31.500 caratteri** di testo, offerta anche in PDF. Materiale dichiarato: interviste a **più di una dozzina** di startup, quindici delle quali nominate — **Artemis Security**, **Cainex**, **Clay**, **ClickHouse**, **Cognition**, **Commure**, **Crosby**, **Emergent**, **Harvey**, **Heidi**, **Higgsfield**, **Omni**, **Parahelp**, **Translucent**, **Zingage**. (A) Cinque regole operative: *everyone ships*, *automate the tedium*, *trust, but verify*, *build for rebuilding*, *prototype, dogfood, productionize*, ciascuna chiusa da suggerimenti sui prodotti e riunite in una checklist finale. (B) Un corpo composto da citazioni attribuite, ogni regola illustrata da dirigenti nominati piuttosto che da una metrica aggregata. Le quattro cifre in evidenza sono quelle delle aziende intervistate: **+30%** di funzionalità rilasciate in più (ClickHouse), **da 2 a 3×** produttività ingegneristica (Omni), **100%** del bug triage automatizzato (Clay), **più di 6.000 PR a settimana** (Artemis Security). Due passaggi si discostano dal registro testimoniale: il ciclo di autocorrezione di **Cainex** sulla codifica medica, descritto passo per passo, e l'uso interno di **Claude Tag** in **Anthropic** come primo responsabile per la reperibilità CI/CD. La domanda posta in apertura — *"what would it look like if an organization built their product development lifecycle with Claude Code from the ground up?"* — si collega a [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], pubblicato il giorno successivo dallo stesso editore, e prolunga [[cherny-wu-reflecting-year-claude-code-2026-07-17]].
#Claude Code#startup#everyone ships
Michael Segner · auteur du guide sur le blog claude.com (fonction non affichée par la page) ; entretiens avec les dirigeants de quinze entreprises nommées.
Post del blog aziendale di **Block** (`block.xyz/inside`), non firmato — l'autore indicato è **"Block"** —, pubblicato il **18 agosto 2026**, ~930 parole, che annuncia **l'apertura open source di Berd**, l'applicazione desktop interna di Block per lavorare con gli agenti, ed espone la tesi progettuale che l'ha guidata: dare carattere agli agenti *"non solo attraverso ruoli, istruzioni, skill e strumenti, ma attraverso identità visive distintive"* — da cui i personaggi animati proprietari, i *"Gloopies"*. Il post parte da un'osservazione di frammentazione (*"The technology was powerful, but the experience around it was fragmented"*) e da un problema d'interfaccia denominato con precisione: *"the product gives people little sense of how the agent is configured, which context and tools are available to it, and how it differs from another agent"*. Due contributi strutturanti. **(A) Un'articolazione a tre livelli**: **goose** resta il framework e il *runtime* che sostiene l'agent loop; **Berd** è il client desktop (progetti, contesto, sessioni, agenti, configurazione); i due comunicano tramite l'**Agent Client Protocol**. **Buzz** è designato come il seguito, per quando il lavoro solitario diventa collaborativo (*"Start alone, then go multiplayer"*). **(B) Sei requisiti trasmessi a Buzz**, formulati come conclusione: *"private space, durable context, recognizable agent identities, reusable skills, visible configuration, and clearer visibility into an agent's configured context, tools, and capabilities"* — una griglia direttamente riutilizzabile per valutare un client di agenti. Il testo stesso distingue identità e capacità: *"The avatars make the agent recognizable. Its role, skills, and tools make it useful."* Non viene prodotta alcuna cifra d'uso e non è indicata alcuna licenza per l'apertura open source.
#Berd#Block#open source
**Aucun auteur nommé** : le billet est signé **« Block »** — le champ *Author* de la page porte le nom de l'entreprise. Publié le **18 août 2026** sur `block.xyz/inside` · le blog **corporate** · et non sur `engineering.block.xyz`.
Post del blog di **Sonatype** a firma di **Aaron Linskens** (*technical writer*), pubblicato il **18 agosto 2026**, ~1.300 parole: racconta uno studio di **Sonatype Research Labs** condotto su **49 mesi** (giugno 2022 — giugno 2026) su una **coorte fissa** di applicazioni enterprise, scelta metodologica dichiarata per isolare l'evoluzione del parco applicativo da quella del portafoglio clienti. Il risultato è presentato come una contraddizione: il rimedio è più rapido, ma il rischio si accumula ulteriormente. (A) **Lo stock è in crescita** — vulnerabilità *Critical* e *High* per applicazione **×4,31** (da **14,14** a giugno 2022 a **54,3** nel 2026, ancora **×3,91** escludendo le applicazioni legacy portate di recente sotto gestione), nuove versioni di componenti interessate al **46×** il tasso pre-IA, creazione mensile di applicazioni **×4,84**. (B) **Il rimedio sta migliorando** — oltre la metà delle violazioni risolte lo è in meno di un giorno, l'età mediana delle vulnerabilità *Critical/High* non risolte scende da **228** a **126 giorni**, poi a **103** a maggio 2026; tra le coorti che hanno avuto dodici mesi, il **52,6%** è risolto, il **44,3%** aperto, il **3,1%** sotto waiver. (C) **La leva proposta è la selezione dei componenti**: al momento della scelta di una dipendenza vulnerabile, esisteva già una versione sostanzialmente meno rischiosa nel **62,2%** dei casi su **Maven**, nel **46,9%** su **npm**, nel **34,3%** su **PyPI** — uno scarto che il testo attribuisce a un gap informativo piuttosto che a una colpa dello sviluppatore. Il post stesso afferma che l'IA non è l'unica causa dell'accelerazione, e conclude su **Sonatype Guide**, che porta questa intelligence fino al punto di selezione. Sul versante supply-chain, estende quanto [[fiches/2026-08/staples-gitlab-when-code-is-abundant-2026-08-24]] inquadra in termini economici e [[fiches/2026-07/clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] in termini di ciclo sicuro.
#supply chain software#supply chain software#Sonatype Research Labs
Aaron Linskens · *technical writer* chez Sonatype · sur le blog de l'éditeur ; les chiffres sont produits par Sonatype Research Labs · non par l'auteur.