A febrero de 2026: estado de uso de los agentes de programación y comparación de flujos de trabajo

• El criterio clave para elegir un agente de programación está pasando de ser el rendimiento del modelo en sí a el tiempo disponible del usuario y el tiempo de ejecución autónoma, y se usan Claude Code y Codex en paralelo según la situación
• Opus destaca en gestión de ventanas de contexto y uso de herramientas, y al ejecutar varios subagentes al mismo tiempo resulta ventajoso para explorar y planificar con rapidez
• Codex supera a Opus en precisión del código, pero tiene la desventaja de que es más lento por su falta de delegación de trabajo entre ventanas de contexto
• Mediante la automatización con skills se construyó paso a paso el ciclo planificación → implementación → revisión → corrección de bugs, y fue más efectivo automatizar gradualmente el trabajo manual repetitivo que diseñarlo todo desde el inicio
• En última instancia se avanza hacia un futuro en el que los agentes trabajen de forma autónoma 24/7, pero los principales obstáculos son los límites de la ventana de contexto y la resistencia a la inyección de prompts

---

Contexto

• Trabajó en temas relacionados con la versión web de Codex y dejó OpenAI en julio de 2025
• Organizó este texto con el objetivo de ordenar estrategias detalladas de uso de agentes de programación después del podcast de YC Lightcone
• Los criterios para elegir agentes se están desplazando del rendimiento del modelo hacia el tiempo de ejecución autónoma y la importancia de la tarea
• Está suscrito a Claude Max, ChatGPT Pro y Cursor Pro+, y considera que tienen una alta eficiencia de costos frente a la productividad

Principio clave: entender el contexto

• Para usar bien a los agentes de programación, es indispensable entender el contexto (context)
• Por muy bueno que sea un agente, al final realiza next token prediction, y todos los tokens deben caber dentro de la ventana de contexto
• Principios principales que se derivan de esto:
  • Hay que dividir los problemas en tamaños adecuados para que encajen en la ventana de contexto; si el problema es demasiado grande, tarda más y el resultado empeora
  • Compaction es una técnica con pérdida: el agente decide qué información incluir y cuál omitir, y mientras más compaction haya, mayor tiende a ser la degradación del rendimiento
  • Si se externaliza el contexto al sistema de archivos con documentos de planificación y similares, el agente puede leer y recordar selectivamente sin llenar todo el contexto de la conversación
  • Es importante mantenerse en la “mitad inteligente” de la ventana de contexto; como el entrenamiento funciona mejor con contexto corto, se obtienen mejores resultados cuando la ventana está menos llena. Dex Horthy lo describe como mantenerse fuera de la "dumb zone"
  • Si el agente pasa por alto archivos o paquetes relevantes, puede avanzar en una dirección inesperada; por eso ayuda la "divulgación progresiva (progressive disclosure)" de la estructura y arquitectura del código. OpenAI publicó un post sobre cómo estructuran múltiples archivos Markdown
• El rendimiento y la velocidad no dependen solo de la capacidad pura del modelo, sino también de la gestión de múltiples ventanas de contexto y la capacidad de delegar a subagentes/equipos

Opus: gestión de contexto, uso de herramientas y sensación más humana

• Usa Claude Code como herramienta principal para planificación, coordinación de terminal y gestión de tareas con git/GitHub
• Opus está entrenado para operar de forma muy eficiente entre múltiples ventanas de contexto, por lo que al usar Claude Code se siente más rápido que Codex
• Se observa con frecuencia a Opus ejecutando varios subagentes al mismo tiempo, como llamadas a Explore o Task
  • La herramienta Explore usa Haiku, por lo que procesa grandes volúmenes de tokens rápidamente y entrega el contexto relevante a Opus
• También está bien entrenado para usar herramientas locales como gh, git y varios servidores MCP
  • La extensión /chrome también permite verificar bugs, aunque puede ser lenta e inestable
