JetBrains Air en IDEs abre EAP, pero la orquestación es la verdadera apuesta

JetBrains ha abierto JetBrains Air en IDEs al acceso anticipado, incorporando cinco agentes de programación compatibles a un espacio de trabajo diseñado para tareas paralelas. El movimiento tiene menos que ver con añadir otro chatbot y más con decidir dónde supervisarán los desarrolladores el código generado por IA.

Air admite Codex, Gemini, GitHub Copilot, Claude Agent y Junie, de JetBrains, de forma nativa. También puede conectar otras herramientas compatibles mediante el Agent Client Protocol, o ACP, una interfaz común entre los agentes de programación y los entornos de desarrollo.

Esto sitúa a JetBrains frente a una visión del desarrollo de software centrada en los modelos. En ese enfoque, los desarrolladores siguen al agente que obtiene los mejores resultados en cada momento. JetBrains apuesta por que el producto duradero será el entorno que aporta contexto, realiza el seguimiento del trabajo simultáneo y ayuda a las personas a revisar cada cambio.

El primer titular hablaba de un EAP que llegaba a cinco IDEs. La documentación actual de JetBrains afirma ahora que el plugin es compatible con toda su gama de IDEs excepto Android Studio, lo que amplía el alcance final respecto a ese planteamiento inicial. La cifra más importante sigue siendo la de cinco agentes, porque Air los trata como trabajadores intercambiables dentro de una misma superficie de control.

JetBrains no pide a los desarrolladores que abandonen Codex, Claude, Gemini, Copilot o Cursor. Quiere que esos sistemas funcionen dentro de los productos de JetBrains. Esa distinción convierte el EAP de JetBrains Air en una prueba de si el IDE puede seguir siendo el centro del desarrollo de software cuando los agentes realizan una mayor parte de la implementación.

JetBrains Air en IDEs separa el espacio de trabajo del modelo

JetBrains Air en IDEs es una capa de orquestación, no un modelo nuevo ni un nombre sustituto de AI Assistant.

JetBrains lanzó el EAP a principios de octubre a través del Marketplace y las compilaciones EAP 2026.3 de sus IDEs. El anuncio de Air EAP de la empresa indica que el plugin llega sin ningún agente instalado y no actúa como proveedor de IA.

Este diseño importa porque separa tres productos que los usuarios suelen encontrar como una experiencia agrupada. El modelo genera o interpreta texto. El agente de programación planifica tareas, opera herramientas, edita archivos y ejecuta comandos. Air organiza esos agentes y su trabajo dentro del IDE.

Los desarrolladores pueden conectar los agentes que ya utilizan, sujetos a las reglas de autenticación de cada proveedor. No necesitan una suscripción a JetBrains AI simplemente para ejecutar un agente externo compatible. Air puede detectar instalaciones locales de agentes, ofrecer agentes mediante un registro y reutilizar métodos de autorización compatibles.

Cinco agentes reciben soporte explícito de primer nivel: Codex, Gemini, GitHub Copilot, Claude Agent y Junie. Cursor y otras herramientas pueden acceder mediante compatibilidad con ACP, aunque la interfaz exacta y el proceso de autorización pueden variar según el agente.

El producto organiza el trabajo en torno a sesiones, en lugar de un único chat continuo. Cada sesión representa una tarea, su agente, su contexto, su progreso y los cambios que produce. Los desarrolladores pueden ver el trabajo activo entre proyectos, identificar las sesiones que esperan intervención y abrir los cambios completados para revisarlos.

Air también admite presets. Un preset almacena un agente, la selección de modelo, el esfuerzo de razonamiento, el nivel de acceso y otros ajustes de lanzamiento. Esto permite a un equipo crear configuraciones distintas para correcciones rutinarias, refactorizaciones mayores, revisiones o experimentos.

Esta estructura convierte el IDE en un despachador. Un desarrollador podría enviar una prueba fallida a Codex, asignar cambios de documentación a Gemini y pedir a Junie que inspeccione un problema de rendimiento. Air no afirma que esos agentes cooperen como una inteligencia colectiva. Da a cada tarea un lugar visible y mantiene sus resultados dentro de un flujo de revisión.

La distinción evita un malentendido importante sobre la expresión “ejecuta cinco agentes de IA”. Air admite de forma nativa cinco agentes nombrados, pero no exige que los cinco se ejecuten juntos. Tampoco garantiza que los agentes simultáneos produzcan código compatible.

