SimpleOne demuestra por qué Claude y los revisores de IA no distinguen el código de IA del humano

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

Por qué es tan difícil

En su artículo, el equipo reunió varios pares de funciones: validación de email, una petición a una API, carga de configuración y cálculo de un descuento. En cada par, una versión la escribió una persona y la otra, un modelo. En teoría la tarea parece sencilla: el código de IA suele tener más tipado, más comentarios y una pseudo-pulcritud. En la práctica es peor. Algunos ejemplos sí se delatan por su exceso de corrección, pero hacia el tercer o cuarto par queda claro que, solo por el estilo, no siempre se puede identificar al autor.

El ejemplo más contundente es la función de cálculo de descuento, donde la diferencia entre las versiones casi desaparece. Ambos fragmentos funcionan, ambos pasan la comprobación estática, ambos parecen razonables. Pero el error real no está dentro de la función, sino en el lugar donde se la llama. Si el descuento debe fijarse en el momento de formalizar el pedido, no se puede recalcular cada vez que se abre la página. Ya no es una cuestión de sintaxis ni de best practices, sino de lógica de negocio y de contexto del proyecto, que el revisor automático normalmente no tiene.

Qué delata al código sintético

SimpleOne identifica varios rasgos por los que el código de IA a veces aún puede detectarse. No se trata de errores groseros, sino de un estilo sospechosamente "perfecto": el código parece pulcro, pero se comporta como si intentara impresionar al revisor en lugar de resolver una tarea concreta de producción. Estas señales aparecieron con más frecuencia en los ejemplos de email, API y configuración.

• Docstrings demasiado detallados, con listas de Args, Returns y cada excepción, incluso para una función minúscula.
• Edge cases y comprobaciones superfluos que nadie pidió y que no se derivan del enunciado de la tarea.
• 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 de inmediato, pero enmascaran el problema real.

De ahí el principal riesgo: la IA a menudo no escribe código abiertamente malo, sino código que resulta convincente. Está tipado, formateado, comentado y contempla una multitud de escenarios. Pero parte de esos escenarios salen de la nada, y parte de las construcciones defensivas solo complica la depuración. Es fácil tomar ese código por bueno si se mira la forma y no se comprueba cómo encaja en un sistema concreto.

Dónde se rompe la revisión

El problema que describe SimpleOne no se reduce a la calidad de un único modelo. Si Claude genera el código y otra herramienta de IA lo revisa con los mismos patrones, el equipo obtiene un circuito cerrado de confianza sintética. Todo se ve en verde: hay tipos, manejo de errores y comentarios. Pero la revisión puede no advertir que UserFetchError no existe en el proyecto, que secret_key apareció de repente sin que nadie lo exigiera, o que un retorno "silencioso" de un diccionario vacío costará después horas de búsqueda del bug.

«El revisor de IA encontró 2 de 5».

El equipo lo comprobó con bugs reales de producción. El revisor automático detectó solo dos casos simples: una variable sin usar y la falta de una comprobación de null. Se le escaparon los problemas que requieren contexto del proyecto: un error lógico en un cálculo, una race condition con peticiones paralelas y un orden incorrecto de migraciones.

La conclusión es práctica: la IA funciona bien como primer filtro, pero no sustituye a una persona en las zonas críticas, donde importa entender la lógica del dominio y las consecuencias de los cambios.

Qué significa

El uso masivo de IA en el desarrollo cambia no solo la velocidad de escritura del código, sino también el propio proceso de control de calidad. Revisar código generado con otra herramienta generativa es útil, pero insuficiente. Si un equipo no prueba a su revisor con bugs antiguos y no mantiene a una persona en la cadena de decisiones, corre el riesgo de obtener no calidad, sino una imitación muy verosímil de ella.