A IA poderá substituir os gerenciadores de pacotes? Do npm a um registro de prompts

Um autor de tecnologia russo no Habr analisou uma ideia proposta pelo desenvolvedor Marcelo Emmerich em um post no Medium: substituir gerenciadores de pacotes tradicionais, como o npm, por um "registro de prompts", sistema em que os autores de bibliotecas publicam não código pronto, mas prompts para uma IA que gera uma implementação autossuficiente diretamente no lado do desenvolvedor.

Qual é a essência da ideia do "registro de prompts"

Pela concepção de Emmerich, em vez de instalar uma biblioteca pronta com npm install, o desenvolvedor cola o prompt do autor da biblioteca em sua ferramenta de IA, que gera a funcionalidade na hora, ajustada à linguagem de programação e às particularidades do projeto. Como observa o autor do Habr, essa abordagem tem uma lógica atraente: se o código é gerado do zero a cada tarefa, desaparecem as dependências transitivas (bibliotecas que outra biblioteca puxa junto), os ataques à cadeia de suprimentos (supply chain attacks) por meio de pacotes comprometidos e os conflitos entre versões de diferentes dependências de um mesmo projeto, pontos dolorosos clássicos do desenvolvimento moderno.

Por que a proposta é ingênua, mas não infundada

O autor do Habr chama a ideia de ingênua, mas admite que ela aponta para problemas reais. Os ataques à cadeia de suprimentos, ou seja, a injeção de código malicioso por meio de uma dependência comprometida no fundo da árvore de pacotes, são uma ameaça séria e difícil de controlar: descobrir o que exatamente existe em todas as dependências transitivas de um projeto grande é praticamente impossível manualmente. A ideia de "gerar exatamente o necessário, sem nada a mais" também é atraente à sua maneira, pois promete acabar com o inchaço dos aplicativos modernos, que arrastam dezenas de megabytes de código não utilizado por cadeias de dependências.

Principais pontos da análise:

• A ideia original é de Marcelo Emmerich, em um post publicado no Medium.
• A alternativa proposta aos gerenciadores de pacotes é um "registro de prompts" para gerar código na hora.
• As vantagens declaradas são a ausência de dependências transitivas, proteção contra ataques à cadeia de suprimentos e ausência de conflitos de versão.
• Contra-argumento do autor do Habr: a complexidade (TLS, parsing de JSON, Unicode) não desaparece, apenas deixa de se chamar "dependência".

O que a ideia não leva em conta

O principal contra-argumento do autor do Habr diz respeito à natureza da complexidade do software. Mesmo que cada desenvolvedor gere de novo a funcionalidade básica (criptografia TLS, parsing do formato JSON, tratamento correto de Unicode), essa complexidade não vai a lugar nenhum. Ela apenas se desloca de uma biblioteca pública, escrita uma vez e verificada muitas vezes pela comunidade, para milhares de implementações paralelas geradas de forma independente, cada uma potencialmente com bugs e vulnerabilidades próprios. Em outras palavras, abrir mão do conceito de "dependência" não elimina a tarefa em si, que é implementar uma lógica complexa e propensa a erros; apenas muda quem a resolve e quando.

Isso remete a um compromisso fundamental dos ecossistemas de código aberto: bibliotecas centralizadas e amplamente usadas, apesar de todos os riscos para a cadeia de suprimentos, ganham pelo efeito de escala, já que milhares de olhos revisam o mesmo código, e os bugs são encontrados e corrigidos uma só vez para todos. O modelo de "gerar do zero para cada projeto", ao contrário, perde esse teste coletivo em troca de personalização e da ausência de dependências externas. Não se sabe se a troca compensa, sobretudo em lógica de infraestrutura crítica, como criptografia ou parsing de protocolos de rede, em que o custo de um erro é alto e casos extremos raros são difíceis de prever em uma única geração de código.

O ecossistema npm, que Marcelo Emmerich menciona em seu texto, reúne milhões de pacotes e continua sendo o maior registro do mundo para desenvolvimento em JavaScript. É também um dos alvos mais frequentes de ataques à cadeia de suprimentos, nos quais invasores publicam versões maliciosas de pacotes populares ou de nome parecido, na expectativa de que desenvolvedores ou sistemas de build automatizados os instalem por engano. É justamente essa longa experiência no combate a esses incidentes que explica por que a ideia de abandonar de vez o código compartilhado em favor de gerá-lo "do zero" soa atraente para parte da comunidade, ainda que, como mostra a análise do Habr, ela transfira o problema da complexidade para um lugar novo e menos testado, em vez de resolvê-lo.