Acabo de cancelar mi suscripción anual a JetBrains.
Hace unos años, eso me habría parecido casi impensable. IntelliJ y el resto de la suite de JetBrains eran exactamente el tipo de software por el que pagaba con gusto: herramientas potentes y pulidas, repletas de funciones que facilitaban enormemente escribir, recorrer, refactorizar y depurar grandes bases de código. Durante mucho tiempo, el IDE fue el lugar donde yo desarrollaba software.
El problema es que ya casi no abro ninguno.
No es porque haya dejado de crear software. De hecho, probablemente estoy creando más que nunca. La diferencia es que cada vez interactúo menos con el código a través de un IDE. Trabajo con Orgabot y otros entornos de agentes: describo lo que quiero y dejo que los agentes examinen el repositorio, rastreen el código pertinente, modifiquen archivos, ejecuten pruebas, corrijan fallos, revisen la implementación, abran solicitudes de incorporación de cambios, resuelvan conflictos y sigan adelante.
Mi principal interfaz de programación ha pasado gradualmente de un editor de texto lleno de código fuente a una conversación sobre la intención. El lenguaje natural se ha convertido en mi lenguaje para programar.
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.
¿Sigues necesitando leer el código?
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.
Por si sirve, la interfaz que describo aquí está documentada: Claude Code está construido en torno a la programación con agentes desde la terminal, y no alrededor de una ventana de editor.
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.
¿Lo resuelven Cursor y Windsurf?
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.
Desde entonces ambos han añadido agentes de terminal e interfaces de automatización, y eso es un movimiento real en esta dirección. Pero el editor sigue siendo el producto: ahí es donde aterrizan las funciones, hacia donde va la atención y por lo que pagas.
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.
