Descubre cómo Skyscanner potenció Codex CLI de OpenAI al integrarlo con los IDE de JetBrains. Así, su asistente de IA puede usar las mismas herramientas de depuración y pruebas que usa el equipo de desarrollo.
En Skyscanner, siempre buscamos formas de acelerar el desarrollo sin sacrificar la calidad. En los últimos meses, he estado probando Codex de OpenAI como compañero de programación en mi trabajo diario.
¿Qué hice diferente? Conecté Codex CLI a los IDE de JetBrains mediante el servidor de Model Context Protocol (MCP) que ofrece JetBrains. Así, la IA puede ver qué herramientas ofrece el IDE y usarlas. Esta integración cambió mi forma de trabajar. En este artículo, te cuento cómo el acceso a las herramientas de JetBrains ha mejorado la capacidad de Codex para resolver problemas y ha acelerado nuestro trabajo de desarrollo.
Cómo darle a Codex acceso al contexto del IDE
Gracias al servidor MCP de JetBrains, Codex ahora puede aprovechar la información que ofrece mi entorno de desarrollo, incluidos detalles que normalmente no podría “ver”.
Con el servidor MCP de JetBrains, Codex puede pedirle más contexto al IDE mediante herramientas como estas:
- Detectar problemas en un archivo: analiza el archivo con las inspecciones de IntelliJ, identifica los errores y las advertencias e indica el mensaje y la ubicación de cada problema.
- Ejecutar configuraciones de ejecución: ejecuta configuraciones predefinidas para tareas como realizar pruebas unitarias, analizar el código con un linter o darle formato, y devuelve el código de salida y la salida de cada ejecución.
Esto ha resultado sumamente útil. Codex recibe la misma información que consultamos los desarrolladores cuando escribimos, compilamos y probamos código. Con ese contexto del IDE, puede verificar mejor el código que genera y dedicar menos tiempo a cada iteración.
Cómo detectar errores más rápido: un caso real
Mientras escribía pruebas unitarias para verificar cómo manejamos los errores en nuestro código que usa el SDK de Java de Databricks, le pedí a Codex que me ayudara a simular un caso en el que se produce una excepción. Sin dudarlo, generó una línea de Java parecida a esta:
var stubError = new NotFound("dummy error");A primera vista, parece razonable. Queremos simular un error NotFound. Sin embargo, unos instantes después, IntelliJ marcó esa línea con un grueso subrayado rojo.
El problema era que la clase de excepción NotFound del SDK de Databricks no tiene un constructor que acepte una sola cadena como argumento (puedes verlo en el código fuente del SDK de Databricks, en NotFound.java). En otras palabras, el código que propuso Codex no iba a compilar.
Con su configuración predeterminada, Codex no habría detectado ese error de inmediato. Tal vez se habría dado cuenta más tarde, al intentar ejecutar las pruebas. Sin embargo, gracias a la integración con el servidor MCP de JetBrains, lo detectó enseguida. En segundo plano, Codex llamó a la herramienta get_file_problems del IDE para inspeccionar el archivo. La herramienta informó de inmediato que la compilación fallaría porque ningún constructor aceptaba ese argumento.
Sin el servidor MCP, Codex probablemente habría seguido estos pasos:
- Generar el código
- Averiguar cómo ejecutar las pruebas unitarias
- Ejecutar las pruebas unitarias (quizás tendría que pedirle al usuario autorización para ejecutar algunos comandos)
- Leer e interpretar el mensaje de error
- Intentar corregir el error
Con el servidor MCP de JetBrains, el proceso es mucho más corto:
- Generar el código
- Preguntarle al IDE de JetBrains qué problemas detectó en el archivo
- Corregir el error específico que señala IntelliJ
Así ahorramos tiempo y usamos menos contexto. La experiencia se pareció mucho a programar en pareja con un ingeniero que enseguida te dice: “Ah, esa clase no tiene un constructor así. Necesita otros argumentos. Dame un momento y lo corrijo”.
Configuraciones predefinidas para pruebas y formato
Otra ventaja que he podido aprovechar es que Codex puede usar nuestras herramientas de compilación y pruebas directamente desde el IDE. Para la mayoría de nuestros proyectos, ya tengo configuraciones de ejecución locales en mi IDE para tareas como ejecutar pruebas, dar formato al código y analizarlo con un linter. Con el servidor MCP de JetBrains, Codex puede encontrar esas configuraciones y ejecutarlas cuando las necesita.
En la práctica, Codex necesita menos tiempo y contexto para averiguar cómo realizar esas tareas, así que puede seguir concentrado en el problema original. Desde que hice este cambio, he observado que Codex ya no tiene dificultades para ejecutar las pruebas, dar formato al código o pasar el linter.
Por eso, en mis instrucciones personalizadas para el agente, le pido a Codex que ejecute las pruebas, pase el linter y dé formato al código después de cada cambio.
## Instrucciones para editar el código
Cuando termines de editar el código:
- Si el servidor MCP de JetBrains está disponible, úsalo para detectar problemas.
- Si el comando format está disponible, ejecútalo para dar formato al código.
- Si el comando lint está disponible, ejecútalo para analizar el código.He notado que ahora Codex suele resolver los problemas por su cuenta, sin que yo tenga que intervenir. Para mí, como desarrollador, es una gran ventaja:
- Ya no tengo que ejecutar las pruebas, pasar el linter y dar formato al código manualmente cada vez que Codex cambia algo.
- Ya no tengo que copiar los mensajes de error y pegarlos en el chat.
- Codex recibe información rápida y precisa sobre si sus cambios funcionan, lo que reduce la cantidad de ciclos de revisión.
Esto me deja más tiempo para concentrarme en mi tarea: entregar software de alta calidad que funcione.
Qué cambia en nuestra forma de desarrollar software
Al integrar Codex con el servidor MCP de JetBrains, nuestro asistente de IA puede hacer mucho más y es más confiable durante el desarrollo. Estas son algunas de las ventajas que hemos observado:
- Respuesta más rápida del IDE: Codex recibe información inmediata del IDE sobre errores de compilación y pruebas fallidas.
- Menos intercambios en el chat: Codex ya no tiene que esperar siempre a que yo ejecute algo y pegue un mensaje de error. Puede consultar el IDE directamente.
- Sugerencias de mayor calidad: como Codex puede ver lo mismo que el IDE, es más probable que el código que corrige compile y pase las pruebas al primer intento.
- Mejor integración con nuestros flujos de trabajo: Codex aprovecha las herramientas que ya usamos en lugar de inventar las suyas.
En conjunto, Codex pasó de ser una herramienta independiente a integrarse mejor en nuestro entorno de desarrollo.
Resumen
En Skyscanner aprendimos algo sencillo: el contexto es fundamental. Codex es potente por sí solo, pero resulta mucho más eficaz cuando tiene acceso a la información del IDE. Con ese contexto, Codex entiende mejor el problema y puede proponer correcciones precisas en menos tiempo. Eso me da aún más confianza en sus resultados.
Esperamos que nuestra experiencia anime a otros a probar estas integraciones. Trabajar así se parece mucho menos a usar una herramienta y mucho más a programar en pareja con un asistente de IA que puede ver lo mismo que nosotros.