JetBrains Air: guía práctica para usar Air Alpha

JetBrains Air permite iniciar un agente de programación dentro de un IDE de JetBrains, darle solo el contexto del proyecto que interesa y revisar sus cambios en el mismo entorno donde ya se navega y se prueba el código. Para empezar, no conviene encargar una refactorización enorme. Instala Air Alpha, conecta un agente, entrégale un archivo y una prueba que falla, y no aceptes nada hasta entender tanto el diff como el resultado de la prueba.

La versión breve

Usa Air como centro de control para agentes, no como un botón de autocompletado. El agente ejecuta el trabajo; Air organiza la sesión, le pasa el contexto del IDE y devuelve el resultado a una interfaz de revisión integrada en el propio entorno.

Para una primera sesión:

1. Instala Air Alpha desde el Marketplace del IDE.
2. Abre un proyecto descartable o una rama con una prueba que puedas ejecutar.
3. Elige un perfil de New Session y conserva Standard Access.
4. Envía el primer mensaje y completa el inicio de sesión si Air lo solicita.
5. Adjunta el archivo relevante con @file:.
6. Pide una corrección pequeña y una prueba.
7. Revisa cada archivo modificado en Agent Sessions.
8. Ejecuta la prueba por tu cuenta y luego conserva, edita, confirma o revierte el cambio.

Ese es todo el ciclo que importa al principio. Las sesiones paralelas, más agentes, los controles para organizaciones y el traspaso a la nube pueden esperar hasta que el flujo resulte confiable.

Qué es realmente JetBrains Air

Air es la capa que conecta un proyecto de JetBrains con uno o varios agentes de programación. Puede imaginarse como el banco de inspección de un taller: el agente lleva una pieza propuesta a la mesa, pero el IDE sigue aportando las medidas, las comprobaciones de encaje y la decisión final.

La versión del 22 de septiembre convirtió Air en un sistema más amplio con tres componentes definidos: Air en los IDE de JetBrains para el trabajo individual, Air Teams para coordinación y automatización, y Air Governance para políticas, visibilidad y control de costos. Esta guía se concentra en la ruta local que ya puede ejecutarse: el plugin Air Alpha para el IDE.

El plugin para el IDE no es un nuevo modelo fundacional. Puede ejecutar Codex, Gemini, GitHub Copilot, Claude y Junie desde el primer momento. Además, JetBrains afirma que otros agentes pueden conectarse mediante ACP. ACP, o Agent Client Protocol, funciona como una conexión común entre el IDE y toda la maquinaria operativa de un agente, incluidas sus herramientas y el enrutamiento de modelos.

La página actual de Air para IDE todavía presenta el traspaso del entorno local a la nube como una función próxima. Para que la primera ejecución sea confiable, conviene mantener la tarea pequeña y local.

Antes de instalar Air Alpha

Air Alpha es una versión alfa pública, no una herramienta estable y discreta. JetBrains advierte que la interfaz y el comportamiento pueden cambiar, y señala que se esperan actualizaciones aproximadamente cada semana. Antes de investigar cualquier otro problema, comprueba la compatibilidad.

El 23 de septiembre de 2026, el paquete vigente del Marketplace para la línea 2026.2 era Air 262.8665.463. Es compatible con IntelliJ IDEA desde 2026.2 hasta 2026.2.3 y con las versiones 2026.2 correspondientes de los IDE de JetBrains incluidos en la lista. El Marketplace también ofrece compilaciones para la línea 2026.3, por lo que la versión exacta del plugin puede variar según la rama del IDE.

Comprobación de compatibilidad realizada para esta guía

IntelliJ IDEA 2026.2.3, compilación IU-262.10968.63, cargó Air 262.8665.463 en un perfil aislado e indexó un proyecto descartable de Node sin errores del plugin. El agente detectado fue codex-cli 0.153.4, pero su sesión no estaba iniciada y el equipo anfitrión no contaba con una sesión gráfica. Por tanto, aquí no se afirma haber ejecutado una tarea interactiva en Air, generado un diff ni superado una prueba escrita por el agente. Los pasos de interfaz que siguen se basan en la guía de inicio rápido actual de JetBrains y en las etiquetas incluidas en esa versión del plugin.

Cómo usar JetBrains Air paso a paso

1. Instala Air Alpha

Abre la configuración del IDE, selecciona Plugins, cambia a Marketplace, busca Air Alpha y haz clic en Install. Reinicia el IDE si lo solicita.

Air no tiene costo. Sin embargo, el agente que funciona detrás puede requerir una cuenta, una suscripción o facturación mediante API. Si el costo es lo que frena la decisión, ¿JetBrains Air es gratis? distingue el precio del plugin del costo del agente.

2. Abre un proyecto con un fallo barato de reproducir

