OpenClaw + Claude Code Tutorial: ¡Un solo desarrollador puede construir un equipo de desarrollo completo!
OpenClaw + Claude Code Tutorial: ¡Un solo desarrollador puede construir un equipo de desarrollo completo!
Hoy comparto un caso práctico impresionante. (Tutorial al final del artículo)
Un desarrollador independiente, utilizando OpenClaw + Codex/CC, construyó un sistema de Agente AI. ¿Qué resultados logró?
94 envíos en un día, 7 PR completados en 30 minutos, y ese día también tuvo 3 reuniones con clientes, sin siquiera abrir el editor.
Esto realmente sucedió en enero de 2026. El autor ha hecho público todo el sistema de arquitectura, flujo de trabajo y configuración de código. Después de verlo, pensé que este enfoque es muy valioso para aprender, así que lo organicé en este artículo para compartirlo contigo.
Si también estás usando Codex o Claude Code, o si estás interesado en OpenClaw, este artículo te dará muchas ideas.
Un solo desarrollador, 94 envíos de código en un día
Primero, veamos algunos datos para sentir el poder de este sistema:
- Máximo de 94 envíos en un solo día (promedio de 50 envíos diarios)
- 7 PR completados en 30 minutos
- La velocidad de llevar una idea a producción es tan rápida que puede "entregar la demanda del cliente el mismo día"
¿Y el costo? $190 al mes (Claude $100 + Codex $90), un principiante puede comenzar con solo $20.
Podrías preguntar: ¿no es esto solo acumular un montón de herramientas de IA y generar código basura?
No. El historial de Git del autor parece como si "acaba de contratar un equipo de desarrollo", pero en realidad solo es él. El cambio clave es: pasó de "gestionar Claude Code" a "gestionar un mayordomo AI, que a su vez gestiona un grupo de Claude Code".
- Antes de enero: escribir código directamente con Codex o Claude Code
- Después de enero: usar OpenClaw como capa de orquestación, permitiendo que gestione Codex/Claude Code/Gemini
¿Por qué Codex y Claude Code por separado no son suficientes?
En este punto, podrías pensar: Codex y Claude Code ya son muy poderosos, ¿por qué añadir una capa de orquestación?
La respuesta del autor es muy directa: Codex y Claude Code prácticamente no saben nada de tu negocio. Solo ven el código, no ven el panorama completo del negocio.
Aquí hay una limitación fundamental: la ventana de contexto es fija, solo puedes elegir uno.
Debes decidir qué meter:
- Llenar de código → No hay espacio para el contexto del negocio
- Llenar de historial del cliente → No hay espacio para el repositorio de código
- No sabe para qué cliente se está desarrollando esta función
- No sabe por qué fracasó la última demanda similar
- No sabe tu posicionamiento de producto y principios de diseño
- Solo puede trabajar según el código actual y tu prompt
Actúa como una capa de orquestación, situada entre tú y todas las herramientas de IA. Su papel es:
- Mantener todo el contexto del negocio (datos de clientes, actas de reuniones, decisiones históricas, casos de éxito/fracasos)
- Traducir el contexto del negocio en prompts precisos, que se alimentan a agentes específicos
- Permitir que estos agentes se concentren en lo que mejor saben hacer: escribir código
- Codex/Claude Code = Chef profesional, solo se encarga de cocinar
- OpenClaw = Chef principal, conoce los gustos de los clientes, el inventario de ingredientes, la ubicación del menú, y da instrucciones precisas a cada chef
Arquitectura específica del sistema de doble capa: capa de orquestación + capa de ejecución
Veamos la arquitectura específica de este sistema.
Dos capas, cada una con su función:
¿Qué puede hacer OpenClaw (capa de orquestación)?
- Leer todos los registros de reuniones en las notas de Obsidian (sincronización automática)
- Acceder a la base de datos de producción (solo permisos de lectura) para obtener la configuración del cliente
- Tener permisos de API de administrador, puede recargar a los clientes y desbloquear directamente
- Seleccionar el agente adecuado según el tipo de tarea
- Monitorear el progreso de todos los agentes, si falla, analizar la causa y ajustar el prompt para reintentar
- Notificar al autor a través de Telegram una vez completado
¿Qué puede hacer el Agente (capa de ejecución)?
- Leer y escribir en el repositorio de código
- Ejecutar pruebas y construcciones
- Enviar código y crear PR
- Responder a los comentarios de la revisión de código
Este diseño es inteligente: el límite de seguridad es claro, mientras se garantiza la eficiencia.
Flujo de trabajo completo: 8 pasos desde la solicitud del cliente hasta la fusión del PR
Ahora entramos en la parte central. Usaremos un caso real del autor de la semana pasada para guiarte a través del proceso completo.
Contexto: Un cliente empresarial llamó y dijo que quería reutilizar su configuración ya establecida y compartirla dentro del equipo.
Paso 1: Solicitud del cliente → OpenClaw entiende y descompone
Después de la llamada, el autor y Zoe (su OpenClaw) discutieron esta solicitud.
Lo maravilloso aquí: costo de explicación cero. Debido a que todos los registros de reuniones se sincronizan automáticamente con Obsidian, Zoe ya había leído el contenido de la llamada, sabe quién es el cliente, su escenario de negocio y la configuración existente.
El autor y Zoe descompusieron la solicitud en: crear un sistema de plantillas que permita a los usuarios guardar y editar la configuración existente.
Luego, Zoe hizo tres cosas:
- Recargar al cliente — Usando la API de administrador, eliminó inmediatamente las restricciones de uso del cliente
- Obtener la configuración del cliente — Desde la base de datos de producción (solo lectura) para obtener la configuración existente del cliente
- Generar el prompt e iniciar el agente — Empaquetar todo el contexto y alimentarlo a Codex
Paso 2: Iniciar el agente
Zoe creó para esta tarea:
- Un worktree git independiente (entorno de rama aislada)
- Una sesión tmux (para que el Agente se ejecute en segundo plano)
# Crear worktree + iniciar agente git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install
tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high ¿Por qué usar tmux? Porque permite intervenir en medio del proceso.
Si la IA se desvía, no es necesario matar el proceso y empezar de nuevo, simplemente se envían comandos directamente en tmux:
# El agente se está desviando tmux send-keys -t codex-templates "Detente. Primero haz la capa API, no te preocupes por la UI." Enter
El agente necesita más contexto
tmux send-keys -t codex-templates "La definición de tipo está en src/types/template.ts, usa eso." Enter Al mismo tiempo, la tarea se registrará en un archivo JSON:{ "id": "feat-custom-templates", "tmuxSession": "codex-templates", "agent": "codex", "description": "Función de plantillas de correo electrónico personalizadas para clientes empresariales", "repo": "medialyst", "worktree": "feat-custom-templates", "branch": "feat/custom-templates", "startedAt": 1740268800000, "status": "running", "notifyOnComplete": true}
Paso 3: Monitoreo Automático
Una tarea cron verifica el estado de todos los agentes cada 10 minutos.
Punto clave: no se trata de "preguntar" al Agente cómo va el progreso (eso consume muchos tokens), sino de verificar hechos objetivos:
- ¿La sesión de tmux sigue activa?
- ¿Se ha creado un PR?
- ¿Cuál es el estado de CI?
- Si falla, ¿es necesario reiniciar? (máximo 3 reintentos)
Esto es en realidad una versión mejorada del Ralph Loop, que se explicará en detalle más adelante.
Paso 4: El Agente Crea PR
El Agente termina de escribir el código, lo envía y luego crea un PR usando gh pr create --fill.
Nota: en este momento, el autor no recibirá notificación. Porque un PR en sí mismo no representa "completo".
La definición de "completo" es:
- ✅ PR creado
- ✅ Rama sincronizada con main (sin conflictos)
- ✅ CI aprobado (lint, verificación de tipos, pruebas unitarias, pruebas E2E)
- ✅ Revisión de Codex aprobada
- ✅ Revisión de Claude aprobada
- ✅ Revisión de Gemini aprobada
- ✅ Si hay cambios en la UI, debe incluir capturas de pantalla
Paso 5: Revisión de Código Automatizada
Cada PR será revisado por tres Agentes:
- Revisor de Codex — El revisor más confiable - experto en detectar casos límite
- Puede identificar errores lógicos, manejo de errores faltantes, condiciones de carrera
- Tasa de falsos positivos muy baja
- Revisor de Asistencia de Código Gemini — Gratuito y fácil de usar - puede detectar problemas de seguridad y escalabilidad que otros revisores pasaron por alto
- Proporcionará sugerencias específicas de corrección
- No hay razón para no usarlo
- Revisor de Código Claude — Básicamente inútil - excesivamente cauteloso, siempre sugiere "considerar agregar..."
- La mayoría de las sugerencias son sobre diseño excesivo
- A menos que se marque como "crítico", se salta directamente
Paso 6: Pruebas Automatizadas
El pipeline de CI ejecutará:
- Verificaciones de Lint y TypeScript
- Pruebas unitarias
- Pruebas E2E
- Pruebas de Playwright (ejecutadas en un entorno de vista previa idéntico al de producción)
Esta regla ha reducido drásticamente el tiempo de revisión: el autor puede ver de un vistazo la captura de pantalla y saber qué se ha cambiado, sin necesidad de entrar en el entorno de vista previa.
Paso 7: Revisión Manual
Ahora, el autor recibe una notificación de Telegram: "PR #341 está listo para revisión."
En este momento:
- CI está completamente verde
- Los tres revisores AI han aprobado
- La captura de pantalla muestra el cambio en la UI
- Todos los casos límite están registrados en los comentarios de revisión
Paso 8: Fusión
Se fusiona el PR. Cada día hay una tarea cron que limpia los worktrees aislados y los registros de tareas.Completo el proceso, desde la necesidad del cliente hasta el despliegue del código, puede que solo haya tomado de 1 a 2 horas, mientras que la inversión real del autor puede haber sido solo de 10 minutos.
Tres mecanismos para hacer que el sistema sea más inteligente
Mecanismo 1: Ralph Loop mejorado — No solo repetir, sino aprender
Es posible que hayas oído hablar del Ralph Loop: extraer contexto de la memoria → generar salida → evaluar resultados → guardar aprendizaje.
Pero la mayoría de las implementaciones tienen un problema: el prompt utilizado en cada ciclo es el mismo. Lo que se aprende mejora la recuperación futura, pero el prompt en sí es estático.
Este sistema es diferente.
Cuando el Agente falla, Zoe no reinicia con el mismo prompt. Ella lleva el contexto completo del negocio, analiza la causa del fallo y luego reescribe el prompt:
❌ Mal ejemplo (prompt estático): { "Implementar función de plantilla personalizada" }
✅ Buen ejemplo (ajuste dinámico): { "Detente. El cliente quiere X, no Y. Estas son sus palabras en la reunión: Queremos conservar la configuración existente, en lugar de crear una nueva desde cero. Enfócate en la reutilización de configuraciones, no en crear un nuevo proceso." }Zoe puede hacer este tipo de ajustes porque tiene contexto que el Agente no tiene:
- Lo que el cliente dijo en la reunión
- A qué se dedica la empresa
- Por qué falló la última solicitud similar
- Por la mañana: escanea Sentry → encuentra 4 nuevos errores → inicia 4 Agentes para investigar y reparar
- Después de la reunión: escanea las actas de la reunión → encuentra 3 requisitos de funcionalidad mencionados por los clientes → inicia 3 Codex
- Por la noche: escanea el git log → inicia Claude Code para actualizar el changelog y la documentación del cliente
Los patrones exitosos se registran:
- "Esta estructura de prompt es muy efectiva para la función de facturación"
- "Codex necesita recibir las definiciones de tipo con anticipación"
- "Siempre debe incluir la ruta del archivo de prueba"
Cuanto más tiempo pasa, mejor es el prompt que escribe Zoe, porque recuerda qué ha tenido éxito.
Mecanismo 2: Estrategia de selección de Agentes — Diferentes tareas requieren diferentes expertos
No todos los Agentes son igual de fuertes. La estrategia de selección resumida por el autor:
- Codex(gpt-5.3-codex) — Principal - Lógica de backend, errores complejos, reestructuración de múltiples archivos, tareas que requieren inferencia entre bibliotecas de código
- Lento pero exhaustivo
- Cubre el 90% de las tareas
- Claude Code(claude-opus-4.5) — Competidor rápido - Trabajo de frontend
- Menos problemas de permisos, adecuado para operaciones de git
- (El autor lo usaba más antes, pero cambió a Codex 5.3)
- Gemini — Diseñador - Tiene sentido estético
- Para una UI atractiva, primero deja que Gemini genere las especificaciones HTML/CSS, luego se las pasa a Claude Code para implementarlas en el sistema de componentes
- Gemini diseña, Claude construye
Mecanismo 3: ¿Dónde está el cuello de botella? RAM
Aquí hay una limitación inesperada: no es el costo de tokens, no es la tasa de API, sino la memoria.
Cada Agente necesita:
- Su propio worktree
- Sus propios node_modules
- Ejecutar construcción, verificación de tipos, pruebas
El Mac Mini del autor (16GB de RAM) puede ejecutar un máximo de 4-5 Agentes al mismo tiempo, más que eso comenzará a hacer swap, y hay que rezar para que no construyan al mismo tiempo.Así que compró una Mac Studio M4 Max (128GB RAM, $3500), que llegó a finales de marzo. Dijo que compartirá si valió la pena.
También puedes construirlo: solo toma 10 minutos desde cero
¿Quieres probar este sistema?
La forma más sencilla:
Copia todo este artículo a OpenClaw y dile: "Implementa un sistema de clúster de Agentes para mi repositorio de código según esta arquitectura."
Entonces, hará lo siguiente:
- Leerá el diseño de la arquitectura
- Creará scripts
- Configurará la estructura de directorios
- Configurará la monitorización de cron
Necesitas preparar:
- Cuenta de OpenClaw
- Acceso a la API de Codex y/o Claude Code
- Un repositorio git
- (Opcional) Obsidian para almacenar el contexto del negocio
2026: La compañía de un millón de dólares de una sola persona
El autor dijo algo al final que me pareció muy inspirador:
"Veremos una gran cantidad de compañías de un millón de dólares de una sola persona aparecer a partir de 2026. El apalancamiento es enorme, pertenece a aquellos que entienden cómo construir sistemas de IA de auto-mejora recursiva."
Así es como se verá:
- Un orquestador de IA como tu extensión (como Zoe para el autor)
- Delegar trabajo a Agentes especializados, manejando diferentes funciones del negocio
- Ingeniería, soporte al cliente, operaciones, marketing
- Cada Agente se enfoca en lo que mejor sabe hacer
- Tú te mantienes enfocado y con control total
Ahora hay demasiados contenidos basura generados por IA. Todo tipo de exageraciones, todo tipo de demos llamativos de "centros de control de tareas", pero sin nada realmente útil.
El autor dice que quiere hacer lo contrario: menos exageración, más documentación del proceso de construcción real. Clientes reales, ingresos reales, envíos reales a producción, y también fracasos reales.
Este artículo termina aquí.
Resumen de los puntos clave:
- Arquitectura de doble capa: la capa de orquestación mantiene el contexto del negocio, la capa de ejecución se enfoca en el código
- Automatización completa: un proceso de 8 pasos desde la demanda hasta el PR, la mayoría de las tareas se completan con éxito en un intento
- Aprendizaje dinámico: no se trata de ejecutar repetidamente, sino de ajustar la estrategia según las razones del fracaso
- Costos controlables: comienza en $20/mes, uso intensivo $190/mes
Dirección de referencia:Contenido: https://x.com/elvissun/status/2025920521871716562
