Landing page della **specifica ufficiale** dell'**Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultata il **2 agosto 2026**. Non si tratta di un articolo datato ma di un **artefatto vivo**: la scheda è datata in base alla sua osservazione, non a una data di pubblicazione. **Dichiarazione di missione in una frase**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **Il problema enunciato** sta in tre righe: gli agenti di codifica e gli editor sono **strettamente accoppiati** e *« interoperability isn't the default »* — ogni editor deve costruire un'integrazione personalizzata per ogni agente, ogni agente deve implementare API specifiche dell'editor. Tre conseguenze nominate: **onere di integrazione** (ogni coppia agente-editor richiede lavoro personalizzato), **compatibilità limitata** (un agente raggiunge solo un sottoinsieme di editor), **dipendenza dal fornitore per lo sviluppatore** (*« choosing an agent often means accepting their available interfaces »*). **La soluzione è esplicitamente modellata su LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — con un beneficio reciproco: un agente che parla ACP funziona con **qualsiasi** editor compatibile, un editor che supporta ACP accede all'**intero** ecosistema di agenti ACP. **Due modalità di distribuzione, ed è il punto più sottovalutato**: gli agenti **locali** girano come sottoprocesso dell'editor via **JSON-RPC su stdio**, ma gli agenti **remoti** sono previsti su **HTTP o WebSocket** — supporto dichiarato *« work in progress »*, con collaborazione in corso con piattaforme agentiche. **Filiazione tecnica con MCP, più forte di una semplice complementarità**: ACP *« re-uses the JSON representations used in MCP where possible »*, aggiungendo tipi specifici alle esigenze UX della codifica agentica (la visualizzazione dei **diff** è l'esempio riportato); il formato predefinito per il testo leggibile è **Markdown**, scelto affinché l'editor non sia tenuto a renderizzare HTML. **Due osservazioni su governance e versioning** tratte dalla pagina stessa, non dal discorso circostante: la navigazione espone **v1 (Latest)** e **v2 (Draft)** — e **non un "ACP 1.2"** —, e la barra di navigazione collega **Zed Industries *e* JetBrains** allo stesso livello, accanto a un **ACP Registry**, alle **RFD**, a una sezione **Community**, a **Publications**, **Updates** e una pagina **Brand**. Librerie ufficiali annunciate: **Kotlin, Java, Python, Rust, TypeScript**, più un percorso community.
#Agent Client Protocol#ACP#protocollo aperto
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
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.)
Articolo SFEIR (in francese) che formalizza uno **SDLC guidato dall'IA in 11 fasi (da 0 a 10)** e sostiene che il settore stia convergendo verso di esso. Osservazione di partenza: nel 2025 le organizzazioni hanno aggiunto strumenti di IA senza trasformare il proprio modello operativo — generando un paradosso in cui « tutto cambia… e nulla cambia » (la velocità di esecuzione si moltiplica senza un guadagno proporzionale). La vera risposta non è la scelta degli strumenti ma la **riprogettazione del ciclo** per l'esecuzione da parte della macchina. Il ciclo SFEIR poggia su **tre gate umani inamovibili** (Define, Plan, Ship), fasi automatiche tra di essi, e **due momenti di capitalizzazione** (Compound-1 pre-deployment, Compound-2 in produzione) che trasformano le lezioni apprese in regole riutilizzabili. Tre principi: **l'IA esegue** (artefatti completi + prova di esecuzione, senza mai fidarsi delle affermazioni dell'agente stesso), l'**essere umano mantiene il controllo dell'intento**, il **sistema apprende in modo cumulativo**. Risultati misurati (riprogettazione da 6 mesi a 1 giorno, **−30% delle iterazioni** dopo dieci cicli) e convergenza dichiarata con ADLC, Google e DORA 2025.
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
Guida di Augment Code (Paula Hingel) che descrive come gli agenti IA stiano ristrutturando il ciclo di vita dello sviluppo software (SDLC), fase per fase. Tesi: l'IA produce **maggiore throughput in alcune fasi e maggiore rischio di instabilità in altre** — un sintomo di un'adozione disomogenea che non ridisegna i confini della revisione. Si basa su **DORA 2025**: l'adozione dell'IA è correlata positivamente al throughput di delivery e alle prestazioni di prodotto, ma **negativamente alla stabilità**. Sei fasi rilette (Requisiti, Design/Architettura, Implementazione, Testing/QA, Deployment, Manutenzione), tre rischi principali (erosione della pipeline junior, **validazione circolare** dei test generati dall'IA, lacune di governance su larga scala) e tre ruoli emergenti (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Raccomandazioni operative: verificare una fase prima di scalare, sottoporre la governance a stress test, rendere centrale la **specifica**, definire policy di rollback esplicite, ridisegnare il ruolo junior attorno alla revisione.
#SDLC#software development lifecycle#agenti di coding