Midiendo la chapucería del código
Las afirmaciones de que la IA ya “resolvió” la programación chocan con la creciente preocupación de que los modelos de lenguaje grande generan enormes cantidades de código de baja calidad y difícil de mantener. Los comentaristas exploran intentos de cuantificar esta “chapucería” usando métricas como líneas de código, complejidad ciclomática, reglas de verbosidad y benchmarks de varios pasos que muestran cómo los agentes acumulan deuda técnica con cada iteración. Muchos argumentan que, aunque los modelos a menudo pueden producir fragmentos correctos rápidamente, la verdadera calidad del código —mantenibilidad, arquitectura, seguridad y comprensibilidad humana o de agentes a escala— sigue sin resolverse y es difícil de medir sin caer en la ley de Goodhart.
SlopCodeBench y la acumulación de “slop”
- El benchmark invierte el patrón habitual: múltiples tareas iterativas con el contexto borrado entre rondas, imitando el uso real de agentes.
- Las malas decisiones de diseño tempranas se acumulan; bajo criterios estrictos (que pasen todos los puntos de control), incluso los mejores modelos supuestamente logran 0% de resolución.
- Se usan métricas simples: crecimiento de LOC, complejidad ciclomática y reglas heurísticas de “verbosidad” para detectar código demasiado largo o redundante.
- A muchos comentaristas les entusiasma por fin tener un enfoque cuantitativo para un fenómeno que ven en la práctica.
¿Qué es realmente la calidad del código?
- Varios sostienen que la corrección solo es una base; la calidad también incluye eficiencia, seguridad, mantenibilidad, legibilidad, observabilidad, portabilidad, etc.
- Otros señalan que gran parte del código empresarial escrito por humanos ha sido históricamente de baja calidad; el slop de IA se ve como “más de lo mismo, pero más rápido”.
- Algunos afirman que la calidad del código es fundamentalmente difícil o intratable de medir (comparándola con el problema de la parada) e inherentemente basada en la vibra.
¿Son buenos programadores los LLM? Experiencias contradictorias
- Lado entusiasta:
- Para muchas tareas, se dice que la salida de los LLM es mejor que la de un dev promedio o junior, especialmente con una guía humana competente.
- La gente reporta mayor rendimiento con calidad aceptable, especialmente en lenguajes de nivel superior y trabajo greenfield.
- Lado escéptico:
- Los agentes producen demasiado código, duplican lógica, evitan borrar código muerto y rompen la arquitectura existente.
- A menudo fallan en cambios no locales, sistemas complejos y bugs sutiles, o requieren una microgestión intensa.
- Algunos dicen que las bases de código escritas por LLM se “speedrunnean” hasta estados imposibles de mantener.
Diseño global, mantenibilidad y modelos mentales
- Los comentaristas enfatizan que los problemas más difíciles son globales: separación de responsabilidades, capas, interfaces y evolución a largo plazo.
- Programar se describe como una forma en que los humanos construyen modelos mentales compartidos; si los agentes hacen todo el código, los humanos pueden perder comprensión y control.
- Otros argumentan que futuras herramientas pueden proporcionar “vistas” sobre bases de código enormes, reduciendo la necesidad de modelos globales retenidos por humanos.
Métricas, ley de Goodhart e ideas de evaluación
- El cambio en LOC se considera ampliamente una métrica de olor sorprendentemente efectiva, pero vulnerable a la optimización y al “code golfing” patológico.
- Sugerencias: combinar LOC/tokens con complejidad ciclomática, churn, acoplamiento, cohesión, profundidad de indentación, patrones AST y coste de tokens para “grokear” el código.
- Algunos proponen:
- “Número de rondas resueltas correctamente” iterativo como métrica central.
- Usar un modelo base separado para juzgar si el código de otro modelo es utilizable.
- Benchmarks de dominio/arquitectura (por ejemplo, apps de “contador” progresivamente más complejas) que midan la calidad del diseño, no solo aprobar tests.
Impacto en la industria y preguntas abiertas
- Muchos distinguen entre “codificar” e “ingeniería de software”; ven lo primero acercándose a la automatización más rápido que lo segundo.
- Hay debate sobre si los modelos actuales ya superan a “la mayoría” de los desarrolladores o si siguen siendo mucho peores que profesionales competentes.
- El coste y los límites de tokens son restricciones prácticas; algunos informan haber revertido configuraciones agentic agresivas por gasto y slop.
- Sentimiento general: medir la chapucería es valioso, pero definir y optimizar la verdadera calidad del código sigue sin resolverse.