Deja de quemar tokens: el ciclo de desarrollo con Claude Code + OpenClaw

Una sesión seria de desarrollo dentro de OpenClaw — construir un servicio backend, depurar integraciones, iterar sobre una API — puede quemar entre 50 € y más de 100 € en tokens de Sonnet antes de llegar a la mitad. No porque algo esté roto. OpenClaw mantiene el estado del workspace, carga contexto de forma agresiva, ejecuta bucles de razonamiento y realiza llamadas a herramientas en cada paso. Eso es lo que hace que la orquestación funcione. También hace que escribir endpoints CRUD sea absurdamente caro.

La causa raíz: OpenClaw está construido para razonamiento a nivel de sistema. Usarlo para escribir tests unitarios es como usar una llave dinamométrica para clavar clavos.

Separa la orquestación de la programación

Divide el trabajo entre dos herramientas:

Claude Code funciona con una suscripción plana — aproximadamente 17 €/mes. La programación intensiva se mantiene dentro de ese coste fijo. OpenClaw solo toca el proyecto cuando necesitas razonamiento a nivel de sistema: diseñar arquitectura, validar integraciones, identificar casos límite entre componentes.

He visto que la diferencia de coste se acerca al 80% en proyectos que de otro modo serían sesiones puras de Sonnet.

Git como interfaz entre agentes

Git se convierte en el contrato entre los dos entornos. OpenClaw hace commit de las decisiones de arquitectura. Claude Code hace commit de la implementación. Ninguno necesita saber qué hizo el otro internamente — leen el estado actual del repositorio y trabajan a partir de ahí.

Una estructura de repositorio limpia importa:

repo/
 ├─ src/
 ├─ tests/
 ├─ docs/
 ├─ requirements.md
 ├─ architecture.md
 └─ README.md

El archivo requirements.md es la única fuente de verdad — la especificación que Claude Code lee para entender qué construir, y que OpenClaw actualiza cuando cambia el alcance. Trátalo como un contrato, no como un borrador.

Haz commit en cada traspaso. Esto te da un historial reproducible y rollbacks fáciles si un pase de razonamiento sale mal.

OpenClaw diseña el framework

Empieza en OpenClaw, pero usa un modelo de razonamiento barato como DeepSeek Chat para esta fase. No necesitas Sonnet para esbozar arquitectura.

El objetivo es producir artefactos, no código:

• requirements.md — qué debe hacer el sistema
• architecture.md — cómo está estructurado, qué componentes existen
• Layout inicial de archivos — archivos vacíos o stubs mostrando la estructura prevista
• Contratos de API — firmas de endpoints, formas de request/response, códigos de error
• Lista de tareas — trabajo de implementación ordenado

Mantén la programación real al mínimo. OpenClaw debe definir el esqueleto, no rellenarlo. Unas pocas líneas de boilerplate por archivo está bien. Implementaciones completas no.

Una vez que el esqueleto existe:

git init
git add .
git commit -m "Initial architecture and requirements"
git push

Ese push es el traspaso.

Claude Code implementa el proyecto

Claude Code clona el repositorio, lee requirements.md y architecture.md, y empieza a construir.

Aquí es donde justifica el coste de la suscripción. Es genuinamente excelente en:

• Implementar funcionalidades completas a partir de una especificación
• Escribir código limpio e idiomático
• Construir suites de tests con cobertura significativa
• Ejecutar tests localmente y corregir fallos
• Escribir documentación inline y secciones del README
• Primera pasada de refactorización una vez que las funcionalidades funcionan

Una sesión típica para un servicio backend:

→ Implementar módulo de autenticación según architecture.md
→ Escribir tests unitarios para el módulo de auth
→ Implementar endpoints CRUD de usuario
→ Escribir tests de integración contra los endpoints
→ Corregir tres tests fallidos
→ Actualizar README con instrucciones de configuración
→ Ejecutar black + isort

Todo eso dentro de la suscripción. Sin coste por token. Cuando la sesión termina:

git add .
git commit -m "Implement auth module and user endpoints with tests"
git push

OpenClaw valida la integración

Trae el repositorio de vuelta a OpenClaw. Ahora úsalo para lo que realmente es bueno.

git pull

El trabajo de OpenClaw en esta fase:

• ¿El código implementado coincide con la especificación de arquitectura?
• ¿Hay bugs de interacción entre componentes que los tests unitarios no detectarían?
• ¿Faltan casos límite en los contratos de API?
• ¿El manejo de errores se sostiene a lo largo de todo el ciclo de vida de la petición?

OpenClaw encontrará cosas que Claude Code pasó por alto — no porque Claude Code sea peor programando, sino porque el razonamiento a nivel de integración requiere mantener todo el sistema en contexto simultáneamente. Eso es exactamente para lo que está construida la gestión de contexto de OpenClaw.

