Problemas de las webs hechas con IA: los 5 límites al crecer

Una web hecha con un builder de IA funciona desde el primer día. Los problemas llegan hacia el décimo cambio: una función nueva rompe dos antiguas, una página que cargaba en un segundo ahora tarda cuatro y nadie sabe decir qué filas de la base de datos puede leer un visitante sin sesión. Son los problemas de las webs hechas con IA que aparecen cuando llegan usuarios reales, y tienen una causa común. El builder escribió cada parte del código para responder a un prompt concreto, y nadie escribió el plan que mantiene unidas las partes.

Un builder de IA es una herramienta que convierte una petición escrita en una web o una aplicación que funciona, con el código y el hosting incluidos. La categoría abarca los productos que pasan del prompt a la app y los modos de IA que ya ofrecen los creadores de webs de siempre. Para una primera versión son rápidos y a menudo bastan. Aquí hablamos de lo que viene después: los cinco límites que frenan el crecimiento de una web hecha con IA, lo que cuesta cada uno y cómo recuperar una web que ya se ha topado con ellos.

¿Cómo se nota que una web hecha con IA ya no aguanta el crecimiento?

Las señales se reconocen fácilmente cuando sabes buscarlas:

• Cada prompt arregla una cosa y rompe otra, y cada cambio tarda más que el anterior.
• La misma lógica aparece en tres o cuatro archivos, cada vez un poco distinta.
• Las páginas salen en Google pero nunca en las respuestas de ChatGPT o de Claude.
• Nadie en el equipo sabe decir quién puede leer cada tabla.
• El código está en los servidores del builder, e irse supondría empezar de cero.

Una de estas señales es un bug. Tres a la vez indican que la web ha llegado al tamaño en el que los prompts ya no bastan.

¿Por qué una web hecha con IA deja de crecer?

Un prompt es una petición local. El modelo lee una parte del proyecto, escribe el cambio más corto que cumple la petición y sigue adelante. Le sale más barato añadir un bloque nuevo que reordenar tres antiguos, así que el código crece por acumulación. El refactoring, es decir, mover el código para poder reutilizarlo, necesita a alguien que conozca todo el sistema y quiera mantenerlo pequeño.

La tendencia se puede medir incluso cuando un desarrollador revisa el trabajo. El estudio de 2025 de GitClear sobre 211 millones de líneas modificadas detectó que en 2024, por primera vez, se copió y pegó más código del que se movió, y que los bloques de cinco o más líneas duplicadas se multiplicaron por ocho en un año. Son datos de equipos que usan asistentes de IA con ingenieros que revisan el resultado. En un builder que solo funciona con prompts, ese trabajo de mover el código no lo hace nadie.

Los 5 límites que frenan una web hecha con IA

1. Código que crece copiándose

La lógica duplicada funciona hasta que hay que cambiarla. Una regla de precios escrita en cuatro sitios se actualiza en tres, y el cuarto sigue cobrando el precio antiguo. Cada función nueva deja más sitio a estas diferencias, así que el coste de un cambio crece con el tamaño del código y no con el tamaño del cambio. Es el primer límite con el que se encuentra una web que crece, y el que hace más lentos todos los arreglos posteriores.

2. Ajustes de seguridad que nadie revisó

Una app generada que guarda datos de usuarios necesita reglas de acceso en cada tabla. Si faltan, basta con la clave pública que llega a cada navegador para leer los datos. Es lo que describe la CVE-2025-48757: una política de Row Level Security insuficiente en las webs generadas por uno de los builders de IA más usados permitía, hasta el 15 de abril de 2025, que cualquiera sin autenticarse leyera o escribiera tablas arbitrarias. El NVD le da un 9,3, nivel crítico, y recoge que el proveedor la discute. Los investigadores encontraron más de 170 apps expuestas, con nombres, direcciones, importes de deudas y claves de API entre los datos.

El problema va más allá de una plataforma. El GenAI Code Security Report 2025 de Veracode dio 80 tareas de programación a más de 100 modelos de lenguaje: en el 45% de los casos el código incluía una vulnerabilidad del OWASP Top 10, y el cross-site scripting quedaba abierto en el 86% de las tareas donde entraba en juego. Una web puede pasar todas las pruebas manuales y aun así dejar la base de datos a cualquiera que abra la consola del navegador. Las reglas de acceso son trabajo de diseño; lo contamos en el artículo sobre Supabase Row Level Security a escala.

3. Páginas que los buscadores y los crawlers de IA no leen

Muchas webs hechas con IA se pintan en el navegador: el servidor envía un HTML casi vacío y JavaScript lo rellena. Google puede ejecutar JavaScript, pero pone las páginas en cola para renderizarlas, un paso más después del rastreo. Los crawlers de IA, en general, no. Un estudio de Vercel y MERJ comprobó que ninguno de los principales crawlers de IA ejecuta JavaScript, entre ellos GPTBot y OAI-SearchBot de OpenAI, ClaudeBot de Anthropic y PerplexityBot. Una página que solo existe después de ejecutar JavaScript, para esos motores, no existe.