Comienza con un proyecto existente que puedas descartar o restablecer. Una buena primera tarea tiene un solo archivo relevante, un fallo observable y un comando que demuestre si el cambio funcionó.

Puede ser una función para generar slugs que procese mal los espacios repetidos, un formateador al que le falte un caso límite o una pequeña función de validación con una prueba unitaria fallida. En la primera ejecución, evita migraciones, autenticación, código de despliegue y actualizaciones amplias de dependencias.

Antes de abrir una sesión, registra el punto de partida:

• la rama actual o el worktree descartable;
• el comando exacto de prueba;
• si esa prueba pasa o falla en ese momento;
• los archivos que esperas que toque la tarea.

Así, la revisión se convierte en una comparación y no en una impresión subjetiva.

3. Elige un perfil de New Session

El botón New Session de la barra de herramientas principal inicia el perfil seleccionado. Usa el chevrón del botón para cambiar de perfil.

Un perfil es una configuración de inicio guardada. Define el agente y puede preseleccionar el modelo, el nivel de razonamiento, el nivel de acceso y la superficie de la sesión. Air muestra los agentes que detecta en el equipo junto a sus perfiles integrados. Si falta el agente seleccionado, el plugin puede ofrecer su instalación.

Para la primera tarea, elige Standard Access. En la versión actual del plugin, Standard Access permite que el agente lea, edite y ejecute comandos dentro del proyecto; para acceder a archivos externos o a la red necesita aprobación. Full Access elimina esas solicitudes de aprobación para usar la red y editar cualquier lugar del equipo. No es una buena configuración inicial para una primera sesión.

4. Envía el primer mensaje y autoriza al agente

La autorización aparece cuando el agente realmente la necesita. Escribe un primer mensaje breve y presiona Enter. Si Air encuentra credenciales que ese agente ya utiliza en el equipo, la sesión continúa. De lo contrario, muestra Choose a sign-in method to continue.

La vía disponible depende del agente:

• el inicio de sesión del agente puede continuar en un navegador o en la terminal;
• una licencia válida de JetBrains AI o el espacio de trabajo de una organización puede aportar créditos;
• Add an AI provider abre Tools | Air | Accounts para configurar una suscripción de terceros o una clave de API.

En Accounts, elige More Providers, añade las credenciales necesarias, usa Test Connection, guarda con OK y vuelve a la sesión para seleccionar ese proveedor.

No pegues ningún secreto en el prompt de la tarea. Las credenciales deben permanecer en el flujo de conexión del proveedor.

5. Añade solo el contexto que necesita la tarea

Air puede adjuntar archivos, commits y skills desde el control para añadir contexto. También puedes escribir @file: para un archivo o @folder: para una carpeta. La diferencia importa: adjuntar un único archivo pertinente es como entregar a un mecánico la pieza averiada; adjuntar todo el repositorio equivale a vaciar el garaje sobre la mesa de trabajo.

En la primera ejecución, adjunta el archivo de implementación e indica el comando de prueba. Añade un archivo de pruebas solo si el agente necesita comprender un patrón existente.

6. Pide un cambio acotado y exige una prueba

Un buen prompt identifica el defecto, delimita el alcance permitido y especifica el comando de verificación. Por ejemplo:

Corrige el manejo de espacios repetidos en @file:src/slug.js. Añade o actualiza la prueba pertinente más pequeña. Ejecuta node --test. No cambies dependencias ni toques archivos ajenos a la tarea. Si el comando de prueba no puede ejecutarse, detente y explica el motivo.

Ese prompt le da al agente una meta inequívoca. “Mejora esta función” no lo hace.

7. Sigue la sesión, pero no evalúes la narración

El agente informa sobre el progreso y puede hacer preguntas. Responde cuando falten requisitos, aprueba solo las acciones que comprendas y presta atención a solicitudes inesperadas de acceso a la red o a archivos externos al proyecto.

El texto de progreso aporta contexto, pero no constituye una prueba. La evidencia está en el diff resultante y en una prueba que puedas repetir.

8. Revisa el cambio en Agent Sessions

Abre Agent Sessions y despliega la sesión terminada. Consulta el diff de cada archivo modificado. El paquete actual incluye las acciones Show Diff, Generate summary... y Revert. La guía de inicio rápido de JetBrains indica que puedes conservar, editar, confirmar o revertir los archivos modificados.

Revisa en este orden:

1. Alcance: ¿Solo cambiaron los archivos previstos?
2. Comportamiento: ¿La implementación resuelve exactamente el fallo?
3. Calidad de la prueba: ¿La prueba nueva fallaría sin la corrección?
4. Efectos secundarios: ¿Se modificaron la configuración, las dependencias o las interfaces públicas?
5. Verificación: ¿La prueba pasa cuando la ejecutas fuera de la narración del agente?

