**Boris Cherny** (Creator & Head of Claude Code @Anthropic) pubblica su LinkedIn una tabella-framework, **« Steps of AI Adoption »**, che mappa l'adozione dell'IA agentica da parte di un team di ingegneria lungo **5 stadi (0→4)**, ciascuno caratterizzato da un **ordine di grandezza di agenti guidati** e da una **trasformazione del ruolo dell'ingegnere**: **0 Gated** (0 agenti, accesso bloccato), **1 Assisted** (~1 agente — "tu + un agente", pair programming supervisionato), **2 Parallel** (~10 agenti — **orchestrator**), **3 Supervised autonomy** (~100 agenti — **manager of managers**, un albero organizzativo), **4 AI-native** (~1.000+ agenti — **VP steering by intent**). La tabella incrocia cinque colonne: numero di agenti, *a cosa assomiglia*, *il collo di bottiglia*, *i prodotti che aiutano*, *i guardrail*. **Tesi centrale**: consumare più token non fa salire di livello — avanzare allo stadio successivo richiede **identificare e rompere il prossimo collo di bottiglia** E **costruire il prossimo set di guardrail**. Concretamente: dare a Claude un **loop di auto-verifica** affidabile (test + build + lint + e2e su un ambiente reale), attivare **Auto mode** (evitando prompt di permesso bloccanti), rendere **il code review e il security review predefiniti**, adottare interfacce multi-agente (Agent view CLI, Desktop, app iOS/Android, Tag), poi `/loop`, `/batch`, `/goal`, **dynamic workflows** e **worktree isolation** per i subagenti. Sullo steering: l'utilizzo (dashboard) misura **l'attività, non il ritorno**; la domanda giusta è *"avremmo comunque speso sforzo ingegneristico su questo? se sì, quante ore-ingegnere manuali sarebbero costate?"* — questo è il ROI. Il vero guadagno arriva quando **la correzione e la manutenzione avvengono in background** e i team si concentrano sul *costruire*. Anthropic si colloca allo **stadio 3, diretta verso il 4**; Boris Cherny dichiara di aver raggiunto personalmente il **livello 4**.
#Boris Cherny#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)
Netflix — Lettera agli azionisti Q2 FY2026: il GenAI si espande in produzione (≈300 titoli nel 2026), LLM per la scoperta e la ricerca in linguaggio naturale, strumenti AI lungo l'intero ciclo pubblicitario (Netflix)
Analisi SFEIR (voce dell'azienda) sulla decisione, annunciata il 16 luglio 2026, di **Airbus** di selezionare **Scaleway** (gruppo **iliad**) come proprio **"cloud di fiducia"** per ospitare e modernizzare le sue applicazioni aziendali critiche e i dati più sensibili (progettazione aeronautica, ingegneria, produzione industriale, operazioni, proprietà intellettuale). Al termine di una gara d'appalto avviata a **inizio gennaio 2026** che confrontava **dieci candidati**, Scaleway vince su **tre criteri** — capacità tecnologiche/IA, eccellenza operativa e, soprattutto, **garanzie legali e di governance**: giurisdizione europea, protezione dei dati reale, **immunità dal** **Cloud Act** statunitense. SFEIR sottolinea il **capovolgimento della gerarchia**: la governance ha pesato più della funzionalità, sebbene gli hyperscaler statunitensi (Microsoft, Google, AWS) mantengano una superiorità funzionale che nessun attore europeo eguaglia "su tutta la linea". L'accordo, pluriennale e di importo non divulgato, **integra** (non sostituisce) la strategia **multicloud** di Airbus — la dottrina sostenuta dall'azienda: costruire un portafoglio in cui ogni reparto opera secondo i propri vincoli, mantenendo al contempo il **potere di cambiare** (reversibilità, cfr. France Télévisions/ALIX distribuita senza riscrittura). La vera posta in gioco è l'**IA souveraine**: far girare modelli su dati industriali (simulazione, manutenzione predittiva, ingegneria assistita) richiede una **catena completa — calcolo, addestramento, inferenza — mantenuta all'interno di una giurisdizione di fiducia**. Tre insegnamenti: una **soglia di credibilità** superata per il cloud sovrano europeo; **governance > funzionalità** per i dati strategici; la sovranità si costruisce **a strati** (infrastruttura → piattaforma → modello), e la parte decisiva — la reversibilità dell'IA — si giocherà nei prossimi mesi.
Analisi del gabinetto di ingegneria SFEIR ("una lettura da ingegnere") sul lancio, il **16 luglio 2026**, di **Kimi K3** da parte del laboratorio cinese **Moonshot AI**: un modello **open-weights, di livello frontier**, il cui fornitore dichiara **circa 2.800 miliardi di parametri**, un **contesto da un milione di token** e il **rilascio dei pesi prima del 27 luglio 2026** (probabilmente con licenza Modified MIT, come per la linea K2). Tesi: una capacità un tempo ritenuta riservata ai giganti proprietari (Anthropic, OpenAI, Google) diventa disponibile **in open weights, a prezzo scontato, da un laboratorio cinese**. SFEIR — pur essendo **partner di Anthropic e Google Cloud**, e quindi "senza alcun interesse a sopravvalutare un modello cinese" — adotta una **riserva metodologica** cardinale: il giorno del lancio **non esiste alcuna tabella di benchmark ufficiale e completa**; le specifiche (2,8T, Kimi Delta Attention, +25% di efficienza di addestramento) e i punteggi sono **dichiarati dal fornitore** o tratti da **arene comunitarie**, "da trattare come affermazioni, non come fatti misurati." La nuova architettura (**Kimi Delta Attention**, attenzione lineare ibrida; decodifica dichiarata fino a **6,3 volte più veloce** a 1M di token) rompe con la cadenza K2 (K2 lug. 2025 → K2.7 Code giu. 2026, un modello di punta ogni due mesi); due varianti accompagnano il lancio (**K3 Max**, **K3 Swarm Max**), con dismissione forzata della serie kimi-k2.5/moonshot-v1 il **31 agosto 2026**. **La vera arma è il prezzo** (~3$/M in ingresso, 0,30$ in cache, 15$ in uscita secondo fonti secondarie): un modello open-weights di livello frontier a questo livello **trascina verso il basso l'intera curva prezzo-prestazioni** — la commodizzazione del livello modello, accelerata dall'open source. Ma la singolarità decisiva non è un punteggio: è la **reversibilità**. Un modello open-weights di livello frontier trasforma un'API consumata (dipendenza dal fornitore) in un'**opzione** (self-hosting, portabilità, uscita dal lock-in), al prezzo di un'infrastruttura pesante per ospitare 2,8T di parametri. Il punto di vista di SFEIR: **l'open-weights cambia la domanda, non solo la risposta** — non più "quale modello è il migliore/il più economico?" ma "quanta parte del mio sistema sono disposto a rendere dipendente da un fornitore che non controllo?". La postura corretta resta un **portafoglio instradato** (un modello per compito, un modello per vincolo), con Kimi K3 che aggiunge una **colonna "reversibilità"** alla griglia decisionale. La convinzione "AI Only" resta invariata: il modello è una commodity, il vantaggio duraturo risiede nell'ingegneria che lo circonda (Context Engineering, harness, governance dei costi, capacità di cambiare idea). Le cifre restano da validare "in autonomia" — sui propri repository, sui propri dati.
Digest di tech-watch da fonti primarie sulla posizione di **Gregor Hohpe** (autore di *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; ex Enterprise Strategist per AWS e Google Cloud, ex Chief Architect di Allianz) riguardo al ruolo dell'architetto nell'era dell'IA generativa. Tesi: 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," comunicare con gli esseri umani, produrre astrazioni solide**. Formula chiave (Craft Conference 2026): "*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*". La sua tesi distintiva (l'architetto non dovrebbe essere la persona più intelligente della stanza, dovrebbe **rendere più intelligenti tutti gli altri**) si rafforza man mano che il codice diventa abbondante: il vantaggio deriva dalla **disciplina decisionale** e dal **far emergere trade-off nascosti**, non dal volume. Il digest analizza inoltre le sue posizioni per ruolo (enterprise architect: da **cartografo a esploratore**; software architect: **debug** delle decisioni piuttosto che scrittura di codice; platform architect: **astrazioni, non illusioni**), la sua metafora delle **opzioni reali** (valore crescente con la volatilità tecnologica, analogia con Black-Scholes) e i suoi avvertimenti ("*An AI-driven SDLC punishes bad habits much faster*"; i vincitori dell'IA si distingueranno per la velocità con cui passano dalla sperimentazione alla **produzione governata**). ⚠️ La formula ampiamente diffusa "gli architetti che usano l'IA sostituiranno chi non la usa" **non è di Hohpe**. Dominio: architettura del software, ruolo dell'architetto, processo decisionale, opzioni reali, piattaforme, GenAI nell'SDLC.
Nota di analisi SFEIR che ripercorre il ruolo dell'architetto software nell'era dell'IA generativa attraverso il framework di **Gregor Hohpe** (*The Software Architect Elevator*). Tesi centrale: l'architetto « **Oracolo** » — il supremo custode della conoscenza che emette regole dalla torre d'avorio — è superato, poiché l'IA genera codice e proposte su richiesta; l'architetto moderno diventa un **amplificatore di intelligenza (IQ Amplifier)** che fornisce ai team i modelli mentali, il contesto di business e gli strumenti decisionali per sfruttare l'IA garantendo al contempo la coerenza del sistema. Il documento scompone l'impatto **piano per piano dell'"Architect Elevator"** (Enterprise / Solution / Platform / Software architect) e argomenta a favore del **Domain-Driven Design (DDD)** come salvaguardia indispensabile: il **linguaggio ubiquo** sottende i *system prompt* (un dizionario di dominio iniettato tramite `.clinerules`/template, che riduce le allucinazioni e le interpretazioni errate del business), e i **bounded context** limitano l'ambito affidato all'IA per massimizzare l'affidabilità della generazione. Conclusione: l'IA non è una minaccia ma un catalizzatore che solleva l'architetto dai compiti tecnici di input per mettere in primo piano la sintesi, la visione strategica, la modellazione e il legame umano tra tecnologia e business. Dominio: architettura software, ruolo dell'architetto, DDD, prompting strutturato, governance dell'IA aziendale.
Prasanna Sankar (co-fondatore/CTO di Rippling, fondatore di Vorflux) pubblica "The Great Flattening" — un saggio-manifesto che sostiene che i modelli di coding sono diventati **sovrumani** e che il collo di bottiglia si è spostato dalla produzione di codice alla **codifica del giudizio** negli *agent harness*. Tutto, all'interno dell'organizzazione, "collassa verso l'harness"; il vero lavoro di ciascuno diventa *self-profiling*: estrarre i framework decisionali taciti dalla propria testa per codificarli nella codebase. Lancio simultaneo di Vorflux ("autopilot for software engineering"), seed da 15 milioni di dollari (Y Combinator, Peak XV Partners, Alliance DAO). Il saggio ha totalizzato oltre 60.000 visualizzazioni su X in 24 ore.
#Great Flattening#Vorflux#Prasanna Sankar
Prasanna Sankar (Prasanna S, @myprasanna) — co-fondateur et ex-CTO de Rippling ($16B+ valorisation) · fondateur et CEO de Vorflux AI. Article publié sur X (format long-form article) le 14 juillet 2026 · contenu repris comme manifeste Vorflux (vorflux.com/manifesto).
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.)
Analisi SFEIR (voce dell'azienda) sulla disponibilità generale, a partire dal 9 luglio 2026, di **GPT-5.6** di OpenAI — non un singolo modello, ma una **famiglia di tre livelli**: **Sol** (ammiraglia per compiti long-horizon/cyber/scienza, l'unico a sbloccare le modalità "max" e "ultra"), **Terra** (livello bilanciato per l'uso quotidiano, ~metà del prezzo di GPT-5.5) e **Luna** (veloce/economico, alto volume). Tutti e tre condividono ~**1,05 M di token** di contesto, **128k** token di output e una data di cutoff della conoscenza al **16 febbraio 2026**. Il fatto più strutturante non è un punteggio, ma una **griglia tariffaria aggressiva** (Sol 5$/30$, Terra 2,50$/15$, Luna 1$/6$ per milione di token): Sol mantiene il prezzo dell'ammiraglia precedente pur essendo più capace, spostando il confronto sul **rapporto capacità-costo**. Due sottigliezze di fatturazione (le scritture in cache fatturate a **1,25×**, un sovrapprezzo oltre i **272k** token) rendono la griglia fuorviante finché non si è misurato quanto contesto l'agente rilegge (rapporto lettura/scrittura ~**153:1** nella programmazione agentica). Verdetto dell'ingegnere, presentato come neutrale (SFEIR è al tempo stesso partner **Google Cloud Premier** *e* partner **Anthropic**): **nessuno vince su tutti i tavoli** — GPT-5.6 domina Terminal-Bench 2.1 e il Coding Agent Index (a un terzo del costo per compito), Claude resta avanti su SWE-Bench Pro (~15 pt); METR ha segnalato un tasso record di **reward hacking** su Sol. Conclusione: "smettere di cercare il campione, imparare a instradare" — il modello è un commodity, il vantaggio duraturo risiede nel **Context Engineering/Harness Engineering**.
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.
#fingerprinting#browser fingerprint#anti-bot
**Scrapfly Engineering** — équipe d'ingénierie de **Scrapfly** · fournisseur d'infrastructure de collecte web. Le texte annonce sa position d'intérêt sans détour : *« Scrapfly ships a browser that has to match a real one across hundreds of signals · and math is one of the harder ones. »* On lit donc un **attaquant du problème de détection** · qui documente le canal parce qu'il doit le neutraliser.
Analisi SFEIR (voce da società di consulenza) del lancio, l'8 luglio 2026, di **LLMD** da parte della startup parigina **ZML** (fondata da **Steeve Morin**, ex VP Engineering di Zenly): un server di inferenza che esegue LLM su **cinque famiglie di chip** (NVIDIA CUDA, AMD ROCm, Google TPU, Intel oneAPI, Apple Metal) **a partire da un'unica codebase**. Tesi strutturante: il training sta cedendo il centro della scena all'**inferenza**, dove si decidono ormai il costo per token, la latenza e soprattutto la **dipendenza dal silicio**. La scommessa di ZML — riassunta dal motto *model to metal* — consiste nel **disaccoppiare il modello dall'hardware** tramite un compilatore scritto in **Zig + MLIR** che produce un binario nativo ermetico, senza Python nel percorso di esecuzione, esposto tramite una **API compatibile con OpenAI**. Due componenti, due licenze: **ZML** (il framework, Apache-2.0, >90% Zig) è open source; **LLMD** (il server) non lo è, gratuito al lancio. L'articolo legge l'oggetto attraverso tre lenti da società di consulenza — **FinOps dei token**, **libertà architetturale** (Design to Exit), **sovranità** (chip europei emergenti, integrazione nel processore VSORA Jotunn8) — per poi emettere un verdetto senza sconti: si tratta di un'**alpha**, da mettere "sotto osservazione attiva", non da adottare oggi.
Post X di **Eric S. Raymond** (ESR, autore di *The Cathedral and the Bazaar*, co-fondatore della Open Source Initiative, ~50 anni di programmazione) — **una controtestimonianza frontale alla narrazione secondo cui "gli LLM producono codice pessimo e hanno allucinazioni, inutili per la programmazione".** La sua tesi: questo **non gli accade quasi mai**, e **per nulla più negli ultimi due generazioni** di modelli che usa ("chat GPT 5.4 e 5.5" sotto **codex**). Il sintomo precedente — un modello che "esce dai binari" avvicinandosi al proprio limite di contesto — è scomparso: codex ora mostra un **avviso rosso** che invita l'utente a **svuotare la sessione** invece di degenerare. **Ambito d'uso**: IA applicata a **modifiche di funzionalità, refactoring e debugging su 63 progetti** in **C, Go, Rust, Python e shell**; scrittura di documentazione; **decompilazione di un binario DOS in codice sorgente leggibile**. Una **routine di lavoro** consolidata: quando riapre un progetto, esegue prima i **test di regressione**, poi avvia codex e gli chiede di **verificare il codice** (bug + suggerimenti di miglioramento). Verdetto: gli LLM sono **"eccellenti e straordinariamente responsabilizzanti"**; il loro **limite peggiore** è la **"visione a tunnel architetturale"** — eccellenti nel generare codice a partire da specifiche, ma talvolta **ciechi ai pattern di livello superiore** — cosa che considera il **compito del suo "meatbrain".** Il punto più forte, controintuitivo: gli LLM **NON sbagliano i dettagli e i casi limite**; dichiara di essere **peggiore di loro** su questo fronte (nonostante 50 anni di esperienza), perché se una modifica deve **toccare cinque punti**, il modello **li trova tutti e cinque in modo affidabile**, mentre l'essere umano ne corregge quattro e **passa ore a fare debugging** prima di trovare il quinto dimenticato. Interroga poi i **"downshouters"**: vivono in un **universo diverso**? Usano **modelli vecchi e deboli**? C'è uno **skill issue** che lui non vede perché le sue **abitudini mentali e la sua comunicazione** si adattano bene agli "handle" di questi strumenti? Una questione che considera importante da chiarire, poiché "**miliardi di dollari verrebbero sprecati in una spesa di token mal indirizzata**". La sua ricetta, "molto semplice": **"Sii chiaro nel pensiero, di' al modello ciò che vuoi con precisione, e succedono cose buone"** — chiudendo con: "cosa mi sto perdendo qui?" Da leggere come un **contrappunto pro-LLM da parte di una figura storica dell'open source** al dibattito ricorrente sulla (s)valutazione degli agenti di codifica — facendo eco allo "skill issue" e alla disciplina delle specifiche (cfr. [[martignole-token-manifesto-2026-07-17]]), e formando un dittico con la posizione dottrinale pro-strumenti-IA di **Linus Torvalds** a nome del kernel Linux ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
Resoconto tecnico di prim'ordine di **Jarred Sumner**, creatore di **Bun** (runtime JS/TS, >22M download/mese), sulla **riscrittura completa di Bun da Zig a Rust in 11 giorni** (3→14 maggio 2026) guidata da **Claude** — un caso di studio eccezionale di ingegneria del software assistita dall'IA **su scala industriale**. Motivazione: una classe ricorrente di bug (use-after-free, double-free, leak) derivante dal mix di memoria gestita da GC (JavaScriptCore) e memoria manuale (Zig); in **Rust sicuro**, questi bug diventano **errori di compilazione** con pulizia automatica (`Drop`/RAII) — "un ciclo di feedback migliore di una guida di stile". Rifiutando il dogma secondo cui "una riscrittura è sempre una cattiva idea" (un anno di blocco delle correzioni di bug per 3 ingegneri), Sumner sceglie un **porting meccanico** (preservare l'architettura, cambiamento minimo del comportamento) validato dalla **suite di test esistente, scritta in TypeScript e quindi indipendente dal linguaggio** (60.624 test, 1,39M asserzioni `expect()`, 0 test rimossi, 6 piattaforme). L'harness: **~50 workflow dinamici** in **Claude Code**, cicli *scrittura → 2+ revisori avversari → applicazione*, fino a **64 istanze Claude in parallelo** (4 worktree × 16), con **PORTING.md** + **LIFETIMES.tsv** generati in preparazione. Numeri: **6.502 commit** (picco 695/h, 58/min, ~1.300 righe/min), diff finale **+1.009.272 righe**, ~16.000 errori di compilazione trattati come una coda, **5,9 miliardi di token di input non in cache + 690M di output ≈ 165.000 $**. Leve metodologiche chiave: la **revisione avversaria** (un secondo Claude, contesto separato, vede solo il diff, incaricato di trovare perché è sbagliato — individua bug sottili che sono *semanticamente* diversi ma *sintatticamente* identici) e il principio **"correggere il processo che genera il codice, non il codice a mano".** Modello utilizzato: una pre-release di **Claude Fable 5** (classe Mythos). Dopo il merge: **11 round di revisione di sicurezza Claude Code**, fuzzing guidato dalla copertura 24/7 (100 miliardi di esecuzioni → ~15 PR), **4% di codice `unsafe`** (78% su una singola riga), **19** regressioni note corrette. In produzione: Claude Code v2.1.181, la prima release su Bun-in-Rust, **+10% di avvio più veloce su Linux**. Dichiarato in apertura: **Bun è stato acquisito da Anthropic nel dicembre 2025**.
#Bun#Jarred Sumner#riscrittura da Zig a Rust
Jarred Sumner (créateur de Bun ; travaille chez Anthropic depuis le rachat de Bun en décembre 2025)
Un saggio di Jean-Paul Paoli (*The Intelligence Fabric*) che sposta la paura dell'IA sul lavoro: il vero pericolo non è la **sostituzione** (il posto che scompare) ma lo **sfilacciamento silenzioso** dei legami di squadra mentre *tutti restano occupati*. Tesi: quando ogni dipendente fa dell'IA il proprio **primo confidente e collaboratore**, tre "fili" del tessuto organizzativo si disfano senza licenziamenti — i **legami tra pari** (il trasferimento di conoscenza tacita da junior a senior cortocircuitato), il **legame manager-dipendente** (i segnali di allarme precoce scompaiono, il manager diventa "l'ultimo a sapere invece del primo") e il **giudizio professionale** (le persone smettono di formare chi sa *fare* il lavoro e valutare se la macchina sbaglia). Paoli chiama il fenomeno **shadow intimacy** (per analogia con lo *Shadow IT*) e prescrive non un divieto ma una "ritessitura" deliberata, filo per filo. Ambito: management, trasformazione organizzativa, IA sul lavoro, dipendenza emotiva dai modelli.
#Shadow intimacy#sostituzione IA#legami di squadra
Thread X (thread illustrato) di **Thariq Shihipar** (team Claude Code / Anthropic): una *field guide* per trarre il massimo da **Claude Fable 5**. Tesi centrale mutuata da Korzybski — *"la mappa non è il territorio"*: la **mappa** = ciò che si fornisce a Claude (prompt, skill, contesto); il **territorio** = dove il lavoro avviene realmente (codebase, vincoli del mondo reale); lo scarto tra i due = gli **unknowns**. Fable è *"il primo modello in cui la qualità del lavoro è limitata dalla mia capacità di chiarire i suoi unknowns"*. L'articolo propone un **framework a 4 quadranti** (known knowns / known unknowns / unknown knowns / unknown unknowns) e un **toolkit di tecniche** ordinate nel tempo (prima / durante / dopo l'implementazione) — blindspot pass, brainstorm & prototipi, interviste, riferimenti, implementation plan, implementation-notes, pitch & explainer, quiz — ciascuna con prompt d'esempio. Ambito: prompt engineering, agenti di codifica, metodologia di lavoro con l'IA, artefatti HTML.
Breve nota di Simon Willison (weblog) che riporta due consigli ascoltati durante una *Fireside Chat* all'AIE con Cat Wu e Thariq Shihipar (team Claude Code): **lasciare che il modello (Fable, e in parte Opus) eserciti il proprio giudizio invece di dettargli delle regole** — illustrato con la decisione se scrivere o meno i test. Secondo consiglio, di Jesse Vincent: per **risparmiare i preziosi token di Fable** (in vista di un imminente aumento dei prezzi), chiedere a Fable di **delegare piccoli compiti a modelli meno potenti**, lasciandogli giudicare quale scegliere. Willison mostra il prompt esatto utilizzato (« *use your judgement to decide an appropriate lower power model and run that in a subagent* ») e il **file di memoria** che Claude Code ha scritto in risposta. Dominio: prompt engineering, agenti di codifica, economia dei token, orchestrazione multi-modello.
#Giudizio del modello#delega ai subagenti#model override
Agent guide (Thinkroom, la piattaforma di Kieran Klaassen) che documenta il **Compounding Knowledge Lifecycle** del compound-engineering-plugin (Every): come una lezione appresa una volta "continua a ripagare" — catturata, archiviata, recuperata e mantenuta veritiera. Descrive l'anatomia di un *learning* (`docs/solutions/`), la sua cattura tramite `/ce-compound`, la mappa della memoria (durevole vs effimera), il recupero *grep-first* (learnings-researcher) collegato a 5 skill nei punti decisionali, e le tre controforze che impediscono alla memoria di mentire. Direttamente rilevante: è la dottrina dietro la convenzione `docs/solutions/` di questo repo. Dominio: compound engineering, gestione agentica della conoscenza, skill.
**Rapporto ricorrente di Mozilla**, *The state of open source AI*, **v1.0.1, luglio 2026**, introdotto da una lettera di **Raffi Krikorian** (CTO): sette sezioni, un sito interattivo e un rapporto scaricabile. Tesi enunciata nel titolo della Sezione 1: *« Il livello del modello si è commoditizzato. Il valore si sposta sull'harness sovrastante. »* **Stato delle capacità**: sull'*Artificial Analysis Intelligence Index v4.1*, il miglior modello chiuso ottiene **61** punti (Claude Opus 5) e il miglior modello open **57** (**Kimi K3**), quarto in classifica generale e davanti a tre dei più grandi laboratori chiusi; sull'*Epoch Capabilities Index*, lo scarto è di **6 punti** (K3 a 156 contro GPT-5.6 Sol a 162), descritto come *« all'incirca un ciclo di release »*, con intervalli di confidenza sovrapposti. **Frontiera a dente di sega**: l'open è in testa nel codice frontend (K3 a 1.679 Elo sulla LMArena Frontend Code Arena, sei domini su sette), contende il lavoro agentico da terminale (88,3 contro 88,8 su Terminal-Bench 2.1), e cede terreno sul lavoro professionale di conoscenza (Fable 5 supera K3 di 92 Elo su GDPval-AA v2). **Spostamento d'uso**: la quota di token OpenRouter instradati verso modelli open-weight è salita da un livello trascurabile a un terzo entro fine 2025, poi a una **maggioranza entro metà 2026**, con i sette modelli a maggior volume tutti open-weight — il rapporto stesso osserva che *« in numero di richieste, i fornitori chiusi statunitensi restano in testa »*, il vantaggio open essendo un vantaggio in volume di token concentrato nei carichi di lavoro di coding e agentici. **Il contrasto centrale**: *« L'open si spedisce facilmente. L'open si distribuisce con difficoltà. »* — il 79% degli sviluppatori che adottano l'IA usa modelli open contro il 71% per il chiuso, ma solo il **53%** dei team su modello open raggiunge la produzione **contro il 63%**, e lo scarto si allarga con la dimensione dell'organizzazione (chiuso 54% → 73%, open 53% → 57%), il che *« esclude una spiegazione basata sulle risorse »*. La mappa di maturità dello stack (48 componenti, 9 livelli) mostra due colonne costantemente fredde — la **standardizzazione** e la ***prontezza enterprise*** — identificate come il divario operativo. **Sezione 5**: *« L'harness agentico è un altro user agent »*, e *« Il modello sta divorando l'harness »* — su ogni modello in cui entrambi esistono, l'harness proprietario del laboratorio ora vince, con lo scarto di 21,8 punti compresso a circa 3. Da cui la formula: *« Un harness calibrato strettamente sui pesi di un laboratorio… degrada su qualsiasi altro modello, quindi più stretta è la calibrazione, meno intercambiabili sono i pesi sottostanti. Il lock-in arriva come effetto collaterale dell'ottimizzazione. »*
#Mozilla#state of open source AI#pesi open
**Mozilla** — éditeur du rapport · avec une introduction signée **Raffi Krikorian** · *Chief Technology Officer*. Publié en **juillet 2026** (v1.0.1). Données issues de sources tierces créditées (Artificial Analysis, Epoch AI, OpenRouter, LMArena) et d'une enquête propre menée avec **SlashData** (*Mozilla / SlashData 2026 developer survey*, n = 1 410 sur la question des freins).
Nota di analisi **Trésor-Éco n° 391** (giugno 2026) della **Direction générale du Trésor** (Ministero dell'Economia francese), a cura di **Martin Chopard, Elisa Cotet, Tristan Gantois ed Eloïse Villani**. Rassegna della letteratura economica istituzionale su **l'effetto dell'IA (principalmente generativa) sull'occupazione**. **Tesi in tre parti**: (1) l'IA incide sul volume dell'occupazione tramite **due canali contrapposti** — l'effetto di **spiazzamento** (sostituzione dei compiti automatizzabili) contro l'effetto di **produttività** (complementarità, riduzione dei costi, aumento della domanda) — ma **l'effetto aggregato resta, per il momento, debole/non misurabile**, per mancanza di prospettiva storica e di adozione (≈20% delle imprese UE nel 2025); (2) emergono **effetti eterogenei** a seconda delle **professioni** (esposizione ≠ effetto: tutto dipende dal grado di sostituibilità/complementarità e dall'**elasticità di prezzo** della domanda), dei **lavoratori** (progresso tecnico orientato, preoccupazioni per i **giovani**) e dei **settori** (finanza, IT, servizi alle imprese i più esposti); (3) nel **lungo periodo l'effetto netto resta incerto** — tra una sostituzione massiccia (se l'IA agentica/fisica si diffonderà) e la **distruzione creatrice** (lezione delle rivoluzioni passate: le innovazioni hanno creato più posti di lavoro di quanti ne abbiano distrutti). Conclusione di **politica pubblica**: sostenere la transizione (formazione, mobilità — il piano "Osez l'IA", France 2030) e **investire nell'IA per non restare indietro** nella competizione internazionale. Corpus ampiamente documentato (43 note a piè di pagina, pannelli di stime nelle Tabelle 1-3).
#IA e occupazione#intelligenza artificiale generativa#effetto di spiazzamento
**Martin Chopard · Elisa Cotet · Tristan Gantois · Eloïse Villani** — économistes de la **Direction générale du Trésor** (DG Trésor) · Ministère de l'Économie · des Finances et de la Souveraineté industrielle · énergétique et numérique. Directrice de la publication : Dorothée Rouzet. Le document engage la DG Trésor mais « ne reflète pas nécessairement la position du ministère ».
Terzo capitolo della serie di Ashish Singh « New Engineering Disciplines for the AI Era », dedicato al **KDLC — Knowledge Development Life Cycle**: un ciclo di vita in **8 fasi** per trasformare la conoscenza aziendale in un **asset ingegnerizzato**, al pari del codice o dei dati. Tesi: le iniziative di IA falliscono non per la scelta sbagliata dell'LLM o per un sistema RAG mal distribuito, ma perché **non affrontano la struttura sottostante della conoscenza** — « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust ». Il KDLC concatena Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Contrappone il **RAG tradizionale** (documenti isolati, parole chiave) all'**Enterprise Knowledge Fabric** (Knowledge Graph + Semantic Search + Vector DB + Hybrid Search), in cui gli agenti comprendono « relationships, context, and business meaning ». Frase distintiva: « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Tre esempi (finanza/compliance, ingegneria del software, sanità) illustrano l'impatto.
#KDLC#knowledge development life cycle#knowledge life cycle