Programando en 2026
2026.02.10
Sevilla, España
Programando en 2026
«Cuaderno de bitácora, Año Interestelar 2026 de nuestro Señor Jesucristo…
Los Borg han venido para quedarse.
La resistencia es fútil, serás asimilado.»
A estas alturas de la película a nadie le pilla ya por sorpresa si digo que la inteligencia artificial ha venido para quedarse. Fue impresionante ver hace unos meses cómo la inteligencia artificial generativa era utilizada para generar imágenes primero y vídeos después, haciendo que los diseñadores gráficos tuvieran que repensar la manera en la que trabajan para apoyarse en la IA.
En el mundo de la programación en este año 2026 se está consolidando la tendencia de que los agentes de código como Claude, Codex o Gemini han venido para quedarse. Es casi mágico contemplar la capacidad que tienen para corregir Pull Request, o generar código con pocas instrucciones de manera sistemática y sin descanso. Pueden ser utilizadas como un verdadero exoesqueleto para mejorar las capacidades de los ingenieros que saben lo que quieren construir.
Como toda herramienta de precisión, es potente y afilada hasta el punto de que te puedes pegar un “tiro en un pie” si no sabes lo que estás haciendo. En cambio, en manos de personal cualificado es innegablemente un multiplicador de su productividad que no podemos soslayar.
Esta tendencia no va a hacer más que seguir mejorando año tras año. Es cierto que hay objeciones de rendimiento y consumo energético, pero según mi optimista opinión, creo que seguirá mejorando sin duda en los próximos meses hasta hacerlos irrelevantes o al menos razonables y controlados.
A pesar de todo esto, lo cierto es que la profesión de programador está cambiando. Vamos a disponer de nuevas herramientas. De la misma manera que las matemáticas cambiaron con la aparición de la calculadora porque el cálculo se volvió barato, y sin embargo, no desaparecieron los matemáticos, al contrario están bien cotizados. No va a destruir, ni mucho menos, la labor de programación, pero sí que nos va a forzar trabajar de otra manera. En el extremo de la utopía (en la asíntota) podemos fantasear con que el código va a ser generado por completo por la inteligencia artificial (aún dudoso). Y en ese caso, si concedemos este punto la pregunta relevante a formular es ¿qué nos queda como labor a los ingenieros de software?
Al menos veo cuatro aspectos clave:
1. Los requisitos
Sin duda tomar buenos requisitos será una tarea primordial para guiar correctamente a la inteligencia artificial.
La mayoría de los proyectos que fracasan lo hacen por no tener claros los requisitos y las expectativas del cliente.
2. La arquitectura
La arquitectura resulta clave para conseguir buenos resultados de acuerdo a la función perseguida. Buenas ideas en la teoría se convierten en basura cuando son mal ejecutadas cuando aspectos no funcionales como rendimiento, tiempo real, usabilidad o granularidad del cambio no son tenidos en cuenta para el contexto donde el software debe ser usado.
Para muestra un botón: recuerdo aquella solución de hace un par de años para convertir video hecha con Amazon Lambdas donde cada función se encargaba de convertir un fotograma. Altamente escalable, sí, sin duda. La mejor arquitectura para el fin que se persigue, no de ninguna manera, terrible decisión de rendimiento y económica.
3. Depuración y explicabilidad
Cuando las cosas se tuercen, hay que depurar los sistemas y conocer extremo a extremo que paso. Si confiamos todo a la IA, ¿que humano será capaz de inspeccionar las tripas para validar que todo se comporta como se espera? ¿Está en peligro esa ave mítica: el desarrollador full stack? o al contrario ¿estará más cotizado?
4. La responsabilidad y rendición de cuentas
¿Quien será el último reponsable en caso de desastre? Como IBM apuntaba bien temprano (en 1979) "A computer can never be held accountable, therefore a computer must never make a management decision". Por tanto, si no podemos culpar a las máquinas, seguiremos siendo los humanos los responsables.
En este contexto, las herramientas para la toma de requisitos se vuelven cruciales Herramientas como Puffin de J.J. Dubray exploran la mejor manera de tomar requisitos. Hay estándares emergentes debatiendo sobre ello como OpenSpec y el movimiento asociado SDD (Spec Driven Development por contraposición al Vibe Programming).
En el libro premonitorio de John Macías The broken telephone explora cómo usar DDD y eliminar intermediarios para no acabar como en el juego con un «teléfono escacharrado».
El protocolo MCP es el estándar de facto para exponer nuestras APIs y recursos del mundo físico a tiro de la IA, que las usa y las combina de modo que antes ni habíamos imaginado. Exponer recursos a la IA tiene sus riesgos: más concretamente mucha superficie de ataque. En este sentido, recomiendo la lectura del libro de Daniel Garcia y Alfonso Muñoz Secure MCP - A practical guide for developers, software architects and tech leads las consideraciones de seguridad a la hora de crear MCPs.
Javier Vélez imagina un futuro cercano donde los LLM serán usados en tiempo de ejecución y no cohibidos por los formalismos deterministas e imperativos. Y que por tanto sus especificaciones o requisitos básicamente serán en lenguaje natural.
Para llegar a este punto, obviamente deberemos mejorar la toma de requisitos, reduciendo la ambigüedad del lenguaje y mejorando su precisión semántica.
Nuestros queridos lenguajes formales no ambiguos siempre han estado ahí, esperándonos Los DSLs, las máquinas de estado, las redes de Petri. Tenemos muchos formalismos no ambiguos con capacidad de precisar la semántica que requeriría un cirujano de precisión. Si somos capaces de aprovecharlos, las posibilidades son enormes.
Por nuestra parte, estamos explorando este camino con Structura. Hemos utilizado un DSL pequeño como puede ser un diagrama de clases para explorar los límites de la inteligencia artificial y cómo podemos combinar lo mejor de los dos mundos. Por un lado un lenguaje formal con una semántica clara. Por otro, una inteligencia artificial con una modalidad de chat que permite al usuario expresarse en lenguaje natural de modo escrito o hablado.
Desde el chat podemos preguntar sobre aspectos del modelo, cambiarlo, extenderlo, borrarlo o refactorizarlo a una velocidad que excede la práctica habitual.
Además de todo, esto una vez que el modelo está curado por el ingeniero (con o sin la ayuda de la IA) lo que vamos a hacer es aplicar generación de código de manera sistemática. De manera determinista, de tal modo que no damos pie a potenciales alucinaciones en el código generado. Estos generadores de código están preparados para para usos empresariales. Son capaces de garantizar el cumplimiento por construcción de mejores prácticas y cumplimiento con reglamentación. De tal manera que en los sectores regulados pueden garantizar por construcción el cumplimiento. Esto es especialmente sensible en aquellos entornos regulados (como banca, seguros o utilities) donde un no cumplimiento conlleva una multa importante del regulador.
No sabemos cuán rápido va a evolucionar todo esto. Lo que sí tengo claro es que la toma de requisitos y la arquitectura de software como repite Grady Booch seguirán siendo vitales y esta no es sino un peldaño más en la escalera de la abstracción creciente que es la historia de la ingeniería del software.
Y ahí es donde tenemos que estar los Ingenieros de software, en la cresta de la ola para intentar surfearla con éxito. Pocas profesiones abrazamos con más ímpetu la automatización y la mejora continua aunque eso conlleve la transformación irremediable de la profesión.
¡Bienvenidos Borg!
Dr. Pedro J. Molina