Si el diff está casi bien, edítalo directamente o deja comentarios precisos para otra iteración. Si el alcance resulta inesperado, revierte el cambio y vuelve a empezar con un prompt más estricto. Una explicación convincente no merece un commit por sí sola.

Los costos reales

Air cambia el costo de la capa de orquestación, no el de la inteligencia que funciona por debajo. El plugin suma $0 al gasto en software, mientras que el agente conectado puede consumir una suscripción existente, saldo de API o créditos de JetBrains AI.

Esto importa cuando un equipo ya paga por agentes. Añadir una segunda superficie de control suele significar otro asiento antes de saber si realmente mejora la revisión. Como referencia pública, GitHub ofrece actualmente Copilot Business por $19 por usuario al mes y Enterprise por $39. Diez asientos Business cuestan $190 al mes antes del uso adicional. Air puede conectar agentes compatibles sin cobrar una tarifa adicional por el plugin, pero no elimina el costo de la licencia del IDE, la suscripción al proveedor, el uso de API ni el tiempo humano dedicado a revisar.

La pregunta presupuestaria útil es, por tanto, muy concreta: ¿puede una interfaz local y gratuita de revisión facilitar la dirección y la verificación del gasto actual en agentes? Pruébala con un equipo y una clase de tarea antes de comprar o estandarizar cualquier otra cosa.

Seis casos de uso, ordenados por quién obtiene más valor

1. Equipos que ya usan JetBrains y pagan varios agentes

Un equipo de ingeniería que utiliza Codex para una carga de trabajo y Claude para otra puede iniciar ambos desde el mismo entorno del IDE, adjuntar el mismo contexto del proyecto y revisar los archivos modificados en un solo lugar. El beneficio no consiste, por defecto, en tokens más baratos. Está en reducir los cambios de herramienta y consolidar un hábito de revisión alrededor de suscripciones que el equipo ya paga.

2. Mantenedores que resuelven defectos pequeños y verificables

Quien mantiene un proyecto puede adjuntar la función que falla, describir una regresión concreta, exigir una prueba enfocada y revisar el diff antes de que llegue a una rama. Este flujo resulta rentable cuando el diagnóstico está claro, pero escribir una corrección mecánica compite con trabajo de mayor profundidad.

3. Consultores que entran en un código base desconocido

Un consultor puede aprovechar la navegación de código del IDE para inspeccionar símbolos, adjuntar solo los archivos relevantes y pedir a un agente un cambio acotado. Mantener el trabajo en una rama descartable y usar Standard Access reduce el riesgo de que las convenciones desconocidas del repositorio terminen en una edición descontrolada. El beneficio es una orientación más rápida, sin fingir que el agente conoce reglas del cliente que nadie le explicó.

4. Profesionales de QA que convierten un bug reproducible en una prueba de regresión

Una persona de QA capaz de reproducir un bug puede adjuntar el archivo implicado y el área de pruebas, solicitar la prueba de regresión más pequeña y comprobar si de verdad captura el fallo. El valor está en acortar el recorrido entre la reproducción y un artefacto de ingeniería listo para revisión.

5. Desarrolladores sénior que enseñan a revisar con diffs concretos

Un desarrollador sénior puede dejar que un agente proponga una implementación pequeña y luego recorrer con un compañero menos experimentado el alcance, las suposiciones, el diseño de las pruebas y las decisiones de reversión dentro del IDE que ambos conocen. El resultado no es solo código: es un ejercicio visible de revisión con un conjunto de cambios real.

6. Equipos de plataforma que comparan agentes con la misma tarea

Un equipo de plataforma puede ejecutar la misma tarea acotada con perfiles distintos y comparar archivos modificados, comportamiento de las pruebas, aprobaciones y esfuerzo de revisión. El resultado es una evaluación mucho más útil que comparar respuestas de chat, porque la unidad de medida es un cambio verificado en el mismo repositorio.

Dos productos que vale la pena construir alrededor de Air

1. Un complemento que reúna evidencia de revisión para cambios de agentes

Esta es la oportunidad más sólida. Se puede crear un pequeño complemento que transforme una sesión de agente en un paquete de revisión: tarea, contexto adjunto, archivos modificados, comando y resultado de la prueba, decisión humana y referencia al commit final. Los responsables de ingeniería y los equipos regulados pagarían por un registro limpio que funcione por encima del agente que haya producido el código.

La demanda tiene suficiente precisión como para ser relevante: ai powered code review platform registra cerca de 1,900 búsquedas mensuales en Estados Unidos, con intención comercial. Los precios de $19 para Business y $39 para Enterprise de GitHub también demuestran que los equipos ya reservan presupuesto para asistencia y gobernanza de programación.

