[ PLAYBOOK · 10 ] · 14 DE MAYO, 2026 · 7 min
Codex asíncrono para migraciones largas.
El modo cloud asíncrono de Codex es la herramienta correcta para refactors de varios días, bien acotados. Claude Code es la herramienta correcta para trabajo local con humano al lado. Cursor es la herramienta correcta dentro del IDE. Elige por la forma del trabajo, no por lealtad de marca.
La postura
La mayoría de los equipos elige un agente de código y lo usa para todo. Es un error. Las tres opciones serias en 2026 cubren formas distintas de trabajo, y la manera más barata de pasar menos tiempo peleando con la herramienta es hacer coincidir la herramienta con la tarea. Codex en su modo cloud asíncrono es la elección correcta cuando el trabajo es de varios días, está bien acotado y se puede paralelizar entre muchos archivos similares. Claude Code es la elección correcta cuando el trabajo es interactivo, cruza el codebase y se beneficia de un paso de planificación antes de tocar archivos. Cursor es la elección correcta cuando el trabajo es edición en línea dentro de un archivo abierto. Trátalos como tres herramientas distintas, no como tres marcas en competencia.
Qué significa "Codex asíncrono" en 2026
Codex pasó por varias formas entre su primer lanzamiento en abril de 2025 (Codex CLI) y su versión actual. La forma de 2026 son tres superficies que comparten un backend.
Codex CLI. El agente local en terminal. Corre contra tu filesystem en un sandbox que controlas, en forma parecida a Claude Code. Síncrono; te sientas con él.
Extensión Codex para IDE. Un panel dentro de VS Code (y de JetBrains desde el release del primer trimestre de 2026) para trabajo anclado al editor. En forma parecida a un panel de Cursor o de GitHub Copilot Workspace.
Codex cloud. La pieza de la que va este post. Mandas una descripción de tarea y un repositorio. La tarea corre en un sandbox aislado en la nube que clona tu repo, instala dependencias, ejecuta comandos, edita archivos, abre un pull request y espera revisión. El blog de ingeniería de OpenAI describe corridas de varias horas; en la práctica hemos visto migraciones que corren más de un día con el agente retomando después de revisiones humanas intermedias.
Debajo de las tres superficies vive una familia de modelos que OpenAI llama Codex-tuned (GPT-5-Codex salió en septiembre de 2025; la actualización GPT-5.2-Codex de diciembre de 2025 sumó compactación de contexto para horizontes largos y mejor rendimiento en refactors, ambas cosas en las que se apoya la superficie cloud). El modelo es el mismo; la superficie decide cuánto humano hay en el loop.
Dónde gana el cloud asíncrono
Tres propiedades del trabajo hacen de Codex cloud la elección correcta. Cuando las tres están presentes, ningún agente local le iguala el costo por resultado.
El trabajo está bien acotado antes de empezar. "Migra cada componente de React de sintaxis de clase a componente de función, preservando la suite de tests." "Reemplaza cada llamada directa al SDK v2 de AWS por su equivalente en v3." "Actualiza cada servicio interno de Node 18 a Node 22, arregla las APIs deprecadas, deja CI en verde." Son migraciones donde la intención cabe en un párrafo y el alcance es mecánico. El agente no necesita hacer preguntas de diseño; necesita aplicar la misma transformación en muchos lugares y verificar que los tests siguen pasando.
El trabajo es paralelizable entre archivos o módulos. Codex cloud te deja disparar muchas tareas contra el mismo repo en paralelo. Cada una corre en su propio sandbox. Una migración que toca 200 archivos suele ser más rápida como 10 tareas de 20 archivos cada una que como una tarea de 200 archivos, porque el modo de falla de una corrida autónoma larga es que el agente se pierde en un loop de debugging sobre un archivo conflictivo y quema horas que los otros 199 no necesitan.
No necesitas mirarlo. El agente corre en la infraestructura de OpenAI, no en la tuya. No bloquea tu laptop, tu terminal ni tu atención. Encolas una tarea antes de almorzar, revisas el PR antes de la siguiente reunión. El modelo cloud asíncrono cambia capacidad de respuesta por throughput, y para una migración de varios días ese intercambio es el correcto.
Dónde gana Claude Code en cambio
La fortaleza de Claude Code es la forma opuesta del trabajo.
Trabajo con humano al lado que necesita un plan antes de que cambien archivos. El plan mode es la característica diferencial; separa decidir de hacer en una forma que importa cuando el codebase es lo bastante grande como para que una primera edición equivocada se vuelva cascada. El plan es revisable antes de que se toque un solo archivo, que es exactamente lo que necesita un refactor exploratorio.
Refactors transversales que necesitan contexto de todo el codebase. Claude Code lee archivos de forma lazy pero mantiene la estructura del proyecto en mente durante la sesión, y pregunta antes de tocar archivos fuera del área donde lo apuntaste. La forma de la sesión premia al humano que puede contestar preguntas de arquitectura en el momento, en vez de escribirlas todas en un spec de una sola pasada.
Repositorios sensibles que no deberían salir de la laptop. El sandbox local mantiene secretos en tu máquina, lo cual importa cuando el repo toca llaves privadas, datos de clientes o herramientas propietarias que no pertenecen al cloud de un proveedor. Para industrias reguladas o codebases pre-IPO, esa sola restricción decide la herramienta.
Para un refactor exploratorio donde la forma correcta no está clara al inicio, sentarse junto a Claude Code en plan mode le gana a disparar una tarea de Codex cloud y rezar para que la descripción haya sido lo bastante específica. El costo de una tarea de Codex ambigua es cómputo desperdiciado y un PR ruidoso. El costo de una sesión de Claude Code ambigua son unos minutos de aclaración antes de que cambien archivos.
Dónde gana Cursor en cambio
La fortaleza de Cursor es la unidad de trabajo más chica: editar un archivo que tienes abierto. Tab completion que conoce el codebase, edits inline manejados por la selección, el panel de agente para un cambio de 50 líneas. Vemos a Cursor en su mejor versión cuando el desarrollador es el arquitecto y el agente es el mecanógrafo. Es la herramienta equivocada para una migración de varios días; el loop de "describir, editar, aceptar, repetir" carga demasiada atención humana como para escalar a 200 archivos. Es la herramienta correcta cuando el humano es el que toma decisiones en cada cambio.
La decisión en un párrafo
Elige Codex cloud cuando el trabajo es mecánico, de varios días y paralelizable. Elige Claude Code cuando el trabajo es exploratorio, interactivo y se beneficia de un paso de planificación. Elige Cursor cuando el trabajo va archivo por archivo. Un equipo corriendo una migración seria usará dos de las tres en el mismo proyecto: Codex cloud para el grueso mecánico, Claude Code para las partes que requieren juicio, Cursor para las limpiezas a nivel de archivo al final.
Un playbook de migración con Codex cloud
Si estás por correr una migración de varios días y Codex cloud pasa los tres chequeos de arriba, esta es la secuencia que corremos con clientes.
Paso 1. Acotar en papel antes de cualquier corrida. Escribe la migración como un spec de un párrafo que recibirá el agente. Nombra la transformación, el comando de verificación (casi siempre tu suite de tests o el comando de CI), los archivos fuera de alcance, las convenciones a preservar. Lo guardamos en MIGRATION.md en la raíz del repo y se lo pasamos a cada tarea. Un mal spec es el predictor más grande de un mal PR; la página oficial de mejores prácticas de OpenAI vale la pena leerla antes de la primera corrida.
Paso 2. Dividir el trabajo en lotes de 20 a 50 archivos. Un lote así de chico cabe en el presupuesto de contexto de una tarea; un lote más grande sigue siendo revisable como un solo PR. Los etiquetamos por directorio o por patrón de transformación. Cada lote se vuelve una tarea de Codex cloud, disparada en paralelo.
Paso 3. Anclar el comando de verificación. La descripción de la tarea debe terminar con "ejecuta pnpm test (o tu comando de CI) y solo abre el PR cuando pase". Esa sola frase convierte a Codex de un generador de código a un entregador de código. Sin ella, el agente produce edits que se ven razonables y fallan en CI. Con ella, el agente reintenta hasta que la suite quede en verde o levanta el fallo para revisión humana.
Paso 4. Revisar PRs en lotes chicos. Codex abre un PR por tarea. Revísalos en grupos de tres a cinco, no de a uno. El valor de una migración aparece en el patrón del diff, no en cualquier archivo individual. Revisar un grupo te deja detectar el error sistémico que el agente está cometiendo y ajustar el spec para los lotes restantes antes de que corran.
Paso 5. Reservar el último 10% para un humano. La cola de una migración es la parte que rompe el patrón. Archivos bespoke que necesitan juicio. Tests que hay que reescribir en vez de migrar automáticamente. Configuración de CI que depende del cambio. Planifica hacer ese 10% con Claude Code o a mano, no con otra tarea de Codex. Forzar al agente por la cola cuesta más que simplemente hacerla tú.
Qué medir
Dos números te dicen si Codex cloud está pagando.
Ratio PR a merge. De cada 10 PRs que abre Codex, cuántos mergean sin edits humanos, cuántos mergean con edits pequeños, cuántos se rechazan. Corridas sanas se sientan en 6 a 8 merges limpios, 1 a 3 merges con edits chicos, 0 a 1 rechazos. Si los rechazos superan el 30%, el spec es demasiado vago o el tamaño del lote es muy grande. Ajusta antes de disparar la siguiente ronda.
Tiempo de calendario por cada 100 archivos migrados. El punto entero del cloud asíncrono es el throughput. Si una migración de 200 archivos toma el mismo tiempo de calendario que una sesión de Claude Code, la herramienta no está pagando. Vemos migraciones bien acotadas aterrizar en 1 a 3 días para el grueso y 1 a 2 días para la cola; si el grueso toma más que eso, el spec o el tamaño del lote están mal.
Los agentes de código en 2026 no son una elección de una sola herramienta. Son un portafolio. Los equipos que entregan migraciones en plazo son los que eligen la superficie correcta para cada fase del trabajo y aceptan que la herramienta correcta para el grueso no es la correcta para la cola. Ajusta a la forma, no a la marca.