Codex vs Claude Code: cómo elegir entre dos diseños de Subagent

Las herramientas de programación con IA están prestando cada vez más atención a los subagentes. No es simple moda: un solo agente acaba encontrando límites cuando debe manejar tareas reales de ingeniería.

Si un agente lee código, revisa logs, modifica implementación, ejecuta pruebas, analiza errores y resume resultados a la vez, el contexto principal se ensucia rápido. Resultados de búsqueda, salidas de comandos, logs de pruebas y razonamientos intermedios se mezclan. Las decisiones posteriores se vuelven menos fiables. Además, explorar, implementar, verificar y revisar en un único hilo dificulta el paralelismo.

El objetivo de los subagentes es reducir esa presión. La sesión principal deja de hacerlo todo de principio a fin y pasa a coordinar: define objetivos, asigna trabajo, recibe resultados y los integra. Un subagente se ocupa de una parte local, como exploración, implementación, verificación o revisión, y devuelve una conclusión comprimida.

Un subagente no es “otra copia de mí”. Es una forma de dividir trabajo de ingeniería confuso en roles más claros.

Fundamentos compartidos

Un sistema maduro de subagentes suele necesitar cuatro bases:

Aislamiento de contexto.
Especialización de roles.
Configuración a nivel de proyecto y usuario.
Límites de herramientas y permisos.

El aislamiento de contexto es esencial. En un repositorio real hay mucho material intermedio: búsquedas, logs de pruebas, salidas de comandos. Si todo entra en la sesión principal, el hilo principal se vuelve ruidoso. Un subagente puede digerir ese proceso local y devolver solo las señales útiles.

La especialización de roles también importa. Multi-agent no significa abrir varias copias del mismo modelo. Un rol de exploración debe buscar, leer y resumir. Un rol de implementación debe centrarse en cambios locales. Un rol de verificación debe ejecutar checks, identificar riesgos e informar con claridad.

Los límites de herramientas y permisos determinan si el sistema es seguro. Un subagente no debería heredar automáticamente todas las capacidades de la sesión principal. Un explorer de solo lectura no necesita escribir archivos. Un verifier no siempre necesita modificar implementación.

Codex y Claude Code comparten estas preocupaciones, pero toman caminos distintos.

Codex: delegación explícita

El diseño de Codex es más contenido.

Ofrece un mecanismo de delegación controlado y ligero alrededor de la sesión principal actual. Cuándo delegar, a quién delegar y cuándo recoger resultados son decisiones explícitas. El flujo de control permanece en la tarea actual.

Sus rasgos:

La sesión principal delega explícitamente.
El conjunto de roles se mantiene pequeño.
La sesión principal sabe qué agente hace qué.
Los resultados vuelven a la línea principal.
Los límites de colaboración son transparentes.

Esto encaja con equipos que valoran orquestación manual, previsibilidad y determinismo. Puedes pedir a un explorer que inspeccione una cadena de llamadas, a un worker que haga un cambio acotado y a la sesión principal que integre el resultado.

La contrapartida es que la presión de orquestación sigue en la sesión principal. Debe decidir cuándo dividir, cómo dividir, a quién asignar y cómo fusionar resultados. Para colaboración ligera es cómodo; para flujos largos puede cansar.

Claude Code: agentes como puestos de trabajo

Claude Code toma una ruta más de plataforma.

Trata los agentes como objetos describibles, seleccionables, configurables, con memoria, aislables y capaces de ejecutarse en segundo plano. Un subagente no es solo una ayuda temporal en una conversación; se parece más a un puesto de trabajo dentro de un sistema de ingeniería.

El sistema puede exponer listas de agentes, casos de uso, descripciones y límites de herramientas al modelo, permitiendo que el modelo decida qué rol usar en cada turno. Eso hace la delegación más automática.

Varios elementos definen este enfoque.

Primero, un sistema de roles. Explorer, planner, general-purpose y verifier pueden tener descripción de uso, restricciones de herramientas, modelos por defecto y condiciones de ejecución. Un explorer de solo lectura no edita archivos; un planner diseña; un verifier comprueba.

Segundo, herencia y override. Un subagente no es completamente libre. Hereda los límites grandes de la sesión principal, pero puede ajustar comportamiento local dentro de reglas permitidas.

Tercero, memoria. La memoria no es solo recordar algo. Puede tener alcance: memoria de usuario para preferencias largas, memoria de proyecto para contexto del repositorio y memoria local para estado del entorno.

Cuarto, background y worktree isolation. Algunas verificaciones pueden seguir en segundo plano mientras el hilo principal avanza. Si hace falta aislamiento fuerte, el agente puede trabajar en un worktree separado.

Quinto, ecosistema de plugins. Si los agentes son objetos de primera clase, hay que pensar en distribución, instalación, prioridades, overrides y seguridad. Los plugin agents pueden entrar al sistema, pero campos de alto riesgo como permission mode, hooks o MCP servers deben estar controlados.

