La cuestión de la IA y el desarrollo de software

A principios de año comenté que quería escribir una publicación sobre las profecías del fin del desarrollo de software. Muchos de los puntos que quería tocar han ido apareciendo orgánicamente en las discusiones online acerca del tema, como era de esperar. De todas formas, pretendo afinar y elaborar algunas reflexiones al respecto.

Los debates sobre el futuro del software

Desde hace años, se viene prediciendo el reemplazo de los programadores por la Inteligencia Artificial. A principios de 2026 hubo especial ruido en redes y titulares después de que grandes CEOs y ciertos autores famosos lo dijeran de nuevo. Muchos de los gurús de la programación sacaron vídeos y publicaciones dando consejos para este futuro que venía. Hoy, seguimos viendo grandes despidos de programadores que parecen confirmar las predicciones sobre un futuro cercano de software escrito automáticamente.

Al mismo tiempo, se repite un discurso que compara los LLMs con los compiladores; al igual que nadie escribe ensamblador a día de hoy, se dice que en un futuro nadie escribirá código, sino que usaremos el lenguaje natural para describir un programa y los LLMs lo “compilarán” a software. Como les gusta decir a los defensores de esta idea: “el lenguaje de programación del futuro es el inglés” (nosotros diríamos el español). Se suelen leer dos argumentos en contra:

• Que la salida de un LLM no es determinista y por tanto el código producido no es fiable; no podemos predecir el comportamiento de un programa descrito en un prompt. A esto se suele responder que la salida de los compiladores tampoco es determinista, por factores relacionados con el estado físico del ordenador y, en algunos casos, por lagunas en la definición semántica de los lenguajes. Luego volveremos a este punto.

• Que siempre hará falta un desarrollador que responda del código. Como nos recuerda la famosa máxima de IBM de 1979: “A COMPUTER CAN NEVER BE HELD ACCOUNTABLE. THEREFORE A COMPUTER MUST NEVER MAKE A MANAGEMENT DECISION”. Es decir, que aunque el LLM genere el código, tiene que haber un ser humano con el conocimiento suficiente (es decir, un programador) para revisar el código generado; alguien cuya cabeza pedir si todo estalla.

En qué punto nos encontramos

No hace falta teorizar mucho sobre la validez de unos u otros argumentos, porque ya vivimos una situación de reemplazo parcial. Todavía somos las personas quienes respondemos del código, y por ello tenemos que revisar cada vez más y más código autogenerado. En muchos casos, nos vemos relegados a QAs de un código que se genera más rápido de lo que lo podemos revisar. Nosotros somos el cuello de botella; el elemento humano, se nos llama. La solución a esta situación de embudo es tan predecible que da risa: las revisiones de código también están asistidas por IA, o directamente automatizadas. Lo dicho; como la IA genera el código y la IA lo revisa, el propósito del ingeniero del futuro se reduce a ser el chivo expiatorio, la cabeza de turco de la IA.

Con el paso del tiempo, ni los ingenieros, ni las empresas, ni la misma ley le encontrarán sentido a esto. En realidad, la figura del ingeniero sobra en esta ecuación. Hasta hace poco, nos habrían querido convencer de lo contrario, cuando se puso de moda el prompt engineering. Todavía se ve a gente defendiendo que hace falta conocimiento para escribir un buen prompt, ignorando que el prompt engineering ya está automatizado ¹. El prompt no es más sofisticado que el código. Así que todo pareciera confirmar que, en efecto, la figura del desarrollador está condenada a desaparecer.

¿En qué escenario nos deja esto? El del empresario, o el product owner de turno, prompteando qué producto quiere construir. Lo que hoy se llama vibe coding. A nivel empresarial, esto puede funcionar al principio: tras una entrevista guiada por el LLM, el prompter obtiene un software tal y como lo pide. Sin embargo, hace falta un entendimiento muy claro de la arquitectura del producto y de la infraestructura para mantener dicho producto a lo largo del tiempo. Las buenas decisiones del principio se convierten en malas decisiones después. El software, como todo fenómeno vivo, tiende a aumentar en tamaño y complejidad y, para adaptar, actualizar o migrar sistemas complejos, el prompter se verá delegando decisiones técnicas vitales para su empresa en una IA que, por mucho que se las explique con lenguaje simplificado, no podrá transmitir a un lego toda la complejidad propia de un sistema comercial. El cuello de botella pasaría a ser el propietario del producto, más que el revisor del sistema. Llegados de verdad a ese punto, no es descabellado pensar que lo mejor sería reemplazar también al empresario o product owner por una IA. Pero esa es otra historia.

El problema original

El problema, en realidad, es el mismo de siempre; es el problema original del que nacen los lenguajes de programación: ¿cómo hago que este ordenador, una máquina universal, el invento de los inventos, el ingenio definitivo, haga exactamente lo que yo quiero? La respuesta no ha cambiado en décadas: hay que saber definir formalmente lo que se quiere.

