SimpleOne mostró por qué Claude y los revisores de AI no distinguen el código generado por AI del código humano

SimpleOne propuso una prueba simple: distinguir código humano de código generado por IA. Resultó que esto es difícil no solo para los desarrolladores, sino también para el propio revisor de IA, que verifica el código según los mismos patrones con los que fue creado.

Por Qué es Difícil

En el artículo, el equipo reunió varios pares de funciones: validación de correo electrónico, solicitud a API, carga de configuración y cálculo de descuento. En cada par, una versión fue escrita por un humano, la otra por un modelo. Sobre el papel, la tarea parece simple: el código de IA generalmente tiene más tipado, comentarios y pseudo-precisión.

En la práctica, es peor. Algunos ejemplos realmente se delatan por su corrección excesiva, pero ya en el tercero o cuarto par, queda claro: no siempre es posible distinguir al autor solo por el estilo. El ejemplo más fuerte es la función de cálculo de descuento, donde la diferencia entre las versiones casi desaparece.

Ambos fragmentos son funcionales, ambos pasan verificaciones estáticas, ambos se ven razonables. Pero el error real se esconde no dentro de la función, sino en el lugar donde se la llama. Si el descuento debe fijarse en el momento de la compra, no se puede recalcularlo cada vez que se abre la página.

Esto ya no es una cuestión de sintaxis o mejores prácticas, sino de lógica de negocio y contexto del proyecto, que un revisor automático generalmente no tiene.

Qué Delata lo Sintético

SimpleOne destaca varios signos mediante los cuales el código de IA a veces aún se puede detectar. No se trata de errores obvios, sino más bien de un estilo sospechosamente "perfecto": el código parece pulido, pero se comporta como si intentara impresionar al revisor en lugar de resolver una tarea específica de producción. Tales señales aparecieron con mayor frecuencia en los ejemplos con correo electrónico, API y configuración.

• Docstrings excesivamente detallados con enumeración de Args, Returns y cada excepción incluso para una función diminuta.
• Casos límite innecesarios y comprobaciones que nadie pidió y que no se derivan de la declaración del problema.
• Entidades inventadas alrededor del código: excepciones personalizadas, loggers o campos obligatorios que no existen en el proyecto.
• Fallbacks "seguros" como data.get('user', {}), que no fallan inmediatamente pero enmascaran el problema real.

De aquí viene el riesgo principal: IA a menudo escribe código que no es abiertamente malo, sino código que se ve convincente. Está tipado, formateado, comentado y cuenta para muchos escenarios. Pero algunos de estos escenarios se inventan, y algunas de las construcciones defensivas solo complican la depuración. Tal código es fácil de aceptar como de alta calidad si se mira la forma y no se verifica cómo se integra en un sistema específico.

Dónde Falla la Revisión

El problema que SimpleOne describe no se reduce a la calidad de un modelo. Si Claude genera código y luego otra herramienta de IA lo verifica según los mismos patrones, el equipo obtiene un círculo cerrado de confianza sintética. Todo parece verde: hay tipos, hay manejo de errores, hay comentarios. Pero la revisión puede no notar que UserFetchError no existe en el proyecto, que secret_key de repente apareció sin requisitos, y que un retorno "silencioso" de un diccionario vacío luego consumirá horas buscando un error.

"El revisor de IA encontró 2 de 5."

El equipo probó esto con errores reales de producción. El revisor automático solo capturó dos casos simples: una variable no utilizada y una falta de verificación nula. Lo que se perdió fueron cosas que requerían contexto del proyecto: un error lógico en el cálculo, una race condition con solicitudes paralelas y un orden de migración incorrecto. La conclusión es práctica: IA funciona bien como primer filtro, pero no reemplaza al humano en áreas críticas donde es importante entender la lógica de dominio y las consecuencias de los cambios.

Qué Significa Esto

El uso generalizado de IA en el desarrollo cambia no solo la velocidad de escritura de código, sino también el propio proceso de control de calidad. Verificar código generado con otra herramienta generativa es útil, pero insuficiente. Si el equipo no prueba el revisor contra errores antiguos y no mantiene a un humano en la cadena de toma de decisiones, corre el riesgo de obtener no calidad, sino una imitación muy convincente de ella.