El desarrollador Arnorhs reflexiona en su blog personal sobre el valor del código que nunca se escribe y advierte de un riesgo emergente ligado al uso de inteligencia artificial en el desarrollo de software.
El argumento central del texto es que la mayor parte de las ideas que se acumulan en el backlog de un equipo de desarrollo — más pruebas, una migración de proveedor cloud, una reescritura del sitio web heredado, una capa de gestión de tareas sobre el CRM, un pipeline más elegante para imágenes — no deberían llegar a construirse nunca. Cada vez que se rechaza una de esas ideas, sostiene, se acelera al equipo y se prioriza lo que realmente importa. Cuatro años después, esas ideas serían irrelevantes o el producto ya habría pivotado, y la funcionalidad añadida se habría convertido en lastre técnico que hay que mantener o eliminar. «No construir es una estrategia de producto y desarrollo muy potente», resume.
La segunda parte aborda el papel de los modelos de lenguaje grandes (LLM). Arnorhs reconoce que siguen mejorando y que, en casos puntuales, producen código mejor que el suyo. Sin embargo, en su experiencia diaria el resultado suele ser difícil de leer: la misma definición repetida en 15 archivos, cuatro implementaciones distintas de la misma validación anidadas en bloques if, una estructura tan confusa para el revisor humano como para el propio modelo en iteraciones posteriores.
Aquí aparece su preocupación principal: si antes la barrera para construir ideas del backlog era el coste en tiempo y dinero, ahora los LLM la eliminan. Los desarrolladores, argumenta, están pasando de «elegir qué construir» a simplemente «construirlo todo», gastando tokens sin priorizar. A medio plazo, las bases de código crecerán con más frameworks, más reescrituras y más capas que de otro modo nunca habrían existido, hasta volverse ilegibles para humanos y manejables solo a través de otra IA. El autor recuerda además la ley de Hyrum, según la cual cualquier API pública acumula dependencias implícitas casi imposibles de revertir, y observa que, en la práctica, justificar ante perfiles no técnicos la inversión en borrar funcionalidad sigue siendo tan difícil como siempre.
Arnorhs cierra el ensayo reiterando la tesis: «Hay mucho valor en el código que no escribimos, y a menudo no elegir escribirlo es lo mejor que podemos hacer».