El código fuente consiguió un mejor publicista
El código generado por IA está reviviendo las líneas de código como métrica de gestión, a pesar de décadas de experiencia que muestran que LoC mide sobre todo la carga de mantenimiento futura, no la productividad real. Los comentaristas sostienen que teclear no es el cuello de botella: lo son decidir qué construir, revisar y probar los cambios, y mantener la simplicidad; por eso celebrar “millones de LoC” o altos porcentajes de código escrito por IA solo produce slop y deuda técnica. Muchos ven las afirmaciones actuales sobre despidos y productividad de la IA como relaciones públicas para el exceso de contrataciones y la presión de los inversores más que como evidencia de auténticas ganancias de eficiencia, y advierten que las organizaciones que persigan métricas de LoC enviarán más funciones frágiles e indeseadas en lugar de mejores productos.
El regreso de las métricas de líneas de código
- Los comentaristas señalan un resurgimiento de LoC como métrica de éxito en la era de la IA, a pesar de críticas de larga data.
- La publicación del blog de OpenAI sobre “un millón de líneas de código por agentes” se cita como emblemática: fuerte énfasis en LoC con poca claridad sobre el valor del producto.
- Las comparaciones con Linux, Chrome y grandes monorepos destacan que los enormes conteos de LoC no son inherentemente impresionantes ni deseables.
AI slop, deuda técnica y mantenibilidad
- “AI slop” se contrapone a la tradicional “deuda técnica” y se ve como algo más concreto: grandes volúmenes de código que pocas personas entienden, a menudo mucho mayores de lo necesario para el propósito.
- Algunos sostienen que cada línea de código es un pasivo; las LoC deberían hablarse como un “coste” más que como un activo.
- Preocupan las bases de código escritas por LLM con patrones reconocibles: código plausible, pruebas superficiales o falsas, abstracciones poco claras.
Productividad y cuellos de botella
- Muchos dicen que “escribir código ya no es el cuello de botella”; las verdaderas restricciones son decidir qué construir, la revisión de código, las pruebas y el proceso organizativo.
- Los desarrolladores individuales a menudo se sienten más rápidos, especialmente con pruebas, boilerplate y comprensión de código heredado, pero las ganancias a nivel de equipo o empresa son modestas por los cuellos de botella posteriores que no cambian.
- Hay debate sobre afirmaciones como “1M de LoC por ingeniero por mes”; algunos lo ven como algo relacionado con el portado automatizado, otros como irreal y fácilmente manipulable.
Métricas, manipulación y la ley de Goodhart
- Ejemplos: evaluaciones de desempeño basadas en líneas de código, evaluaciones impulsadas por el conteo de PR, cuotas de cobertura de código manipuladas con basura generada.
- Los comentaristas invocan repetidamente la ley de Goodhart: cuando LoC, PR o “% de código escrito por IA” se convierten en objetivos, dejan de medir la productividad real.
Presión de adopción y división cultural
- Algunos insisten en que todo ingeniero debe usar IA a diario para seguir siendo empleable y competitivo; otros rechazan esto como hype o adopción “con una pistola en la cabeza”.
- Informes de campo mixtos: usuarios no técnicos o junior inicialmente impresionados, pero a menudo decepcionados al usar IA para tareas que conocen bien.
- HN en sí es percibido por distintos participantes tanto como territorio de “fanboy de la IA” como de “odio a la IA”, reflejando una comunidad polarizada.
Sectores críticos para la seguridad y productos “reales”
- Los sectores críticos para la seguridad y embebidos se describen como en gran medida no adoptantes de la generación de código con LLM; un estudio citado encuentra un importante incumplimiento de las directrices.
- Se traza un contraste más amplio entre sectores que deben lanzar productos que funcionen y sean rentables y aquellos vistos como centrados en “falsa productividad”.