zero-waterfaks

El problema

Los LLM tienen tics probabilísticos que emergen de cómo se entrenan: nombres de variable como `processed_data_list` en lugar de `records`, comentarios que explican lo obvio ("# inicializamos el contador"), docstrings con la estructura exacta de los ejemplos de entrenamiento. El problema no es que el código sea incorrecto — es que identifica al autor como un modelo, y eso tiene consecuencias según el contexto en que se use. zero-waterfaks los detecta y los reescribe sin alterar lo que el programa hace.

Los datos

Sin dataset público: el clasificador de tics se construyó sobre análisis propio de código generado por varios LLM comparado con código de repositorios públicos de alta reputación en GitHub.

Enfoque

• Motor AST: parsea el código a árbol de sintaxis abstracta y detecta patrones estructurales estadísticamente asociados a código generado — nesting excesivo, naming conventions demasiado verbosas, docstrings con estructura de plantilla
• Motor n-gramas: detecta tics léxicos en los tokens del código — frases hechas, combinaciones que aparecen con frecuencia anormal en código generado vs código humano
• Reescritura que preserva la lógica: el AST transformado se serializa de vuelta a código semánticamente equivalente, sin cambiar el comportamiento del programa
• Soporte de notebooks: transforma cada celda de código de un .ipynb de forma independiente, preservando las celdas de markdown intactas
• CLI con tres modos: stdin, fichero único, directorio entero con extensiones .py y .ipynb

Herramientas

python

Resultado

CLI en uso en mi flujo de trabajo habitual. La diferencia perceptible en el output es real: el código sale con nombres de variable más cortos, menos comentarios redundantes y docstrings sin la estructura canónica de los LLM.