La documentación actual de Air de JetBrains afirma que los agentes locales se ejecutan en la máquina del desarrollador. Air se comunica con agentes compatibles con ACP mediante el protocolo, mientras que los agentes de línea de comandos pueden conservar sus interfaces de terminal dentro del IDE.

El plugin se puede instalar en las versiones 2026.2 y viene incluido con las compilaciones EAP 2026.3. JetBrains documenta ahora la compatibilidad con todos sus IDEs excepto Android Studio. La disponibilidad, la autorización de agentes y la ejecución en la nube todavía pueden depender de la versión del producto del usuario y de la configuración de la organización.

Estos detalles hacen que esto sea más que una actualización de distribución. JetBrains está reorganizando su interfaz de IA en torno al trabajo delegado, al tiempo que mantiene cerca del resultado su editor, depurador, inspecciones, navegación y herramientas de control de versiones.

Por qué JetBrains está yendo más allá del panel de chat de IA

La presión sobre JetBrains proviene de un cambio en el comportamiento de los desarrolladores, no simplemente de modelos de lenguaje más potentes.

La primera generación de funciones de IA basadas en IDE se centró en el autocompletado y el chat. Un desarrollador seleccionaba código, hacía una pregunta, recibía una respuesta y decidía qué pegar o aplicar. Esa interacción encajaba cómodamente en un panel lateral.

Los agentes de programación crean un problema de gestión diferente. Pueden leer varios archivos, elaborar un plan, ejecutar comandos, modificar un repositorio y ejecutar pruebas antes de devolver el control. Un desarrollador también puede iniciar otra tarea mientras el primer agente sigue activo.

JetBrains afirma que intentó incorporar más agentes en su chat existente de AI Assistant. La empresa concluyó que supervisar tareas simultáneas requería un producto organizado en torno al estado del trabajo, en vez del historial de conversación.

Esa conclusión explica por qué Air y AI Assistant siguen separados durante el EAP. AI Assistant continúa ofreciendo chat, completado, información sobre código, sugerencias para la siguiente edición y acceso a agentes dentro de la experiencia de IDE ya establecida. Air trata a los agentes y las sesiones como las unidades principales de trabajo.

JetBrains espera que Air se convierta con el tiempo en su interfaz agentiva principal, pero no ha anunciado la eliminación de AI Assistant. Los usuarios pueden mantener AI Assistant instalado, aunque instalar Air mediante una notificación de AI Assistant desactiva el plugin anterior para impedir que ambas interfaces se ejecuten simultáneamente. Se puede volver a activar desde la configuración de plugins.

La cuestión competitiva más profunda es quién posee la atención del desarrollador. Los editores centrados en agentes y las herramientas de línea de comandos pueden alejar el trabajo del IDE tradicional. Si los desarrolladores pasan la mayor parte de su tiempo enviando prompts y revisando parches en otro lugar, el IDE corre el riesgo de convertirse en un espacio secundario utilizado solo para depuraciones difíciles.

Air intenta invertir ese flujo. En lugar de obligar a los desarrolladores a elegir entre JetBrains y un agente externo, invita al agente externo al entorno de JetBrains. El agente aporta planificación y generación, mientras el IDE aporta contexto del repositorio y herramientas de verificación.

Este enfoque también aborda la rotación de modelos. El principal modelo de programación puede cambiar más rápido de lo que una organización modifica su entorno de desarrollo. Una empresa puede preferir un agente para migraciones de Java, otro para trabajo de interfaces y un agente interno para repositorios con código restringido.

JetBrains no necesita que Junie gane todas las comparativas si Air sigue siendo el lugar donde se gestionan estos sistemas. La empresa puede beneficiarse de agentes externos más potentes porque esos agentes hacen que el espacio de trabajo compartido sea más útil.

Por eso ACP desempeña un papel central. El contrato ACP define una conexión común entre un cliente, como un IDE, y un agente. El agente conserva su propia selección de modelo, herramientas, autenticación y comportamiento de planificación.

JetBrains compara ese límite con el papel del Language Server Protocol. Un editor no necesita una integración privada independiente para cada servidor de lenguaje compatible. ACP pretende reducir la necesidad de un plugin a medida entre cada agente y cada entorno de desarrollo.

La analogía tiene límites. Los agentes de programación pueden ejecutar comandos y modificar grandes partes de un repositorio, por lo que sus permisos y efectos secundarios conllevan un mayor riesgo. Aun así, una capa de conexión común reduce el trabajo de integración y hace que cambiar de agente resulte menos disruptivo.

