Code review con IA: ¿la IA puede revisar tu app construida con IA?

El code review con IA es útil para una app construida con IA, pero no basta por sí solo. Es bueno para detectar bugs obvios, patrones inseguros y código desordenado. Es débil justo en lo que más les duele a los fundadores: quién puede leer qué datos, qué claves están en el navegador y si un pago realmente se completó.

Soy un ingeniero brasileño que ha hecho muchos code reviews humanos, y yo mismo uso revisores de IA. Mi regla práctica: deja que la IA haga la primera pasada y luego pide a una persona que revise los pocos flujos donde un error cuesta dinero o filtra datos.

¿Qué detecta bien el code review con IA?

Donde un patrón es común y está bien documentado, los revisores de IA funcionan bien. Leen un archivo entero en segundos y no se cansan. En mi experiencia son fuertes en:

• Legibilidad y estructura: lógica duplicada, componentes gigantes, nombres poco claros, código muerto.
• Patrones comunes de bugs: falta de manejo de errores, promises sin await, acceso a null, errores off-by-one.
• Fragmentos inseguros conocidos: SQL armado con strings, renderizado de HTML sin sanitizar, secretos obviamente escritos a mano en un archivo.
• Tests y tipos faltantes: sugerir dónde ayudaría un test o un tipo de TypeScript más estricto.
• Higiene de dependencias: señalar paquetes desactualizados o sin uso.

Esto es valor real. En un equipo, con gusto haría que cada pull request pasara por una revisión automática antes de que una persona lo abra. Le ahorra al revisor tiempo para las preguntas que solo una persona puede responder.

Dónde funciona mejor

Funciona mejor en cambios pequeños y autocontenidos, con contexto claro. Cuanto más del panorama puede ver, mejor es. Dale una función y revisa una función. No puede decirte que esa función se llama desde una pantalla a la que puede llegar el usuario equivocado.

¿Qué pasa por alto en apps generadas por IA?

Los fallos no son aleatorios. Se concentran en lugares donde el código se ve correcto pero las reglas están mal. El código puede pasar todas las revisiones de estilo y aun así dejar que cualquier usuario con sesión iniciada lea los registros de todos.

Reglas de acceso a datos

Las apps construidas con Lovable han mostrado un patrón de reglas débiles de row level security (RLS) en Supabase. Un revisor que lee el frontend ve una query que funciona. No sabe si la policy de la base de datos detrás de ella permite solo las filas del dueño o todas las filas. Tienes que mirar las policies en sí y probarlas con dos usuarios distintos.

Claves en el navegador

Algunas claves están pensadas para ser públicas, como la anon key de Supabase, siempre que la RLS sea correcta. Otras, como la clave secreta de Stripe o una service role key, nunca deben llegar al navegador. Un revisor de IA puede no saber cuál es cuál en tu configuración, o puede tratar una clave filtrada como una nota menor.

Flujos de pago y lógica de negocio

Los escáneres genéricos y los revisores de IA pasan por alto la lógica de negocio, como los webhooks de Stripe y los pedidos duplicados. Preguntas como estas necesitan a alguien que entienda el flujo:

• ¿El acceso se otorga cuando el usuario vuelve a una página de éxito, o solo después de un webhook verificado?
• ¿Se verifica la firma del webhook?
• ¿Qué pasa si el mismo evento llega dos veces?
• ¿Un usuario puede cambiar un precio o una cantidad en la solicitud?

Ninguno de estos es un problema de sintaxis. Son preguntas sobre la intención, y el modelo no conoce tu intención a menos que la escribas.

¿Por qué no basta con pedirle al constructor que revise su propio código?

Es tentador escribir “revisa esta app en busca de problemas de seguridad” en la misma herramienta que la construyó. Es gratis y rápido, y a veces encuentra algo real. Pero tiene límites.

Las reglas de datos, las claves y los flujos de pago son justo lo que estas herramientas suelen hacer mal. Cuando el mismo modelo revisa su propio resultado, a menudo comparte los mismos puntos ciegos y las mismas suposiciones. También puede “corregir” un problema cambiando el código de una forma que rompe otra cosa, porque no tiene a la vista todo tu sistema.

También hay una cuestión de responsabilidad. La plataforma protege su propia infraestructura y sus cuentas. El dueño de la app es responsable de quién puede leer qué datos, de las claves en el navegador, de la confirmación de pagos y de los backups. Una respuesta en el chat del constructor no transfiere esa responsabilidad. Igual tienes que verificar.

No lo digo para desacreditar las herramientas. Un ejemplo documentado: en julio de 2025, investigadores de Wiz descubrieron que Base44, de Wix, permitía que un atacante se registrara en apps que debían ser privadas usando solo el ID de la app, y se corrigió en un día. Fue un problema de la plataforma, no del dueño de la app. Las reglas de tu propia app son una capa aparte, y nadie más las va a revisar por ti.

¿Cómo combino el code review con IA con una revisión humana?

Usa cada uno para lo que hace mejor. Este es el orden que yo seguiría:

1. Ejecuta un revisor de IA para la primera pasada. Si puedes, usa una herramienta distinta de la que escribió el código. Reúne los hallazgos y no los apliques a ciegas.
2. Ejecuta un escáner o una revisión de dependencias. Es barato y detecta problemas conocidos. Trata un resultado limpio como un dato más, no como un veredicto.
3. Escribe tus reglas en lenguaje sencillo. Por ejemplo: un usuario solo puede ver sus propios pedidos; un pedido se considera pagado solo después de un webhook verificado.
4. Pide a una persona que pruebe esas reglas. Inicia sesión con dos usuarios e intenta leer los datos del otro. Reenvía un webhook. Intenta cambiar un precio en la solicitud.
5. Corrige los puntos de mayor riesgo en el código existente. Una reescritura rara vez es la primera respuesta.
6. Vuelve a ejecutar las revisiones después de los cambios y confirma que los backups realmente se pueden restaurar.

La mayor parte del riesgo se encuentra con unas pocas revisiones enfocadas, no con una auditoría completa. El costo de corregir crece después de que llegan usuarios y pagos reales, así que hacerlo temprano es el camino barato.

¿Qué partes de la app necesitan primero una mirada humana?

Si solo puedes dedicarle una tarde, dedícala aquí. Estas son las cuatro revisiones que cubren la mayor parte del riesgo antes de que lleguen los usuarios reales.

Sobre el code review en general, he liderado a más de 15 personas en proyectos web, móviles y de e-commerce, incluyendo planificación de sprints, code review, mentoría y DevOps. Lo que aprendí ahí aplica directamente: los revisores deben poner su atención en los flujos riesgosos, no en el formato. La automatización se encarga del resto.

Cuándo está bien quedarse en el constructor

Quedarse en el constructor a veces es la mejor decisión, por ejemplo para una herramienta interna o un prototipo con pocos usuarios y sin pagos. El código construido en Lovable se puede pasar a GitHub y a tu propio hosting más adelante, así que conservas esa opción. Las revisiones de arriba siguen aplicando dondequiera que corra la app.

¿Quieres una segunda opinión sobre tu app?

Si tienes una app construida con IA y quieres comparar notas, escríbeme a me@filipeeduardo.dev con el link y unas líneas sobre lo que hace, y te diré qué revisaría primero.