Cómo cambiar de coding agent o modelo sin perder la tarea
Transfiere una tarea entre coding agents y modelos con un handoff estructurado, sin secretos y con una comprobación enfocada.
Índice
Al abordar problemas de ingeniería complejos, los desarrolladores suelen cambiar entre coding agents: por ejemplo, pueden empezar a planificar la arquitectura en Claude Code y después intentar un refactor algorítmico o la generación de pruebas en Codex u otro modelo. Sin embargo, volcar el registro completo de una conversación en un agente nuevo llena su contexto de hipótesis obsoletas y desperdicia tokens y tiempo.
Cambiar de modelo solo resulta eficaz si se basa en una tarjeta de handoff formalizada y portable, además de un paso de verificación enfocado; no si se intenta transferir un historial de chat ilimitado.
1. Comparar cambios: modelo, herramienta o proveedor de API
No confundas tres operaciones esencialmente distintas:
| Dimensión | Cambiar el modelo dentro del agent | Cambiar de herramienta (Claude Code ↔ Codex) | Cambiar de proveedor de API |
|---|---|---|---|
| Qué cambia | El parámetro Model ID de la configuración | El cliente CLI, el protocolo y la orquestación de herramientas | El endpoint, la Base URL y la clave de autenticación |
| Contexto de la tarea | Se conserva dentro de la sesión actual | Reinicio completo de la sesión; requiere un handoff limpio | Se conserva en la configuración del entorno local |
| Protocolo de API | Anthropic u OpenAI (sin cambios) | Transición de Anthropic Messages a OpenAI Responses API | Configuración de la Base URL y del grupo de API keys |
| Caso recomendado | Elevar rápidamente el nivel de razonamiento | Probar hipótesis alternativas en un worktree limpio | Enrutar a través de gateways locales o dedicados |
2. Elegir la herramienta según el escenario
Elige el enfoque adecuado para lo que exige la tarea actual:
- Opción 1 (Claude Code): recomendada si necesitas explorar una base de código de forma interactiva, realizar un refactor arquitectónico complejo de varios archivos y usar herramientas de shell flexibles.
- Opción 2 (Codex CLI / Custom Provider): es la mejor opción si necesitas generación de pruebas determinista, ejecución directa sobre la API Responses compatible con OpenAI o una segunda opinión independiente sobre un diff preparado.
3. El protocolo de handoff portable
Para transferir el estado de una tarea de forma fiable y sin ruido en el prompt, redacta una tarjeta de handoff estructurada que contenga solo hechos verificados:
### Task Handoff: Database Connection Pool Limits
- **Goal**: Enforce max_connections=20 and add a 5s connection acquisition timeout.
- **Current State**: Branch `perf/db-pool-limits` created; modified `config/database.go`.
- **Verified Progress**: Test `go test ./config -run TestPoolLimits` passes.
- **Unresolved Blocker**: Under `wrk` load, pool exhaustion crashes without returning HTTP 503.
- **Target Check for Next Agent**: Implement 503 error handling on pool timeout and verify with a test.[!IMPORTANT] Cero secretos en el handoff: nunca incluyas API keys, tokens de autenticación ni el contenido de archivos
.enven las tarjetas de handoff. Cada herramienta CLI lee sus credenciales desde variables de entorno locales. Consulta las guías de configuración de Claude Code y Codex en los BetterToken Docs.
4. Cambiar y verificar paso a paso
Sigue este procedimiento de cinco pasos al entregar el trabajo a otro agent:
- Paso 1: guardar el estado de Git. Revisa y guarda temporalmente los cambios sin confirmar:
git status --short; después, conserva la tarjeta de handoff estructurada. - Paso 2: iniciar una sesión nueva. Arranca el agent secundario en un worktree de Git aislado o en una ventana de terminal limpia.
- Paso 3: entregar solo la tarjeta de handoff. Proporciona al nuevo agent el objetivo de la tarea y el paso de verificación, sin el historial de chat anterior.
- Paso 4: ejecutar la comprobación enfocada. Exige que el agent ejecute la prueba objetivo e inspeccione los archivos modificados:
git diff --check. - Paso 5: decidir según una salida observable. Si el modelo secundario resuelve limpiamente el bloqueo, continúa en esa rama; de lo contrario, vuelve a la sesión principal sin sobrecarga de regresiones.
Este enfoque evita la sobrecarga del prompt y convierte el cambio de modelo en un experimento de ingeniería objetivo y medible.