• El modelo de permisos de Claude Code es más fácil de entender que el de Codex; el modelo de Codex tiende a escribir scripts de comandos en bash, lo que dificulta autorizar herramientas CLI individuales mediante listas blancas
• Ventajas finas de UX en Claude Code: actualiza el título del terminal con contenido relacionado con la tarea, muestra el PR actual en la barra de estado y tiene pequeños mensajes de estado
• Opus supera a Codex al generar explicaciones de PR más fáciles de entender para humanos y diagramas de arquitectura más detallados
• Cuando quiere pedir explicaciones sobre la estructura del código, suele usar Claude Code
• Al planificar, Opus es más “creativo” y tiene la característica de sugerir aspectos que el usuario no mencionó o señalar zonas ambiguas

Codex: una precisión de código aplastante

• El área donde Codex más brilla es la correctitud del código (correctness), y otros desarrolladores que usan mucho estos modelos también coinciden
• Al ejecutarlo con GPT-5.3-Codex-xhigh o high, el código de Codex tiene claramente menos bugs
• Ejemplos de errores frecuentes en Opus:
  • Un componente de React pasa las pruebas unitarias pero olvida agregarse al <App> superior
  • No detecta un error off-by-one evidente
  • Referencias colgantes (dangling references) o condiciones de carrera sutiles
• Durante mucho tiempo pensó que la diferencia entre ambos modelos era despreciable, pero después de ver suficientes PR con la revisión automática de Codex y Cursor Bugbot, concluyó que la calidad de código de los modelos de OpenAI es superior
  • Para hacer una prueba A/B directa, basta con hacer checkout de una rama y comparar /code-review de Claude Code con /review de Codex
• Sin embargo, Codex es lento. La razón principal es la falta de delegación entre ventanas de contexto, y también se percibe una mayor latencia entre tokens
  • El soporte experimental para subagentes (alternando /experimental) funciona, pero no es tan fluido como en Claude y todavía le falta paralelismo
• Como resultado, el patrón es empezar con Claude Code y dejarlo abierto en pantalla, para luego cambiar a Codex en la fase de programación real

Herramientas y configuración útiles

• Actualmente trabaja sobre una codebase greenfield, mucho más pequeña y eficiente en tokens que una codebase de producción
• Estructura del repo: en todos los repos hay una carpeta plans/ para gestionar planes numerados, una carpeta apps/ para separar servicios, una monorepo de TypeScript con turborepo y bun para instalaciones rápidas
• Ghostty: terminal de Mitchellh, rápida, nativa y en mejora continua. En algún momento ejecutaba varias instancias de Claude/Codex con tmux, pero ahora usa varios paneles dentro de la misma pestaña del terminal
• Next.js on Vercel, API en Cloudflare Durable Objects: una estructura que preparticiona la base de datos, la despierta bajo demanda y reduce la preocupación por escrituras concurrentes; desde la perspectiva de infraestructura encaja bien con una era en la que los agentes manipulan fragmentos pequeños de datos
  • Cloudflare se está expandiendo en la dirección de unir cómputo y almacenamiento pequeño colocados conjuntamente con la librería cloudflare/actors
• Worktrees: como el código es liviano, aprovecha worktrees en paralelo y en cada uno valida localmente con bun install → bun run dev; usa la skill worktree para copiar planes relacionados, variables de entorno y actualizaciones, e iniciar una rama nueva
  • Antes de los agentes de programación, usaba sobre todo ramas, pero la combinación de worktree y Claude Code ha resultado muy útil
• Plan, Implement, Review: casi siempre hace que el modelo empiece por un plan — 1) externaliza el contexto más allá de una sola ventana 2) permite revisar o preguntar qué se hizo. Si el agente se interrumpe, el plan puede retomarse en una nueva ventana de contexto
• Preview deploys: todas las ramas reciben un nuevo despliegue de Web + API, lo que favorece la ejecución en paralelo y las pruebas rápidas; sería difícil trabajar sin esta función
• Cursor Bugbot y Codex Code Review: entiende el código a nivel de arquitectura y hace verificaciones puntuales, pero cada vez lee menos cada línea de cada PR; los agentes son mejores encontrando bugs sutiles
  • En algún momento usó Claude Code, Cursor Bugbot y Codex a la vez, pero como Claude Code no detectaba problemas realmente importantes, Cursor quedó como opción predeterminada, aunque Codex también da buenos resultados

Skills: la clave de la automatización

