¿Se ha abaratado el desarrollo? ¿Se ha trasladado el coste? ¿Como estamos decidiendo que se construye? Cuando poner algo en produccion nunca resulto mas facil.
Hace tiempo, cuando alguien de negocio pedía una aplicación/programa/cosa, la conversación empezaba con un dolor, a veces un presupuesto y un plazo que, podia echar para atrás el proyecto. Después de muchos meses de análisis, muchas horas, un par de programadores, pruebas, algún que otro retraso (lo de siempre) y, con suerte, algo en producción antes de que la necesidad hubiera cambiado, o que el negocio hubiese evolucionado.
Ahora esa charla acaba muchas veces con un prototipo funcionando en 2 dias o un fin de semana aburrido, montado con un agente de IA por alguien que no ha escrito una línea de código en su vida. Y sin el criterio de tecnologia de por medio, lo cual hace intuir a negocio que esto se hace en 2 tardes.
No exagero mucho. Cualquiera que esté usando agentes para programar a nivel profesional sabe que el coste de producir código se ha desplomado, yo estoy haciedo cosas que no hacia por pereza, es ridiculamente fácil. Antes se medía en meses ahora se mide en semanas (y a veces en días) es una locura. Todos sabemos que hacer software no es solo poner en marcha el MVP, bueno, casi todos.
Mi punto en este artículo es sencillo, desagradable probablemente para los venden la IA como una máquina de ahorrar. Si escribir código ya no es caro o costoso, el gasto se traslada seguro a otro sitio. Se tiene que decidir qué merece la pena construir, a mantener lo construido durante años y a responder por ello cuando algo se rompe, y ninguna de esas cosas la abarata un modelo, al menos de momento.
Además ¿Donde encaja cada producto? Antes en los 7, 8 o 9 meses de construcción daba tiempo a atar todo, conectarlo con coherencia. La facilidad de poner cosas en marcha enreda los ecosistemas de una manera diabólica y sobre todo cara.
No voy a intentar responder a la realidad de las maquetas de IA de cada uno de los departamentos, esto da para dos o tres artículos mas.
Lo caro nunca fue teclear
En 1986 un tal Fred Brooks publicó No Silver Bullet, un ensayo que os recomiendo, se lee fácil hasta para milenios como yo, con un ingles de los primeros años de la ESO.
Brooks separaba las dificultades del software en dos tipos:
- Por un lado las accidentales, que son las que nos ponemos nosotros mismos con las herramientas, los lenguajes y los procesos.
- y por otro las esenciales, que vienen de la propia naturaleza de un problema. Defendía que lo más difícil de construir software era decidir exactamente qué coj*** debemos construir.
Después e 40 años de evolución, la IA en el desarrollo de software está haciendo justo lo que Brooks pensaba que se podía hacer, atacar la parte accidental. Escribir el código, buscar la sintaxis, montar el esqueleto de un proyecto, hacer las pruebas repetitivas o documentar se está abaratando brutalmente, una buena metodologia con agentes hace trivial escribir código bien estructurado. Pero la segunda parte sigue ahí, intacta, porque alguien tiene que entender el negocio, saber qué problema se quiere resolver y, sobre todo, qué problema NO hay que resolver.
Esto lo he visto muchas veces, mucho antes de que existiera ChatGPT, en proyectos que se iban a la porra con un código impecable ¿porque?, estos resolvían con mucha elegancia un problema que nadie tenía.
La IA no arregla eso seguro, estoy totalmente convencido que lo empeora mucho, por lo menos de momento, porque ahora se puede construir lo equivocado mucho más rápido y encima con mucha más confianza.
Cuando el cuello de botella era escribir código, ese cuello de botella hacía de filtro (mal filto, pero filtro). Las ideas regulares se morían en la cola de tecnología, esperando a que hubiera recursos, o la politica desatascase tu propuesta, y los que lleváis años en esto sabéis que , a mí por lo menos, me ha evitado meterme en muchas barbaridades descabelladas.
Ahora la cola, sobre todo el primer prototipo de servilleta, no existe prácticamente, y cualquier idea que se le ocurra a alguien puede convertirse en una maqueta antes de que nadie se pregunte si debería existir. Cuando negocio ve los fuegos artificiales, intentan encajarlo en problemas que probablemente no existan, o no sean los mas importantes con el argumento de «sí, esto es lo que yo necesito«
Ese tal Jevons también tenía razón con el software
En 1865 un economista (William Stanley Jevons) se dio cuenta de algo que parecía un contrasentido, si lo piensas de primeras no te encaja. Las máquinas de vapor eran más eficientes que las anteriores y, en vez de bajar (lo todos esperarían), el consumo de carbón en Gran Bretaña se disparó, sorpresa, porque al abaratar su uso de repente salía a cuenta usarlo para muchas más cosas.
Es lo que se conoce como la paradoja de Jevons, y vamos de cabeza a vivirla con la IA en el desarrollo de software, sin frenos, abróchense los cinturones señores y señoras.
Si fabricar una aplicación cuesta la décima parte, lo previsible es que acabemos fabricando diez veces más aplicaciones (o veinte) y que el gasto total en software suba en lugar de bajar. Lo que nunca sale en las demos es lo que viene después, porque cada una de esas aplicaciones hay que mantenerla mientras viva.
Cualquiera que haya pasado un tiempo en sistemas sabe que el código no envejece bien por sí solo. Las librerías se quedan obsoletas, salen vulnerabilidades, cambian las APIs de las que depende, el sistema operativo deja de tener soporte y un largo etcétera (y esto era en la epoca pre-IA). Se suele decir que el mantenimiento se come la mayor parte del coste de un software a lo largo de su vida, y aunque las cifras bailan según quién las cuente, o que intereses defiendas, no conozco a nadie serio que defienda que lo caro es la primera versión el MVP.
El mantenimiento también se abarata si, pero añade complejidad operativa, se necesita producción muy madura de software para que no se nos haga bola, madurez que, muy a mi pesar, pocas veces existe.
Por eso me gusta pensar en el código como un pasivo más que como un activo. Lo que tiene valor es lo que hace por el negocio, mientras que el código en sí es una deuda que se va pagando cada mes en parches, actualizaciones y horas de alguien que sabe cómo funciona. Si ahora fabricamos diez veces más código, estamos firmando diez veces más deuda, aunque la entrada nos haya salido casi gratis.
El Excel con macros, versión 2026
Hace unos años escribí aquí sobre el alineamiento estratégico y hablaba de las empresas que gestionaban miles de hojas de Excel de manera caótica entre otras cosillas. Pues bien, preparaos, porque lo que viene es eso mismo pero en torrente de HTML’s, presentaciones, artefactos y muchos «localhost:3232». Hojas de calculo con esteroides.
Todos hemos conocido esa hoja de cálculo crítica que hizo alguien hace diez años, llena de macros, de la que depende medio departamento y que nadie se atreve a tocar (si alguna vez habéis heredado una, sabéis de lo que hablo). El software de andar por casa hecho con IA es eso mismo, pero con base de datos, con usuarios, con permisos y, en el peor de los casos, publicado en internet.
A quien le toque la seguridad de una empresa, esto le va a quitar más el sueño que cualquier amenaza sofisticada. Cada aplicación que alguien levanta en una tarde es una aplicación más que inventariar, parchear, vigilar y auditar. Lo normal es que nadie lo haga, porque quien la construyó solo quería resolver su problema del día, y del ciclo de vida del software ni sabe ni tiene por qué saber. Nos llenamos de Shadow DEV.
Comprar también era comprar a quién llamar
Con todo esto, el eterno debate entre comprar o fabricar se está moviendo. Durante años la cuenta salía casi siempre a favor de comprar, porque desarrollar a medida era caro, lento y arriesgado. Antonio Ortiz comentaba hace poco en Error500 que ese cálculo está cambiando, y no son pocos los que ya miran sus suscripciones pensando que eso lo montan ellos en dos tardes.
Tienen parte de razón, y confieso que a mí también me tienta. Pero creo que en esa cuenta se suele olvidar algo. Cuando comprabas un software el código era lo de menos, lo que pagabas de verdad era a alguien que lo mantenía, que lo parcheaba cuando salía una vulnerabilidad, que respondía ante el auditor y que cogía el teléfono a las tres de la mañana cuando se caía (o que al menos tenía un contrato que decía que lo cogería). Vamos, que comprabas a quién llamar.
Cuando fabricas tú, todo eso pasa a ser tuyo, y la responsabilidad no se abarata con la IA. Con NIS2 o el reglamento europeo de IA encima de la mesa, responder por lo que pones en producción pesa cada vez más.
Tampoco digo que haya que volver a comprarlo todo, ni mucho menos. Creo que la habilidad que más va a valer en los próximos años es distinguir entre el software de usar y tirar y el software que tiene que durar. Hay muchísimos problemas que se resuelven con un script o una pequeña aplicación que se usa dos semanas y se tira, y para eso la IA es una maravilla (no necesitan mantenimiento porque no van a vivir lo suficiente para necesitarlo).
El problema llega cuando lo de usar y tirar no se tira, empieza a usarlo medio departamento y un buen día descubres que el cierre del mes depende de ello.
Qué cambia con la IA en el desarrollo de software
Si lo caro deja de ser escribir código, los equipos van a tener que cambiar. Os lanzo tres ideas, sabiendo que dentro de un año igual me toca tragármelas.
La primera es que el cuello de botella se muda a la revisión. Leer código siempre ha sido más difícil que escribirlo, y ahora vamos a tener muchísimo más código que leer, escrito por alguien (o algo) que no se cansa nunca. Un equipo que genera el triple de código con la misma gente revisando es un equipo que acumula riesgo sin darse cuenta. La IA también revisa si, también prueba sí, ¿Esto es suficiente?, no sabría responder.
La segunda es que van a valer más los perfiles que saben decir que no. Gente que entiende el negocio, que conoce la arquitectura y los sistemas que ya existen, y que es capaz de mirar una petición y decir que eso ya lo tenemos o que dentro de dos años nos va a dar problemas.
Y la tercera es que cada cosa que se construya tiene que tener dueño desde el primer día, alguien con nombre y apellidos que responde por ello, que lo conoce por dentro y que decide cuándo toca jubilarlo.
Los presupuestos también cambian
Con los presupuestos pasa algo parecido. Siempre hemos presupuestado el software como proyectos, con un coste de construcción grande al principio y un mantenimiento estimado a ojo (y casi siempre a la baja).
Si inundamos una arquitectura empresarial de software, estamos añadiendo una complejidad que no se puede medir en un presupuesto de un proyecto, es muy difícil explicar esto, la gente suele simplificar en su cabeza el software y su interacción para poder entender como encajan las «cajitas» que vamos poniendo. En 2 años podemos tener un ovillo de lana terriblemente acoplado muy difícil de desenredar.
Mi recomendación, si os sirve de algo, es que cada vez que alguien presente lo barato que ha salido construir algo, se le pregunte también cuánto va a costar tenerlo funcionando cinco años, donde encaja y como de acoplado esta dentro del ovillo. Estas cifras casi nunca aparece en la presentación, y es la que acaba pagando alguien, y en el peor de los casos el negocio.
Volver a decidir
Tengo la sospecha de que la IA en el desarrollo de software nos va a obligar a recuperar una disciplina que muchas empresas perdieron hace tiempo, la de decidir. Cuando hacer cosas era caro, el propio coste decidía por nosotros y muchas ideas se morían solas en una cola. Ahora esa excusa ha desaparecido y podemos construirlo casi todo, así que la pregunta vuelve a ser la misma que Brooks dejó escrita hace cuarenta años, la de qué merece la pena construir.
Así que la próxima vez que alguien os enseñe la aplicación que ha montado en una tarde, felicitadle (de verdad, es una pasada lo que se puede hacer ya). Eso sí, después preguntadle quién la va a mantener cuando se vaya de vacaciones.
