La era post-IDE

El IDE era una interfaz para gestionar la complejidad

Durante décadas, el IDE fue la cabina de mando del desarrollo de software. A medida que las bases de código crecían y los lenguajes se volvían más sofisticados, los editores de texto sencillos dejaron de ser suficientes. Los desarrolladores necesitaban navegación por símbolos, autocompletado inteligente, análisis estático, herramientas de refactorización, depuración, ejecución de pruebas, exploradores de bases de datos, integración con el control de versiones, gestión de dependencias y decenas de otras comodidades.

Productos como IntelliJ llegaron a resolver ese problema extraordinariamente bien, y cuando yo manipulaba personalmente una base de código todo el día, esas funciones valían cada centavo. Pero, desde una perspectiva más amplia, un IDE es una herramienta que ayuda a una persona a comprender y modificar una gran colección de archivos de código fuente.

El desarrollo con agentes cambia quién realiza esa manipulación.

El código sigue ahí. El compilador sigue ahí. Git, las pruebas, los analizadores de código, los sistemas de tipos, los depuradores, los gestores de paquetes y los sistemas de compilación no han desaparecido. Lo que ha cambiado es que cada vez soy menos yo quien utiliza directamente esas herramientas. Lo hace el agente.

Rara vez necesito mirar el código

Esa constatación fue lo que finalmente me llevó a cancelar JetBrains. Ya casi nunca abro un IDE para «programar». A veces examino un archivo por curiosidad sobre una implementación. De vez en cuando hago una pequeña modificación manual. Puedo mirar un diff o investigar algo particularmente extraño.

Pero esas situaciones son ahora excepciones, no mi flujo de trabajo principal, y cuando solo necesito examinar texto, un editor básico es perfectamente suficiente. No necesito varios gigabytes de IDE y una suscripción anual para las pocas veces que abro manualmente un archivo fuente.

La inmensa mayoría de las funciones de IntelliJ de las que antes dependía siguen siendo importantes. Sigo queriendo navegación inteligente por el código, refactorización, pruebas, análisis estático y revisión de código. Simplemente, cada vez prefiero que el agente haga esas cosas en lugar de manejar yo cada herramienta.

Las herramientas no han desaparecido. Han pasado por debajo de la capa de abstracción en la que paso mi tiempo.

El lenguaje natural se está convirtiendo en una interfaz de programación

Los lenguajes de programación siempre han intentado, en distinta medida, hacer que las máquinas resulten más comprensibles para las personas. Conforme nos alejábamos del código máquina y del ensamblador, los lenguajes se volvían progresivamente más semánticos. Aparecieron variables con nombres significativos, funciones que se leían como acciones, estructuras orientadas a objetos que modelaban conceptos reales y lenguajes declarativos con los que podíamos describir cada vez más lo que queríamos, en lugar de cada instrucción necesaria para conseguirlo.

Pero seguían siendo lenguajes de programación.

Si hace 30 años me hubieras dicho que algún día pasaría gran parte del día programando hablándole o escribiéndole a un ordenador en inglés corriente, habría pensado que estabas diciendo disparates de ciencia ficción. Y, sin embargo, eso es esencialmente lo que hago ahora.

Evidentemente, el inglés no sustituye literalmente a TypeScript, Python, Go, Java o al lenguaje que termine implementando el sistema. Mi CPU no ejecuta un párrafo que le escribí a un agente. Pero esa distinción resulta cada vez menos importante desde el lado humano de la pila tecnológica.

Programar siempre ha consistido en traducir la intención humana a algo que una máquina pueda ejecutar, y con el tiempo hemos elevado repetidamente el nivel de abstracción del lado humano de esa traducción. Antes, las personas manipulaban directamente instrucciones de máquina. El ensamblador les puso nombres. Los lenguajes de alto nivel nos permitieron describir algoritmos sin preocuparnos por los registros. Los frameworks nos permitieron describir aplicaciones sin implementar cada primitiva. La infraestructura como código nos permitió describir entornos completos en lugar de configurar servidores manualmente.

Los agentes añaden otra capa. En vez de expresar personalmente cada detalle de implementación, podemos expresar cada vez más el resultado deseado:

• Añade compatibilidad con OAuth para este proveedor.
• Averigua por qué este endpoint de la API devuelve ocasionalmente datos obsoletos y corrígelo.
• Refactoriza estos servicios para que compartan la misma capa de autorización.
• Implementa esta épica de GitHub y todas sus subtareas.
• Revisa las solicitudes de incorporación de cambios resultantes en busca de problemas de seguridad e intégralas cuando estén listas.