• Define varias skills y archivos compartidos AGENTS.md/CLAUDE.md en un repo llamado claudefiles
• Regla para agregar skills: no añadirlas apresuradamente, sino solo después de repetir algo varias veces y de que el flujo de trabajo se estabilice
• AGENTS/CLAUDE.md sirve para orientar la dirección general del modelo, y las skills tienen dos propósitos:
  1. Encadenamiento y automatización del flujo de trabajo: convertir planificación → implementación por etapas → revisión en skills separadas y luego componer una meta-skill que las ejecute en orden
  2. División de la ventana de contexto: al invocar una skill en Claude Code, si se configura context: fork, puede ejecutarse en una nueva ventana de contexto, separando al “orquestador maestro” de los subagentes
• Las skills son muy eficientes en contexto: a diferencia de las llamadas MCP, que consumen miles de tokens, normalmente usan ~50-100 tokens

Evolución de la automatización con skills

• Al principio le interesó la idea de un marketplace de skills para instalar cosas como diseño frontend, revisión de seguridad o revisión de arquitectura, pero con la experiencia terminó abandonando la mayoría de las skills escritas por otros
• En cambio, cambió a un enfoque de hacer primero el trabajo manual y luego pensar cómo automatizarlo
• Proceso de evolución de skills:
  • /commit: en vez de indicar al modelo que haga commit y push de muchas formas distintas, lo unificó en una sola skill; tomada directamente de Claude Code
  • /worktree: hace que el agente trabaje en un worktree separado, creando uno nuevo a partir del número del plan (por ejemplo, 00034-add-user-auth)
  • /implement: integra en una sola skill el trabajo repetitivo de ejecutar una etapa del plan y luego correr /commit
  • /implement-all: conecta la ruta del worktree actual con el número del plan para implementar automáticamente todas las etapas; durante la noche usa /ralph-loop para seguir hasta completar todo, y con /codex-review local crea un proceso codex --review
  • /address-bugs: busca comentarios de Cursor + Codex desde el último commit mediante la API de GitHub para verificar e intentar corregir bugs
  • /pr-pass: se ejecuta al terminar /implement-all y 1) hace push al remoto 2) espera a que pase todo el CI 3) ejecuta /address-bugs y luego repite opcionalmente el paso 1
  • /focus: consulta el directorio plans, PR no terminados y worktrees para refrescar la memoria y ayudar a seguir el trabajo
• Si hubiera intentado construir este proceso desde cero, probablemente no lo habría logrado; la clave fue descubrir poco a poco pequeñas áreas automatizables y construir gradualmente con el tiempo

Otras herramientas

• Recientemente probó la Codex App y quedó con una impresión positiva por sus detalles y pequeños toques, aunque no se cambia por completo porque prefiere la flexibilidad de las herramientas CLI
• También intentó Cowork, pero fue difícil hacerlo funcionar bien; en ambos casos, el modelo de sandboxing marca una gran diferencia
• A veces usa la interfaz web para trabajo asíncrono, pero depende cada vez más del CLI; en contraste, hace 6 meses usaba principalmente Cursor y su agente/extensiones integradas
• Usa pencil.dev para trabajo de UI frontend; le parece interesante su modelo de despliegue, que hace shell out al Claude Code local para reutilizar sus suscripciones existentes
• Siente la necesidad de un issue tracker más formal; Dex de David Cramer y beads de Steve Yegge parecen prometedores, aunque todavía le resultan más complejos de lo necesario
• Actualmente no usa MCP automatizados de e2e como Playwright

Consejos para los laboratorios

• Feedback para Anthropic

  • Modelo: Opus se siente humano, destaca usando herramientas de ingeniería, dividiendo contexto y proponiendo “cosas que el usuario pudo haber olvidado”, pero le falta precisión de código; espera un modo “Opus Strict” que refuerce el RL sobre el modelo base para mejorar el rendimiento
    • Empieza con Opus, pero deja que Codex escriba el código; si hubiera restricciones de presupuesto, elegiría Codex
  • Harness de producto: casi no hay nada que criticar, y las ideas de Boris y Cat son sobresalientes
    • Pide adoptar un estándar de agent skills; trabajar con symlinks de directorios entre varios CLI es incómodo
    • Pide publicar el formato de salida de --stream-json; le interesa ejecutar Claude Code en un sandbox en nombre del usuario, pero le preocupa el cambio de formato y la configuración de rutas es más engorrosa que en otras CLI (Codex, Cursor, Gemini)

