La primera vez que usé Claude Code para refactorizar un módulo entero, tuve una experiencia casi mística. Le describí lo que quería, me fui a por un café, y cuando volví tenía un pull request con 14 ficheros cambiados, tests actualizados y un commit message decente. «Esto es magia», pensé.
No es magia. Es un while loop.
Michael Bolin, de OpenAI, publicó hace poco un artículo donde desmonta el funcionamiento interno de Codex CLI. Y resulta que el secreto detrás de los AI coding agents no es un algoritmo revolucionario ni una red neuronal misteriosa. Es un bucle que llama a un LLM, ejecuta herramientas, y repite hasta que no queda nada por hacer.
Vamos a abrirlo en canal.
La máquina de estados: 5 fases y un bucle
Todo coding agent — Codex, Claude Code, Cursor, da igual — ejecuta el mismo patrón fundamental. Michael Bolin lo describe como un bucle de 5 fases:
flowchart TD
A["1. Prompt Assembly\n(montar el prompt)"] --> B["2. Inference\n(enviar al LLM)"]
B --> C{¿Tool call?}
C -->|Sí| D["3. Tool Invocation\n(ejecutar herramienta)"]
D --> E["4. Tool Response\n(devolver resultado al LLM)"]
E --> B
C -->|No| F["5. Assistant Message\n(respuesta final)"]
F -->|Nuevo input| A
style A fill:#2d3748,stroke:#4a9eed,color:#fff
style B fill:#2d3748,stroke:#4a9eed,color:#fff
style C fill:#4a3728,stroke:#ed9a4a,color:#fff
style D fill:#2d3748,stroke:#4a9eed,color:#fff
style E fill:#2d3748,stroke:#4a9eed,color:#fff
style F fill:#283d28,stroke:#4aed5c,color:#fff
Dicho en cristiano:
- Prompt Assembly: se monta un prompt gigante con todo lo que el agente necesita saber — tu mensaje, las instrucciones del sistema, las herramientas disponibles, ficheros que ha leído, y el historial completo de la conversación.
- Inference: ese prompt se tokeniza y se envía al modelo. El modelo devuelve un stream de eventos: razonamiento interno, tool calls, o texto de respuesta.
- Tool Invocation: si el modelo pide ejecutar una herramienta (leer un fichero, correr un comando, escribir código), se ejecuta. Si falla, el error vuelve al modelo.
- Tool Response Loop: el resultado de la herramienta vuelve al modelo como contexto adicional. Y se repiten los pasos 2-4 hasta que el modelo no pida más herramientas.
- Assistant Message: cuando el modelo decide que ha terminado, emite un mensaje final y el ciclo se cierra.
Eso es todo. No hay grafos de conocimiento, ni planificadores simbólicos, ni arquitecturas sofisticadas. Es un bucle while con un LLM dentro.
La diferencia entre un agente bueno y uno malo no está en la arquitectura del bucle — que es idéntica — sino en los detalles de cada fase.
Fase 1: El arte de montar un prompt
La primera fase es donde se cuece todo. Antes de que el LLM vea una sola línea de tu código, el agente tiene que construir un prompt que incluya:
flowchart LR
subgraph Prompt["Prompt Assembly"]
direction TB
SP["System Prompt\n(personalidad, reglas)"]
Tools["Herramientas disponibles\n(Read, Write, Bash, MCP...)"]
Ctx["Ficheros / imágenes\nleídos previamente"]
Inst["CLAUDE.md / AGENTS.md\n(instrucciones del repo)"]
Env["Info del entorno\n(OS, shell, git status)"]
Hist["Historial de\nconversación"]
User["Mensaje del usuario"]
end
SP --> Final["Prompt\ncompleto"]
Tools --> Final
Ctx --> Final
Inst --> Final
Env --> Final
Hist --> Final
User --> Final
style Final fill:#283d28,stroke:#4aed5c,color:#fff
Aquí ya ves una decisión de diseño crítica: el orden importa. El prompt se construye de más estable a menos estable. El system prompt va primero (nunca cambia), luego las herramientas (rara vez cambian), luego ficheros e historial (crecen con cada interacción), y al final tu último mensaje.
¿Por qué ese orden? Por el prompt caching. Como el caché funciona por coincidencia exacta de prefijo, si pones el contenido estable al principio, maximizas la cantidad de tokens que se leen de caché en cada iteración. Cambiar algo al principio invalida todo lo que viene después. Ya hablé de esto en detalle en mi artículo sobre prompt caching, pero la idea clave es: el orden de tu prompt no es cosmético, es económico.
Y luego están los ficheros CLAUDE.md y AGENTS.md. Ambos son el equivalente a dejarle una nota al fontanero antes de irte de casa: «la llave de paso está debajo del fregadero, no toques la tubería azul». El agente los lee al arrancar y los inyecta en cada prompt. Son tu mecanismo para darle contexto sin tener que repetírtelo cada vez.
El problema del cuadrado: por qué el contexto crece como una bola de nieve
Aquí viene el bofetón de realidad. Cada iteración del bucle envía toda la conversación completa al modelo. No hay estado en el servidor. Cada request es independiente, stateless.
¿Por qué? Porque así el proveedor puede garantizar Zero Data Retention — tus datos no persisten en sus servidores entre peticiones. Es una decisión de privacidad, no de eficiencia.
Pero tiene un coste brutal:
flowchart LR
subgraph Msg1["Iteración 1"]
S1["System\n10K tok"] --> U1["User\n500 tok"]
end
subgraph Msg5["Iteración 5"]
S5["System\n10K tok"] --> H5["Historial\n40K tok"] --> U5["User\n500 tok"]
end
subgraph Msg20["Iteración 20"]
S20["System\n10K tok"] --> H20["Historial\n180K tok"] --> U20["User\n500 tok"]
end
style Msg1 fill:#1a2332,stroke:#4a9eed,color:#fff
style Msg5 fill:#2a2332,stroke:#9a4eed,color:#fff
style Msg20 fill:#3a1a1a,stroke:#ed4a4a,color:#fff
En la iteración 1 envías 10K tokens. En la 5, envías 50K. En la 20, envías 190K. Cada mensaje reenvía todo el historial previo. Y como el mecanismo de self-attention del transformer tiene coste cuadrático respecto al número de tokens, no solo crece la cantidad de datos enviados — crece el coste computacional de procesarlos.
Dicho de otra forma: la iteración 20 no cuesta 20 veces más que la primera. Cuesta mucho más.
Compaction: comprimir sin perder lo importante
Tanto Codex como Claude Code tienen una solución para el crecimiento descontrolado del contexto: compaction (o compresión automática).
Cuando el historial se acerca al límite de la ventana de contexto, el agente hace algo ingenioso: envía todo el historial a un endpoint especial que genera una representación comprimida. En lugar de 180K tokens de conversación, obtienes quizás 20K que capturan las decisiones tomadas, los ficheros modificados y el estado actual de la tarea.
flowchart TD
Full["Historial completo\n180K tokens"] --> Check{¿Cerca del límite?}
Check -->|No| Continue["Seguir normalmente"]
Check -->|Sí| Compact["Compaction endpoint"]
Compact --> Summary["Resumen comprimido\n~20K tokens"]
Summary --> NewCtx["Nuevo contexto\n= System + Resumen + Último mensaje"]
NewCtx --> Continue2["Seguir con contexto fresco"]
style Full fill:#3a1a1a,stroke:#ed4a4a,color:#fff
style Summary fill:#283d28,stroke:#4aed5c,color:#fff
style Compact fill:#2d3748,stroke:#4a9eed,color:#fff
Ojo al dato: la compresión no es gratis. Pierdes detalle. El modelo ya no tiene acceso al diff exacto que hiciste en el paso 7, sino a un resumen que dice «se refactorizó el módulo de autenticación». Para la mayoría de tareas es suficiente. Para depuración quirúrgica, puede ser un problema.
Codex lo llama compaction. Claude Code hace algo equivalente con compresión automática de contexto. La idea es idéntica: cuando el contexto se te va de las manos, comprimes el pasado y sigues adelante con una versión más ligera.
Sandbox: la jaula dorada
Ambos agentes ejecutan herramientas en un sandbox — un entorno restringido donde el acceso a red y al sistema de ficheros está limitado por defecto.
Esto es fundamental. Sin sandbox, un rm -rf / generado por alucinación del modelo destruiría tu máquina. Con sandbox, el peor escenario es que rompa algo dentro de los límites permitidos.
Claude Code te pide confirmación para cada operación potencialmente destructiva (a menos que la apruebes explícitamente). Codex CLI opera por defecto en un modo similar de permisos explícitos.
La lección aquí no es técnica, es filosófica: un agente que puede hacer cualquier cosa es un agente en el que no puedes confiar. Las restricciones no son limitaciones — son garantías.
Codex CLI vs Claude Code: gemelos no idénticos
Ahora viene la parte divertida. Ambos son el mismo bucle por dentro, pero las decisiones de diseño divergen en puntos interesantes:
flowchart TB
subgraph Codex["Codex CLI (OpenAI)"]
direction TB
CG["GUI de escritorio\n(Command Center)"]
CS["Shell genérico\n(bash/terminal)"]
CA["Automations\n(scheduling nativo)"]
CD["Diffs con\ncomentarios inline"]
end
subgraph Claude["Claude Code (Anthropic)"]
direction TB
CC["CLI-first\n(terminal nativo)"]
CT["Herramientas dedicadas\n(Read, Edit, Grep, Glob)"]
CK["Skills\n(/blog, /improve...)"]
CF["Feedback\nconversacional"]
end
style Codex fill:#1a2332,stroke:#4a9eed,color:#fff
style Claude fill:#2a1a32,stroke:#9a4eed,color:#fff
Herramientas: genérico vs especializado
Codex le da al modelo acceso a un shell genérico. Si quieres leer un fichero, el modelo ejecuta cat archivo.py. Si quieres buscar texto, ejecuta grep -r "patrón" ..
Claude Code hace lo opuesto: tiene herramientas dedicadas para cada operación. Read para leer ficheros, Edit para editarlos (con reemplazo exacto de strings, no reescritura completa), Grep para buscar, Glob para encontrar ficheros por patrón.
¿Cuál es mejor? Depende de cómo lo mires. El shell genérico es más flexible — cualquier cosa que puedas hacer en una terminal, el modelo puede hacerlo. Pero las herramientas dedicadas son más seguras y eficientes. Un Edit que solo envía el diff del cambio es más rápido y menos propenso a errores que un cat > archivo.py << 'EOF' que reescribe el fichero entero.
Mi experiencia: las herramientas dedicadas ganan para el 90% de los casos. El shell genérico gana cuando necesitas hacer algo exótico que ninguna herramienta cubre.
GUI vs CLI
Codex apuesta por una GUI de escritorio (Command Center) donde ves los diffs como en un pull request, puedes poner comentarios inline en los cambios, y tienes una vista gráfica de lo que está haciendo el agente.
Claude Code es CLI puro. Tu terminal. Tu shell. Nada de ventanitas. Si quieres revisar un cambio, el agente te lo muestra en texto. Si quieres dar feedback, lo escribes como un mensaje más en la conversación.
¿Qué prefiero? El CLI, con diferencia. Y no por purismo hacker. Es que un CLI se integra con todo: tmux, scripts, cron, pipelines de CI, remote control vía SSH. Una GUI te ata a una pantalla concreta. Para sesiones interactivas la GUI es más visual, sí. Pero para currar de verdad — tareas largas, automatizaciones, agentes que corren solos — el CLI no tiene competencia.
Scheduling: nativo vs DIY
Codex tiene Automations: puedes programar tareas que se ejecutan automáticamente (reaccionar a un evento de GitHub, lanzar un agente cada mañana, etc.). Es scheduling nativo dentro de la plataforma.
Claude Code no tiene nada de eso. Si quieres que un agente se ejecute cada 30 minutos, le pones un cron o un systemd timer. Si quieres que reaccione a un webhook, te montas la integración tú.
Aquí Codex tiene ventaja objetiva para equipos que quieren automatización out of the box. Pero la solución DIY de Claude Code tiene una ventaja no obvia: tú controlas la infraestructura. Si Anthropic cambia su API, tu cron sigue funcionando porque es tu máquina. Si OpenAI cambia las Automations, estás vendido.
Lo que de verdad importa
Después de desmontar las tripas de ambos agentes, la conclusión es casi decepcionante por lo simple que es:
Un coding agent es un bucle que monta un prompt, llama a un LLM, ejecuta herramientas, y repite. Punto.
La magia no está en el bucle. Está en tres cosas:
-
La calidad del modelo. Un
whileloop con GPT-3 no hace nada útil. Con Claude Opus o GPT-4o, refactoriza módulos enteros. El bucle es el mismo — el cerebro dentro del bucle es lo que marca la diferencia. -
La gestión del contexto. El prompt no puede crecer infinitamente. Cómo ordenas la información, cuándo comprimes, qué priorizas al comprimir — ahí es donde la ingeniería de verdad importa. Un agente que pierde contexto crítico al comprimir comete errores que un humano nunca cometería.
-
El diseño de las herramientas. Darle a un LLM acceso a
bashsin restricciones es como darle las llaves del coche a alguien que nunca ha conducido. Las herramientas bien diseñadas (con validación, restricciones y feedback claro de errores) son la diferencia entre un agente que te ayuda y uno que se te va la olla y te borranode_modulesa las tres de la mañana.
La próxima vez que tu coding agent haga algo que parece magia, recuerda: es un while True con un LLM dentro. Elegante, sí. Potente, sin duda. Pero magia, lo que se dice magia… va a ser que no.
Fuentes: El artículo principal es «What Actually Happens Inside an AI Coding Agent (We Unrolled It)» de Michael Bolin (OpenAI). La comparación con Claude Code viene de experiencia directa y de la documentación oficial de Anthropic. Si te interesa el tema del contexto y caching, lee Por qué el 99% de lo que envías a Claude ya lo tiene en caché y El cache de tu LLM te cobra el doble por ahorrarte dinero.
Read this article in English.
