Clasificador open source detecta comentarios de código generados por IA

Por qué detectar comentarios de código escritos por IA importa más que nunca

Cuando un modelo como Claude o GPT completa una función, también suele dejar un comentario explicando qué hace. En los repos abiertos eso se traduce en una avalancha de docstrings y notas de estilo casi idénticas, pulidas, sin la economía verbal de un humano apurado por terminar el ticket antes del daily. Esa huella estilística es justo la que explota el clasificador open source que el blog Entropic Thoughts publicó esta semana: un modelo entrenado en código con licencia abierta que distingue, con una precisión balanceada del 77%, si un comentario fue escrito por una persona o por un LLM.

El número no es académico. En 2026, según un estudio citado por Mashable, el volumen de artículos en internet generados principalmente por IA ya iguala al de los escritos por humanos. En código abierto ocurre algo parecido: la proliferación de asistentes como GitHub Copilot (que The Next Web documentó haber congelado nuevas altas por el coste de los flujos agenticos) y Claude Code ha cambiado lo que llega a un pull request. Para un tech lead que revisa un contribution externo, o para un equipo que audita código generado bajo políticas internas, saber si ese bloque lo escribió una persona con prisa o un modelo entrenado para sonar impecable ya no es un capricho: es una pieza más del gobierno del código.

Qué mide exactamente el clasificador y cómo lo hace

El enfoque es deliberadamente clásico: regresión logística con features estilísticas, no una red neuronal profunda. El autor entrenó un clasificador de 7 vías que distingue entre humanos y seis LLMs —GPT 5.6, Gemini 3.7, Claude 5, Kimi K2.7, Grok 4.6 y GLM 5.2— y luego reagrupa las predicciones para devolver el veredicto binario humano vs. robot que la mayoría de nosotros queremos en el día a día.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Las features que mejor separan ambos mundos, según el gráfico de rankings publicado en el artículo, son los n-gramas de etiquetas gramaticales (Part-of-Speech) extraídos con motores como wink-nlp, spaCy y nltk. La idea: convertir cada palabra a su rol gramatical —sustantivo plural, verbo, determinante, etc.— y contar secuencias como "NNS VBP IN PRP$". Esas cadenas filtran el contenido semántico y conservan el estilo sintáctico, justo lo que delata a un LLM cuando abusa de frases demasiado equilibradas.

Las siguientes señales más poderosas son los n-gramas de caracteres (pares y tríos consecutivos), las frecuencias crudas de palabras y métricas más débiles como la fracción de palabras largas (bigwords). El autor documenta una observación útil para quien entrene su propio detector: la potencia del clasificador escala aproximadamente con el logaritmo del dinero gastado en generar datos limpios, así que más allá de cierto umbral el coste marginal se dispara.

El dataset: la parte más cara y menos divertida del proyecto

El pipeline de datos merece tanta atención como el modelo. La receta: tomar repositorios con licencias permisivas o copy-left, hacer checkout de su último commit de 2021 (antes de la explosión generativa) y extraer comentarios humanos de archivos seleccionados. Después se eliminan esos comentarios y se pide a varios LLMs que generen sustituciones para los mismos archivos, manteniendo balanceado el número de tokens por archivo entre las clases para evitar que el modelo aprenda a identificar el repositorio en lugar del estilo.

El autor enumera seis errores que casi le cuesta el proyecto entero, y que son un manual práctico para cualquiera que monte un dataset similar:

Subject matter leakage: usar archivos distintos para cada LLM permite que el clasificador detecte el dominio, no el estilo.
No filtrar docstrings: si el LLM ve docstrings existentes, imita el estilo del repo y la señal humana se contamina.
Comentarios humanos demasiado cortos: tokens como // main task structure enseñan al modelo que los humanos escriben "como el culo" y los LLM, mucho más.
Sintaxis de comentarios por lenguaje: cada lenguaje tiene sus convenciones ( #, //, -- ) y olvidarlas deja comentarios residuales que contaminan el set.
Prompts fijos: producen variación insuficiente para capturar las manías reales de cada modelo.

La factura ascendió mucho más que los US$30 teóricos de un dataset bien planificado: el autor reconoce haberlo regenerado varias veces hasta dejarlo limpio.

Métricas: qué dice realmente el 77% de precisión

El informe publica dos tablas de confusion matrix. Sobre datos sintéticos (mezcla balanceada humano/robot usada en cross-validation), el clasificador acierta el 73% de las veces con input humano y el 80% con input robot. Sobre un conjunto out-of-sample de comentarios reales, las cifras mejoran hasta 89% y 86% respectivamente, con un F1 de 87%.

El matiz importante es que la predicción se publica como probabilidad calibrada: cuando el modelo afirma 80% de confianza en su veredicto, el riesgo de falso positivo cae al 5%. Esa calibración se obtiene con un coeficiente de temperatura ajustado por la raíz cuadrada de la longitud del input —una corrección estándar para que la confianza no se infle con textos largos.

El propio autor señala que la métrica agregada del 25% de error suena alta hasta que se entiende que cada predicción llega con su intervalo de confianza. Para uso práctico: no filtres por el veredicto binario; filtra por la probabilidad por encima de un umbral que tu equipo defina.

Por qué no detectar watermarks es la otra mitad del debate

Este lanzamiento llega en un momento incómodo para toda la industria de detección. Ars Technica informó en agosto de 2026 que Anthropic empezó a marcar con watermarks invisibles todo el contenido procesado por Claude, no solo el generado desde cero, para cumplir con el AI Act de la Unión Europea que obliga a etiquetar salidas de modelos liberados después del 2 de agosto. La gracia —y el problema— es que un watermark estadístico no distingue entre reescribir medio párrafo y generar un texto completo, así que puede terminar marcando justo el contenido que la propia regulación exceptúa.

A la vez, Substack integró Pangram, un detector neuronal de IA entrenado con texto humano publicado antes de 2021 (el mismo corte temporal que usa el clasificador que nos ocupa). El patrón se repite: la frontera entre humano y máquina se está moviendo hacia herramientas de capa fina —modelos ligeros que analizan estilo y frecuencia— porque los watermarks a nivel de proveedor son demasiado fáciles de erosionar.

Qué significa esto para tu startup

Si estás construyendo producto y tu código toca LLM, esta categoría de herramientas te interesa por dos motivos: gobierno interno (auditar qué partes de tu codebase salieron de un asistente) y confianza en integraciones (cuando consumes código de terceros vía APIs o repos).

Dos acciones concretas que puedes implementar esta semana:

Integra un detector estilístico en tu code review: si tu equipo recibe pull requests de contractors o de herramientas agenticas internas, ejecuta el clasificador (o uno equivalente como Pangram sobre texto) sobre los comentarios y docstrings. Marca para revisión humana cualquier bloque donde la confianza del modelo en "robot" supere el 80%.
Versiona y etiqueta el código generado por IA en tu repo: añade un tag @generated-by: en docstrings cuando uses Copilot, Claude Code o Cursor, y aplica la regla de que esos bloques requieren un comentario humano añadido a mano para ser mergeados. Es política barata, sin modelos extra, que escala mejor que cualquier detector automático.