La IA exige más disciplina de ingeniería. No menos

Reacción general al artículo

• A muchos les pareció que el texto era verboso, divagante y pobre en conclusiones concretas; algunos sospecharon que era escritura de “AI slop”.
• A una minoría le gustó la idea central (IA ⇒ más disciplina, no menos), pero sintió que el argumento era confuso o ambiguo.
• Los lectores señalaron la tensión entre la retórica de que “la IA es existencialmente importante” y el tratamiento impreciso de las compensaciones.

Código vs. especificaciones, documentación y prompts

• Un debate central: ¿debería el código seguir siendo el “artefacto principal”, o deberían las especificaciones, las pruebas y los prompts convertirse en los objetos principales de revisión mientras el código es desechable?
• Varios argumentan que el código es la única especificación inequívoca y ejecutable, y por tanto debe seguir siendo central.
• Otros apoyan trasladar el conocimiento a documentos de diseño, ADRs, pruebas e historiales de prompts, dejando que la IA regenere el código como un detalle de implementación.
• Los escépticos advierten que las abstracciones más gruesas y las “especificaciones” de LLM aún no son lo bastante fiables como para saltarse una revisión detallada del código.

Calidad del código de IA, “slop” y verificación

• Hay un sentimiento fuerte de que la IA produce código funcional pero extraño, sobrercomplicado o frágil, que es doloroso leer y mantener.
• Quienes la defienden responden que, con buen diseño, restricciones y pruebas, la IA puede producir código de alta calidad y defensivo, y acelerar el trabajo no novedoso.
• Existe un amplio acuerdo en que ahora el cuello de botella es la evaluación y la verificación, no la generación de código.
• Algunos prevén sistemas que validen propiedades y pruebas en lugar de que los humanos lean la mayor parte del código; otros dudan de que eso sea realista sin código estable y comprensible para humanos.

Líneas de código, productividad y deuda técnica

• Norma de HN de larga data: eliminar código es una señal de seniority. Muchos la defienden todavía más en la era de la IA.
• La IA permite PR enormes e inundaciones de código y documentación “superficialmente plausibles”, lo que dificulta identificar quién entiende realmente los sistemas.
• Usar LoC o el número de PR como métricas de productividad se considera especialmente roto ahora.
• Varios comentarios predicen una nueva forma masiva de deuda técnica a partir de código y documentos generados por IA, comparándola con el amianto o con una “bancarrota técnica”.

Disciplina, roles e incentivos

• Muchos están de acuerdo en que la IA puede exigir más disciplina: mejores especificaciones, pruebas, observabilidad y procedencia (por ejemplo, capturar prompts e intención de diseño).
• Al mismo tiempo, la IA hace más fácil parecer productivo sin entender, especialmente bajo presión ejecutiva para “usar IA en todas partes”.
• Algunos esperan que los roles de SWE se desplacen hacia la arquitectura, la documentación y el diseño de pruebas en lugar de desaparecer; otros argumentan que la combinación de poca experiencia + IA es un nuevo riesgo sistémico, especialmente para los juniors.