Escribir software siempre fue la parte barata. La IA abarató justamente esa parte y dejó intacta la parte cara. Qué le sucede a una aplicación generada durante su primer año en producción, y cómo calcular de antemano quién carga con ella.
Hay una frase que hoy escucha casi todo dueño de una pequeña empresa: «Eso hoy se lo escribe la IA en una tarde». Y es verdad. Lo que esa frase calla es lo que viene después.
Escribir software nunca fue la parte cara. Lo caro es el mantenimiento: todos esos años en los que cambian las leyes, los procesos, las personas, y ya nadie recuerda exactamente por qué el código está escrito de esa manera. La IA abarató el primer día. Los mil días restantes los dejó donde estaban.
Un año en la vida de una aplicación generada
Imagine un registro de encargos que la IA le genera en primavera. Funciona. Sus compañeros lo usan. Y luego pasa el tiempo.
Día 1. En marcha. Todos encantados, porque tardó dos días en lugar de dos meses.
Mes 2. Cambia el tipo de IVA de una partida. En la aplicación está escrito a fuego en el código. Alguien tiene que encontrarlo y cambiarlo. Ese alguien es usted, su sobrino o una persona a la que paga para ello.
Mes 6. Se incorpora una nueva compañera a administración. Necesita ver solo sus propios encargos. En la aplicación no existe nada de eso, porque en el prompt original no se hablaba de roles. Añadir permisos no es «un prompt más»: es un cambio que tiene que reflejarse en todas las pantallas.
Mes 12. Algo deja de funcionar. Quien generó la aplicación ya no está en la empresa, o no recuerda qué contiene. Sabe leer el código, pero no lo entiende: lo generó una máquina y nadie lo revisó a fondo.
Escribir la aplicación es la parte barata
El día 1 los dos caminos se parecen. La diferencia aparece en el mes dos, seis y doce, y a partir de ahí no hace más que crecer.
Por qué ocurre casi siempre
No es que la IA escriba mal código. El código suele ser sorprendentemente decente. El problema está en otra parte y tiene tres capas.
Nadie conoce ese código. En una aplicación escrita de forma clásica existe al menos una persona que sabe por qué algo está hecho de determinada manera. En una aplicación generada, esa persona no existe: solo hay un prompt y un resultado.
El mantenimiento no se ve por adelantado. Cuando encarga la aplicación a una agencia, los costes de mantenimiento están en el presupuesto. Cuando la genera usted mismo, no están en ninguna parte, lo que no significa que no existan.
Los cambios no llegan de uno en uno. Una empresa cambia continuamente: un nuevo tipo de encargo, una nueva tarifa, un nuevo compañero, una nueva petición de un cliente. Cada uno de esos cambios es pequeño. Veinte cambios pequeños al año son un mes de trabajo.
Tres preguntas que plantearse antes de empezar
Antes de decidirse a construir algo importante sobre código generado, tienen sentido tres preguntas concretas:
- ¿Quién en la empresa leerá ese código cuando algo se rompa? Si la respuesta es «nadie», no tiene una aplicación, tiene una obligación.
- ¿Cuántos cambios esperamos al año y quién los hará? Anótelos. La mayoría de las empresas llegan a entre ocho y veinte detalles al año, y eso ya es un trabajo constante.
- ¿Qué pasa si esa persona se va? Con código propio, ese riesgo lo asume usted. Con una plataforma, ese riesgo lo asume el proveedor.
No se trata de no usar la IA
Hoy la IA es una forma razonable de diseñar una aplicación, describirla y hacer que se construya. La diferencia está en si el resultado es código fuente que usted tiene que vigilar, o una aplicación que funciona sobre una plataforma que asume el mantenimiento, las copias de seguridad y las actualizaciones.
Qué significa que «la plataforma se ocupa de eso por usted»
Concretamente esto: las actualizaciones, las copias de seguridad, los parches de seguridad y la compatibilidad no son su preocupación. Cuando cambia una regla, usted cambia un campo o una automatización, y eso lo puede hacer una persona no técnica del equipo. Cuando se va quien construyó el sistema, queda una configuración legible, no un código que nadie entiende.
No significa que una plataforma resuelva absolutamente todo. Para lógica realmente única existen vías de escape mediante webhooks y API. La diferencia está en la proporción: en lugar de ser propia toda la aplicación, es propia solo esa única excepción.
Encontrará una mirada práctica a cómo es una automatización a la que se le puede ver por dentro en el artículo Automatización sin caja negra. Y si está valorando generadores de IA concretos, la comparación está en el texto Lovable, Bolt, v0 y compañía. Encontrará una visión general de todo el tema en la guía completa de no-code y desarrollo con IA.
Preguntas frecuentes sobre el mantenimiento de aplicaciones de IA
¿No puede la propia IA reparar la aplicación?
En parte sí, pero se topa con dos cosas. La IA necesita saber exactamente qué está mal, y eso tiene que reconocerlo alguien. Y la segunda reparación se hace sobre el código surgido de la primera, así que con cada ronda crece el riesgo de que se rompa alguna otra cosa.
¿Cuánto cuesta realmente el mantenimiento?
Depende de con qué frecuencia cambie su proceso. Una referencia práctica de aplicaciones de empresa habituales: cuente con diez a veinte cambios pequeños al año. Cuando los resuelve una persona externa, es una partida recurrente del presupuesto, no un coste puntual.
¿Cómo lo controlo si encargo que me hagan la aplicación?
Pregunte de antemano tres cosas: quién hará los cambios, cuánto cuesta la hora de trabajo y dónde se almacenarán los datos. Si el proveedor no tiene respuesta a la última pregunta, es una señal de que nadie se ocupa del mantenimiento.