Para JetBrains, esto crea una apertura estratégica. Cursor, Codex, Claude, Copilot y Gemini no tienen que ser derrotados en la capa del modelo. Pueden convertirse en opciones dentro de un IDE multiagente de JetBrains.

El IDE se convierte en el plano de control del trabajo de los agentes

La apuesta central de Air es que la verificación adquiere más valor a medida que generar código se vuelve más fácil.

Generar un parche es solo una parte del desarrollo de software. Alguien debe determinar si el parche cumple el requisito, preserva la arquitectura, supera las pruebas, respeta los límites de seguridad y se comporta correctamente en condiciones reales.

JetBrains ya posee muchas de las herramientas utilizadas para ese trabajo. Sus IDEs comprenden símbolos, tipos, referencias, estructura del proyecto, ejecutores de pruebas, control de versiones, bases de datos, depuradores y perfiles de rendimiento. Air conecta la actividad de los agentes con esas superficies existentes.

Un agente puede recibir archivos, commits, capturas de pantalla e instrucciones reutilizables como contexto. El desarrollador puede inspeccionar los archivos modificados, comparar diffs, navegar por código relacionado y ejecutar el proyecto sin transferir el resultado a otra aplicación.

Esta conexión puede reducir la exploración duplicada. Un agente de programación suele gastar tokens listando directorios, abriendo archivos de configuración y localizando símbolos relevantes. El contexto proporcionado por el IDE puede dirigirlo antes hacia el código correcto, aunque el ahorro variará según el agente y la tarea.

Air también da a los agentes compatibles acceso a habilidades del IDE para actividades como depuración, perfilado, exploración de bases de datos y búsqueda semántica de código. JetBrains afirma que esas herramientas pueden mejorar los resultados en algunas tareas, pero la afirmación todavía necesita pruebas amplias en repositorios y lenguajes distintos.

La sesión del agente se convierte en el contenedor de este flujo de trabajo. Registra el agente seleccionado, la conversación, la actividad, los archivos modificados, los commits y el coste informado. Las sesiones pueden permanecer visibles entre varios proyectos, lo que ayuda a un desarrollador a detectar trabajo que ha terminado o requiere intervención.

Este modelo es diferente de abrir cinco pestañas de chat. Una pestaña de chat conserva principalmente una conversación. Una sesión de Air vincula la conversación con el estado del repositorio y las acciones de revisión.

Pensemos en un desarrollador responsable de un servicio con una prueba de integración fallida. Una sesión puede investigar el fallo. Una segunda puede actualizar una dependencia relacionada en una rama aislada. Una tercera puede inspeccionar la documentación afectada por el cambio.

El desarrollador puede seguir trabajando en el checkout principal mientras avanzan estas sesiones. Cuando una termina, el IDE se convierte en el lugar para revisar el diff, ejecutar inspecciones, comprobar pruebas y decidir si el resultado debe integrarse en la rama objetivo.

Ese proceso encaja con un cambio más amplio en el trabajo de ingeniería. Los desarrolladores coordinan cada vez más cambios generados en lugar de escribir directamente cada implementación. Su responsabilidad no desaparece. Se desplaza hacia la definición de tareas, la aportación de contexto, el examen de evidencias y la resolución de conflictos.

JetBrains está posicionando el IDE como el plano de control para esas responsabilidades. El término se refiere a una superficie que coordina trabajadores y estado sin ser el trabajador en sí. Air no necesita generar el mejor parche para ser valioso si facilita supervisar a varios agentes.

El modelo también preserva la capacidad de elección del usuario. Un desarrollador puede conectar una suscripción existente cuando el proveedor lo permita, seleccionar JetBrains AI o usar un agente ACP configurado localmente. Air no proporciona un modelo propietario.

Esa flexibilidad es estratégicamente importante. Un espacio de trabajo cerrado vinculado a un único modelo hereda las debilidades y los cambios comerciales de ese modelo. Un espacio de trabajo multiagente puede permitir a los desarrolladores reemplazar el agente mientras conservan los hábitos del proyecto y las herramientas de revisión.

Los equipos que ya están creando contexto de ingeniería consultable pueden reconocer el mismo patrón. El activo duradero no es una única respuesta, sino la estructura que conecta código, decisiones, documentos y revisión. Una base de conocimiento técnica puede complementar las sesiones de agentes al preservar información que debería sobrevivir más allá de una tarea de programación.