Un compilador no es agéntico

El propósito del lenguaje de programación es separar el algoritmo del modelo de ejecución del procesador y acercarlo a algún modelo de pensamiento humano ². En cambio, con un LLM el programa se genera directamente en el flujo conversacional, sin recurrir a un engorroso lenguaje formal. No obstante, consideremos de nuevo la primera crítica que mencionamos antes: no podemos asegurar la corrección de un programa salido de un prompt sin examinar el código.

La respuesta de que un compilador tampoco es determinista tendría peso si cualquier persona en su sano juicio estuviera dispuesto a comparar el nivel de incertidumbre asociado a la salida de un compilador con el margen de decisión que tiene un LLM; un LLM que no posee ninguna semántica verificable y toma decisiones, con el enorme agravante de que el problema del alineamiento no está resuelto. Sí, un compilador, como cualquier programa de ordenador, puede ser víctima de un bug o un exploit, pero solo una IA puede malinterpretar o engañar a su interlocutor ³.

Los problemas de la verificación formal

Igualmente, muy pocos parecen dispuestos a abandonar el enorme potencial de los LLMs para generar código. Desde hace un tiempo, se oye más la propuesta de usar sistemas de verificación formal que definan declarativamente y a alto nivel los sistemas a generar por IA. También se llama Spec-Driven Development. Así, tendríamos la velocidad de desarrollo de un LLM y la confianza de un verificador formal que prevendría efectos indeseados ⁴.

No soy del todo escéptico ante este paradigma, aunque tenga inevitablemente sus problemas. Los sistemas de verificación podrían ser tan complejos como cualquier otro software, así que lo esperable es:

1. que los verificadores acaben implementados también por IA
2. que se conviertan en el nuevo cuello de botella por culpa del elemento humano

El primer caso sería, por definición, un despropósito. El segundo caso, o uno intermedio, sería justificable si consiguen una mayor velocidad neta en el desarrollo, manteniendo la fiabilidad de la verificación.

De consolidarse esta práctica, los conocimientos sobre tecnologías semánticas adquirirían más peso en los planes de estudio y las ofertas de trabajo. Tal vez (aunque no lo veo probable) incluso veríamos un renovado interés en la teoría de la computabilidad, la lógica formal, etc.

Muchos gurús de la programación parecen haber intuido esto, sin llegar del todo a estas últimas conclusiones; bastantes han dicho que en la era de la IA “hay que volver a los fundamentos”, porque te hacen un buen programador. Me temo que lo que llaman “fundamentos” son disciplinas enteras por sí mismas. Teniendo en cuenta el punto de partida de la industria, solo es verosímil un giro incompleto hacia el paradigma de los verificadores. Enseguida más sobre eso.

Predicciones

Las predicciones que hago a continuación solo tienen sentido si el status quo (por el que no pondría la mano en el fuego) se mantiene: la burbuja de la IA no ha estallado por completo, Europa sigue teniendo acceso a los productos de IA estadounidenses y no hemos sufrido ninguna crisis (p. ej.: energética, climática, de desalineamiento, etc.) que resulte en hiperregulaciones o en la extinción ⁵. Además, no me arriesgo a ponerles plazos concretos, porque depende del propio avance de la tecnología y de la rapidez con que unos u otros actores tomen decisiones estratégicas sobre el uso de la misma. Los cambios son los siguientes:

1. Reemplazo parcial en un futuro cercano y consecuencias.
   Los equipos de ingeniería se seguirán reduciendo en empresas existentes, y en muchas empresas nuevas ni los habrá. Las responsabilidades sobre el código las asumirán equipos pequeños o directamente mandos intermedios, donde el desarrollo se convertirá en un proceso de LLMs adversarios para programación y QA. Veremos cómo la calidad del software, que ya venía degenerando desde hace décadas, se sigue degradando a pasos cada vez mayores, no por culpa de los LLMs sino de sus prompters y por un relevo decreciente de ingenieros senior. Lo que ya vemos con el vibe coding, empeorará: los servicios online caerán más a menudo, las aplicaciones serán cada vez más lentas y los fallos en el software serán más habituales, sin importar la frecuencia de actualización ni la competencia. Todo esto resultará en empresas fallidas en el medio plazo y, en el largo, en una renovada búsqueda de ingenieros que arreglen los sistemas que no han podido escalar.

2. Consolidación lenta de la verificación formal.
   Las empresas que, antes o después, apuesten por la calidad y seguridad del software y que mantengan el uso de la IA, optarán por un flujo de trabajo subóptimo por los cuellos de botella humanos. Adoptarán poco a poco las prácticas de verificación formal que irán apareciendo, primero como nicho, luego como moda y finalmente como estándar. Se tratará de algún framework nuevo o un lavado de cara de tecnologías viejas, semánticamente robusto, que permita encontrar el punto intermedio del que hablábamos antes, entre seguridad y velocidad de desarrollo. Este framework y sus variantes permitirán especificaciones de muy alto nivel, estilo UML, y usarán definiciones declarativas de requisitos funcionales para la generación automática de tests.

