Emacs-copilot: completado de código con modelos de lenguaje grandes para Emacs

Artículo original ↗ Discusión en Hacker News ↗

Los usuarios de Emacs reaccionan a un nuevo complemento “emacs-copilot” que lleva al editor la completación de código al estilo GitHub Copilot usando modelos de lenguaje grandes ejecutados localmente mediante la pila llamafile/llama.cpp de Mozilla. Los comentaristas valoran las ventajas de los modelos autohospedados para privacidad, control y rendimiento frente a las APIs en la nube, y debaten estilos de interacción como completaciones bajo demanda frente a completaciones empujadas constantemente. El proyecto también suscita preocupaciones por conflictos de nombre con clientes de Copilot ya existentes en Emacs, posibles problemas de marca registrada de Microsoft alrededor de “Copilot”, y el modelo de seguridad de distribuir paquetes de modelos ejecutables en lugar de archivos de pesos planos.

Nomenclatura, marcas registradas y confusión

  • El nombre del paquete “copilot” es confuso porque Emacs ya tiene un cliente de GitHub Copilot con un nombre similar.
  • Varios comentarios discuten si “Copilot” es o puede ser una marca registrada de Microsoft y cómo eso se cruza con el uso genérico.
  • Algunos argumentan que está bien mientras no haya intención de confundir a los usuarios ni de lucrarse con la confusión de marca; otros anticipan presión legal de todos modos.

Arquitectura, llamafile y rendimiento

  • El paquete usa llamafile (llama.cpp dentro de un “ejecutable realmente portable”) para ejecutar modelos locales.
  • La carga basada en mmap evita recargar completamente el modelo cada vez; la primera completación en un archivo es más lenta, y las siguientes son mucho más rápidas gracias a una caché junto al archivo.
  • Los modelos grandes (p. ej., 34B) son utilizables pero lentos; los modelos cuantizados más pequeños como WizardCoder 13B o Phi-2 se ejecutan de forma aceptable en máquinas de gama media.
  • Actualizar llamafile no requiere estrictamente volver a descargar los pesos; los usuarios pueden extraer pesos GGUF y volver a empaquetarlos en un nuevo binario o apuntar un llamafile genérico a pesos externos con -m.

Local frente a remoto / autohospedado frente a nube

  • Hay un fuerte entusiasmo por los LLM autohospedados para evitar enviar código a OpenAI/Microsoft y conservar el control.
  • Algunos quieren ejecutar modelos en servidores de la LAN o vía SSH; se comentan ejemplos usando ssh con call-process y las API HTTP de llamafile.
  • Otros señalan que herramientas existentes como ollama y el servidor de llama.cpp ya proporcionan endpoints al estilo OpenAI con streaming.

UX: completaciones bajo demanda frente a en línea

  • Algunos usuarios prefieren el estilo de GitHub Copilot: sugerencias en línea grises que aparecen automáticamente.
  • Otros detestan profundamente las completaciones “push”, porque las encuentran distractoras; prefieren interacciones explícitas de “piensa cuando te lo pida” y poder interrumpir el streaming.
  • Hay acuerdo en que lo ideal sería una configurabilidad entre modos push/pull.

Ecosistema y alternativas

  • Se mencionan varios paquetes de LLM para Emacs: gptel, ellama, modos relacionados con ChatGPT, llm.el, herramientas integradas con org y un cliente de GitHub Copilot.
  • Para Vim/Neovim, los usuarios mencionan gp.nvim, gen.nvim y comandos personalizados; algunos bifurcan complementos para mezclar modelos locales (ollama) y remotos.

Seguridad y confianza

  • Algunos desconfían de los llamafiles ejecutables frente a archivos “tontos” de pesos del modelo, trazando analogías con formatos pickle inseguros.
  • Otros responden que llamafile está respaldado por una organización de reputación y que también puede usarse con pesos GGUF externos; los modelos de amenaza difieren.

Problemas de configuración y plataformas

  • Varios usuarios en macOS y Asahi Linux encuentran vfork: Exec format error cuando Emacs lanza llamafile.
  • Las soluciones incluyen usar un intérprete “ape”, convertir llamafiles en binarios nativos con “assimilate”, o ejecutar un Emacs vinculado con Cosmo.

Debate sobre la utilidad de los LLM

  • Algunos están entusiasmados, especialmente para Lisp y trabajo con mucho código repetitivo (p. ej., React moderno).
  • Otros argumentan que revisar y validar la salida de un LLM anula las ganancias de productividad para código de producción de alta calidad, y temen que los desarrolladores desvíen la responsabilidad (“lo escribió el modelo”).