Local Code Team PoC

Tres implementaciones de la misma idea: generación de código con múltiples agentes de IA, corriendo 100% localmente en tu Mac con Ollama. Sin API keys, sin nube, sin costo por token.

Cada script toma una descripción de proyecto en texto plano y genera un codebase funcional. Las implementaciones usan diferentes frameworks y arquitecturas — compararlas muestra los tradeoffs reales del diseño multi-agente.

---

Scripts

| Script | Framework | Patrón | Directorio de salida | | --- | --- | --- | --- | | team-building-aider.py | Aider | Arquitecto → Editor (2 fases, herramienta OSS) | generated-project-aider/ | | team-building-langgraph.py | LangGraph | Supervisor → Arquitecto → Programador → Revisor (bucle) | generated-project/ | | team-building-crewia.py | CrewAI | Pipeline secuencial: Arquitecto → Programador → Revisor | generated-project-crew/ |

---

Instalación en Mac

1 — Homebrew

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2 — Ollama

brew install ollama
brew services start ollama   # corre como servicio en segundo plano en el puerto 11434

3 — Modelos

ollama pull qwen3:8b          # 5.2 GB — arquitecto / planificador (modelo con razonamiento)
ollama pull qwen2.5-coder:7b  # 4.7 GB — programador / editor (especializado en código)

Requisitos de memoria unificada (Apple Silicon):

| RAM Mac | ¿Caben simultáneamente? | Recomendación | | --- | --- | --- | | 8 GB | No (~10 GB en total) | Agregar OLLAMA_MAX_LOADED_MODELS=1 a ~/.zshrc | | 16 GB | Sí | Ambos modelos activos, sin evicción | | 24 GB+ | Sí | Se puede usar qwen3:14b como arquitecto para mejores planes |

4 — Python y dependencias

brew install uv              # gestor de paquetes Python rápido
git clone <este-repo>
cd local-code-crew
uv sync                      # crea .venv e instala todas las dependencias
source .venv/bin/activate

5 — Aider (instalación aislada — sin conflictos de dependencias)

uv tool install aider-chat
# agregar al PATH si no está:
export PATH="$HOME/.local/bin:$PATH"

---

Benchmark

Prueba realizada con el mismo prompt en los 3 scripts: API REST en Node.js 20 + Express + TypeScript para una plataforma de blog. 11 archivos esperados, en una M1 Pro 16 GB.

Resultados de archivos y tiempo

| | Aider | LangGraph | CrewAI | | --- | --- | --- | --- | | Archivos generados | 9 / 11 | 11 / 11 ✅ | 11 / 11 ✅ | | Archivos faltantes | package.json, tsconfig.json | ninguno | ninguno | | Tiempo total | 7m 32s | 3m 46s | 3m 53s |

Calidad del código generado

| | Aider | LangGraph | CrewAI | | --- | --- | --- | --- | | TODOs / stubs | ninguno ✅ | ninguno ✅ | ninguno ✅ | | Middleware montado en app.ts | ❌ logger y errorHandler no conectados | ✅ | ⚠️ conectado pero paths incorrectos (../middleware en vez de ./middleware) | | Exports e imports consistentes | ✅ | ❌ logger es named export, importado como default | ❌ logger y errorHandler son named exports, importados como default | | Endpoints según el prompt | ✅ /users, /posts | ❌ cambió a /api/users, /api/posts | ✅ /users, /posts | | Dependencias extra no pedidas | ninguna | cors, helmet | ninguna |

Features de orquestación

| | Aider | LangGraph | CrewAI | | --- | --- | --- | --- | | Bucle de revisión automático | ❌ un solo paso | ✅ hasta max_iterations | ❌ un solo paso | | Revisor detectó los bugs | — | ❌ aprobó con bugs | — | | Checkpointing / reanudación | ❌ | ✅ SQLite | ❌ | | Human-in-the-loop | ❌ | ✅ configurable | ❌ | | Complejidad de instalación | Baja | Media | Media | | Dependencias | Herramienta aislada (uv tool) | venv completo | venv completo |

---

Cómo funciona cada script

team-building-aider.py — Aider

Aider es una herramienta OSS de asistencia de código con años de desarrollo. Este script es un wrapper delgado alrededor de su CLI.

Arquitectura:

prompt.txt → aider --architect → qwen3:8b (plan) → qwen2.5-coder:7b (escribe archivos)

Generación en dos fases:

1. Fase arquitecto — qwen3:8b recibe el task y escribe un plan. No toca archivos.
2. Fase editor — qwen2.5-coder:7b recibe el plan y crea cada archivo usando el sistema nativo de diff/patch de Aider.

Qué agrega el wrapper:

