¿El fin de los IDEs y los CLIs agénticos? Llegan los ADEs

Aunque las canas lo delatan, probablemente te imaginarás que ya llevo un rato desarrollando software.

Pero la realidad es que cuando empecé a programar, allá por 2003, los IDEs ya existían. Siempre he vivido con ellos y se me hacen algo natural.

Programar en un IDE nos ha hecho mucho más eficientes, generar código más complejo en menos tiempo y, sobre todo, nos ha permitido dejar de confiar en nuestro músculo cerebral para escribir código válido.

Esa función que no recuerdas cómo se escribe, ese punto y coma de cierre de línea. Incluso IDEs como los de JetBrains fueron pioneros en ayudarnos a transformar el código asegurando que no iba a romperse.

La programación no puede existir sin el IDE.

¿O sí?

Podemos estar más o menos de acuerdo en cuánta IA debemos usar para desarrollar, pero lo que ya es innegable es que es una revolución igual o superior a la aparición de los IDEs.

Y, curiosamente, parece que también puede ser su fin.

La IA como apoyo al IDE

Cuando GitHub Copilot apareció, a todos nos explotó un poco la cabeza. Un autocompletado tan inteligente, que básicamente nuestro trabajo se relegó a hacer TAB a las recomendaciones que nos ofrecía.

Después de borrar la flecha del tabulador, nos dimos cuenta de que quizá no era esa la vía.

Si lo que queríamos era que generara nuestro código, o al menos parte de él, no tenía mucho sentido tener que aceptar casi cada línea manualmente. Por aquel entonces ya teníamos un chat al lado al que le podíamos preguntar cosas y tomaba el código como contexto.

Y aquí llegó el cambio de paradigma: dejemos a la IA que modifique nuestro código. Algunos fueron rápidos y vieron el potencial que tenía esto, creando los famosos IDEs agénticos, o IDEs impulsados por IA.

Cada tarea repetitiva que hace un humano, podemos hacerla más eficiente si usamos IA. Con Cursor como su mayor exponente, todo el mundo empezó a virar en esa dirección.

Pero esto solo parecía un parche para lo que estaba por venir.

El auge de los CLIs agénticos

Los IDEs solo aceleraban nuestro flujo de trabajo clásico. Pero… ¿y si hubiera otra forma?

Claude Code llegó para demostrar que sí la había. Si nuestro objetivo era simplemente generar código, necesitábamos herramientas que fueran muy buenas en ello y relegar la revisión al último paso.

Para ello no necesitábamos estar constantemente en el IDE. Podíamos trabajar desde una terminal.

O, mucho mejor, desde muchas instancias de terminal.

Porque si no vamos a revisar cada paso del agente, ¿qué nos impide tener a uno trabajando en una feature, mientras otro me revisa un bug, mientras otro me actualiza la documentación?

O incluso estar trabajando en varios proyectos a la vez.

La terminal permite esto, pero es verdad que no es la herramienta más amigable. Hay gente que, por supuesto, se siente muy cómoda con ella, pero también algunos llegamos allí porque no había otra opción con la misma versatilidad.

Aun así, en mi caso personal, llevaba trabajando con CLIs desde julio del año pasado. Los primeros meses con Claude, y desde septiembre con Codex CLI.

Hasta que llegó Codex App.

Agent Development Environment

Eso significan las siglas de ADE, por si te lo llevabas preguntando todo este tiempo 😄

La primera vez que probé uno en serio, sin saber que se estaba forjando este nombre, fue con Codex App.

He estado probando Codex App en serio, como herramienta de desarrollo de software.

Lo interesante no es “que escriba código”, sino cómo gestiona el estado, el contexto y el flujo cuando hay varias tareas a la vez.

La pregunta es: ¿es mejor que el CLI, o seguirá siendo preferible usarlo en terminal?

Ver publicación

Y poco después hacía esta reflexión:

Creo que Codex App se parece más a un IDE adaptado a los nuevos tiempos de lo que se pueden parecer las clásicas alternativas como Cursor, Windsurf y compañía.

En Codex App, el foco está en la orquestación de agentes, y no en el código.