3. Pronunciamientos aislados por parte de los gobiernos.
   Veremos pronunciamientos de unos pocos gobiernos sobre la necesidad de software verificado; algo similar al pronunciamiento de la Casa Blanca sobre los lenguajes de programación con seguridad de memoria. Puede que algunos países empiecen a imponer medidas de verificación sobre el software de sus administraciones y sistemas críticos. Una creciente necesidad de soberanía y resiliencia tecnológica sumada a las próximas pruebas de que el problema del alineamiento no se va a resolver llevará a muchos sectores estratégicos a considerar la dependencia de la IA como una vulnerabilidad; esto será todavía más pronunciado en países sin acceso a LLMs propios y después de que haya fallos y ciberataques, mayores en número y gravedad que los vistos recientemente por toda Europa.

4. Progresiva desaparición de incentivos para el reemplazo.
   Podría dejar de ser rentable el riesgo de desarrollar software automáticamente: principalmente, por el probable aumento en el coste de los servicios de programación con IA frente a la escasa y lenta oferta de infraestructura propia ⁶; y en mucho menor medida por el endurecimiento de las multas y auditorías derivadas de nuevas regulaciones sobre soberanía digital (véase la predicción anterior; esto sin seguir asumiendo hiperregulaciones más severas como las que mencioné que cambiarían el status quo).

5. Creación de nuevos lenguajes dedicados para IAs.
   No es ninguna locura prever la separación de lenguajes de programación para humanos y lenguajes de programación para IAs. Como dije antes, los lenguajes de programación acercan el modelo de ejecución del procesador a un modelo de pensamiento humano; sin embargo, un LLM con el entrenamiento adecuado no tendría problemas en trabajar directamente con la lógica del procesador o con representaciones intermedias, optimizadas para su verificación o para el hardware objetivo. Esto especialmente a medida que la verificación deje de realizarse leyendo el código.

   Lo lógico es que esto suceda de forma progresiva, porque las principales ventajas de muchos de los lenguajes actuales son las librerías que se pueden aprovechar con ellos. Un reemplazo total necesitaría empezar por “la periferia” de los sistemas (librerías de utilidades) y pasaría por un periodo intermedio donde los lenguajes tendrían APIs para construir sistemas híbridos.

   Sobre esto, se ha dicho que la IA necesita usar lenguajes que tenga en su memoria, y que por eso suele optar por Python, por ejemplo, dado el vastísimo corpus de código abierto en este lenguaje. Sin embargo, los sistemas de IA podrían tener suficiente capacidad de abstracción como para trabajar a partir de la documentación de lenguajes que no conocen con anterioridad. Habría que someter esta suposición a pruebas exhaustivas para los modelos actuales, pero no me cabe duda de que en un futuro cercano esto último se dará por hecho.

6. Transformación de los conceptos de Software Libre y Código Abierto.
   No me atrevo a mojarme mucho los pies en lo referente al código abierto, pero sospecho que nunca terminaría de perder relevancia, pues algunos proyectos seguirán aprovechando todo el potencial de la Ley de Linus junto a lo mejor que tengan que ofrecer los LLMs. El Software Libre pasará a tener una postura más fuerte si cabe, pues tendrá más razones para exigir programas que respeten las libertades del usuario. No creo que todo código producido por LLMs deje de considerarse libre, porque no hay un conflicto técnico en su definición; pero sí creo que aparecerán ramificaciones de los movimientos de Software Libre que incorporen cláusulas relacionadas con el uso de la IA en futuras versiones de la GPL.

7. Cultura hacker.
   Con todo, siempre habrá gente que programe porque es una actividad humana y cualquiera que quiera aprovechar su propio ordenador con independencia de servicios externos y en entornos con menos recursos, aprenderá a hacerlo.

Como dije, no me atrevo tampoco a ponerle plazos a estas predicciones. Considero que el rumbo que ha tomado la ingeniería se encamina a irlas cumpliendo con más o menos antelación, con las inercias y precipitaciones típicas de los cambios históricos. Todo esto, de nuevo, asumiendo que ningún otro evento cambie el mercado de la IA o el propio mundo en que vivimos.

En definitiva, no creo que la ingeniería del software desaparezca. Hay grandes transformaciones y cambios a la vista, pero no considero que en ningún caso estas signifiquen la desaparición definitiva de los programadores.

Pienso revisitar estas predicciones en publicaciones futuras y comprobar si envejecen bien o mal. Incluso si es para entender mejor mis sesgos actuales. Mientras tanto, ¡me encantaría saber qué piensas si has llegado hasta el final de todo el artículo!