Fábrica de software: iterando hacia un sistema multiagente local que ya no depende del modelo
De conversaciones frágiles a un flujo gobernado por estado que sobrevive al cambio de LLM.
Durante meses intenté que varios agentes locales trabajaran juntos usando solo Ollama y LangChain.
Al principio parecía que funcionaba: generaban arquitectura razonable, proponían código coherente y mantenían algo de contexto.
Pero en cuanto el sistema superaba las 2-3 iteraciones, siempre aparecían los mismos tres problemas.
1. El patrón de fallo
El flujo dependía de mí, del prompt inicial y del modelo.
- Yo tenía que decidir constantemente: "ahora el reviewer", "vuelve al coder", "esto ya vale".
- Un pequeño cambio en el primer prompt generaba planes distintos y resultados incompatibles horas después.
- Si pasaba de llama3 a qwen2.5:1.5b, la calidad caía en picado y había que reajustar todo.
El sistema no era estable. Dependía de factores externos.
2. El cambio que lo cambió todo
Dejé de preguntarme "¿cómo hago que el modelo sea más inteligente?"
y empecé a preguntarme:
"¿cómo diseño un proceso que funcione decentemente aunque el modelo sea mediocre?"
Ese giro fue el punto de inflexión.
3. Arquitectura actual (simplificada)
El sistema ya no es una conversación. Es una máquina de estados:
- Estado central: TypedDict con todo lo importante (input, plan, código, review, tool_request, iteraciones…).
- Coordinador: no piensa, solo mira el estado y aplica reglas simples para decidir el siguiente nodo.
- Nodos especializados: Planner, Coder, Tool Executor, Reviewer y Gestor de Contexto.
- Memoria persistente: todo queda registrado en
memoria_del_proyecto.md. - Gates automáticos: límites de iteraciones para evitar bucles infinitos.
4. Desacoplar el sistema del modelo
Ahora uso dos modelos según la tarea:
- qwen2.5:1.5b (986 MB) para coordinación y revisión
- llama3 solo cuando el Coder genera código real
Si mañana cambio de LLM, solo toco el .env. El flujo, las reglas y los contratos siguen exactamente iguales.
5. Caso real: "Quiero crear un endpoint de login"
Input del usuario:
"Quiero crear un endpoint en el backend para hacer login."
Después de un ciclo completo, el sistema generó plan, código, review y ejecutó tools. Pero la review detectó problemas.
Fragmento real de memoria_del_proyecto.md (Iteración 1):
## Review { "estado": "REQUIERE_CAMBIOS", "motivo": "Falta hash de contraseña, no hay dependencia inyectada de servicio de auth, endpoint sin prefijo /auth", "siguiente": "coder" } Iteración 2 — Corrección (Coder)
## Codigo (corrección) { "cambios": [ "Añadido hash de contraseña con bcrypt", "Servicio de autenticación inyectado", "Ruta movida a /auth/login" ] } Review (final)
{ "estado": "OK", "siguiente": "done" } El sistema detectó los fallos, corrigió automáticamente y cerró el ciclo sin intervención manual. Todo quedó trazado en la memoria.
6. Qué ha cambiado de verdad
Antes
Conversación
Prompts largos
Decisiones implícitas
Dependencia del modelo
Ahora
Estado explícito
Reglas claras
Transiciones automáticas
Trazabilidad total
Desacoplamiento del modelo
7. Lo que más valor tiene
- Un buen proceso con un modelo medio > un proceso débil con un modelo excelente
- La memoria estructurada vale más que tener todo en contexto
- Separar coordinación de ejecución permite usar modelos distintos en cada capa
8. Próximos pasos
- Introducir la "unidad_implementable" con scope y acceptance criteria
- Pausa humana real antes de escrituras críticas
- Que el Reviewer pueda ejecutar tests automáticamente
- Un pequeño dashboard HTML con el historial visual del flujo
9. Cierre
El sistema ya no depende de que el prompt sea perfecto,
ni de que el modelo sea brillante,
ni de que yo esté guiando cada paso.
Depende de algo mucho más poderoso:
que el proceso esté bien definido.
Y cuando eso ocurre, deja de ser un experimento con LLMs
y empieza a comportarse como una verdadera fábrica de software.
La diferencia no es el modelo.
Es que ahora el sistema tiene reglas para comportarse.
Comentarios
Publicar un comentario