• Misma interfaz -f prompt.txt que los otros scripts
• Filtra advertencias cosméticas de stderr (ruido de shutdown del summarizador de Aider)
• Post-procesa el output para corregir paths con backtick (`src/ → src/) causados por el modelo arquitecto usando formato markdown en nombres de archivos

Cómo correr:

python team-building-aider.py -f prompt.txt
# o de forma interactiva:
python team-building-aider.py

---

team-building-langgraph.py — LangGraph

Implementa un bucle multi-agente con supervisor usando StateGraph de LangGraph. La implementación más compleja — y la más instructiva para aprender orquestación de agentes.

Arquitectura:

flowchart LR
    START --> supervisor
    supervisor -->|sin plan| arquitecto
    supervisor -->|sin archivos en disco| programador
    supervisor -->|archivos existen, sin veredicto| revisor
    supervisor -->|NEEDS_REVISION| programador
    supervisor -->|APPROVED| END
    arquitecto --> supervisor
    programador --> supervisor
    revisor --> supervisor

Decisiones de diseño clave:

| Decisión | Por qué | | --- | --- | | Supervisor determinista (sin LLM) | Los modelos locales de 7-8B generan razonamientos contradictorios cuando se les pide rutear — Python puro es más rápido y nunca alucina | | Una llamada LLM por archivo en el programador | Enviar todos los archivos en una sola llamada causa "drift de atención": el modelo olvida qué debe contener el archivo 9 de 11 y lo rellena con contenido incorrecto | | Contenido de archivos inyectado en el prompt del revisor | Evita la falta de confiabilidad del tool-calling; el revisor recibe el estado exacto de los archivos leídos por Python | | has_impl verifica el disco, no el historial de mensajes | "El programador corrió" ≠ "los archivos existen" — el modelo puede afirmar haber escrito archivos sin haberlo hecho |

Agentes:

| Agente | Modelo | Cómo funciona | | --- | --- | --- | | Supervisor | — | Python if/elif: verifica has_plan, has_impl, veredicto del revisor | | Arquitecto | qwen3:8b | Llamada LLM simple; debe terminar el plan con un manifiesto <files> | | Programador | qwen2.5-coder:7b | Itera sobre el manifiesto <files>, una llamada LLM por archivo, escribe bloques <file path="..."> | | Revisor | qwen2.5-coder:7b | LLM simple; Python lee todos los archivos e inyecta el contenido en el prompt antes de la llamada |

Configuración (dataclass Config al principio del archivo):

ollama_base:     str  = "http://localhost:11434"
human_in_loop:   bool = False   # pausa antes del revisor para inyectar feedback manual
max_iterations:  int  = 20
architect_model: str  = "qwen3:8b"
coder_model:     str  = "qwen2.5-coder:7b"
reviewer_model:  str  = "qwen2.5-coder:7b"

Cómo correr:

python team-building-langgraph.py -f prompt.txt

Thread ID [ENTER para nueva sesión, o ID para reanudar]:

Presiona ENTER para una sesión nueva. Ingresa un thread ID existente para reanudar desde el último checkpoint. Las sesiones persisten en .checkpoints/checkpoints.db.

Human-in-the-Loop: pon human_in_loop = True — el grafo pausa antes de cada paso del revisor y pide feedback.

---

team-building-crewia.py — CrewAI

Pipeline secuencial usando Agent, Task, Crew, Process.sequential de CrewAI. La arquitectura más fácil de leer — cada agente es una clase, cada tarea tiene un output esperado, corren en orden.

Arquitectura:

Tarea Arquitecto → Tarea Programador → Tarea Revisor  (secuencial, sin bucle)

Cómo el programador escribe archivos:

Los agentes de CrewAI generan texto — no pueden llamar herramientas del filesystem directamente. El programador recibe instrucciones de formatear cada archivo así:

<file path="src/app.ts">
...contenido...
</file>

Una función callback en la tarea del programador parsea estos tags con regex y escribe los archivos al disco cuando la tarea termina.

Limitación clave: un solo paso — si el revisor encuentra problemas, no hay bucle automático de regreso al programador (a diferencia de LangGraph). El veredicto del revisor es solo informativo.

Nota sobre modelos: El bucle ReAct de CrewAI se rompe con modelos de razonamiento (qwen3:*) cuando los agentes tienen herramientas — los tokens <think> confunden el parser de tool-calls de LiteLLM. qwen2.5-coder:7b se usa para el revisor porque tiene herramientas (leer/listar archivos) y no es un modelo de razonamiento.

Cómo correr:

python team-building-crewia.py -f prompt.txt

---

Prompts de ejemplo

Una API REST con FastAPI, SQLite, endpoints CRUD /items y tests con pytest
Una API de blog en Node.js + Express + TypeScript con usuarios, posts y comentarios
Un CLI en Python que monitorea un directorio buscando archivos .csv nuevos e imprime un resumen de filas
Un boilerplate minimal de AWS SAM con TypeScript + esbuild para Node.js 20.x
Un servidor HTTP en Go con endpoints /health y /version y un Makefile

---

Lecciones aprendidas

• El routing con LLM falla en modelos pequeños. Un supervisor-como-LLM genera monólogos internos de 500 palabras, se contradice y rutea mal. Python determinista siempre gana con modelos locales.
• El tool-calling es poco confiable en modelos 7B. qwen2.5-coder:7b vía Ollama no emite el JSON estructurado de tool-calls que espera el bucle ReAct de LangChain. Generación de texto + parsing en Python es más confiable.
• Modelos de razonamiento + herramientas = roto. qwen3:* genera tokens <think> que LiteLLM no puede parsear dentro de los bucles ReAct. Usar modelos de razonamiento solo para llamadas LLM simples (arquitecto), nunca para agentes con herramientas.
• El drift de atención es real. Pedirle a un modelo 7B que escriba 11 archivos en una sola respuesta resulta en que el archivo 9 contiene una copia del archivo 3. Una llamada por archivo con contexto enfocado lo resuelve.
• Aider gana en calidad de output porque lleva años resolviendo exactamente estos problemas. Construir pipelines propios tiene sentido cuando se necesita orquestación personalizada — no para superar a una herramienta OSS en su propio juego.
• Un revisor con LLM no es garantía de calidad. LangGraph generó código con bugs (exports incorrectos, rutas cambiadas) y el revisor lo aprobó de todas formas. La verificación automática requiere ejecución real (compilar, correr tests), no solo lectura del código.