El costo del que YAGNI nunca se trató
Los ingenieros de software están reexaminando el principio “You aren’t gonna need it” (YAGNI) a la luz de la codificación asistida por IA y de la refactorización más barata. Algunos sostienen que las abstracciones especulativas y la estructura prematura siguen creando deuda técnica costosa, mientras que otros dicen que un YAGNI estricto puede socavar funciones básicas necesarias y hacer que los cambios futuros sean más difíciles o políticamente imposibles. Varios comentaristas señalan que la IA reduce el costo de escribir código y pruebas, pero también puede generar suites de pruebas frágiles y código mal estructurado, por lo que sigue siendo crucial juzgar cuándo generalizar, cuándo posponer y cómo mantener los sistemas evolutivos de forma segura.
IA, reestructuración y costo de oportunidad
- Algunos sostienen que la IA ha reducido drásticamente el costo de reestructurar, añadir pruebas y realizar migraciones sofisticadas sin tiempo de inactividad, convirtiendo en la principal optimización el objetivo de “cambios fáciles y seguros”.
- Otros replican que la IA sobre todo acelera la escritura y la plantilla, no los verdaderos cuellos de botella (coordinación, gestión del riesgo, aprobaciones).
- En organizaciones grandes, la frecuencia de despliegue está limitada por la burocracia y los controles de riesgo; la IA no cambia los plazos contractuales ni la gobernanza.
- Preocupa que las pruebas y el código generados por IA a menudo aumenten la fragilidad y hagan más difícil la refactorización segura, especialmente cuando los agentes están mal guiados.
YAGNI, predicción y analogía de la opción
- Tensión central: YAGNI dice “no construyas funciones/estructuras especulativas”; los críticos señalan que eso mismo es una predicción sobre el futuro (“you aren’t gonna need it”).
- Los partidarios enfatizan: normalmente sobreestimas tu capacidad para prever necesidades futuras; las abstracciones se construyen mejor después de ver casos de uso reales (“regla de 3”).
- Los detractores dicen que YAGNI a menudo se convierte en un “no” reflejo que bloquea un diseño legítimamente orientado al futuro, especialmente cuando los desarrolladores no entienden el dominio o ignoran a las partes interesadas.
- La analogía de la opción financiera del artículo es debatida: algunos ven el código no escrito como una forma de preservar flexibilidad; otros dicen que solo el comportamiento implementado tiene valor, y que el “andamiaje” es solo una prima de opción pagada que quizá nunca rinda frutos.
Abstracciones, deuda técnica y pruebas
- Un bando afirma que la mayor parte de la deuda técnica proviene de abstracciones sobregeneralizadas y sin uso que restringen cambios futuros.
- Otro bando señala código apresurado y mal arquitecturado, con violaciones de capas y pruebas débiles, que más tarde se convierten en “desastres portantes”.
- La generación de pruebas impulsada por IA es criticada por crear grandes suites de pruebas frágiles; algunos ven las pruebas de mutación como una sobreponderación en atrapar cualquier cambio de código, lo que aumenta aún más el costo de refactorizar.
Contexto de proceso: Agile, Waterfall y restricciones de dominio
- Se destaca que el hardware/chips y los dominios críticos para la seguridad son lugares donde el pensamiento tipo agile/YAGNI encaja mal debido a los enormes costos de cambio; procesos más tradicionales, parecidos a waterfall, y la verificación independiente siguen siendo estándar.
- Otros señalan que “shift left” y las prácticas iterativas existían mucho antes de la marca agile; agile בעיקרamente las empaquetó y popularizó.
Reacción al artículo y al uso de IA
- Varios comentaristas encuentran incoherente o “ensalada de palabras” el cuerpo principal del texto, atribuyéndolo a su parte explícitamente generada por IA.
- Algunos ven la publicación como un experimento útil de “optimización de agentes”; otros la consideran una distracción que debilita el argumento subyacente de YAGNI.