Air no resuelve por sí solo ese problema más amplio de conocimiento. Una sesión contiene contexto de trabajo útil, pero los equipos siguen necesitando registros duraderos para decisiones de arquitectura, incidentes y requisitos. El IDE puede coordinar la implementación, mientras que los sistemas de conocimiento compartido preservan por qué existe esa implementación.

Los agentes paralelos crean un problema de integración y atención

Ejecutar más agentes aumenta el rendimiento solo cuando los desarrolladores pueden revisar, conciliar y confiar en sus resultados.

Air permite a los desarrolladores iniciar sesiones desde una rama y colocar el trabajo en un worktree temporal de Git. Un worktree es una copia de trabajo independiente vinculada al mismo historial del repositorio. Mantiene las ediciones de un agente separadas del checkout actual del desarrollador.

Este aislamiento es esencial para el trabajo paralelo. Dos agentes que editan los mismos archivos en un espacio de trabajo pueden sobrescribir supuestos o crear cambios que funcionan de forma independiente pero fallan juntos. Los worktrees separados reducen la interferencia directa.

Air puede mostrar el resultado y permitir al desarrollador transferir commits seleccionados de vuelta al proyecto activo. Su flujo de trabajo de sesiones documentado admite revisar los cambios antes de aplicarlos mediante cherry-pick en la rama de destino.

El aislamiento no elimina el trabajo de integración. Si cinco agentes modifican áreas conectadas, el desarrollador puede enfrentarse a cinco ramas, ediciones duplicadas, abstracciones incoherentes y conflictos de fusión. Cada agente puede producir un resultado local plausible mientras el sistema combinado se vuelve menos coherente.

El cuello de botella pasa entonces de la producción de código a la atención humana. Un desarrollador debe entender qué cambió cada agente y por qué. También debe decidir qué pruebas aportan evidencia significativa, en lugar de aceptar un resumen en verde generado por el mismo sistema que escribió el código.

La lista de sesiones de Air ayuda a mostrar esa carga de trabajo. Puede mostrar sesiones activas, actualizaciones no leídas, archivos modificados, commits salientes y tareas que esperan intervención. Esa visibilidad es útil, pero no puede determinar si las decisiones subyacentes son correctas.

Esta es la principal contraprestación detrás del EAP de JetBrains Air. El paralelismo puede acortar el tiempo de espera, pero también puede multiplicar las obligaciones de revisión. Un equipo que inicia agentes más rápido de lo que puede verificar su trabajo simplemente crea una cola más grande de parches inciertos.

Los presets introducen otra preocupación de gobernanza. Hacen que la configuración sea repetible, pero los equipos deben decidir qué modelos, permisos y niveles de esfuerzo corresponden a cada clase de tarea. Un agente con acceso elevado adecuado para un repositorio de pruebas desechable puede ser inaceptable para infraestructura de producción.

La autenticación también sigue siendo desigual. JetBrains admite varias rutas, incluidos inicios de sesión gestionados por proveedores, credenciales de terceros y JetBrains AI. Sin embargo, una suscripción utilizable en una interfaz puede no autorizar al mismo agente en otra superficie.

Claude ilustra esa complejidad. JetBrains afirma que una suscripción de Claude puede utilizarse mediante la interfaz de terminal, mientras que Claude Agent en el chat estructurado requiere JetBrains AI o una clave API de Anthropic con facturación de API. Los desarrolladores deberían comprobar las reglas de autorización vigentes antes de considerar Air como un centro universal de suscripciones.

La ejecución en la nube añade más límites. Las sesiones locales se ejecutan en la máquina del desarrollador, pero las organizaciones elegibles pueden enviar determinadas tareas a la infraestructura de JetBrains. Las ejecuciones en la nube pueden continuar después de cerrar el IDE, aunque la disponibilidad depende de la configuración de la organización, el alojamiento del repositorio y una suscripción a JetBrains AI.

Por tanto, el tratamiento de datos depende de la ruta seleccionada. JetBrains afirma que los datos de agentes de terceros van directamente a ese proveedor bajo el acuerdo existente del usuario cuando se utiliza una suscripción de terceros. JetBrains AI y las funciones en la nube operan bajo sus términos aplicables.

El acuerdo del EAP también deja explícito el nivel de madurez. El software de acceso anticipado puede contener errores, comportarse de forma inesperada y cambiar durante el desarrollo. Los equipos no deberían tratar la etiqueta EAP como una insignia rutinaria cuando los agentes pueden editar archivos y ejecutar comandos.