La versión vendible más pequeña no necesita controlar al agente. Puede recibir un diff y la salida de las pruebas, exigir una lista de comprobación al revisor y exportar un registro firmado en Markdown o JSON. El riesgo está en la plataforma: Air es una versión alfa, sus interfaces pueden cambiar semanalmente y JetBrains podría incorporar mejores funciones de evidencia o auditoría. La ventaja competitiva debe residir en políticas compatibles con varios agentes y en informes duraderos, no en un simple botón dentro de un IDE.

2. Un asesor para configurar agentes según cada repositorio

Otro producto posible es una herramienta de incorporación que examine los lenguajes, los comandos de prueba, las rutas sensibles y las reglas de contribución de un repositorio, y después recomiende una plantilla segura para la primera tarea y la configuración del perfil. Podría venderse a equipos que incorporan agentes en repositorios heterogéneos, donde hoy cada desarrollador repite el trabajo de configuración.

La demanda general es grande: ai coding assistant recibe cerca de 18,100 búsquedas mensuales en Estados Unidos, mientras que ai powered coding agent ronda las 8,100. El MVP puede ser un cuestionario sobre el repositorio acompañado de notas de configuración generadas, prompts iniciales acotados y una lista de comprobación para pruebas de humo. Al principio no hace falta una integración profunda con el IDE.

El problema es la diferenciación. JetBrains, los proveedores de agentes o las plantillas de repositorio pueden absorber consejos genéricos de configuración. Para ser viable, el producto necesita controles basados en las políticas de cada organización y evidencia de que sus recomendaciones reducen los cambios fallidos o de alcance excesivo.

Límites y una valoración honesta

Air aporta más valor a quienes ya prefieren un IDE de JetBrains y quieren elegir entre varios agentes sin renunciar a la revisión integrada en el entorno. No justifica delegar un cambio arriesgado que nadie pueda verificar.

Hoy importan tres limitaciones:

• Es una versión alfa. Las etiquetas y el comportamiento pueden cambiar con un ritmo de lanzamientos aproximadamente semanal.
• El plugin es gratuito; el trabajo no. La autorización del agente, las suscripciones, el uso de API, las licencias del IDE y la revisión humana siguen siendo costos separados.
• El entorno local es el punto de partida confiable. La página del IDE aún describe el traspaso a la nube como una función próxima, así que no diseñes el primer flujo alrededor de cerrar la computadora mientras la tarea continúa.

Standard Access tampoco es de solo lectura. Permite hacer ediciones y ejecutar comandos dentro del proyecto. Usa una rama o un worktree descartable, inspecciona el diff y vuelve a ejecutar la prueba por tu cuenta.

La conclusión es sencilla: vale la pena probar Air con un cambio pequeño si JetBrains ya es el espacio de trabajo diario. Todavía es pronto para convertirlo en la ruta obligatoria de repositorios sensibles sin un plan de reversión, una política de proveedores y evidencia de revisión.

Lo que puedes hacer el lunes

Elige un bug que tenga una prueba ejecutable con un solo comando. Colócalo en una rama descartable, instala en un equipo de desarrollo la versión de Air Alpha que corresponda, selecciona Standard Access, adjunta un archivo relevante y pide la corrección más pequeña junto con una prueba de regresión. Conserva el cambio solo si el diff es limitado y la prueba pasa cuando la ejecutas por tu cuenta. Ese único ciclo dirá más que una semana de demostraciones de agentes.

¿Qué hace JetBrains Air?

JetBrains Air coordina agentes de programación y administra su contexto, sus sesiones y su revisión dentro y fuera de los IDE de JetBrains. En el plugin local para el IDE, se selecciona un agente, se envía una tarea con contexto del proyecto y luego se inspeccionan los cambios resultantes en Agent Sessions.

¿Cuáles son las diferencias clave entre JetBrains Air y Claude Code?

Claude Code es un agente de programación. Air es una interfaz de control y revisión para varios agentes que puede ejecutar Claude junto con Codex, Junie, GitHub Copilot, Gemini, OpenCode y agentes compatibles con ACP, según las integraciones y autorizaciones disponibles.

¿Cuál es el mejor IDE para programar con agentes?

No existe un ganador universal. Air resulta atractivo cuando un equipo ya depende de la navegación, las inspecciones y las herramientas de diff de JetBrains. La mejor opción es el entorno que permita acotar, inspeccionar, probar y revertir de forma confiable el trabajo de un agente.

¿Se puede usar JetBrains gratis?

El plugin Air Alpha es gratuito. El IDE de JetBrains y el agente que funciona detrás de Air pueden tener costos independientes de licencia, suscripción o API.

Si quieres implantar un flujo seguro de agentes adaptado a tus repositorios y reglas de revisión, consulta desarrollo de agentes de IA.