Alexandru Nedelcu sostiene que el riesgo central de la programación asistida por IA no es un error único y evidente. Es la acumulación aplazada de decisiones de diseño que hacen que el software resulte difícil de comprender, modificar y probar. Su advertencia se dirige menos a los modelos en sí que a las organizaciones que permiten que el código generado sustituya el juicio humano y la experiencia adquirida al corregir errores.

El argumento comienza con un problema de medición. La mantenibilidad normalmente no es visible cuando una función ya funciona, y los efectos de una arquitectura deficiente pueden tardar meses o años en manifestarse. Una base de código puede parecer productiva mientras dependencias ocultas, invariantes poco claros, lógica duplicada y pruebas frágiles encarecen cada cambio futuro. Por ello, Nedelcu considera la mantenibilidad una propiedad de largo plazo, no una cualidad que pueda garantizarse mediante un comprobador de código convencional o el resultado inmediato de una prueba.

Esta distinción es importante porque los sistemas de aprendizaje automático necesitan retroalimentación medible. Si la recompensa disponible refleja si el código funciona hoy, un modelo puede mejorar su comportamiento a corto plazo sin aprender si el diseño resultante seguirá siendo coherente después de varias versiones. Esto respalda una versión más limitada de la afirmación de Nedelcu: la generación automatizada de código puede optimizar resultados fáciles de observar y, al mismo tiempo, pasar por alto consecuencias que aparecen más adelante. No demuestra que todos los modelos carezcan de conocimientos útiles sobre arquitectura ni que todos los proyectos asistidos por IA se deterioren.

Nedelcu también sostiene que la experiencia profesional depende de enfrentarse al fracaso. Las personas ingenieras aprenden qué abstracciones son realmente reutilizables, qué atajos crean limitaciones futuras y cuándo una simplificación local oculta la intención del sistema. Según su argumento, si quienes desarrollan software dejan de leer o escribir código, pierden oportunidades para ejercer esos juicios y aprender de sus consecuencias. El riesgo resultante es institucional: el conocimiento sobre por qué un diseño funciona, o ha dejado de funcionar, puede no conservarse cuando la responsabilidad se transfiere sistemáticamente a una herramienta.

El modelo de adquisición de habilidades de Dreyfus proporcionado aporta contexto a esta parte del argumento. Describe cómo quienes aprenden comienzan aplicando reglas y procedimientos explícitos y, después, desarrollan gradualmente mediante la experiencia un juicio más intuitivo y sensible al contexto. También advierte que seguir dependiendo de reglas conscientes puede impedir avanzar más allá de la competencia. Ese marco hace comprensible la preocupación de Nedelcu, pero no constituye una prueba independiente de que la programación con IA produzca el mismo efecto. El modelo expone una teoría sobre el desarrollo de habilidades; no evalúa agentes de programación, no mide el mantenimiento del software ni valida la previsión del artículo.

De ello se desprende una pregunta práctica: ¿pueden los equipos utilizar agentes de programación sin renunciar al juicio arquitectónico? Las pruebas aportadas no resuelven esa cuestión. Sin embargo, sí sugieren qué debe preservarse para utilizarlos de forma responsable: quienes desarrollan software deben inspeccionar los cambios generados, comprender las compensaciones de diseño, mantener pruebas que comprueben comportamientos relevantes y reconsiderar las decisiones a medida que evolucionan los requisitos. La automatización puede encargarse del trabajo repetitivo mientras las personas siguen siendo responsables de los límites, los invariantes y las razones que sustentan un diseño.

Las pruebas también dejan sin resolver comparaciones importantes. No ofrecen ningún estudio controlado que compare el código escrito con asistencia de IA y el escrito por personas, ninguna medición longitudinal del coste de mantenimiento ni ninguna prueba de que una política de «cero IA» proporcione una ventaja competitiva. Tampoco establecen que la calidad del código carezca de métricas útiles. La conclusión defendible es más limitada: las señales fáciles de medir son indicadores incompletos de la mantenibilidad a largo plazo, y las organizaciones no deben considerar que una compilación correcta demuestre que un diseño envejecerá bien.

Para quienes leen, la lección útil es operativa, no contraria a la tecnología. Hay que mantener a las personas involucradas en las decisiones cuyas consecuencias no serán visibles de inmediato. Deben documentarse las razones arquitectónicas, exigir revisiones sustantivas y tratar el código generado como una propuesta que hay que comprender, no como una fuente autónoma de sabiduría. Ese enfoque preserva las ventajas de eficiencia de la automatización y aborda el modo de fallo específico que identifica Nedelcu: una base de código que funciona ahora, pero que cada vez resulta más difícil de modificar para su propio equipo.