Un despliegue cauteloso comenzaría con repositorios no críticos y permisos restringidos. Los equipos deberían exigir revisión humana, preservar ramas recuperables y ejecutar pruebas independientes antes de fusionar. El código sensible necesita una decisión clara sobre proveedor y enrutamiento de datos antes de que cualquier agente reciba contexto.

Estos controles no son argumentos contra JetBrains Air en los IDE. Son las condiciones bajo las cuales su modelo paralelo se vuelve útil. La orquestación crea ventaja solo cuando hace más visible la responsabilidad en lugar de ocultarla detrás de paneles de actividad.

JetBrains convierte a los rivales en componentes reemplazables

Air desafía a los editores centrados en agentes al incorporar sus agentes mientras preserva el entorno de desarrollo de JetBrains.

El rival más importante no es una sola empresa. Es la idea de que el agente de programación debería poseer todo el espacio de trabajo del desarrollador.

Un editor centrado en agentes puede optimizar cada interacción alrededor de un sistema integrado. Eso crea una experiencia enfocada, pero también puede hacer que el flujo de trabajo del desarrollador dependa del enrutamiento de modelos, las decisiones de interfaz y el calendario de lanzamientos de ese producto.

JetBrains adopta la posición opuesta. El IDE permanece estable mientras los agentes compiten por tareas dentro de él. Los desarrolladores pueden conservar herramientas conocidas de navegación, refactorización, depuración e inspección mientras cambian el sistema que genera código.

ACP hace creíble esa propuesta. Sin un protocolo compartido, admitir muchos agentes requeriría una colección creciente de integraciones privadas. Cada actualización de proveedor podría romper un conector o dejar funciones incoherentes entre productos.

Con ACP, la unidad reemplazable incluye más que un modelo. Un agente incorpora su lógica de planificación, herramientas, permisos, enrutamiento de modelos y comportamiento de interfaz. Air se conecta a ese paquete completo mediante un límite común de cliente.

Esto ofrece a JetBrains una forma de beneficiarse de la innovación externa. Si Codex mejora en cambios a escala de repositorio, los usuarios de Air pueden elegirlo. Si Gemini se vuelve mejor para otra carga de trabajo, el espacio de trabajo no necesita cambiar. Un agente ACP interno puede atender tareas restringidas.

Por tanto, los cinco agentes nombrados son una alineación inicial, no un límite fijo. Codex, Gemini, GitHub Copilot, Claude Agent y Junie ofrecen al EAP opciones reconocibles. El registro y la configuración personalizada amplían el conjunto posible.

Cursor es un ejemplo revelador. Compite por la atención de los desarrolladores como un entorno de programación orientado a IA, pero su agente también puede conectarse a productos de JetBrains mediante ACP. JetBrains puede convertir un producto asociado con cambiar de editor en un trabajador disponible dentro de su propio IDE.

Eso no garantiza que los usuarios se queden. Un producto nativo centrado en agentes aún puede ofrecer una interfaz más coherente, entrega de funciones más rápida o una integración más estrecha con su modelo preferido. La compatibilidad de protocolos rara vez hace idéntica cada experiencia de cliente.

Air también debe justificar la complejidad de elegir. Cinco agentes con distintos permisos, suscripciones, modos y fortalezas pueden resultar más difíciles de gestionar que una herramienta conocida. El espacio de trabajo necesita estados claros, configuración predecible e información de revisión confiable.

La propia línea de productos de JetBrains añade otro riesgo. Los usuarios ya se encuentran con AI Assistant, Junie, Air, agentes ACP, cuentas de proveedores y JetBrains AI. Air crea una división conceptual más clara, pero el período de transición aún puede sentirse fragmentado.

La empresa intenta resolver ese problema al convertir Air en el entorno dedicado para flujos de trabajo agénticos, mientras conserva AI Assistant para chat y asistencia en línea. Que los usuarios entiendan y prefieran esa división será un resultado clave del EAP.

JetBrains presentó por primera vez el entorno independiente Air como un espacio construido alrededor de agentes, en lugar de un editor con IA añadida. Su vista previa pública de marzo estableció la delegación concurrente como la idea central del producto.

Incorporar esa experiencia a los IDE establecidos cambia la propuesta. Los desarrolladores ya no necesitan adoptar una aplicación independiente para probar el flujo de trabajo. JetBrains puede distribuir Air a través de productos ya integrados en los equipos de ingeniería.

