Página de aterrizaje de la **especificación oficial** del **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultada el **2 de agosto de 2026**. No se trata de un artículo fechado sino de un **artefacto vivo**: la ficha se fecha por su observación, no por una fecha de publicación. **Declaración de misión en 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. »* **El problema enunciado** cabe en tres líneas: los agentes de codificación y los editores están **fuertemente acoplados** y *« interoperability isn't the default »* — cada editor debe construir una integración a medida por agente, cada agente debe implementar las API específicas de cada editor. Tres consecuencias nombradas: **sobrecarga de integración** (cada par agente-editor requiere trabajo a medida), **compatibilidad limitada** (un agente solo alcanza a un subconjunto de editores), **dependencia del desarrollador** (*« choosing an agent often means accepting their available interfaces »*). **La solución está explícitamente modelada sobre LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — con el beneficio mutuo: un agente que habla ACP funciona con **cualquier** editor compatible, un editor que soporta ACP gana acceso al **conjunto** del ecosistema de agentes ACP. **Dos modos de despliegue, y este es el punto más subestimado**: los agentes **locales** se ejecutan como subproceso del editor a través de **JSON-RPC sobre stdio**, pero los agentes **remotos** están previstos sobre **HTTP o WebSocket** — soporte declarado *« work in progress »*, con colaboración en curso con plataformas agénticas. **Linaje técnico con MCP, más fuerte que una simple complementariedad**: ACP *« re-uses the JSON representations used in MCP where possible »*, añadiendo tipos específicos a las necesidades de UX de codificación agéntica (la visualización de **diff** es el ejemplo dado); el formato por defecto para texto legible es **Markdown**, elegido para que el editor no esté obligado a renderizar HTML. **Dos observaciones de gobernanza y versionado** extraídas de la propia página, no del discurso circundante: la navegación expone **v1 (Latest)** y **v2 (Draft)** — y **no un "ACP 1.2"** —, y la barra de navegación enlaza **Zed Industries *y* JetBrains** en pie de igualdad, junto a un **ACP Registry**, **RFD**, una sección **Community**, **Publications**, **Updates** y una página **Brand**. Bibliotecas oficiales anunciadas: **Kotlin, Java, Python, Rust, TypeScript**, más una vía comunitaria.
#Agent Client Protocol#ACP#protocolo abierto
**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 en X de **Eric S. Raymond** (ESR, autor de *The Cathedral and the Bazaar*, cofundador de la Open Source Initiative, ~50 años de programación) — **un contratestimonio frontal a la narrativa de que "los LLM producen código basura y alucinan, inútiles para programar".** Su tesis: esto **casi nunca le ocurre**, y **ya no en absoluto en las últimas dos generaciones** de modelos que usa ("chat GPT 5.4 y 5.5" bajo **codex**). El antiguo síntoma —un modelo "descarrilando" al acercarse a su límite de contexto— ha desaparecido: codex ahora muestra una **advertencia roja** que invita al usuario a **limpiar la sesión** en lugar de descontrolarse. **Alcance de uso**: IA aplicada a **cambios de funcionalidades, refactorización y depuración en 63 proyectos** en **C, Go, Rust, Python y shell**; redacción de documentación; **descompilación de un binario DOS en código fuente legible**. Una **rutina de trabajo** establecida: al reabrir un proyecto, primero ejecuta las **pruebas de regresión**, luego inicia codex y le pide que **audite el código** (errores + sugerencias de mejora). Veredicto: los LLM son **"excelentes y tremendamente empoderadores"**; su **peor limitación** es la **"visión de túnel arquitectónica"** —excelentes generando código según especificación, pero a veces **ciegos a los patrones de más alto nivel**— algo que considera **tarea de su "cerebro de carne".** El punto más fuerte y contraintuitivo: los LLM **NO se equivocan en los detalles y casos límite**; afirma ser **peor que ellos** en este aspecto (pese a 50 años de experiencia), porque si un cambio debe **tocar cinco lugares**, el modelo **los encuentra los cinco de forma fiable**, mientras que el humano corrige cuatro y **pasa horas depurando** antes de encontrar el quinto olvidado. Después cuestiona a los **"downshouters"**: ¿viven en un **universo diferente**? ¿Usan **modelos antiguos y débiles**? ¿Hay un **skill issue** que él no percibe porque sus **hábitos mentales y su comunicación** encajan bien con los "handles" de estas herramientas? Una cuestión que considera importante resolver, ya que "se **malgastarían miles de millones de dólares en gasto de tokens mal dirigido**". Su receta, "muy simple": **"Piensa con claridad, dile al modelo lo que quieres con precisión, y ocurren cosas buenas"** —cerrando con: "¿qué me estoy perdiendo aquí?". Debe leerse como un **contrapunto pro-LLM de una figura histórica del open source** al debate recurrente sobre la (des)valorización de los agentes de codificación —haciendo eco del "skill issue" y de la disciplina de especificación (cf. [[martignole-token-manifesto-2026-07-17]])— y formando un díptico con la postura doctrinal pro-herramientas-IA de **Linus Torvalds** en nombre 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.)
Artículo de SFEIR (en francés) que formaliza un SDLC impulsado por IA en 11 fases (0 a 10) y sostiene que el sector converge hacia él. Observación de partida: en 2025, las organizaciones añadieron herramientas de IA sin transformar su modelo operativo, produciendo una paradoja de «todo cambia… y nada cambia» (la velocidad de ejecución se multiplica sin una ganancia proporcional). La verdadera respuesta no es la elección de herramientas, sino el rediseño del ciclo para la ejecución por máquinas. El ciclo de SFEIR se apoya en tres puertas humanas inamovibles (Define, Plan, Ship), fases automáticas entre ellas, y dos momentos de capitalización (Compound-1 antes del despliegue, Compound-2 en producción) que convierten las lecciones en reglas reutilizables. Tres principios: la IA ejecuta (artefactos completos + prueba de ejecución, sin confiar nunca en las afirmaciones del propio agente), el humano conserva el control de la intención, el sistema aprende de forma acumulativa. Resultados medidos (rediseño de 6 meses a 1 día, −30 % de iteraciones tras diez ciclos) y convergencia declarada con ADLC, Google y DORA 2025.
Un artículo de arXiv (cs.SE) de Martin Monperrus que defiende una tesis radical para el SDLC: los agentes de codificación han superado un umbral de capacidad tal que **la revisión de código humana ya no es un componente necesario** de un pipeline de calidad. Dos afirmaciones: (1) los sistemas autónomos basados en LLM alcanzan todos los objetivos de la revisión (detección de defectos, calidad, cumplimiento) con menor coste y mayor rendimiento; (2) el modelo híbrido "el agente escribe, el humano revisa" es insostenible — no garantiza una calidad real y no escala al ritmo de la velocidad de la IA, generando una "falsa sensación de seguridad". Monperrus contrasta la inspection de Fagan (1976) con un **pipeline de verificación adversarial multi-agente** (agente generador + agentes revisores independientes + tests/métodos formales + consenso basado en voto). El humano se reenfoca en la especificación, las decisiones arquitectónicas, la aprobación de dominios críticos y los casos límite. Recomendaciones: pilotar primero en componentes de bajo riesgo, medir agente frente a humano, hacer explícitas las decisiones de rechazo.
Guía de Augment Code (Paula Hingel) que describe cómo los agentes de IA están reestructurando el ciclo de vida del desarrollo de software (SDLC), etapa por etapa. Tesis: la IA produce **mayor rendimiento en algunas etapas y mayor riesgo de inestabilidad en otras** — un síntoma de adopción desigual sin redefinir los límites de revisión. Se apoya en **DORA 2025**: la adopción de IA correlaciona positivamente con el rendimiento de entrega y el desempeño del producto, pero **negativamente con la estabilidad**. Seis etapas revisadas (Requisitos, Diseño/Arquitectura, Implementación, Pruebas/QA, Despliegue, Mantenimiento), tres riesgos principales (erosión del pipeline junior, **validación circular** de pruebas generadas por IA, brechas de gobernanza a escala) y tres roles emergentes (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Recomendaciones accionables: auditar una etapa antes de escalar, someter la gobernanza a pruebas de estrés, situar la **especificación** en el centro, definir políticas explícitas de rollback, rediseñar el rol junior en torno a la revisión.
#SDLC#ciclo de vida del desarrollo de software#agentes de codificación