¿Podrá la IA sustituir a los gestores de paquetes? De npm a un registro de prompts

Un autor tecnológico ruso en Habr ha analizado una idea planteada por el desarrollador Marcelo Emmerich en una publicación en Medium: sustituir los gestores de paquetes tradicionales como npm por un «registro de prompts», un sistema en el que los autores de bibliotecas publican no código listo, sino prompts para una IA que genera una implementación autosuficiente directamente en el equipo del desarrollador.

En qué consiste la idea del «registro de prompts»

Según Emmerich, en lugar de instalar una biblioteca ya hecha con npm install, el desarrollador pega el prompt del autor de la biblioteca en su herramienta de IA, y esta genera la funcionalidad en el momento, adaptada al lenguaje de programación y a las particularidades del proyecto. Como señala el autor de Habr, este enfoque tiene una lógica atractiva: si el código se genera de nuevo para cada tarea, desaparecen las dependencias transitivas (bibliotecas que arrastra otra biblioteca), los ataques a la cadena de suministro (supply chain attacks) mediante paquetes comprometidos y los conflictos entre versiones de distintas dependencias de un mismo proyecto, puntos débiles clásicos del desarrollo moderno.

Por qué es una propuesta ingenua, pero no infundada

El autor de Habr califica la idea de ingenua, pero admite que señala problemas reales. Los ataques a la cadena de suministro, es decir, la inyección de código malicioso mediante una dependencia comprometida en lo más profundo del árbol de paquetes, son una amenaza seria y difícil de controlar: averiguar qué contienen exactamente todas las dependencias transitivas de un proyecto grande es prácticamente imposible a mano. La idea de «generar justo lo necesario y nada más» también resulta atractiva a su manera, pues promete acabar con la hinchazón de las aplicaciones modernas, que arrastran decenas de megabytes de código sin usar a través de cadenas de dependencias.

Puntos clave del análisis:

• La idea original es de Marcelo Emmerich, en una publicación en Medium.
• La alternativa propuesta a los gestores de paquetes es un «registro de prompts» para generar código en el momento.
• Las ventajas declaradas son la ausencia de dependencias transitivas, la protección frente a ataques a la cadena de suministro y la ausencia de conflictos de versiones.
• Contraargumento del autor de Habr: la complejidad (TLS, análisis de JSON, Unicode) no desaparece, solo deja de llamarse «dependencia».

Lo que esta idea no tiene en cuenta

El principal contraargumento del autor de Habr se refiere a la naturaleza de la complejidad del software. Aunque cada desarrollador genere de nuevo la funcionalidad básica (cifrado TLS, análisis del formato JSON, tratamiento correcto de Unicode), esa complejidad no desaparece. Pasa de una biblioteca pública, escrita una vez y revisada muchas veces por la comunidad, a miles de implementaciones paralelas generadas de forma independiente, cada una con posibles errores y vulnerabilidades propios. Dicho de otro modo, renunciar al concepto de «dependencia» no elimina la tarea de fondo, que es implementar una lógica compleja y propensa a errores; solo cambia quién la resuelve y cuándo.

Esto devuelve al compromiso fundamental de los ecosistemas de código abierto: las bibliotecas centralizadas y ampliamente usadas, con todos sus riesgos para la cadena de suministro, ganan gracias a la escala: miles de ojos revisan el mismo código, y los errores se encuentran y se corrigen una sola vez para todos. El modelo de «generar de nuevo para cada proyecto», en cambio, pierde esas pruebas colectivas a cambio de personalización y de la ausencia de dependencias externas. No se sabe si el intercambio compensa, sobre todo en lógica de infraestructura crítica como la criptografía o el análisis de protocolos de red, donde el coste de un error es alto y los casos límite poco frecuentes son difíciles de prever en una única generación de código.

El ecosistema npm, que Marcelo Emmerich menciona en su texto, reúne millones de paquetes y sigue siendo el mayor registro del mundo para el desarrollo en JavaScript. Es también uno de los objetivos más frecuentes de ataques a la cadena de suministro, en los que los atacantes publican versiones maliciosas de paquetes populares o de nombre parecido, con la esperanza de que desarrolladores o sistemas de compilación automatizados las instalen por error. Precisamente esa larga experiencia lidiando con estos incidentes explica por qué la idea de renunciar por completo al código compartido en favor de generarlo «desde cero» resulta atractiva para parte de la comunidad, aunque, como muestra el análisis de Habr, traslade el problema de la complejidad a un lugar nuevo y menos probado en lugar de resolverlo.