Tem uma thread circulando em que alguém reclama que o assistente de IA dele “vive adicionando ao meu código imports que não existem”. O melhor são as respostas. O agente de programação de uma pessoa inventou um módulo, foi confrontado e ainda respondeu que o módulo era real. Outra pessoa achou um pacote misterioso chamado algo como TrjnHrs.Pkg adicionado em silêncio ao projeto. E mais alguém percebeu que um módulo inexistente era o motivo de o serviço que a IA havia reescrito para um colega estar quebrado, sem ninguém notar, havia um dia inteiro.
A gente riu. Depois parou de rir, porque isso também estava deixando a gente louco.
Por que os modelos inventam imports
Modelos de linguagem são reconhecedores de padrões, não compiladores. Quando um modelo escreve import seguido de um nome plausível, ele não está verificando se aquele pacote existe. Ele está prevendo o que um programador confiante provavelmente digitaria em seguida. Na maioria das vezes a previsão acerta. Às vezes ele recorre, com toda a confiança, a requests_async, react-use-debounce-hook, ou algum utilitário de nome caprichado que ninguém nunca publicou.
O modelo não tem uma fonte de verdade. Ele tem feeling. E feeling é ótimo para produzir nomes que parecem exatamente pacotes reais.
A parte que deveria mesmo te assustar
Um import alucinado não é só um build quebrado. É uma superfície de ataque.
Os pesquisadores já deram um nome a isso: slopsquatting. Os atacantes observam quais nomes falsos de pacotes as ferramentas de IA tendem a alucinar e então registram esses nomes nos registros públicos com malware dentro. Seu assistente inventa trjnhrs-pkg. Alguém já publicou trjnhrs-pkg. Seu comando de instalação resolve sem erro nenhum. E agora você está rodando o código de outra pessoa. O import que “não existia” ontem existe hoje, de propósito, e é hostil.
Esse é o modo de falha de verdade perigoso. Um typo você pega em cinco segundos. Um nome de pacote plausível que resolve silenciosamente para o payload de alguém é o tipo de coisa que você só pega quando já está em produção.
Por que “é só mandar ele não fazer” não funciona
A thread está cheia do conselho de sempre. Escreva prompts melhores. Mande ele não errar. Configure os warnings como erros. Pegue um checker.
Os dois primeiros são ilusão. Você não consegue, via prompt, deixar um sistema probabilístico determinístico sobre fatos que ele não tem. Os dois últimos chegam mais perto, mas um linter genérico aponta o sintoma (um import que não resolve) sem entender a causa. A dependência simplesmente nunca foi adicionada ao manifesto? É um módulo interno que o linter não enxerga? Ou esse pacote realmente não existe em lugar nenhum do planeta? Esses três casos parecem idênticos para um checker burro e exigem respostas completamente diferentes. (É o mesmo motivo pelo qual revisar o próprio código não pega os erros de aparência plausível de uma IA: o que escreveu o código não pode ser a única coisa que o verifica.)
É essa a lacuna que o Surmado Code Review veio fechar.
Como a gente pega de verdade: checagens determinísticas mais julgamento
O conserto não é um modelo mais inteligente. É não fazer ao modelo a pergunta factual, para começar.
As checagens determinísticas fazem o trabalho de saber. Em cada pull request, o Surmado Code Review resolve cada import do diff contra uma fonte de verdade: seu lockfile, seu manifesto, seus módulos instalados, a biblioteca padrão, seus pacotes internos. Esse passo não chuta. Um pacote ou resolve ou não resolve. Se super-fast-parser aparece no diff e não resolve para nada no seu grafo de dependências nem para nada no registro, isso é um fato, não uma opinião. Aqui não há alucinação possível, porque nada está sendo gerado. É uma busca.
O Scout faz o trabalho de julgar. Com os fatos em mãos, o modelo faz o que os modelos são realmente bons em fazer: triar e explicar. Ele distingue entre “você esqueceu de adicionar isso ao package.json” e “esse módulo não existe, e o real mais parecido tem outro nome”. Ele tira duplicatas. Aponta o import que você quase com certeza queria. E escala o caso assustador: esse nome resolve para um pacote publicado três dias atrás que mais nada no seu ecossistema referencia. Esse é o cheiro de slopsquatting, e é exatamente o tipo de julgamento que um linter simples não consegue fazer.
Nenhuma metade funciona sozinha. Checagens determinísticas sem julgamento são barulhentas e não sabem se explicar. Um modelo sem ancoragem determinística é só mais uma coisa que aluciona imports, agora revisando os seus imports alucinados. Junte as duas e você tem o que todo mundo naquela thread queria de verdade: certeza sobre o que é real, mais julgamento sobre o que fazer.
Onde ele roda
O Surmado Code Review comenta nos seus pull requests. Ele checa o diff contra o STANDARDS.MD do seu time e sinaliza os imports inventados antes de eles entrarem no merge, não depois de já terem quebrado em silêncio a branch de um colega ou puxado um pacote que ninguém revisou. Um comentário por PR, ancorado nas suas regras, editado no mesmo lugar quando você sobe uma correção. É a camada entre “a IA escreveu” e “já está na main”.
Experimente de graça
A gente construiu isso porque o problema dos imports-que-não-existem estava fazendo a gente perder tempo, e a versão de cadeia de suprimentos disso deu medo de verdade. A gente usa nos nossos próprios repositórios; veja como construímos. Então não vamos esconder atrás de um muro.
O Surmado Code Review é grátis para 10 PRs por mês. Conecte a um repositório do GitHub, escreva um STANDARDS.MD (o Scout te ajuda a redigir a partir de uma conversa, como explicar seu código para alguém que acabou de chegar) e ele começa a pegar imports alucinados no seu próximo PR. Depois disso, são US$ 15 por mês para 100 PRs. Sem preço por assento. Zero retenção de dados.
Sua IA vai continuar inventando imports. Você não precisa continuar dando merge neles.
Experimente o Surmado Code Review de graça
Leituras relacionadas: