Uno de los agentes de IA con los que trabajo no encontraba una decisión que yo había aprobado unas horas antes. No la había olvidado: estaba guardada en un sitio al que no tenía acceso, así que para él sencillamente no existía. Otro se pasó horas haciendo comprobaciones que nadie le había pedido, hasta llenar el disco. Los dos escribían código bastante más rápido de lo que yo podría hacerlo nunca. El problema era otro.
Me acordé de ellos al leer uno de esos titulares que anuncian la muerte de la programación. Venía de un artículo académico publicado en junio de 2026 por Zhenfeng Cao, investigador en Shenzhen, con un título sin matices: The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm. Seis días después, el propio autor lo cambió por otro bastante más sobrio: Agentic Software: How AI Agents Are Restructuring the Software Paradigm.
El cambio dice mucho. Anunciar el fin de la ingeniería del software no es lo mismo que describir una manera distinta de construirlo. Lo que Cao firma es una propuesta teórica sobre esa transformación, no una prueba de que los programadores se hayan quedado sin trabajo. Y sin embargo, debajo del titular hay una pregunta que merece la pena: ¿qué ocurre cuando escribir código deja de ser la parte difícil?
Llevo meses respondiéndola sin habérmelo propuesto, a través de dos experimentos: UXMachine y RosmarOps.
El código deja de ser el producto
Durante décadas, construir software ha consistido en escribir instrucciones. Alguien traducía las necesidades de una persona o de una organización a reglas que una máquina pudiera ejecutar. Esas reglas contenían la lógica del sistema: si querías que se comportara de otra manera, había que reescribirlas.
Cao sostiene que los agentes alteran esa relación. Un agente recibe un objetivo, decide cómo abordarlo, genera el código que necesita, lo ejecuta y puede tirarlo después. El programa deja de ser el resultado y pasa a ser una herramienta más del agente. De ahí deriva lo que llama Agent-as-a-Service, la evolución del SaaS: en lugar de pagar por una aplicación con la que hacer una tarea, pagarías por un servicio que la hace por ti. La lógica es difícil de discutir. Si lo que necesito es resolver un problema, ¿por qué debería importarme qué pantallas, menús o programas hay detrás?
Lo que me cuesta es el salto entre resolver una tarea puntual y responder de un sistema durante años. No imagino a un banco, a un hospital o a una empresa mediana renunciando al software estable, a las reglas deterministas, a las pruebas de seguridad y al mantenimiento porque un agente pueda improvisar una solución cada vez. Que un programa pueda generarse no lo vuelve prescindible. El código no desaparece: cambia quién lo escribe, cuándo se genera y qué parte del valor representa. Ya es bastante cambio.
Lo que aprendí construyendo con agentes
Mi caso es particular. No soy un ingeniero que haya cambiado su editor por un agente. Vengo del marketing, de la gestión y de la creación de empresas digitales. He trabajado muchos años con equipos técnicos, pero nunca había desarrollado yo mismo productos de esta complejidad. Con UXMachine y RosmarOps lo he hecho.
- UXMachine: permite a los agentes de programación revisar webs con un navegador real y devolver evidencias de lo que funciona, lo que falla y lo que no se ha podido comprobar.
- RosmarOps: examina en local la configuración de los agentes de IA instalados en un ordenador, mostrando qué pueden leer, ejecutar o modificar, y en qué condiciones.
Son proyectos distintos con una obsesión común: que el trabajo de los agentes sea más verificable y más controlable.
En los dos, buena parte del código la han escrito agentes. Mi tiempo se ha ido en otra cosa: definir qué quería, discutir alternativas, entender implicaciones, decidir y comprobar. Al principio me preocupaba que los agentes hicieran lo que les pedía. Ahora me preocupa bastante más estar pidiéndoles lo correcto. Un agente puede completar una tarea técnicamente impecable que no resuelve nada. Puede arreglar un error introduciendo otro, o proponer una arquitectura razonable que complica el producto sin necesidad. También puede seguir ejecutando cuando debería haberse parado a preguntar. No lo cuento de oídas.
Trabajar así tampoco va de escribir buenas instrucciones. Va de montar un sistema. Hay que fijar qué puede decidir el agente solo y qué necesita aprobación, y dónde se guardan los acuerdos —el primer agente de este texto falló justo ahí—. También qué pruebas hay que pasar, cuándo algo está terminado y, sobre todo, cómo se comprueba que el resultado es el esperado. He acabado dedicando una parte considerable del esfuerzo a escribir reglas sobre lo que los agentes no deben hacer. No es exactamente la revolución sin fricción que nos vendieron.
Arquitecto de la intención, pero no solo
Cao usa una expresión que me gusta para el nuevo papel humano: intent architect, arquitecto de la intención. Las personas dejarían de escribir código para definir objetivos, orientar a los agentes y auditar lo que producen. Me reconozco bastante en esa descripción. Pero se queda corta, porque da por hecho que la intención existe antes de empezar.
Cuando construyes un producto, buena parte del trabajo consiste en descubrir qué quieres de verdad. Empiezas con una idea que parece clara hasta que intentas que funcione. Entonces aparecen las excepciones, las dependencias, los costes, los riesgos y las decisiones que habías pasado por alto. Un agente muy capaz no te ahorra ese descubrimiento. Más bien al contrario: la facilidad para construir hace más tentador avanzar sin haber entendido el problema. Antes, las limitaciones técnicas te obligaban a parar. Ahora puedes llegar mucho más lejos antes de descubrir que la decisión de base era equivocada. Y cuanto más has levantado encima, más cara sale la corrección.
«La facilidad para construir hace más tentador avanzar sin haber entendido el problema. Antes, las limitaciones técnicas te obligaban a parar.»
Por eso no me convence la tesis del final. En octubre de 2026, Alfonso Fuggetta publicó un trabajo con un título casi opuesto: Why Software Engineering Is Indispensable in the Age of Coding Agents. Fuggetta sostiene que los agentes hacen más necesarios, no menos, los métodos de ingeniería: especificaciones, arquitectura, pruebas, conocimiento del negocio y decisiones documentadas. Sin eso se produce software convincente en apariencia, pero difícil de verificar y de mantener. No sé si todas sus conclusiones aguantarán la evolución de los modelos. Su diagnóstico, en cambio, encaja bastante con lo que vivo a diario.
Cuanto más capaces son mis agentes, más falta me hace un criterio independiente para evaluar lo que hacen. Y ese criterio exige conocimiento. No hace falta saber escribir cada línea, pero sí entender el sistema, sus riesgos y lo que arrastra cada decisión. A veces tengo que recurrir a profesionales que saben mucho más que yo. Los agentes no han eliminado esa necesidad. Me han permitido llegar mucho más lejos por mi cuenta y, de paso, hacerles preguntas bastante mejores.
Producir más no es avanzar más
Hay otro cambio del que se habla menos. Cuando desarrollar software era caro y lento, funcionaba una especie de selección natural: muchas ideas no llegaban a construirse porque no había presupuesto, equipo o tiempo. Ese filtro se está debilitando. Una idea puede convertirse en prototipo en pocos días. Se pueden explorar alternativas que antes se habrían descartado y experimentar sin movilizar a nadie. Para alguien que siempre ha tenido más ideas que capacidad de ejecutarlas, es un regalo.
Con su contrapartida. También puedes construir cosas innecesarias a toda velocidad. Puedes pasar semanas puliendo una funcionalidad que nadie pidió, sacar productos que nunca encontrarán usuarios o complicar sistemas que funcionarían mejor siendo simples. Poder producir algo no dice nada sobre si merece la pena producirlo.
Eso me ha obligado a repartir el tiempo de otra manera. Con UXMachine y RosmarOps me he impuesto dedicar a darlos a conocer una atención comparable a la que dedico a construirlos. Conseguir que un agente implemente una funcionalidad es cada vez más fácil. Conseguir que alguien descubra el producto, entienda para qué sirve, confíe en él y lo use sigue siendo igual de difícil. La IA acelera la construcción. La demanda no la fabrica.
Tampoco elimina los costes. Modelos, pruebas, iteraciones, errores y supervisión consumen tiempo y dinero. Bastante más de lo que sugiere cualquier demostración en la que alguien levanta una aplicación en cinco minutos. El prototipo sale barato. El producto que funciona, se mantiene y encuentra clientes es otra historia.
Si construir se abarata, el valor se va a otra parte
Esta es probablemente la consecuencia empresarial de más calado. Durante mucho tiempo, tener tecnología propia ha sido una ventaja competitiva. Desarrollar una plataforma exigía inversión, especialistas y años, y esa dificultad era en sí misma una barrera de entrada. Si la barrera baja, cambia también el valor de lo construido.
No todo el software se va a convertir en mercancía. Hay sistemas, integraciones, datos y conocimiento acumulado muy difíciles de reproducir. Pero tener ciertas funcionalidades dejará de bastar para diferenciarse. A la pregunta de qué hace tu software se le sumará otra más incómoda: por qué alguien debería usar el tuyo. Podría construirse una alternativa, pedirle a un agente que resuelva la necesidad directamente o escoger entre diez soluciones parecidas. Las empresas de software tendrán que revisar propuestas de valor y modelos de negocio. A los emprendedores pequeños, en cambio, se les abren posibilidades impensables hace muy poco.
Yo mismo puedo experimentar con productos que antes habrían requerido un equipo y una inversión difícil de justificar. Eso no me da ninguna ventaja automática, porque cualquiera puede hacer lo mismo. Y cuando mucha gente puede construir, pesan más otras cosas: el conocimiento del problema, la relación con los clientes, los datos difíciles de replicar, la distribución y la confianza. No es casualidad que, después de construir RosmarOps en muy poco tiempo, haya dedicado buena parte del esfuerzo a resolver cómo distribuirlo de forma segura. Y a conseguir que alguien se atreva a instalarlo. Lo contaba hace poco en Cuando el código sobra, falta la confianza. La dificultad no había desaparecido. Me la encontré antes de lo que esperaba.
Decidir y escribir ya no son lo mismo
Lo que veo no es el final de la programación, sino la separación de dos actividades que han ido juntas durante mucho tiempo: decidir qué debe hacer una máquina y escribir las instrucciones para que lo haga. Saber programar era casi una condición previa para convertir una idea en un producto digital. Para una parte creciente de los proyectos está dejando de serlo.
Eso abre la puerta a gente que conoce un problema a fondo desde otro oficio. Ahora puede empezar a construir sin depender desde el primer día de un equipo de desarrollo. Y libera a los buenos ingenieros de parte del trabajo mecánico para dedicarlo a arquitectura, calidad y evolución del sistema. No significa que los dos perfiles sean intercambiables, ni que cualquiera pueda construir cualquier cosa sabiendo hablar con un modelo. Significa que la frontera de lo que cada uno puede intentar se ha movido.
Y con ella, la manera de aprender. UXMachine y RosmarOps son productos, pero sobre todo son mi forma de aprender a trabajar con IA. Buena parte de lo que sé ahora no lo habría aprendido en un manual ni en un curso. Lo he aprendido enfrentándome a problemas reales, equivocándome, discutiendo con agentes y buscando cómo comprobar lo que me decían. Cada obstáculo que antes me habría hecho abandonar se ha convertido en algo que tenía que entender. No es cómodo —hay frustración, decisiones equivocadas y muchas horas en cuestiones que parecían triviales—, pero no recuerdo otra etapa en la que haya aprendido tanto construyendo.
Quizá eso sea lo que de verdad está cambiando. No que los agentes escriban código, ni que una aplicación tarde horas en lugar de meses. Lo que cambia es que quien antes solo podía imaginar una solución ahora puede construirla, probarla y descubrir por sí mismo si tiene sentido.
Escribir código se abarata. Todo lo demás sigue costando lo mismo que antes, y algunas cosas bastante más. Lo que me llevo de estos meses no es que pueda construir casi cualquier cosa. Es que ahora me toca decidir cuáles.