Es un hecho que cada vez vamos a revisar menos código, y sobre todo a escribirlo, y ocupar la mayor parte del espacio de trabajo con código no es práctico.

Ver publicación

Si el nuevo paradigma es la gestión de agentes en paralelo, entonces un IDE donde el centro es el código se nos queda corto.

Aquí nos centramos en:

• Orquestar agentes: el proceso no es secuencial, es paralelo, y por tanto poder movernos fácilmente entre ellos es primordial.
• Que puedan trabajar sin pisarse: para un proyecto personal, tener a 4 agentes trabajando en main puede tolerarse un tiempo. Pero esto no escala. Estas herramientas integran desde su base el concepto de worktrees.
• La revisión sigue estando: no es que desaparezca, solo que queda relegada a una sección lateral que desplegamos cuando la necesitamos. El código ya no es el centro.

Pocos días después, leí de alguien, lo siento, no recuerdo quién, que se movía a Cursor para seguir trabajando en lo que él consideraba el futuro: los ADEs.

Y ahí es donde escuché el concepto por primera vez. También entendí que esto no era nada nuevo:

• Cursor tiene su Agent Mode.
• Antigravity su Agent Manager.
• Y ayer mismo, JetBrains presentó Air, que ellos mismos definen como ADE.

Seguro que me dejo muchos otros que, o bien recientemente o ya desde hace tiempo, ofrecen interfaces similares.

Pero parece que todos los grandes se están moviendo en esa dirección.

No estamos preparados para este cambio

No digo que no sea el futuro, pero sin duda alguna no es el presente. Al menos para la mayor parte de los desarrolladores.

Yo soy un fiel defensor del uso de IA para desarrollo de software. Estoy convencido de que si decides no usarla, estás pegándote un tiro en el pie en tu carrera como desarrollador.

Las personas que la usan con criterio y conocimiento son mucho más productivas, siendo capaces de mantener o incluso superar la calidad del código que generaban previamente.

Pero esto no es la inmensa mayoría. Mucha gente hoy no tiene conocimientos ni siquiera para hacer que un único agente desarrolle código de forma adecuada, siguiendo sus propias reglas y ofreciendo resultados de calidad.

Se nos ha vendido que la IA es mágica, y que con un prompt bien escrito conseguimos resultados perfectos.

Y esto no es así. Se necesitan unos conocimientos muy sólidos sobre cómo ofrecerles el ecosistema adecuado para que puedan trabajar:

Contexto (estático y dinámico), guardrails, validaciones, flujos de trabajo…

Esto no se aprende en dos días. Es justo el tipo de trabajo que hacemos en AI Expert, y cada vez tengo más claro que 6 semanas intensivas se quedan cortas.

Y lo que estamos viendo en muchas empresas es lo contrario:

Les ofrecen una suscripción a la IA de turno y les dicen que desde el día siguiente tienen que ser más productivos.

El daño que se puede hacer con un solo agente es enorme. Imagina ahora que nos ponemos a ejecutar 3, 4… ¡10! agentes en paralelo.

Por eso creo que al sector le falta madurar sobre el uso de la IA para poder sacarle partido a esta forma de trabajar.

¿Llegaremos? Mi opinión es que sí, y que incluso hay personas para las que hoy en día es su mejor herramienta. Yo mismo uso Codex App como mi herramienta de desarrollo.

Pero para el común de los mortales que no está en la cresta de la ola constantemente, esto está a años luz de lo que se pueden plantear hoy en día.

Mi recomendación

Si estás empezando en esto de la IA, lo primero que tienes que conseguir es que un solo agente desarrolle el trabajo tal y como quieres.

Ve delegándole primero tareas muy pequeñas, validando los resultados línea por línea, ajustando el contexto cada vez que haga algo que no encaje con lo que buscabas.

Y poco a poco le irás delegando más tareas. Quizá una feature más grande, más adelante un commit completo, más adelante incluso permitirle revisar una PR, y siempre cuando todo lo anterior esté validado.

Que tú te hayas hecho a la herramienta, y que la herramienta haga lo que esperas.

Antes de coordinar diez agentes, asegúrate de que sabes trabajar bien con uno.

Y si quieres acelerar todo esto, podemos vernos en mayo en AI Expert 😊