Asistente de código local: el código fuente no sale

Un asistente de programación ve más de una empresa que casi cualquier otra herramienta. Lee el código fuente, los comentarios, los archivos de configuración, a veces una credencial que se coló en el repositorio por descuido. Si ese asistente vive en la nube, estás mandando justo eso a un tercero. Para muchos equipos, ahí es donde aparece la duda.

La buena noticia: el asistente ya no tiene por qué dejar salir el código. La semana pasada explicamos cómo montar una IA local para muchos usuarios a la vez con vLLM u Ollama. Aquello era el lado del servidor. Esta vez miramos un uso concreto encima, programar, y si un asistente en local basta de verdad en el día a día. Lo nuevo de este verano es sobre todo que los modelos abiertos de código dieron un salto y las herramientas alrededor se han estabilizado.

Por qué el código fuente es un caso aparte

Con un chatbot de atención al cliente se puede discutir cuán delicadas son las entradas. Con el código fuente la cosa está más clara. Suele ser el activo central de la empresa, contiene la lógica de negocio, y muchos contratos con clientes dicen con todas las letras que no puede ir a terceros. Un despacho, una pasarela de pagos o un proveedor que guarda conocimiento de diseño ajeno no se lo puede permitir.

A eso se suma la protección de datos. En los datos de prueba, los mensajes de error y los comentarios suele haber datos personales reales. Si llegan a un proveedor fuera de la UE, la transferencia es un asunto propio que habría que justificar. Un modelo que corre en local esquiva la pregunta, porque el contenido nunca sale del equipo.

Qué corre en local hoy

El montaje tiene dos partes: un modelo y una herramienta que lo integra en el trabajo.

Para código se ha impuesto una familia. Qwen3-Coder-Next, un modelo abierto del equipo Qwen de Alibaba, trabaja según las especificaciones publicadas con unos 80000 millones de parámetros, de los cuales solo unos 3000 millones están activos por token. Ese diseño permite que quepa en una sola workstation y aun así se acerque, según los informes, a la variante mucho mayor de 480000 millones de parámetros. Con menos hardware se recurre a modelos de código más pequeños, de 7000 a 32000 millones.

Para la herramienta hay varios caminos, según el estilo de trabajo:

• Ollama como servidor de modelos local con una interfaz compatible con OpenAI. El modelo queda listo como servicio, y una llamada como aider --model ollama/qwen2.5-coder:32b basta para un agente de terminal totalmente local.
• Continue como extensión en el editor. Apunta a cualquier servidor compatible con OpenAI, local o autoalojado, y lleva el autocompletado y el chat directo a VS Code o a un entorno JetBrains.
• Tabby como servidor de asistente autoalojado propio. Indexa el repositorio, funciona en VS Code, JetBrains y Vim, y trae control de administración, lo que lo hace interesante para equipos.

Ninguno de los tres necesita nube si lo ejecutas en local puro. La elección depende de si prefieres la terminal, el editor o un servidor central para todo el equipo.

Qué tan bueno es de verdad

Con sinceridad: muy bueno para lo pequeño del día a día, todavía no al nivel de la nube para las tareas más grandes, pero la distancia se acorta.

Autocompletado, explicar código ajeno, escribir tests, refactorizaciones menores: los modelos abiertos de código lo resuelven bien hoy según la comunidad. En las grandes tareas agénticas, es decir un cambio que abarca muchos archivos y planifica varios pasos por su cuenta, los mayores modelos de nube aún van algo por delante. Como referencia, la comunidad cita en torno al 70 por ciento en la prueba SWE-Bench Verified para Qwen3-Coder-Next, una cifra que conviene leer como orientación, no como garantía.

Sobre la velocidad: un modelo pequeño de 7000 millones de parámetros corre incluso en una CPU pura con 8 gigabytes de memoria según mediciones de la comunidad, ahí a unos 10 a 15 tokens por segundo. Suficiente para autocompletar, pesado para respuestas largas. Con una tarjeta gráfica o Apple Silicon con bastante memoria unificada se vuelve fluido.

La trampa de la palabra local

Aquí conviene precisión, porque local no es automáticamente privado. Varias de las herramientas citadas han introducido niveles de nube opcionales, a veces de pago. En ellos, ciertas funciones sí pasan por los servidores del proveedor, aunque la herramienta se conozca como local.

En la práctica eso significa que no decide la marca la confidencialidad, sino la función concreta que activaste. Un modelo alojado en tu equipo puede ser privado mientras una función añadida del mismo programa manda tu petición hacia fuera. Antes de confiar repositorios confidenciales a un montaje, comprueba en cada función activa si calcula en local. Ayuda una prueba sencilla: corta la red y mira qué sigue funcionando. Lo que aguanta sin conexión corre en local.

Para quién compensa

Más claro para equipos cuyo código no puede salir por motivos contractuales o legales, o sea finanzas, infraestructura crítica, despachos, y cualquier sitio donde el repositorio guarde conocimiento operativo ajeno. Para ellos el asistente local no es una renuncia, es la única opción que ni siquiera pone en juego la confidencialidad.

Empezar es más pequeño de lo que suena. Un modelo, una herramienta, una workstation, y un repositorio acotado como primer caso de prueba. En unos días ves si la calidad y el ritmo aguantan tu trabajo, sin que un solo fragmento salga del edificio. Para una pyme española, parte del hardware puede encajar en ayudas como las de Kit Digital, y cómo se ve un montaje local con la soberanía del dato en mente lo describimos en soberanía del dato.

¿Quieres saber si un asistente de código local sirve para tu equipo? En un proyecto piloto montamos modelo, herramienta y flujo de datos sobre un repositorio real y medimos calidad y ritmo antes de que te comprometas.