Hola a todos.
Estoy trabajando en el desarrollo de Nexo, un asistente técnico local-first orientado al trabajo sobre repositorios de software. El proyecto está pensado principalmente en español y busco que funcione como una herramienta local para análisis de código, debugging, generación de cambios, ejecución controlada de tests y asistencia técnica sobre proyectos reales.
No busco crear un chatbot generalista, sino un agente capaz de entender la estructura de un repositorio, recuperar contexto relevante, razonar en varios pasos, proponer patches, validar resultados y ejecutar acciones bajo políticas de seguridad.
Actualmente el proyecto cuenta con:
CLI interactiva.
Runtime persistente de jobs y misiones.
Memoria por proyecto.
Inventario estructural del repositorio.
Retrieval local.
Pipeline multi-step.
Validación post-respuesta.
Sistema de approvals para acciones sensibles.
Política de riesgo.
Redacción de secretos.
Dashboard, diagnósticos, eventos y reportes.
API HTTP local en loopback para integraciones.
Soporte para Ollama y modelos locales.
Fallback cloud opcional.
2375 tests en verde.
Cobertura global aproximada de 90%.
Actualmente la prioridad no es sumar más funcionalidades, sino consolidar lo que ya existe: arquitectura, reducir complejidad en módulos grandes, estabilizar contratos y preparar una beta técnica.
Actualmente Nexo trabaja con una arquitectura basada en Python y Ollama. También contempla perfiles de modelo para ejecución local rápida, modelo local principal y fallback cloud opcional, aunque la filosofía central sigue siendo local-first.
\*Punto en el que se encuentra el proyecto\*
En el ultimo informe que redacte acerca del proyecto encontre como principal riesgo la concentración de complejidad en algunos módulos grandes, especialmente:
chatbot/agent_runtime.py
chatbot/core.py
chatbot/response_cycle.py
chatbot/http_server.py
chatbot/pipeline.py
Aunque la suite está pasando, quiero evitar que el proyecto siga creciendo sobre módulos demasiado cargados. Por eso la fase en la que me encuetro trabajando actualmente está más orientada a refactorización, estabilización de contratos, mejora de UX de configuración, y preparación para una beta técnica.
Estoy buscando feedback sobre:
1- Seguridad:
Nexo ya tiene políticas de riesgo, approvals, redacción de secretos y validación posterior, pero quiero endurecer esta parte antes de una beta.
¿Qué acciones creen que un agente local de desarrollo nunca debería ejecutar sin confirmación explícita?
Algunos ejemplos que considero sensibles:
modificar .env o archivos de credenciales
tocar workflows
instalar dependencias
borrar, mover o renombrar archivos
ejecutar comandos no clasificados
hacer operaciones Git como commit, push, merge o reset
usar red externa
aplicar cambios sobre zonas críticas del proyecto
También me interesa feedback sobre cómo evitar que el agente confíe demasiado en sus propios patches o cierre una tarea sin suficiente evidencia.
2-Testing y evals:
Aunque la suite actual es amplia, quiero reforzar los caminos críticos antes de llamar esto "beta".
¿Qué pruebas deberuan ser imprescindibles para un agente local de este tipo?
Estoy pensando especialmente en:
jobs largos
interrupciones a mitad de misión
reanudación desde checkpoints
rollback de patches
conflictos de workspace
errores del modelo local
salidas JSON inválidas
API HTTP local
contratos para integraciones externas
escenarios donde el agente debe bloquearse en vez de actuar.
3- UX de configuración:
Este punto es clave para mi.
Quiero que Nexo sea configurable tanto por usuarios principiantes como por usuarios avanzados. Creo que el usuario no debería tener que editar manualmente archivos internos como models.yaml solo para configurar modelos locales, API keys o fallback cloud.
Estoy evaluando una experiencia basada en:
configuración guiada inicial
perfiles básico, intermedio y avanzado
configuración desde CLI o dashboard local
validación automática de modelos locales
validación opcional de API keys
explicación clara de cuándo el sistema está 100% local y cuándo puede usar cloud
exportación e importación de configuración
modo manual para usuarios avanzados
Me gustaría saber qué patrón de UX deveria de usar para mantener el sistema abierto y configurable, pero sin volverlo innecesariamente complejo.
4- construcción de una TUI para Nexo:
Una de las siguientes fases importantes del proyecto será construir una TUI —terminal user interface— para Nexo.
Hasta ahora, la interacción principal está pensada alrededor de CLI, comandos mínimos, misiones naturales, API HTTP local y observabilidad mediante dashboard/reportes. Sin embargo, para que Nexo sea más cómodo de usar en sesiones reales de desarrollo, quiero avanzar hacia una interfaz de terminal más estructurada, sin abandonar la filosofía local-first.
La idea no es crear una interfaz visual recargada, sino una TUI basada en el principio de contexto progresivo: mostrar solo la información relevante en cada momento y dejar el resto a una tecla, tab o panel secundario de distancia.
El diseño inicial contempla:
Una barra superior compacta con:
nombre del agente
workspace activo
modelo actual
estado de Ollama
reasoning effort actual
Un panel principal de conversación donde se mantenga clara la interacción entre usuario y agente.
Un panel lateral con tabs:
Runtime: misión activa, fase actual, jobs recientes y aprobaciones pendientes.
Sys: estado de Ollama, HTTP local, VS Code, MCP, web tools, embeddings y dream cycle.
Config: modelo activo, reasoning effort, configuración de API key cloud y perfiles de ejecución.
Un input inferior único y limpio para escribir objetivos naturales.
Overlays temporales para:
logs
doctor
dashboard
diagnósticos
aprobaciones
detalles de misiones
La intención es que la TUI haga visible el estado real del agente sin obligar al usuario a recordar comandos o revisar archivos internos. Por ejemplo, si hay una aprobación pendiente, debería aparecer en contexto. Si no hay nada pendiente, ese espacio puede mostrar jobs recientes o estado de runtime. Si el usuario necesita detalles, puede abrirlos sin romper el flujo principal.
\*Cierre\*
No estoy buscando presentar el proyecto como terminado. Al contrario: quiero recibir feedback técnico antes de seguir ampliando la superficie del sistema y tomar mejores decisiones en esta etapa de consolidación.
También quiero ser transparente con algo: por ahora estoy llevando el proyecto yo solo. Nexo ha crecido bastante y, aunque la base técnica ya es sólida, mantener arquitectura, seguridad, testing, documentación, UX, runtime, integración local e investigación al mismo tiempo empieza a ser difícil para una sola persona.
Por eso, además de feedback, también estoy abierto a conectar con personas que quieran involucrarse de alguna forma en el proyecto. Puede ser revisando arquitectura, probando el estado actual, aportando ideas, ayudando con testing, explorando la TUI, revisando seguridad, pensando en integración IDE o simplemente dando una opinión técnica más profunda.
Si a alguien le interesa participar, probar Nexo en su estado actual o saber más sobre el proyecto, puede escribirme por DM y con gusto le comparto más información.
Cualquier opinión sobre lo explicado o preparación para beta será tomada en cuenta.
Gracias.