Esa ventaja de distribución es significativa, pero la adopción depende de la utilidad diaria. Los desarrolladores no mantendrán otra ventana de herramienta solo porque reconoce a varios agentes. Air debe hacer que el trabajo concurrente sea más fácil de entender, revisar y fusionar que terminales o aplicaciones de proveedores separadas.

Qué observar después del EAP de JetBrains Air

La próxima prueba no es cuántos agentes enumera Air, sino si los equipos completan trabajo real con menos cambios de contexto y costes de revisión manejables.

La primera señal es la adopción en repositorios habituales. JetBrains necesita evidencia de que los desarrolladores sigan usando Air después de que se desvanezca la novedad de iniciar sesiones paralelas. El uso repetido en depuración, mantenimiento, pruebas y refactorización respaldaría la tesis de la orquestación.

La métrica útil no es el número de prompts. Los equipos deberían examinar tareas completadas, cambios aceptados, tiempo de revisión, defectos reabiertos y la cantidad de reparación manual necesaria después de que un agente termine. Un alto volumen de sesiones puede ocultar resultados de baja calidad.

La segunda señal es la fiabilidad de la integración basada en worktrees. Air debería hacer evidentes el estado de las ramas, los cambios no confirmados, los conflictos y los destinos de transferencia. Un sistema diseñado para agentes paralelos debe evitar que los desarrolladores pierdan trabajo o apliquen un parche correcto a la rama equivocada.

JetBrains documenta medidas de protección y controles de revisión, pero el EAP revelará cómo se comportan bajo la presión diaria. Los repositorios grandes, archivos generados, monorepos y refactorizaciones superpuestas aportarán pruebas más exigentes que las demostraciones aisladas.

La tercera señal es la respuesta competitiva de los proveedores de agentes y editores rivales. Una adopción más amplia de ACP reforzaría la estrategia de espacio de trabajo abierto de JetBrains porque los desarrolladores podrían mover agentes entre clientes compatibles. En cambio, los proveedores podrían favorecer funciones propietarias que funcionen mejor dentro de sus propias aplicaciones.

La compatibilidad con capacidades comunes importará tanto como el número de agentes. Los permisos, las llamadas a herramientas, los adjuntos de contexto, los informes de costes, la reanudación de sesiones y la atribución de diferencias necesitan un comportamiento coherente. Un protocolo que conecte muchos agentes pero exponga solo sus funciones comunes mínimas limitaría la ventaja de Air.

Las organizaciones también deberían vigilar los controles administrativos. JetBrains afirma que las empresas pueden desactivar Air mediante el acceso administrado a IA, pero su documentación señala que la gestión de IDE Services aún no está completa. La adopción empresarial requiere políticas claras para proveedores, credenciales, ejecuciones en la nube, enrutamiento de datos y auditabilidad.

La relación entre Air y AI Assistant es otra señal concreta. JetBrains afirma que AI Assistant seguirá siendo compatible, mientras que Air se convertirá en la experiencia agéntica preferida. Las futuras versiones mostrarán si esta división se simplifica o genera interfaces superpuestas.

Una transición exitosa dejaría a los desarrolladores un lugar claro para las tareas delegadas y otro para la ayuda contextual ligera. Una transición confusa obligaría a los usuarios a entender qué plugin controla cada agente, suscripción o modo de chat.

Los cinco agentes compatibles también revelarán si la especialización aporta valor práctico. Los desarrolladores necesitan razones observables para elegir Codex para una tarea y Junie o Gemini para otra. De lo contrario, el selector se convierte en una decisión administrativa en lugar de una función de productividad.

JetBrains Air en los IDE se basa, en última instancia, en una premisa defendible: el código generado aumenta el valor del contexto y la revisión. La cuestión sin resolver es si un IDE puede organizar suficientes agentes sin convertir a los desarrolladores en gestores de colas a tiempo completo.

Prueba la EAP en una rama recuperable y asígnale una tarea que abarque varios archivos, pruebas y pasos de revisión. Después, compara el flujo de trabajo completo con tu configuración actual de agentes. ¿Air redujo el cambio de contexto, facilitó la inspección de los cambios y preservó el control sobre el repositorio? ¿O simplemente reunió cinco interfaces en una sola ventana? Esa respuesta, repetida en equipos reales, determinará si JetBrains Air se convierte en la capa operativa para el desarrollo agéntico o sigue siendo un experimento interesante.