Esto hace que Claude Code se parezca más a un runtime de agentes que a una herramienta de colaboración de una sola sesión.

Diferencia principal

Codex se parece a una herramienta de delegación controlada:

Delegación explícita.
Roles ligeros.
Flujo de control claro.
Subtareas centradas en la sesión actual.
Adecuado para trabajo humano-orquestado y determinista.

Claude Code se parece a un sistema de puestos de ingeniería:

Los agentes están modelados formalmente.
Los roles son más sistemáticos.
Memoria, background, aislamiento y plugins forman parte del runtime.
El modelo puede ayudar a elegir roles.
Adecuado para proyectos largos y workflows de plataforma.

La pregunta no es cuál tiene más funciones. Es si quieres que un subagente sea “un ayudante al que llamo explícitamente” o “un puesto permanente dentro del sistema”.

Cómo elegir

Elige el estilo Codex si valoras control explícito, delegación ligera y paralelismo seguro dentro de la sesión actual. Encaja con revisiones, cambios pequeños, tareas claras y flujos donde la persona quiere mantener el ritmo.

Elige el estilo Claude Code si necesitas roles sistemáticos, memoria a largo plazo, ejecución en segundo plano, aislamiento por worktree, plugins y un runtime más completo.

Hazte dos preguntas:

¿Aceptas que el modelo decida quién debe hacer el trabajo?
¿Necesitas un runtime de agentes más completo?

Si la primera te incomoda, la delegación explícita es mejor. Si la segunda es sí, un sistema tipo plataforma encaja mejor.

Consejos prácticos

No trates los subagentes como “más modelos igual a más potencia”.

Define límites de tarea para cada rol.
Limita las herramientas de cada rol.
Pide conclusiones, no logs crudos.
Mantén la decisión final en la sesión principal.
Haz visibles tareas en background y worktrees.
Define límites de seguridad para plugins.

El valor de los subagentes no está en la cantidad, sino en la calidad de la división del trabajo.

Proyectos adecuados e implementación de subagents en Claude Code

Buen encaje 1: mapear un código grande

Cuando heredas un repositorio desconocido, el primer problema es saber dónde mirar.

Puedes delegar exploraciones:

api-reader: rutas, controladores, autenticación.
db-reader: schema, migraciones, modelos ORM.
frontend-reader: páginas, estado, entradas de componentes.
test-reader: framework de tests, cobertura, comandos.

Cada subagent devuelve 5 a 10 conclusiones. La sesión principal mantiene un mapa, no todo el detalle del repositorio.

Esto encaja con monorepos, sistemas legacy, repos frontend/backend mixtos, scripts dispersos y evaluaciones de deuda técnica.

Si diseñas un handoff entre Codex y Claude Code, puedes poner esta lectura del repo del lado de subagents de Claude Code y entregar el mapa a Codex para cambios más largos: Guía de handoff entre Codex y Claude Code: implementación, revisión y recuperación de tareas largas.

Buen encaje 2: dividir revisión de código por roles

La revisión se divide naturalmente por preocupación:

bug-reviewer: errores lógicos, nulls, límites, regresiones.
security-reviewer: permisos, validación, secretos, inyección, bypass.
performance-reviewer: bucles, queries, caché, rendering, concurrencia.
test-reviewer: si las pruebas cubren riesgos reales.

El límite importante: los subagents de revisión deberían ser read-only por defecto.

Flujo seguro:

La sesión principal reúne el diff.
Varios subagents read-only revisan.
La sesión principal fusiona conclusiones.
Un implementador explícito aplica arreglos pequeños.

Para un flujo cerrado de revisión entre Claude Code y Codex, mira: Cómo montar un flujo de revisión de código con Claude Code y Codex: de cambios locales a PR.

Buen encaje 3: fallos de tests y logs ruidosos

Las pruebas fallidas producen mucha salida. En E2E, integración y CI, el error útil suele estar escondido.

Un test-runner puede:

ejecutar el comando indicado;
extraer casos fallidos;
resumir la causa probable;
señalar archivos relacionados;
no corregir código directamente.

subagent	Herramientas sugeridas	Tarea
`test-runner`	`Bash, Read, Grep`	Ejecutar tests y explicar fallos
`log-analyzer`	`Read, Grep, Glob`	Analizar logs y stack traces
`coverage-reviewer`	`Read, Grep, Glob`	Encontrar pruebas faltantes y ramas riesgosas

Si ya usas hooks de Claude Code para ejecutar tests, los hooks pueden disparar la ejecución y el subagent explicar el fallo: .

Buen encaje 4: análisis de impacto antes de refactorizar

Un refactor grande no debería empezar editando. Los subagents sirven para reconocimiento read-only.

