JetBrains pone un orquestador de agentes dentro de cada IDE que distribuye

JetBrains abrió el acceso anticipado a Air en sus IDE el 1 de octubre. Está disponible como plugin en JetBrains Marketplace o incluido en las compilaciones EAP 2026.3 de IntelliJ, PyCharm, WebStorm, Rider y el resto de la familia, y funciona desde la versión 2026.2 en adelante. El plugin es gratuito.

El enfoque es la parte interesante. Air no es un modelo ni un agente. Se distribuye sin agentes instalados. JetBrains lo describe como un conducto para agentes y suscripciones que un desarrollador ya paga, y detecta lo que ya está en la máquina tal como el IDE detecta terminales.

Sesiones en lugar de chat

JetBrains sostiene que orquestar varias tareas de forma concurrente es una actividad distinta de mantener una conversación con un modelo, y que usar una sola interfaz para ambas ha sido un error. La IA clásica de los IDE se centraba en el chat. Air se centra en las sesiones.

Cada sesión es un agente trabajando en una tarea, y la interfaz las sigue en conjunto: actividad, actualizaciones no leídas, archivos modificados, commits salientes y el coste de cada sesión en una sola vista. Las sesiones pueden ejecutarse entre proyectos, aparecer como pestañas del editor o permanecer en una terminal o en un chat gráfico según la tarea. Pulsar Ctrl dos veces en cualquier lugar del IDE abre una ventana de prompt con el contexto actual adjunto.

El aislamiento se gestiona con worktrees temporales de Git. Una sesión puede comenzar desde cualquier rama, en una rama nueva o en estado detached, y los resultados se aplican de vuelta al proyecto principal mediante cherry-pick. JetBrains dice que la salida del agente aparece como un diff revisable dentro del IDE, usando las mismas herramientas que un desarrollador usaría para revisar un pull request, y que los cambios no se aplican automáticamente.

La jugada del protocolo es la parte estratégica

Air conecta agentes que admiten el Agent Client Protocol, un estándar abierto que JetBrains codesarrolló con Zed y publicó bajo la licencia Apache. ACP usa JSON-RPC 2.0 sobre stdin y stdout, y JetBrains, Zed, Google, GitHub y más de 25 agentes lo han adoptado. Las dos empresas también lanzaron un ACP Registry, un directorio de agentes compatibles que se puede explorar, integrado en el IDE.

La comparación más fácil es con el Language Server Protocol. LSP permitió que cualquier editor admitiera cualquier lenguaje mediante un único estándar compartido en lugar de una integración a medida por cada combinación. ACP aspira a hacer lo mismo con los agentes.

JetBrains compite por la capa donde se lanzan, supervisan y revisan los agentes, en lugar de por la calidad del modelo, y coautorar el protocolo que rige cómo se comunican los agentes con los editores es una forma de ser infraestructura en vez de una función. La explicación de la propia empresa es más directa: un IDE que mantenga a los agentes a distancia lo tendrá difícil a medida que el desarrollo agéntico se normalice.

Los agentes admitidos incluyen Codex, Claude Agent, GitHub Copilot, Gemini, OpenCode y Junie, el propio de JetBrains, además de otras herramientas compatibles con ACP. Un usuario con una clave existente de Anthropic, OpenAI o Google no paga nada a JetBrains. Para quienes no tienen una suscripción de agente, JetBrains ofrece ejecuciones gratuitas de Junie Lite tras iniciar sesión con una cuenta de JetBrains. Los créditos de JetBrains AI comienzan en diez dólares al mes para el acceso a los modelos alojados de la propia empresa.

La función que Cursor no tiene

El diferenciador en el que JetBrains se apoya es que los agentes conectados a Air pueden invocar las herramientas del IDE como habilidades. Un agente puede desencadenar una ejecución de depuración para investigar una prueba fallida, ejecutar el generador de perfiles o usar el motor de refactorización con contexto completo de varios archivos. Los agentes también pueden acceder a las herramientas del IDE a través de MCP y trabajar con contexto estructurado en lugar de texto pegado.