Esas son instrucciones de programación. El resultado puede terminar siendo miles de líneas de código fuente convencional, pero yo no escribí personalmente la mayoría. Describí el sistema que quería, establecí restricciones, evalué el resultado y dejé que las máquinas tradujeran mi intención a los lenguajes que necesitan.

Hace treinta años, la idea de que el inglés corriente pudiera ocupar la cima de una pila de desarrollo sonaba a ciencia ficción. Ahora es mi forma habitual de trabajar. El lenguaje natural no está reemplazando los lenguajes de programación que hay debajo del sistema; se está convirtiendo en el lenguaje de programación que yo utilizo.

La habilidad valiosa nunca fue realmente el lenguaje

Tener experiencia con muchos lenguajes de programación sigue siendo enormemente valioso. Saber cómo distintos lenguajes representan tipos, concurrencia, memoria, estado, interfaces, errores y abstracciones te proporciona un modelo mental mucho mejor para evaluar lo que produce un agente. Esa experiencia ayuda a reconocer malas arquitecturas, complejidad innecesaria, interfaces frágiles y decisiones de implementación que probablemente causarán problemas más adelante.

Pero creo que una habilidad más importante es la experiencia construyendo sistemas complejos. Los lenguajes son, en última instancia, un medio para un fin.

Las partes difíciles del desarrollo de software nunca fueron simplemente recordar la sintaxis o saber qué función de una biblioteca llamar. Lo difícil es decidir dónde establecer los límites, comprender cómo deben interactuar los componentes, anticipar modos de fallo, gestionar el estado, diseñar para el cambio, sopesar compromisos, depurar comportamientos emergentes y saber cuándo una implementación aparentemente razonable se derrumbará ante la complejidad del mundo real.

Esas habilidades sobreviven a la transición al desarrollo con agentes y pueden volverse aún más importantes. Si un agente puede producir TypeScript, Python, Go, Rust o Java competente cuando se le pide, dominar una sintaxis concreta se vuelve menos escaso. Lo que gana valor es saber qué debe construirse, cómo deben encajar las piezas, qué restricciones importan y si el resultado es realmente bueno.

Por eso tampoco creo que el futuro pertenezca solo a quienes saben redactar buenas instrucciones. Un prompt ingenioso no sustituye al criterio de ingeniería. Alguien con décadas de experiencia construyendo sistemas puede mirar el plan de un agente y reconocer que los límites están mal definidos, que el modelo de datos no escalará, que las suposiciones de seguridad son débiles o que la arquitectura propuesta resuelve el problema equivocado.

El agente puede encargarse cada vez más de traducir la intención en implementación. La persona sigue necesitando comprender el sistema.

Para mí, ese es el verdadero cambio: el lenguaje de programación desciende en la pila, mientras que la arquitectura, el criterio, la orquestación y el pensamiento sistémico ascienden.

Cursor y Windsurf tampoco resuelven esto

La respuesta obvia es que quizá los IDE tradicionales estén perdiendo relevancia, pero los IDE nativos de IA como Cursor y Windsurf sean el futuro. No lo creo.

Cursor y Windsurf siguen siendo fundamentalmente IDE. Dan por sentado que el centro del desarrollo es una persona mirando archivos fuente, recorriendo un repositorio, seleccionando código, revisando diferencias e interactuando con la IA desde un editor. Eso ya me parece un paso intermedio.

Si trabajo con Orgabot u otro entorno de agentes, no necesito un editor mejorado con IA más de lo que necesito uno tradicional. No estoy sentado esperando al autocompletado, seleccionando una función para pedirle a la IA que la reescriba ni saltando manualmente entre archivos mientras un asistente mira por encima de mi hombro.

Le encargo el trabajo al agente.

El agente puede abrir los archivos, buscar en el código, examinar dependencias, ejecutar comandos, leer fallos de pruebas, modificar veinte archivos, poner en marcha subagentes, revisar los cambios resultantes y seguir iterando hasta completar la tarea. Llegado ese punto, meter la IA dentro de un IDE parece casi hacerlo al revés.

El objetivo no es que las personas editen código muchísimo más rápido. Es que necesiten editar muchísimo menos código.

La distinción importa. Cursor y Windsurf pueden ser mejores cabinas para programar con ayuda de IA, pero la dirección que estoy tomando cada vez requiere menos una cabina. La interfaz principal pasa a ser la misión, la incidencia, la especificación o la conversación. El código fuente sigue siendo fundamental, pero se convierte en un artefacto producido y manipulado debajo de esa interfaz, en lugar del sitio donde paso el día.

Así que, cuando cancelé JetBrains, no lo sustituí por Cursor ni por Windsurf. Sustituí el IDE por el agente.