El resultado es una lista de problemas, no correcciones:

## Problemas de integración encontrados

1. La expiración del token de auth no se propaga a los servicios downstream
2. El endpoint de eliminación de usuario no hace cascade a los recursos relacionados
3. El rate limiting se aplica antes de la verificación de auth — debería ser al revés
4. Falta respuesta de error para cuerpo JSON malformado

Haz commit de esto como un archivo de requirements actualizado, push, y devuélvelo a Claude Code.

El bucle de iteración

El desarrollo se convierte en un ciclo ajustado:

OpenClaw → arquitectura / feedback de integración / identificación de problemas
    ↓
Claude Code → implementación / tests / correcciones / refactorización
    ↓
git commit → git push → git pull
    ↓
repetir

Cada herramienta opera en su nivel natural. Claude Code nunca razona sobre arquitectura del sistema. OpenClaw nunca escribe un bucle for. Git los mantiene limpiamente separados.

Un servicio backend que podría llevar un día entero de sesiones puras de OpenClaw puede pasar por arquitectura, implementación y validación en unas pocas horas — a una fracción del coste.

La pasada final de refactorización

Una vez que el proyecto se estabiliza — los tests pasan, los problemas de integración están resueltos, la especificación está completamente implementada — entrega el repositorio a Claude Code una última vez.

• Unificar el estilo de código entre módulos escritos en diferentes sesiones
• Simplificar la arquitectura que se complicó durante la iteración
• Expandir docstrings y documentación
• Eliminar código muerto e imports no utilizados
• Finalizar la cobertura de tests y añadir casos límite faltantes

Esta pasada es barata. Trabajo puro de programación sin ambigüedad arquitectónica.

Cuándo funciona y cuándo no

Ideal para servicios backend, APIs, herramientas de automatización, herramientas CLI, código de infraestructura — cualquier cosa que eventualmente se integre en un flujo de trabajo de OpenClaw.

Menos útil para scripts muy pequeños (la sobrecarga no compensa), prototipado exploratorio (no tienes una especificación que traspasar), o tareas puntuales donde el tiempo total de programación es menor a una hora.

Consejos prácticos

Mantén los prompts de OpenClaw cortos. Estás pagando por razonamiento, no por contexto. No pegues codebases enteros cuando quieras una opinión arquitectónica — describe la estructura y deja que razone a partir de ahí.

Haz commit en cada traspaso. No pases un directorio de trabajo sucio entre herramientas. Cada traspaso es un commit.

Trata requirements.md como inmutable durante la implementación. Los cambios en los requisitos pasan por OpenClaw, se hacen commit, y luego Claude Code los recoge. No dejes que Claude Code modifique la especificación.

Deja que Claude Code sea dueño de los tests. OpenClaw identifica qué necesita testing a nivel de integración. Claude Code escribe el código de test real.

Evita escribir código dentro de OpenClaw a menos que sea lógica de pegamento. En el momento en que estás implementando lógica de negocio en una sesión de OpenClaw, estás quemando tokens caros en trabajo barato.

El principio

OpenClaw es excelente en lo que está diseñado para hacer. El error es usarlo para todo.

Implementación, testing, refactorización, documentación — eso pertenece a Claude Code con un coste de suscripción fijo. Arquitectura, validación de integraciones, razonamiento a nivel de sistema — eso pertenece a OpenClaw donde la gestión de contexto justifica el gasto en tokens.

Git es el apretón de manos. Cada commit es un traspaso limpio. Cada pull es una carga de contexto fresca. Los agentes nunca necesitan saber el uno del otro — solo el estado actual del repositorio.

Puedes pegar la URL de este post en Claude Code o en tu asistente de IA favorito como contexto al configurar este flujo de trabajo.

Dónde ejecutar esto

Necesitas un VPS que pueda ejecutar OpenClaw de forma fiable. Hetzner te da 10 € de crédito al registrarte — un CX22 a 4,85 €/mes maneja OpenClaw y tus repositorios Git sin problemas. Es donde funciona este blog.

Si prefieres saltarte el self-hosting por completo, xCloud ofrece hosting gestionado de OpenClaw. Apuntar, clic, desplegar — sigues teniendo el mismo flujo de trabajo híbrido, solo que sin mantener el servidor tú mismo.

Para equipos que quieren la capa de orquestación sin el trabajo de infraestructura, ClawTrust es una plataforma de automatización con IA que gestiona la parte de OpenClaw de este bucle como un servicio gestionado.

(Enlaces de afiliado — nos llevamos una pequeña comisión si te registras, sin coste para ti.)