OpenIDE añade ACP: cómo el protocolo de JetBrains y Zed cambia la forma en que trabajan los agentes de AI en IDEs

ACP se convierte en una nueva capa de compatibilidad entre IDE y agentes de IA: en lugar de una integración separada para cada herramienta, el editor y el agente acuerdan un protocolo común. OpenIDE ya ha implementado soporte básico para ACP y se está preparando para pruebas beta.

Qué es ACP

Durante el último año, el mercado de herramientas de IA para desarrollo se ha convertido en una mezcla de ecosistemas separados. Claude Code, Codex, Cursor, Windsurf, Kilo Code, Qwen Code y otros agentes pueden escribir, corregir y refactorizar código, pero casi cada uno viene con su propio esquema para conectarse al editor. Como resultado, el desarrollador elige no solo el agente más fuerte, sino también el editor donde ya se ha escrito una integración para él.

ACP intenta romper esta dependencia. En su concepto, ACP es muy similar a LSP, que una vez liberó a los editores de la necesidad de implementar por separado el soporte para cada idioma. Si en aquel entonces un protocolo unificado conectaba el editor con el servidor de lenguaje, ahora una capa de compatibilidad así está surgiendo entre el IDE y el agente de IA.

El protocolo describe cómo las partes intercambian mensajes, contexto, solicitudes de acción y estado de ejecución. En la práctica, esto significa que un agente puede conectarse completamente — junto con su lógica, herramientas y forma de funcionar, en lugar de simplemente enviar solicitudes al modelo seleccionado a través de API.

Por qué sin estándar es difícil

El problema principal del mercado actual es que muchas integraciones siguen siendo personalizadas. Un editor puede trabajar con un agente, otro con dos, un tercero requiere un plugin separado o un script semioficial. Aunque esto parece tolerable si usas una herramienta.

Pero tan pronto como quieras comparar varios agentes, rápidamente te encuentras con incompatibilidades, configuraciones adicionales y bloqueo del proveedor. Para los equipos, esto es aún más doloroso: cambiar un editor o un agente comienza a requerir migración de procesos adicionales. ACP es necesario precisamente para dividir los roles.

El IDE es responsable del entorno de desarrollo: navegación del código, resaltado, diffs, refactorización, trabajo con archivos y terminal. El agente es responsable de la lógica autónoma: cómo construir un plan, qué herramientas llamar, cómo realizar cambios y cuándo solicitar confirmación. En la descripción oficial del protocolo, se contemplan tanto fases básicas como inicialización y transmisión de indicaciones, como cosas más prácticas — lectura y escritura de archivos, creación de terminal, actualizaciones de tareas y solicitudes de permisos de acción.

Otro punto importante: conectar un modelo a través de API no es lo mismo que conectar un agente. Cuando simplemente proporcionas una clave a un LLM, el editor en sí sigue siendo el orquestrador y simplemente envía solicitudes al proveedor. ACP te permite integrar un agente listo en el IDE como una entidad separada.

Para el desarrollador, esto es más conveniente: puedes usar tu editor favorito sin perder las características de una herramienta de IA específica. En otras palabras, el estándar trae no solo un modelo al IDE, sino todo su bucle de trabajo.

Qué aparecerá en OpenIDE

Haulmont escribe que la implementación básica de ACP en OpenIDE ya está lista, y la siguiente etapa es la prueba beta. Para los usuarios, esto no es un abstracto "lo soportaremos en algún momento", sino un paso bastante práctico hacia un IDE donde un agente se conecta como un componente estándar. Si el soporte llega a una versión estable sin limitaciones graves, OpenIDE podrá adoptar nuevos agentes compatibles más rápidamente sin integraciones personalizadas separadas para cada uno.

• El soporte básico de ACP ya está implementado
• La función será parte de OpenIDE Pro
• Durante el período beta, se promete compatibilidad en la versión base de OpenIDE
• Los interesados pueden solicitar acceso anticipado y configuración por adelantado

La lógica es clara: en lugar de mantener manualmente un número cada vez mayor de plugins de IA separados, el IDE recibe una única interfaz para agentes externos. Al mismo tiempo, OpenIDE en sí sigue confiando en cosas familiares para los desarrolladores — el editor, navegación, refactorización, terminal y el ecosistema de plugins. El artículo enfatiza específicamente que el entorno actualmente está diseñado para Java, Spring, Python, Go, JavaScript y TypeScript, y también puede trabajar con Docker y extensiones de un marketplace compatible. ACP en este esquema no parece un complemento moderno, sino como la siguiente capa de infraestructura.

Qué significa esto

Si ACP se establece de la manera que lo hizo LSP, el mercado de codificación de IA se volverá notablemente más abierto. Los desarrolladores podrán elegir el mejor agente por separado de su IDE favorito, y los creadores de agentes gastarán menos esfuerzo en docenas de integraciones individuales. Para OpenIDE, esta es una oportunidad de conectar herramientas populares más rápidamente, y para todo el ecosistema, un paso de un zoo caótico de plugins de IA a un estándar más coherente. Por lo general, son estos protocolos los que determinan qué enfoques se vuelven mainstream y cuáles permanecen en nicho.