Pueden responder:

qué archivos dependen de la interfaz antigua;
qué tests cubren esa lógica;
qué rutas de llamada son frágiles;
si docs, scripts o configs necesitan cambios;
dónde conviene añadir tests antes de tocar código.

La regla: el subagent entrega impacto, no parches.

La sesión principal decide después si cambiar todo, dividir fases o añadir tests primero. Esto también ayuda a recuperar tareas largas: .

Mal encaje: no dividas todo

Los subagents tienen coste: más contexto, espera y coordinación.

Normalmente no convienen para:

1. Problemas pequeños

Typos, imports, una clase CSS, un null check o una config se resuelven mejor en la sesión principal.

2. Requisitos vagos

“Optimiza este proyecto” o “mejora esta página” requieren aclarar objetivo, restricciones y aceptación antes de delegar.

3. Tareas con negociación constante

Los subagents funcionan mejor con trabajo independiente, no con diseño que cambia cada dos líneas.

4. Varios agents editando los mismos archivos

Mejor que revisen read-only y que un solo ejecutor aplique cambios.

5. Operaciones externas de alto riesgo

Producción, cuentas reales, APIs pagas, borrado, permisos, emails o mensajes requieren límites estrictos y puntos de confirmación.

Diseño de subagents de proyecto

Claude Code permite escribir subagents como Markdown. Los de proyecto suelen vivir en:

1

.claude/agents/

Los globales en:

1

~/.claude/agents/

Un subagent de proyecto debería capturar comandos de test, estructura, prioridades de revisión, archivos prohibidos y formato de salida.

Ejemplo mínimo read-only:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


---
name: code-reviewer
description: Use when the task needs a read-only review of code changes for bugs, regressions, security risks, and missing tests.
tools: Read, Grep, Glob
---

# Code Reviewer

Only perform read-only review. Do not modify files.

Focus on:

- logic errors and edge cases
- regression risk
- security and permission issues
- missing tests
- inconsistency with project style

Output:

1. List high-risk issues first.
2. Include file paths and reasons.
3. If no issue is found, say so clearly.
4. Do not output long rewritten code.

La parte más importante es description, porque Claude Code la usa para decidir cuándo delegar.

Conjunto común de subagents

Empieza con 3 a 5 roles:

Nombre	Herramientas	Propósito
`code-reviewer`	`Read, Grep, Glob`	Revisión read-only de bugs y regresiones
`test-runner`	`Bash, Read, Grep`	Ejecutar tests y explicar fallos
`docs-researcher`	`Read, Grep, Glob`	Resumir docs, migraciones y convenciones
`security-reviewer`	`Read, Grep, Glob`	Revisar permisos, inputs, secretos e inyección
`refactor-planner`	`Read, Grep, Glob`	Analizar impacto antes de cambios grandes

Si un subagent devuelve consejos genéricos, su rol es demasiado amplio.

Cómo llamar un subagent

Puedes llamarlo explícitamente:

1

Use the code-reviewer subagent to review the current diff. Do not modify files.

También puedes nombrarlo como @code-reviewer o iniciar:

1

claude --agent code-reviewer

En tareas críticas, no dependas solo de delegación automática. Di “read-only”, “do not modify files” y “return conclusions only”.

Fórmula de decisión

Haz cinco preguntas:

¿La tarea se puede dividir por módulo, directorio, rol o preocupación?
¿Las subtareas son relativamente independientes?
¿Cada subtarea puede devolver una conclusión clara?
¿Se necesitan permisos de herramientas diferentes?
¿El beneficio de aislar contexto supera el coste en tokens y espera?

Si tres o más son sí, prueba subagents. Si solo una es sí, probablemente no conviene.

Checklist de errores

Usa nombres concretos, no helper, assistant o worker.
En description, escribe el caso de activación.
Los subagents de revisión deberían ser read-only.
Los subagents que editan deben tener un alcance pequeño.
En refactors grandes, analiza impacto primero.
Los subagents de test deben resumir fallos, no devolver logs completos.
La sesión principal fusiona las salidas.
Limita herramientas y alcance en acciones riesgosas.
Reglas de proyecto en .claude/agents/; hábitos personales en ~/.claude/agents/.
Elimina subagents de baja calidad o duplicados.

Referencias

Resumen

Codex y Claude Code resuelven el mismo problema: un solo agente no puede cargar cómodamente con todo el trabajo real de ingeniería. Ambos reconocen la importancia de aislar contexto, especializar roles, definir permisos y resumir localmente.

Codex es más contenido y prioriza delegación explícita y control de la sesión principal. Claude Code es más sistemático y trata los agentes como puestos configurables, con memoria, aislamiento, background y ecosistema de plugins.

La elección no depende de qué marca gana, sino de si tu flujo necesita una herramienta de colaboración controlada o un runtime completo de agentes.