Últimamente se escucha mucho que 2026 será el año en que mueran los IDE. Los LLM serán tan buenos escribiendo código que lo generarán todo por su cuenta, y los desarrolladores pasaremos a ser una mezcla de product managers, arquitectos y revisores.
Puede ser. Pero esa forma de contar el cambio se queda corta.
Crear código nunca ha sido un objetivo en sí mismo. El objetivo son las funcionalidades que ese código hace posibles: resolver problemas reales para las personas que usan nuestro software. Cada línea de código valiosa existe porque acerca el producto a ese resultado.
Opus 4.5 es un modelo impresionante. La calidad del código que genera y su capacidad de planificación sorprenden. Cursor Composer y GPT Codex también son muy buenos. Si miramos la evolución de los últimos seis meses, parece evidente que tendremos modelos muy capaces en muy poco tiempo.
Pero incluso con modelos excelentes seguimos arrastrando un problema grande: las decisiones de negocio todavía las tenemos que aportar nosotros.
El código no es el centro
La verdadera revolución, el cambio grande en cómo desarrollamos software, llegará el día en que podamos hablar con los LLM sobre nuestro negocio.
No solo sobre controladores, modelos, endpoints, migraciones o componentes. Sobre el negocio. Sobre clientes, restricciones, márgenes, prioridades, excepciones, promesas comerciales, riesgos operativos y criterios reales de éxito.
Solo cuando los modelos entiendan ese contexto podrán empezar a hacer las preguntas correctas cuando pidamos una nueva funcionalidad o una corrección de bug.
Hoy seguimos funcionando demasiado a menudo así: damos una orden técnica, el modelo produce una solución técnica y después revisamos si encaja. Eso es útil, pero no cambia el centro de gravedad. Sigue siendo desarrollo asistido alrededor del código.
El salto importante será distinto: pedir una mejora de producto y que el modelo entienda qué parte del problema falta por definir antes de tocar el código.
La analogía del coche autónomo
Lo veo parecido al coche autónomo.
El cambio real del coche autónomo no es solamente que pueda conducir sin conductor. Eso es espectacular, pero no es la transformación completa.
La transformación es que, si un coche puede conducir solo, quizá ya no necesito comprar uno. Puedo pedirlo desde una aplicación cuando lo necesite. Me recoge, me lleva a mi destino y después se marcha a servir a otra persona.
Eso no mejora simplemente la experiencia de conducir. Cambia la industria del automóvil: propiedad, seguros, aparcamientos, flotas, mantenimiento, diseño urbano y modelos de negocio.
Con los LLM pasa algo parecido. Si solo pensamos en "la IA escribirá código dentro del IDE", estamos mirando la parte más visible, pero no necesariamente la más importante.
Contexto de código frente a contexto de negocio
El contexto engineering y las herramientas actuales siguen centradas sobre todo en el código: repositorios, convenciones, tests, documentación técnica, historial de cambios, comandos, rutas y dependencias.
Todo eso importa. Un modelo que no entiende el código existente rompe cosas. Necesita contexto técnico para trabajar bien.
Pero el código es el medio, no el problema. Lo que deberíamos querer es que el modelo entienda qué estamos intentando resolver con ese código.
Si le pido "añade un campo para marcar clientes prioritarios", un buen asistente técnico puede crear la migración, actualizar el formulario y ajustar la vista. Un asistente que entiende el negocio preguntaría antes:
- ¿Qué hace que un cliente sea prioritario?
- ¿Quién puede cambiar ese estado?
- ¿Afecta a facturación, soporte, tiempos de respuesta o reporting?
- ¿Debe ser visible para el cliente o solo para el equipo interno?
- ¿Qué ocurre con los clientes que ya existen?
Ese es el cambio que importa. No que el modelo escriba más rápido el código que yo ya había decidido escribir, sino que ayude a decidir si ese código es el correcto.
Ahí está el gran cambio
Los IDE pueden cambiar, reducirse o desaparecer como centro de trabajo. Puede que dentro de unos años pasemos menos tiempo mirando archivos y más tiempo dirigiendo sistemas que modifican software por nosotros.
Pero la muerte del IDE no es la revolución. Es una consecuencia secundaria.
La revolución llegará cuando dejemos de hablar con la IA solo sobre implementación y empecemos a hablar con ella sobre el negocio. Cuando el modelo tenga suficiente contexto para entender el problema, detectar huecos, cuestionar decisiones y proponer caminos mejores antes de escribir una sola línea.
Entonces sí cambiará de verdad la forma en que desarrollamos software.