Los builders se están adaptando. El más usado genera las apps nuevas con renderizado en servidor desde el 13 de mayo de 2026 y sirve copias prerrenderizadas de las apps antiguas a los crawlers verificados. Los proyectos creados antes de esa fecha, y las webs de los builders que no han cambiado, se siguen pintando en el navegador. Comprobarlo lleva un minuto: pide la página con curl y mira si el texto que ve un lector está en el HTML que devuelve. El resto está en la guía sobre cómo hacer que tu web salga en Google y en las respuestas de IA.

4. Un stack que no eliges y un código que vive en la plataforma de otro

El builder elige el framework, la base de datos y el hosting, y se los queda. La documentación de uno de ellos responde "No" a la pregunta "¿Puedo elegir otro framework, como Next.js?", y su sincronización con Git crea un repositorio nuevo en lugar de conectar uno existente. Para el builder es una decisión de producto razonable. Para una empresa significa que la arquitectura la decide la hoja de ruta de un proveedor, y que cada límite de ese stack se convierte en un límite del negocio.

La plataforma guarda además el código, los prompts y las credenciales. En abril de 2026 un investigador hizo público que la API del mismo builder permitía a cualquier usuario registrado leer el código fuente, las credenciales de la base de datos y el historial de chats con la IA de los proyectos públicos de otros usuarios. Después, el builder eliminó la visibilidad pública de los proyectos. Una empresa con el código en su propio repositorio y los secretos en su propio gestor habría tenido menos que perder.

5. Un agente con las llaves de producción

Los builders que ponen a un agente a trabajar sobre una base de datos en vivo le dan poder para cambiar datos reales. En julio de 2025, durante un experimento público de 12 días, un agente de IA en un builder alojado ejecutó comandos destructivos contra la base de datos de producción durante una congelación de cambios declarada y borró los registros de más de 1.200 directivos y 1.190 empresas. El agente dijo al principio que no se podía recuperar; los datos se recuperaron a mano. La solución es ingeniería de siempre: bases de datos separadas para desarrollo y producción, copias de seguridad con una restauración probada y ningún acceso de escritura a producción para lo que nadie ha revisado.

¿Cuánto le cuestan estos límites a una empresa?

Los costes llegan en monedas distintas. El código duplicado cuesta tiempo: cada cambio toca más archivos y cada versión corre más riesgo de romper algo que funcionaba. Las reglas de acceso que faltan cuestan dinero y confianza: con el RGPD, una brecha de datos personales hay que notificarla a la autoridad de control en un plazo de 72 horas desde que se tiene constancia de ella. Pintar en el navegador cuesta alcance: las páginas que los motores de IA no leen nunca aparecen citadas en sus respuestas. El lock-in cuesta margen de maniobra: cuando el stack deja de encajar, la única salida es rehacerlo todo.

Ninguno de estos costes aparece en la factura del builder, y por eso la primera versión parece más barata de lo que es. Los problemas de velocidad siguen el mismo patrón, como explicamos en por qué una web va lenta, y también el desgaste lento que describimos en el deterioro post-lanzamiento.

¿Cómo se arregla una web hecha con IA que ya ha chocado contra el muro?

El orden importa. Primero los datos, luego la visibilidad, luego la estructura.

1. Lleva el código a un repositorio que controles. Expórtalo, ejecútalo una vez fuera del builder y apunta cada secreto que necesita. Si fuera de la plataforma no arranca, ese es el primer hallazgo.
2. Revisa el acceso a los datos. Haz la lista de todas las tablas, comprueba que la Row Level Security está activada, lee cada política e intenta leer y escribir con la clave pública como usuario sin sesión. Cambia cualquier clave que haya aparecido alguna vez en el código del cliente.
3. Comprueba qué reciben los crawlers. Pide las páginas principales sin JavaScript. Si falta el contenido, pasa esas páginas a renderizado en servidor o a generación estática; la zona privada puede quedarse como está.
4. Localiza las duplicaciones. Busca las reglas de negocio escritas en más de un sitio, como precios, permisos y validaciones. Escribe pruebas que las cubran y después junta cada una en un solo módulo.
5. Quítale la producción al agente. Crea una base de datos de desarrollo aparte, programa las copias de seguridad, prueba una restauración y haz que cada cambio pase por una revisión antes de llegar a producción.

Después de estos cinco pasos, la pregunta honesta es si arreglar o rehacer. Si el modelo de datos está sano y las duplicaciones se concentran en pocos módulos, arreglar es el camino más rápido. Si cada función depende de lógica copiada y en el modelo de datos no está claro quién es dueño de qué, rehacer el núcleo sobre un stack que elijas tú cuesta menos que ir poniendo parches un año más.

¿Cómo evitar que la próxima web hecha con IA se atasque?

Usa el builder para lo que hace bien: prototipos, landing pages, herramientas internas sin datos sensibles y la primera versión de una idea que quieres probar con usuarios reales. Decide tú el modelo de datos y las reglas de acceso antes del primer prompt, porque son lo más difícil de cambiar después. Guarda el código en tu propio repositorio desde el primer día. Y deja la arquitectura en manos de una persona: alguien que lea cada cambio que toque la autenticación, los datos o los pagos, y que pueda decir que una función espera hasta que la estructura esté lista para sostenerla.

Un builder de IA lleva rápido a la primera versión. Ir más allá exige el mismo trabajo de ingeniería de siempre, hecho sobre un código que creció más deprisa de lo que nadie había previsto.