# Hiciste tu app con IA y ahora nadie sabe arreglarla > Montar un producto pidiéndoselo a una IA funciona sorprendentemente bien hasta que deja de funcionar. Por qué pasa, cómo saber si tu caso tiene arreglo y qué se hace para salir del bloqueo. URL: https://skyquetz.com/blog/app-hecha-con-ia-que-nadie-sabe-mantener Autor: Santiago Gómez de la Torre Publicado: 2026-09-23 --- La historia se repite con una regularidad que ya asusta. Alguien con una idea clara y sin equipo técnico se pone a construirla pidiéndosela a una IA. En dos semanas tiene algo que funciona. En dos meses tiene clientes. En seis meses tiene un problema que no sabe describir. El síntoma siempre es el mismo. Cada cambio nuevo rompe algo viejo. Se arregla lo roto y se rompe otra cosa. Nadie es capaz de explicar por qué, porque nadie entiende del todo cómo está hecho lo que hay debajo. ## Qué está pasando por dentro Los números de 2026 describen bien el fenómeno. El 81% de los responsables técnicos de empresa reporta más incidencias en producción ligadas a código generado con IA. Dos tercios de los desarrolladores dicen que ese código necesita correcciones importantes antes de poder usarse de verdad. Y un análisis comparativo encontró en el código coescrito con IA alrededor de 1,7 veces más problemas graves, con las vulnerabilidades de seguridad casi triplicándose. La causa no es que la IA escriba mal. Escribe sorprendentemente bien línea a línea. El problema es de otro nivel. Un asistente resuelve el trozo que le pides. Lo resuelve rápido y suele funcionar. Lo que no hace, salvo que alguien se lo exija con criterio, es sostener una idea coherente de cómo encaja ese trozo con los cuarenta anteriores. Así que cada petición añade una solución razonable en aislamiento, y al cabo de trescientas peticiones tienes trescientas decisiones razonables que juntas no forman ninguna estructura. Eso tiene nombre desde mucho antes de la IA. Deuda técnica. Lo nuevo es la velocidad a la que se acumula. Antes hacían falta tres años y un equipo para llegar a este punto. Ahora se llega solo y en un trimestre. ## La parte que de verdad duele Si fuera solo código desordenado sería llevadero. Se reordena. Lo caro es otra cosa. Cuando nadie del negocio entiende cómo funciona su propio producto, el negocio pierde la capacidad de decidir. No puedes valorar si una función nueva es fácil o difícil. No puedes saber si un fallo es grave. No puedes contratar a alguien y explicarle el sistema, porque no hay nada que explicar salvo el propio código. Y no puedes estimar nada, así que cualquier compromiso con un cliente es una apuesta. Hay además un riesgo silencioso. Las vulnerabilidades. Un prototipo que empezó siendo una demo para enseñar a dos amigos acaba con datos reales de clientes dentro sin que nadie haya revisado nunca quién puede leer qué. Se han documentado miles de aplicaciones construidas así exponiendo datos de empresa sin que sus dueños lo supieran. ## Cómo saber en qué punto estás Tres preguntas, y conviene contestarlas con honestidad. **¿Puedes explicar, en cinco minutos y sin abrir el código, dónde se guardan los datos de tus clientes y quién puede acceder a ellos?** Si no, ahí hay un asunto de seguridad antes que de calidad. **¿Cuánto tardas en publicar un cambio pequeño y cuántas veces se rompió algo en los últimos tres intentos?** Si la respuesta es "depende" y "casi siempre", el sistema ya te está frenando más de lo que te ayuda. **¿Existe alguna prueba automática?** No hace falta que sean muchas. Si no hay ninguna, cada cambio se verifica a ojo, y verificar a ojo un sistema que nadie entiende es lo que produce el bucle de romper y arreglar. ## Qué se hace, y lo que casi nunca se hace Lo primero que hay que descartar es la reacción instintiva de tirarlo todo y reescribir desde cero. Suele ser mala idea. Ese código feo contiene meses de aprendizaje real sobre tu negocio, decisiones que tomaste porque un cliente se quejó, casos raros que descubriste por las malas. Reescribir de cero tira eso a la basura y te garantiza redescubrirlo todo otra vez. Lo que funciona se parece más a esto. **Poner una red antes de tocar nada.** Pruebas automáticas sobre los cuatro o cinco caminos que no pueden fallar. Registrarse, pagar, lo que sea que da dinero. Con eso ya puedes cambiar cosas sin miedo, que es la diferencia entre avanzar y no avanzar. **Cerrar los agujeros de seguridad primero.** Accesos, permisos, claves metidas en el código, datos personales sin proteger. Esto va antes que cualquier mejora, porque es lo único con consecuencias legales. **Entender y documentar el corazón.** No el sistema entero. La parte que sostiene tu negocio. Que exista un documento de dos páginas que explique cómo funciona ya cambia la situación por completo. **Reordenar por trozos, empezando por donde más duele.** La zona que rompes cada semana es la que hay que arreglar primero, y es también donde el arreglo se nota antes. ## Que conste que la herramienta no es el problema Nosotros usamos asistentes de IA a diario y son extraordinariamente útiles. La diferencia no está en usarlos o no. Está en si hay alguien que sabe qué está pidiendo, que revisa lo que llega y que mantiene una idea de conjunto que la herramienta no puede tener. Usar IA para construir rápido un prototipo y validar una idea es una decisión excelente. El error es dejar que ese prototipo se convierta en el producto por inercia, sin que nadie decida en qué momento pasa de experimento a cosa seria. Si estás en ese punto, lo primero es un diagnóstico honesto de qué hay, no un presupuesto de reescritura. Es la misma lógica que defendemos con las webs en [audita antes de rehacer](/blog/auditar-seo-y-geo-antes-de-rehacer-tu-web). Y si lo que necesitas es que alguien se haga cargo del sistema y lo lleve a un estado mantenible, eso es [nuestro servicio de mantenimiento y soporte](/servicios/mantenimiento).