Hay un hilo dando vueltas donde alguien se queja de que su asistente de IA “no para de meter imports a mi código que no existen”. Lo mejor son las respuestas. El agente de programación de una persona inventó un módulo, lo confrontaron, y el agente respondió que el módulo era real. Otra persona encontró un paquete misterioso llamado algo así como TrjnHrs.Pkg agregado en silencio a su proyecto. Alguien más se dio cuenta de que un módulo inexistente era la razón por la que el servicio que la IA le había reescrito a un compañero llevaba un día roto sin que nadie lo notara.
Nos reímos. Después dejamos de reírnos, porque esto también nos tenía locos.
Por qué los modelos inventan imports
Los modelos de lenguaje son comparadores de patrones, no compiladores. Cuando un modelo escribe import seguido de un nombre plausible, no está verificando si ese paquete existe. Está prediciendo lo que un programador seguro de sí mismo probablemente escribiría a continuación. La mayoría de las veces la predicción acierta. A veces echa mano, con total confianza, de requests_async, react-use-debounce-hook, o alguna utilidad de nombre prolijo que nadie publicó jamás.
El modelo no tiene una fuente de verdad. Tiene intuición. Y la intuición es buenísima para producir nombres que se ven exactamente como paquetes reales.
La parte que de verdad debería darte miedo
Un import alucinado no es solo un build roto. Es una superficie de ataque.
Los investigadores ya le pusieron nombre: slopsquatting. Los atacantes observan qué nombres de paquetes falsos tienden a alucinar las herramientas de IA, y luego registran esos nombres en los registros públicos con malware adentro. Tu asistente inventa trjnhrs-pkg. Alguien ya publicó trjnhrs-pkg. Tu comando de instalación resuelve sin problemas. Y ahora estás ejecutando código ajeno. El import que “no existía” ayer hoy existe, a propósito, y es hostil.
Este es el modo de fallo verdaderamente peligroso. Un typo lo detectas en cinco segundos. Un nombre de paquete plausible que resuelve en silencio hacia el payload de alguien es de esas cosas que no detectas hasta que ya está en producción.
Por qué “solo dile que no lo haga” no funciona
El hilo está lleno del consejo de siempre. Escribe mejores prompts. Dile que no cometa errores. Configura los warnings como errores. Consigue un checker.
Los primeros dos son ilusiones. No puedes hacer que un sistema probabilístico se vuelva determinista sobre hechos que no tiene. Los últimos dos se acercan, pero un linter genérico marca el síntoma (un import que no resuelve) sin entender la causa. ¿La dependencia simplemente nunca se agregó al manifiesto? ¿Es un módulo interno que el linter no ve? ¿O este paquete de verdad no existe en ningún lugar del planeta? Esos tres casos se ven idénticos para un checker tonto y necesitan respuestas completamente distintas. (Es la misma razón por la que revisarte a ti mismo no detecta los errores de aspecto plausible de una IA: lo que escribió el código no puede ser lo único que lo revise.)
Esa es la brecha que Surmado Code Review vino a cerrar.
Cómo lo detectamos de verdad: chequeos deterministas más criterio
El arreglo no es un modelo más inteligente. Es no hacerle al modelo la pregunta factual en primer lugar.
Los chequeos deterministas hacen el trabajo de saber. En cada pull request, Surmado Code Review resuelve cada import del diff contra una fuente de verdad: tu lockfile, tu manifiesto, tus módulos instalados, la biblioteca estándar, tus paquetes internos. Este paso no adivina. Un paquete o resuelve o no resuelve. Si super-fast-parser aparece en el diff y no resuelve a nada en tu grafo de dependencias ni a nada en el registro, eso es un hecho, no una opinión. Aquí no hay alucinación posible, porque no se está generando nada. Es una búsqueda.
Scout hace el trabajo de juzgar. Con los hechos en la mano, el modelo hace lo que los modelos saben hacer de verdad: clasificar y explicar. Distingue entre “olvidaste agregar esto a package.json” y “este módulo no existe, y el real más parecido se llama distinto”. Quita duplicados. Te apunta al import que casi seguro querías. Y escala el caso que da miedo: este nombre resuelve a un paquete publicado hace tres días que nada más en tu ecosistema referencia. Ese es el olor a slopsquatting, y es justo el tipo de criterio que un linter simple no puede tener.
Ninguna mitad funciona sola. Los chequeos deterministas sin criterio son ruidosos y no saben explicarse. Un modelo sin un anclaje determinista es solo otra cosa que aluciona imports, ahora revisando tus imports alucinados. Júntalos y obtienes lo que toda la gente de ese hilo quería en realidad: certeza sobre lo que es real, más criterio sobre qué hacer.
Dónde corre
Surmado Code Review comenta en tus pull requests. Revisa el diff contra el STANDARDS.MD de tu equipo y marca los imports inventados antes de que se hagan merge, no después de que ya rompieron la rama de un compañero o metieron un paquete que nadie revisó. Un comentario por PR, anclado a tus reglas, editado en el mismo lugar cuando subes un arreglo. Es la capa entre “la IA lo escribió” y “ya está en main”.
Pruébalo gratis
Construimos esto porque el problema de los imports-que-no-existen nos estaba haciendo perder tiempo, y la versión de cadena de suministro nos dio miedo de verdad. Lo usamos en nuestros propios repos; así lo construimos. Así que no lo vamos a esconder detrás de un muro.
Surmado Code Review es gratis para 10 PRs al mes. Conéctalo a un repo de GitHub, escribe un STANDARDS.MD (Scout te ayuda a redactarlo a partir de una conversación, como explicarle tu código a alguien que recién llega), y empieza a atrapar imports alucinados en tu próximo PR. Después de eso, son $15 al mes por 100 PRs. Sin precio por asiento. Cero retención de datos.
Tu IA va a seguir inventando imports. Tú no tienes por qué seguir haciéndoles merge.
Prueba Surmado Code Review gratis
Lecturas relacionadas: