Qué se puede salvar de un código generado por IA

Por qué el vibe coding funciona al principio#

Vibe coding es construir software conversando con una IA, sin base de ingeniería debajo. Al mercado le gusta tratarlo como pecado. No lo es: es la forma más barata que ha existido de descubrir si alguien quiere tu producto.

El caso que sostiene este artículo es un buen ejemplo. Una plataforma gamificada de desarrollo personal — tareas, hábitos, metas, finanzas, ranking, tienda de monedas — construida por los propios fundadores conversando con una IA, sin equipo técnico. Cuando nos llamaron, el producto tenía 1.312 usuarios activos, planes mensuales, trimestrales, semestrales y vitalicios en venta, más de 40 tablas en la base y ocho funciones de servidor. Ninguna software house entrega eso a la velocidad con que lo entregaron dos fundadores conversando con una IA.

El problema aparece después, y no donde la gente mira.

Qué se rompe cuando el producto crece#

La intuición dice que el problema del código generado por IA es la calidad del código: duplicación, archivo gigante, mal nombre de variable. Eso existe — en el caso anterior había un archivo de 800 líneas y la regla de XP repartida en cinco lugares distintos — pero es deuda técnica, no riesgo. La deuda cobra intereses; el riesgo cobra todo de golpe.

Lo que cobra todo de golpe son tres cosas, y ninguna es sobre estética:

1. La frontera: quién puede llamar a qué. En la app auditada, las ocho funciones de servidor estaban configuradas para no exigir autenticación. Entre ellas las de pago. Quien descubriera la URL podía enviar una petición simulando una compra aprobada y darse una suscripción vitalicia, acreditarse monedas ilimitadas o cancelar la suscripción de otra persona. Una de ellas permitía borrar registros históricos del sistema.

Y la misma frontera faltaba dentro de la base: las tareas, hábitos, metas y los registros diarios de sueño, ánimo y productividad de cualquier usuario podían ser leídos por cualquier otro — parte de ellos sin siquiera estar autenticado. Una tabla tenía una regla que permitía a cualquiera crear, editar y borrar registros de cualquier otro.

Nótese que ninguno de estos es un bug. El código hacía exactamente lo que se le pidió. Nadie pidió "y rechaza a quien llame desde fuera" — y la IA no pregunta.

2. La cuenta que nadie está mirando. El entorno corría en la nube gestionada de la propia herramienta de IA: la opción más cómoda, la más cara y la menos visible. Hubo cobros diarios que pasaron días sin que nadie los notara y compra de crédito por encima del consumo real. Cerca de R$ 2.000 al mes para un producto que, tras migrar a una base gestionada propia más hosting de front dedicado, pasó a costar cerca de US$ 20 al mes — ahora con backup automático, que la configuración anterior no garantizaba.

3. Qué pasa el día en que algo salga mal. Ninguna prueba automatizada, ningún monitoreo de errores, ningún entorno de homologación y ninguna documentación. Los cambios iban directo a producción, sobre usuarios que pagaban; si un pago fallaba, nadie se enteraba; y el conocimiento de cómo funcionaba la plataforma existía en un único lugar — la conversación con la IA.

No es un caso aislado. Veracode probó más de 100 modelos y midió que el 45% de las muestras de código generadas introdujeron vulnerabilidades del OWASP Top 10, con la tasa de aprobación en seguridad estancada en torno al 55% — y la conclusión más incómoda del informe es que aumentar el tamaño del modelo no mejora la seguridad. Es un problema sistémico, no una cuestión de esperar el próximo lanzamiento.

Cómo se hace la radiografía#

El orden del diagnóstico es lo que separa un informe que genera decisiones de uno que genera ansiedad. El nuestro va por consecuencia, no por gusto:

1. Lo que causa pérdida directa — pago, suscripción, crédito, saldo. Un agujero aquí es dinero saliendo hoy.
2. Lo que filtra dato personal — regla de acceso a la base, dato sensible legible por terceros, acceso sin autenticación.
3. Lo que impide crecer — regla de negocio en el cliente, ausencia de capa de servidor para integrar, límites de escala que ya se están pagando con funcionalidad recortada del producto.
4. Lo que es deuda técnica — duplicación, archivos grandes, tipado flojo, falta de pruebas. Importa. Va al final.

Cada hallazgo sale con la misma forma, y esa forma es la mitad del valor: criticidad · urgencia · qué está configurado · la evidencia en el código · el ataque que permite · cómo queda después. Hallazgo sin evidencia no entra. Y el informe también debe decir qué no hacer ahora — en el caso anterior dijimos explícitamente que la arquitectura sin servidor propio era adecuada para esa escala, y que cambiarla antes de cerrar seguridad y proceso sería gastar en el lugar equivocado.

Qué se salva, qué se mueve, qué se rehace#

La tabla se lee en una frase: lo que la IA hizo bien está arriba, y lo que hay que cambiar está debajo. Por eso la reescritura completa casi nunca se justifica — destruye la capa buena para arreglar la mala.

El detalle que solo existe en apps hechas con IA#

Este es el hallazgo que no está en ningún artículo sobre vibe coding, y es el más práctico de todos.

El stack de varias herramientas de IA instala, por defecto, un service worker — la tecnología que permite que la app funcione como aplicación instalada y abra sin red. Excelente para la experiencia. Terrible el día en que cambias de base de datos.