JetBrains afirma que esto produce mejores resultados en algunas tareas y, en algunos casos, usa menos tokens. La afirmación sobre los tokens es de la empresa, y no se ha publicado ninguna prueba independiente.

El argumento de fondo trata sobre lo que un agente puede ver. Un agente que solo puede leer y escribir archivos trabaja a partir de texto. Un agente que puede perfilar una función lenta e inspeccionar la pila de llamadas tiene el contexto que tendría un desarrollador sénior al diagnosticar el mismo problema. JetBrains ha pasado 26 años creando esas herramientas, y Air es la primera vez que los agentes acceden a ellas.

Por qué el momento tiene sentido

JetBrains lanza esto en un momento en el que el paso de revisión se ha convertido en el cuello de botella reconocido. Escribir código ya no es la limitación para muchos equipos. Comprobar lo escrito sí lo es.

Ese juicio está apareciendo en todo el mercado de herramientas a la vez. Qodo lanzó la versión 3.0 esa misma semana con la revisión como pieza central, y Cursor añadió un bot de revisión a su flujo de trabajo de agentes. Que tres proveedores converjan en la misma conclusión sugiere que la limitación se ha desplazado para quedarse: cuando los agentes pueden producir código más rápido de lo que los humanos pueden leerlo, el valor se traslada a cualquier cosa que reduzca el coste de lectura.

El diseño de Air refleja eso. El producto trata las sesiones de agentes paralelas como una cola de trabajo por revisar en lugar de como una conversación que dirigir, y coloca el coste por sesión en la misma vista que los archivos modificados. Para un responsable de ingeniería que decide cuántos agentes ejecutar, esa línea de coste es el límite práctico.

La visualización del coste por sesión es una función pequeña con un efecto descomunal en el comportamiento. Un equipo que no puede ver lo que gasta un agente de larga duración tiende a ejecutar un solo agente con cautela. Un equipo que puede ver el número por sesión está más dispuesto a ejecutar varios, porque la decisión se convierte en una asignación en lugar de una apuesta. Es el mismo cambio que ocurrió con los paneles de gasto en la nube, y altera cómo organizan el trabajo las personas.

También hay un problema de coordinación que Air intenta resolver. Un equipo que ejecuta Claude en una tarea, Codex en otra y Copilot en una tercera termina con tres interfaces separadas y ningún registro compartido de lo que tocó cada una. Consolidarlas en un IDE que ya controla diffs, inspecciones y control de versiones es un cambio menor que adoptar una herramienta nueva, y para los equipos estandarizados en JetBrains para Java, Kotlin o Python, evita empujar a todos a un editor diferente solo para obtener agentes.

Lo que no está resuelto

Air es una versión de acceso anticipado. JetBrains dice que hay que esperar detalles sin pulir, cambios en la interfaz y el comportamiento, y actualizaciones aproximadamente cada semana. No ha dado una fecha de disponibilidad general. La ejecución en la nube para tareas de larga duración está limitada a organizaciones con licencias de AI, y JetBrains no ha indicado precios para ello.

En cuanto a la privacidad, la empresa dice que, si no hay ningún agente con sesión iniciada, nada sale de la máquina, y que, con una suscripción de terceros, los datos van a ese proveedor bajo el acuerdo existente en lugar de pasar por JetBrains. Desactivar el plugin no cambia nada más, y el AI Assistant independiente sigue teniendo soporte.

La afirmación que vale la pena probar en el propio repositorio de un equipo es la relativa a la revisión. Air facilita ejecutar varios agentes a la vez. Si eso produce más trabajo fusionado o más diffs que nadie lee es una cuestión empírica, y se responderá en el primer mes de uso, no en una publicación de lanzamiento.