• Feedback para OpenAI

  • Modelo: la mejora prioritaria es la división entre ventanas de contexto y la delegación a subagentes; también sería útil el concepto de “hacer más de lo pedido” que Opus logra en la planificación
  • Feedback detallado sobre el harness de producto:
    • El modelo de sandboxing es difícil de entender comparado con Claude Code; como el modelo intenta escribir scripts, pide muchas aprobaciones, lo que genera preocupación al ejecutar el modo --yolo
    • Pide agregar una guía de usuario integrada en el CLI como en Claude Code, para poder preguntar por ubicación de skills, campos soportados y configuración del sandboxing
    • Pide convertir /review en una skill general en vez de un comando empaquetado, para que el modelo pueda invocarlo dinámicamente
    • Pide que al ejecutar cambie el título de la pestaña del terminal a algo relacionado con la tarea, porque con decenas de pestañas codex se vuelve confuso
    • Hace falta entrenamiento especializado para descripciones de PR y commits; la personalidad concisa de Codex le gusta, pero necesita mejores explicaciones
    • Pide soporte para context: fork en la definición de skills
    • Pide que los enlaces sigan siendo clicables cuando se parten en varias líneas dentro de un panel
    • Pide mostrar en la parte inferior de la barra de estado el worktree/PR/nombre de rama actual

Perspectivas a futuro

• Cita el post Gas Town de Steve Yegge, que sostiene que siempre hay que usar el máximo de tokens, mantener un pool de trabajadores operando 24/7 y esperar planear y descartar muchas cosas
  • Más allá de si la abstracción es exactamente correcta o no, evalúa que en dirección general está absolutamente en lo cierto
• Futuro ideal: laptops o sandboxes en la nube procesando ideas continuamente en segundo plano, mientras el usuario ajusta la dirección, investiga o revisa resultados
  • Trabajar con agentes de programación se parece al rol de engineering manager, pero sin tener que preocuparse por la motivación o la personalidad del agente
• En este momento ya se está bastante cerca de ese futuro; aunque en Twitter se exagera, en la práctica tiene la rutina de iniciar 3-4 tareas en Codex antes de dormir y revisarlas por la mañana
  • Sin embargo, todavía no se está al nivel de ejecutar agentes 24/7
• Dos barreras frenan un avance mayor:
  1. Tamaño/coordinación de la ventana de contexto: el agente no puede comprimir y reutilizar indefinidamente la misma ventana, así que hacen falta harnesses o mecanismos de delegación más inteligentes
  2. Resistencia a la inyección de prompts: los agentes piden aprobaciones a los pocos minutos y no se puede confiar en el modo --yolo, aunque sí existe un subconjunto de permisos/dominios aceptable
• Sobre el primer problema, Cursor está llevando al límite a los enjambres de agentes sobre múltiples ventanas de contexto; el segundo sigue siendo un área de investigación activa
  • Ejecutar en sandbox es la mejor solución provisional por ahora, pero la configuración sigue siendo engorrosa, y si un agente tiene acceso a internet abierto y a datos privilegiados al mismo tiempo, queda expuesto a la “Lethal Trifecta” de la que habla Simon Willison
• Como ingeniero solo, el cuello de botella ya son las ideas correctas, y cada vez más las ideas, la arquitectura y la secuenciación de proyectos serán los factores limitantes para construir grandes productos

[yangeok]

¿También la arquitectura..?

[wegaia]

Creo que me cambiaría a Codex aunque solo tuviera la función de subagentes.
Pero bueno, no sé si es que no les interesa...

[tested]

https://developers.openai.com/codex/multi-agent
Parece que sigue en una etapa experimental, pero sí están avanzando con ello.

[kgcrom]

En codex cli, si ingresas el comando /experimental, te ofrece Multi-agents como una función experimental.
› [x] Multi-agents Ask Codex to spawn multiple agents to parallelize the work and win in efficiency.

No sé si va exactamente en la misma línea que el subagente que mencionaste, pero échale un vistazo.