La IA no entiende el código mantenible y quien deje de leerlo lo pagará

Un ingeniero veterano ha publicado una entrada en su blog con una tesis incómoda: la IA no ha aprendido nada sobre lo que hace mantenible a un código, y quien le delegue no solo la escritura sino también la lectura lo va a pagar. En el último mes, cuenta, ha oído decir que nadie ha vuelto a escribir código desde 2025, que las revisiones han muerto y que ya nadie lee el código que ejecuta. Su predicción: cada vez más empresas presumirán de una política «sin IA» como ventaja competitiva, y tendrán razón.

El problema es que la mantenibilidad no se mide

El argumento central lo reconoce cualquiera que haya heredado un sistema: el código malo se identifica sin dificultad (cuesta leerlo, cuesta entenderlo, cuesta cambiarlo), pero sus efectos tardan meses o años en aparecer. Tocar una línea rompe algo al otro lado del proyecto, los invariantes del diseño se pierden cuando sus autores ya no están, los tests necesitan mocks y acaban bloqueando cualquier refactor serio. Con ese horizonte temporal no hay forma de entrenar a un modelo: el aprendizaje por refuerzo necesita una señal de recompensa inmediata, no una que llegue dos años después.

Así que los modelos aprenden lo que hay: reglas de manual escritas para principiantes y patrones extraídos de código ajeno. El autor es directo con lo segundo: la mayor parte del código que corre por ahí es bastante malo. Y añade el detalle que más duele: si existiera una función de aptitud capaz de puntuar el código mantenible, ya estaría dentro de los linters.

Dedica también un párrafo a la manía de los modelos de «simplificar»: parten una función grande en trozos que no son reutilizables, así que para entender la original hay que leer además las extraídas. Definir funciones que aclaren y se puedan reutilizar es un oficio, y ni la mayoría de los desarrolladores ni los modelos actuales lo dominan.

Quien no decide, no aprende

Ahí está lo que le parece más grave. Usar la IA como herramienta es una cosa; dejar que escriba y lea el código por ti es otra. Quien no toma decisiones no asume errores y no aprende de ellos: los comete el modelo, que tampoco aprende, y el desarrollador se queda donde estaba. Tira del modelo de Dreyfus para situar a buena parte de la profesión en la categoría de principiante avanzado. Los expertos, dice, no siguen reglas: las escriben.

No es un alegato contra la herramienta. El autor cuenta que ha integrado LLM en su trabajo diario, que enseña a sus compañeros lo que va aprendiendo y que le quita de encima la parte aburrida. Su tesis es más estrecha: son una herramienta más y no resuelven la programación. Desmontar la analogía de la cadena de montaje le cuesta poco, porque el software ya es automatización a escala y los LLM no son la única forma de hacerla.

Queda por ver si la etiqueta «sin IA» vende algo o se queda en gesto. Lo que sostiene el texto es que el coste de no leer el código no lo paga el modelo.