Detector de código hecho con IA: ¿funcionan de verdad?
Un detector de código hecho con IA te da, como mucho, una probabilidad: ninguno puede asegurar si un archivo lo escribió ChatGPT, Claude o una persona. Los modelos ya escriben código muy parecido al de un programador, y basta editar unas líneas para confundir al detector. Lo útil no es saber quién lo escribió, sino si está bien hecho. Aquí te explicamos ambas cosas.
¿Cómo funcionan los detectores de código generado por IA?
La mayoría analiza patrones estadísticos: qué tan “predecible” es cada línea para un modelo de lenguaje, la uniformidad del estilo, los nombres de variables y la forma de los comentarios. Si el texto se parece mucho a lo que un modelo produciría, marcan un porcentaje alto.
Sus limitaciones son importantes:
- Código corto: con 20 o 30 líneas casi no hay señal.
- Código editado: si una persona renombra variables o reacomoda funciones, el porcentaje cae.
- Código muy estándar: un formulario en React o una consulta SQL se escriben casi igual por humanos y por IA. Ahí hay muchos falsos positivos.
- Versiones de modelos: un detector entrenado con modelos de hace un año puede no reconocer a los actuales.
Por eso, en escuelas y empresas serias, el resultado de un detector se usa como una pista para conversar, no como prueba.
Señales de que un código fue hecho con IA
Sin herramientas, estas pistas suelen aparecer en proyectos generados con Lovable, Bolt, Cursor o ChatGPT:
- Comentarios que explican lo obvio, por ejemplo
// Incrementa el contador en 1encima decount++. - Estructura de archivos de plantilla: carpetas como
components/ui/con decenas de componentes de shadcn/ui que no se usan. - Código duplicado con pequeñas variaciones: la IA tiende a copiar una función en vez de reutilizarla.
- Manejo de errores genérico:
catch (error) { console.error(error) }en todos lados, sin avisarle nada al usuario. - Mezcla de estilos: partes en un estilo y partes en otro, porque se generaron en conversaciones distintas.
- Archivos de “fix”: nombres como
fixAuth2.ts,newDashboardFinal.tsx. - Historial de git con mensajes automáticos repetidos (Lovable y Bolt dejan mensajes muy reconocibles si el proyecto está conectado a GitHub).
Ninguna de estas señales es prueba; código humano apresurado se ve igual.
Lo que sí importa: revisar el código generado por IA
Si heredaste una app o la hiciste tú con IA, enfócate en esto en vez del detector:
1. Llaves y secretos en el navegador
Busca en el proyecto palabras como sk_live, service_role, SECRET, API_KEY:
grep -rniE "sk_live|service_role|secret|api_key" src/
Cualquier llave secreta en archivos del frontend (lo que corre en el navegador) es un problema. Si encuentras una, sigue qué hacer si tienes una API key expuesta.
2. Permisos de la base de datos
Si usas Supabase, revisa que todas las tablas tengan RLS (Row Level Security, las reglas que definen quién puede leer o escribir cada fila). No es teoría: en mayo de 2025, la vulnerabilidad CVE-2025-48757 mostró que 170 de 1,645 apps de la vitrina de Lovable dejaban leer o escribir sus tablas con la llave pública. Aquí te explicamos qué es RLS en Supabase.
3. Qué pasa cuando algo falla
Desconecta el internet, escribe datos raros en los formularios, recarga en medio de un pago. Una app bien hecha muestra un mensaje claro; una mal hecha se queda en blanco.
4. Dependencias
Revisa paquetes desactualizados o con vulnerabilidades conocidas:
npm audit
npm outdated
5. Si alguien más puede mantenerlo
Pídele a un programador que lea el código 30 minutos. Si no entiende cómo está organizado, cada cambio futuro va a costar más.
Casos comunes
“Contraté a alguien y creo que todo lo hizo con ChatGPT.” Usar IA es normal y no es fraude por sí mismo. Lo que sí debes pedir: que te explique cómo funciona, que el código esté en un repositorio a tu nombre y que no haya llaves expuestas.
“Soy profesor y quiero detectar tareas hechas con IA.” Los detectores te dan una pista, pero la prueba más justa es pedirle al alumno que explique o modifique su código en vivo.
“Hice mi app con IA y quiero saber si está bien.” Ahí el detector no te sirve: necesitas una revisión de código y seguridad. Empieza con la checklist de seguridad para apps hechas con IA o lee qué incluye una auditoría de código fuente.
Qué revisar antes de confiar en un resultado
- ¿El fragmento analizado es largo (cientos de líneas) o solo unas cuantas?
- ¿El detector dice con qué modelos fue entrenado o cuándo se actualizó?
- ¿Probaste el mismo detector con código que sabes que escribiste tú? Si también lo marca, ya sabes cuánto confiar.
Si tu duda de fondo es si una app hecha con IA está lista para usuarios reales, en Black Engine revisamos el código contigo por WhatsApp: seguridad, errores y qué tan mantenible es, sin importar quién o qué lo escribió.
Preguntas frecuentes
¿Hay un detector de código hecho con IA 100% confiable?
No. Los detectores dan una probabilidad, no una prueba. Fallan con código corto, con código editado por una persona y con estilos muy estandarizados, así que no deberías tomar decisiones solo con su resultado.
¿Es malo que mi código esté generado por IA?
No por sí mismo. El problema no es quién lo escribió sino si es seguro, si funciona y si alguien puede mantenerlo. Código humano también puede ser malo.
¿Cómo sé si el programador que contraté usó IA?
Pregúntale directamente; hoy es normal usarla. Lo importante es que entienda el código, que lo pueda explicar y que haya pruebas y revisión de seguridad.
¿Qué reviso en una app hecha con IA antes de lanzarla?
Permisos de la base de datos, llaves o API keys en el código del navegador, manejo de errores, respaldos y que los pagos se confirmen del lado del servidor.