Ya no quiero ser el programador

Orgabot me llevó un paso más allá. Cuando uso Orgabot para crear una aplicación o una organización, no abordo el trabajo como un ingeniero de software con mejores herramientas para programar. Lo abordo desde la perspectiva del director ejecutivo.

Un director ejecutivo no abre un archivo fuente y corrige una función. Define el objetivo, asigna responsabilidades, se asegura de que trabajen las personas o los agentes adecuados, revisa si el resultado cumple el objetivo y cambia la organización cuando el proceso falla.

La propia orquestación también se puede delegar. Un director ejecutivo puede encargarle un producto al director de tecnología, y este coordina ingeniería, seguridad, infraestructura, diseño y revisión bajo ese mandato. El director ejecutivo no necesita saber qué archivo contiene el middleware de autenticación.

Cada vez construyo software más de esa manera. Puedo decir:

• Construye este producto.
• Resuelve esta épica y todas sus subtareas.
• Investiga por qué falla este sistema y resuelve la causa raíz.
• Haz que seguridad revise la implementación antes de publicarla.
• Reduce el coste de este flujo de trabajo sin degradar la calidad.

Esas instrucciones generan trabajo que acaba produciendo código, pero el código está varias capas por debajo de la interfaz en la que opero.

De ahí sale una regla útil: si el director ejecutivo está revisando o editando código fuente, probablemente hay un flujo de trabajo defectuoso por debajo.

Quizá falló el agente de ingeniería. Quizá el proceso de revisión es débil. Quizá la organización no tiene el rol o la habilidad adecuados. Quizá los límites para escalar problemas están mal definidos. Sea cual sea la causa, la respuesta no debería ser arrastrar indefinidamente al director ejecutivo a la capa de implementación. Debería ser arreglar el sistema para que la organización pueda encargarse bien de ese trabajo la próxima vez.

Por eso también tengo poco interés en sustituir IntelliJ por Cursor, Windsurf u otro IDE con IA. Esas herramientas hacen más eficaz a un programador dentro de la capa de código. Orgabot intenta convertir esa capa en un lugar al que rara vez necesito entrar.

El IDE puede estar convirtiéndose en un detalle de implementación

Por eso creo que estamos entrando en una era post-IDE.

Eso no significa que los IDE vayan a desaparecer mañana, ni siquiera que desaparezcan los editores gráficos de código. Siempre habrá momentos en los que mirar directamente el código fuente sea la mejor forma de comprender un problema. Pero creo que el IDE está perdiendo su posición como interfaz principal entre el programador y el software.

El entorno de agentes está convirtiéndose en esa interfaz, lo que plantea un problema estratégico incómodo tanto para las empresas de IDE tradicionales como para las de IDE con IA. La respuesta obvia ha sido meter IA dentro del IDE: añadir un panel de chat, autocompletado, un modo agente y la posibilidad de que la IA modifique varios archivos a la vez.

Son mejoras útiles, pero me pregunto si no tienen la arquitectura al revés.

Quizá el futuro no sea un IDE con un agente dentro. Quizá sea un agente con un editor dentro.

El agente se convierte en el entorno. El repositorio, la terminal, el navegador, el depurador, el editor, las pruebas, el sistema de integración continua, el gestor de incidencias y la infraestructura de despliegue son herramientas a disposición de ese entorno cuando hacen falta. La mayor parte del tiempo, la persona se mantiene un nivel por encima.

No cancelé JetBrains porque JetBrains empeorara

Esta distinción importa. JetBrains no me perdió porque IntelliJ se convirtiera en mal software. Todo lo contrario: IntelliJ sigue siendo una obra de ingeniería asombrosamente capaz.

Cancelé porque mi forma de trabajar cambió tanto que ya no necesito el 99 por ciento de lo que hace, y esa es una amenaza mucho mayor. El problema competitivo más difícil no surge cuando alguien crea una versión mejor de tu producto. Surge cuando el comportamiento del usuario cambia tanto que la propia categoría del producto pierde importancia.

Durante años quise el mejor entorno posible para editar código fuente. Después quise el mejor entorno para dirigir agentes que editan código fuente. Cada vez más, incluso eso se queda corto para describir hacia dónde vamos.

Quiero el mejor entorno posible para crear organizaciones de agentes que puedan asumir responsabilidades, delegar trabajo, revisarse mutuamente, escalar cuando sea necesario y producir software sin obligarme a bajar a la capa de implementación.

El IDE no es el centro de ese mundo. Es una herramienta que podría utilizar uno de los agentes.

Después de años viviendo dentro de IDE, creo que por fin puede que los haya dejado atrás.