Por qué construí un agente de código local
Un poco de hartazgo, un poco de curiosidad y muchas ganas de tener algo que funcione en la propia máquina sin necesitar tarjeta de crédito ni conexión a internet.
Todo empezó con una sesión de trabajo bastante frustrante. Tenía un proyecto privado, con código sensible, y quería que un asistente de IA me ayudara a refactorizar un módulo completo. El problema: para usar cualquier herramienta de las "buenas" tenía que pegar mi código en un servicio en la nube de alguien más, confiar en que no lo usarían para entrenar un modelo futuro, y pagar por token.
No era dramático. Pero tampoco era lo que quería. Así que empecé a buscar alternativas.
La pregunta del millón: ¿por qué no usás X?
La respuesta corta: las probé todas. Ollama es excelente para correr modelos localmente, pero no es un agente de código. LM Studio tiene una interfaz bonita pero tampoco. Los agentes que existían eran Python, requerían 47 dependencias, y ninguno tenía la experiencia de uso que me parecía razonable para alguien que quiere simplemente abrir la app y ponerse a trabajar.
Quería algo que se comportara más como una herramienta y menos como un experimento de laboratorio.
Entonces decidí construirlo. Y acá está la parte donde la gente suele preguntar "¿pero no es demasiado trabajo?". Sí. Y también no. Depende de cómo lo encarés.
Elegir el stack
Lo primero fue decidir cómo construirlo. Tenía algunas restricciones claras:
- Desktop nativo, no una web app. Quería que funcionara sin servidor, sin deployar nada.
- Rendimiento real, especialmente para la parte que lanza y habla con el modelo.
- UI moderna, sin sacrificar todo el tiempo de desarrollo aprendiendo a hacer un frontend en Rust.
La combinación que me convenció fue Tauri 2 + Rust para el backend y Svelte 5 para el frontend. Tauri básicamente te da un webview donde corre tu app Svelte, y toda la lógica "de sistema" vive en Rust: lanzar procesos, manejar archivos, hablar con el modelo. Lo mejor de los dos mundos, más o menos.
Para el motor del modelo elegí llama.cpp, específicamente su servidor HTTP llama-server. Es un binario compilado, arranca rápido, expone una API compatible con OpenAI y soporta GPU offload sin que tengas que tocar nada de código. Perfecto.
La primera versión que funcionó
La primera versión que realmente funcionó de punta a punta fue bastante austera. Tenías un campo de texto, mandabas un mensaje, el modelo respondía con streaming (token a token, como los servicios en la nube) y listo. Sin herramientas, sin agente, sin nada fancy.
Pero funcionaba. El modelo corría en mi máquina, el código nunca salía de mi red local, y la latencia era razonable incluso en CPU. Eso ya era suficiente para validar que la dirección era la correcta.
El primer mensaje que generó Aleph completo, de punta a punta, fue "Hola. Soy Agent Aleph. ¿En qué puedo ayudarte?" Y fue ridículamente satisfactorio verlo aparecer token a token.
Qué viene después
A partir de esa base simple, fuimos agregando cosas: gestor de modelos, descarga desde Hugging Face, detección de hardware, sistema de herramientas, modo agente... Cada una de esas partes tiene su propia historia, y las vamos a contar acá.
Agent Aleph no es perfecto todavía. Funciona sólo en Linux x64, tiene algunas limitaciones de MVP, y hay un montón de cosas en la lista. Pero es completamente local, completamente tuyo, y cada semana es un poco mejor.
Si querés seguir el proceso, estás en el lugar correcto.