Cuando migramos la infraestructura, parte de los usuarios más activos siguió abriendo una versión de la app congelada en la caché de su propio dispositivo — una versión que apuntaba a la base antigua. Siguieron usando el producto y guardando datos, solo que en el lugar equivocado. Nada se perdió: los registros quedaron en la base vieja y fueron recuperados por script y fusionados en la nueva. Pero la lección es dura y específica:

Migrar la base de una app generada por IA sin tratar el service worker deja al usuario escribiendo en el lugar equivocado — y solo lo descubres cuando expira la caché del primer dispositivo.

Lo que funciona: subir la versión nueva a una dirección limpia (un subdominio que ningún navegador visitó, donde no existe caché), redirigir la dirección antigua hacia ella, y revocar la clave pública de la base antigua para que cualquier app fantasma reciba un error en vez de escribir en silencio.

Lo que no hace falta hacer#

Esta es la sección más importante, porque es donde el mercado se equivoca con más convicción.

No hace falta reescribir todo. El desenlace del caso que sostiene este artículo es el opuesto: después del diagnóstico, las correcciones y la migración, el cliente volvió a evolucionar su propio producto con la misma herramienta de IA. Lo que cambió fue lo que estaba debajo.

No hace falta cambiar de herramienta ni de arquitectura por principio. Una arquitectura sin servidor propio — front conversando directo con una base gestionada — es adecuada para muchos productos, y es lo que permite que dos fundadores lleguen a mil usuarios sin equipo. El disparador para cambiar es la escala y la necesidad de integración, no el gusto de un ingeniero.

No es la clave pública en el repositorio lo que te va a tumbar. Aquí está el error técnico más común: encontrar una clave en un archivo versionado y declarar catástrofe. La documentación de Supabase es explícita — la clave publicable es "safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code", siempre que la seguridad a nivel de fila esté activa en todas las tablas. La capa de seguridad real es la regla de acceso a la base, no el secreto de esa clave. Versionar credenciales sigue siendo mala práctica — sobrevive en el historial de Git, expone la infraestructura y facilita ataques dirigidos. Solo que no es la emergencia. La emergencia es la clave secreta, que ignora todas las reglas de acceso y nunca debe salir del servidor.

No hace falta detener el producto para arreglar la base. Estabilizar lo que está en el aire y construir la base nueva son frentes paralelos. Las correcciones entran por rama y revisión, con el producto vendiendo.

No es una auditoría de estilo. Lint, formato y duplicación no van en el tope de la lista. Si un diagnóstico llega con refactorización en la primera página y un webhook sin proteger en la décima, está vendiendo retrabajo.

Preguntas frecuentes#

¿Voy a tener que tirar lo que ya hizo la IA?#

Casi nunca. La interfaz, los flujos y el modelo de datos suelen ser el activo más valioso del producto, porque fueron validados con usuarios reales que pagan. Lo que se reemplaza está debajo: dónde corre la regla de negocio, quién puede llamar a cada endpoint, quién paga la infraestructura y si existe backup. En la app que auditamos, el producto siguió en el aire durante y después de las correcciones.

¿Puedo seguir usando la IA después de corregir la base?#

Sí, y es el desenlace más común cuando la corrección se hace bien. Después del diagnóstico y la migración, el cliente volvió a editar su propio producto con la misma herramienta de IA — la diferencia es que ahora lo hace con el código en su cuenta, con un camino definido entre la rama de trabajo y producción, y con las reglas de acceso a la base cerradas.

¿Cuánto tarda una auditoría de código generado por IA?#

Para un producto del tamaño de un MVP ya en producción, cerca de tres semanas cubren el diagnóstico y la aplicación de las correcciones críticas. El diagnóstico en sí es cuestión de días; lo que consume tiempo es corregir sin sacar el producto del aire. Un hallazgo que solo se señala y no se arregla no es diagnóstico, es presupuesto.

¿Qué accesos necesitan?#

Código, base de datos y el panel de infraestructura — los tres. Sin la base no se evalúa la regla de acceso, que es la capa de seguridad real en una arquitectura sin servidor propio; sin el panel de infraestructura no se evalúa costo, backup ni entornos. Con solo uno de los tres, el resultado es una conjetura.

¿Mi MVP hecho con IA es seguro para guardar datos de clientes?#

Asuma que no hasta que alguien lo verifique. En los productos hechos con IA que vemos, el patrón es ausencia de términos de uso y política de privacidad, dato personal legible por cualquier usuario autenticado, y ningún registro de quién accedió a qué. Eso no es una falla de código: es la ausencia de una decisión sobre quién puede ver qué — y nadie se lo pidió a la IA.

Fuentes#

• Veracode — 2025 GenAI Code Security Report — https://www.veracode.com/blog/genai-code-security-report/
• Veracode — Spring 2026 GenAI Code Security Update — https://www.veracode.com/blog/spring-2026-genai-code-security/
• Supabase — API Keys: Publishable vs Secret — https://supabase.com/docs/guides/api/api-keys

Próximo paso#

El producto de este artículo es real y sigue en el aire: lee el case de Sistema Forja, la app hecha con IA que auditamos con 1.312 usuarios activos. Si construiste con IA y quieres saber qué se rompe antes de escalar, es exactamente lo que hacemos en diagnóstico de vibe coding.