Ask HN: ¿Conoces alguna empresa que haya vuelto a escribir código a mano?
Las herramientas de codificación con IA son elogiadas por su rápida creación de prototipos y por reducir la “inercia”, pero muchos ingenieros informan que la velocidad se compensa con un aumento descontrolado de la deuda técnica, bases de código “heredadas” e inestables creadas en meses y una pérdida de comprensión profunda de los sistemas. Los comentaristas describen estrategias divergentes: algunos equipos prohíben o limitan mucho la IA para el código central y la usan para revisiones, pruebas o código repetitivo; otros son empujados por la dirección a maximizar el uso de IA incluso a costa de la calidad y la mantenibilidad a largo plazo. Un tema recurrente es que el verdadero problema no son tanto las herramientas en sí, sino el liderazgo, los incentivos y los flujos de trabajo que priorizan la producción a corto plazo sobre la calidad del código, el aprendizaje y las prácticas de ingeniería sostenibles.
Alcance de la pregunta
- El autor original pregunta: ¿hay empresas que adoptaron la generación de código con IA y luego volvieron al código escrito por humanos?
- Varias respuestas dicen no conocer ninguna a gran escala; otras señalan que muchas empresas todavía no han adoptado herramientas de codificación con IA.
Ganancias de productividad vs calidad del código
- Algunos sostienen que la IA claramente aumenta la productividad a corto plazo al eliminar la inercia y acelerar la creación de prototipos.
- Los críticos dicen que “productividad” no significa nada si solo produce funciones de bajo valor o incorrectas.
- Muchos prevén que las “ganancias” a largo plazo se evaporarán bajo una deuda técnica y cognitiva extrema.
Deuda técnica, código heredado y “slop”
- Varios comentarios describen la IA como una “pistola de fogueo nuclear”: puedes construir una base de código heredada en meses en lugar de años.
- Historia de una startup: la iteración rápida habilitada por IA llevó a un núcleo de código desordenado e inestable; un refactor grande fracasó porque la IA seguía reintroduciendo patrones antiguos a través del contexto de git. El equipo está considerando prohibir la IA en las partes centrales.
- Otros informan que los equipos pierden conocimiento del proyecto cuando el 99% de los cambios son generados por IA; los bugs difíciles tardan mucho más.
Políticas limitadas o sin IA
- Algunos equipos evitan la IA para el código central o “profundo” y solo la usan como revisora (similar al análisis estático).
- Una startup con unos 15 ingenieros escribe a mano toda la lógica central “interesante”, usando IA solo para UI de commodity y tareas tipo búsqueda.
- Otra empresa no usa IA en absoluto; otras solo la permiten para comprobaciones de seguridad/rendimiento o para pruebas (con escepticismo sobre el valor de las pruebas generadas por IA).
Liderazgo, proceso y cultura
- Varios argumentan que el código desordenado impulsado por IA es un fallo de liderazgo/proceso, no una inevitabilidad de la IA.
- Sugerencias: imponer flujos de trabajo estructurados para el uso de IA, enfatizar la comunicación y la comprensión compartida.
- Se señala la tensión entre “un equipo feliz usando IA como quiere” y la calidad del software a largo plazo.
Comparaciones, analogías y otros dominios
- Algunos comparan las herramientas de IA con IDEs, compiladores y Stack Overflow; otros responden que la IA “alucina”, así que la analogía es débil.
- Se reporta que unos médicos abandonaron los escribas de IA: el tiempo ahorrado se perdía verificando notas verbosas e inexactas.
- Preocupa que la dependencia generalizada de la IA erosione el aprendizaje, la artesanía y la calidad general del producto, incluso mientras las corporaciones optimizan para la producción a corto plazo.