Guía de uso de Codex: cómo empezar, 5 tips y best practices

Name

Soren Atelier

Actualizado el 16/3/2026

Codex no es solo un autocompletador. Es un agente de AI coding que puede leer código, editar archivos, ejecutar comandos y ayudarte a revisar cambios. Cuando alguien busca codex cómo usar, la clave no es memorizar la instalación, sino entender qué delegar al agente y qué validar como humano.

La conclusión rápida es esta: Codex funciona mejor cuando empiezas con tareas pequeñas y bien delimitadas. En vez de pedir "arregla todo el repo", define archivos objetivo, resultado esperado, restricciones y criterio de finalización. Con eso suben la precisión y la calidad del review.

Si quieres ver el contexto general de AI coding, empieza por el hub de AI Coding y por Best Vibe Coding Tools 2026. Si ademas quieres comparar enfoques, te conviene leer Codex vs Claude Code Skills.

Resumen directo: cuál es la forma correcta de usar Codex

Una secuencia de inicio simple:

1. Elige CLI o App para empezar, no las dos a la vez.
2. Haz 3 tareas pequeñas seguidas.
3. Aprende a usar AGENTS.md y review.
4. Luego escala a skills y subagents.

La primera decisión suele ser "por dónde empiezo". CLI te deja probar rápido, App destaca en review y worktree, e IDE extension minimiza la fricción en el flujo que ya usas.

Qué es Codex

Codex es el coding agent de OpenAI. En CLI trabaja dentro de un directorio local: lee código, edita y ejecuta comandos. En App suma revisión de diffs, trabajo paralelo con worktrees y tareas en segundo plano. La extensión de IDE acerca esa experiencia al editor.

El error común es tratarlo solo como "chat que escribe código". En la práctica, donde más valor aporta es en:

• comprender código que no conoces
• cambios pequeños y medianos de funcionalidad
• investigación y reproducción de bugs
• validación de cambios con test, lint y build
• code review y depuracion de diffs
• convertir tareas repetitivas en skills o automations

Es mejor pensarlo como un agente integrado en tu flujo real, no como un modelo aislado.

Cómo empezar con Codex

1. Instala la CLI y abre la primera sesión

La vía mínima de arranque en la documentación oficial es:

npm i -g @openai/codex
codex

En el primer arranque te autenticas con cuenta de ChatGPT o API key. Lo importante en esa primera sesión no es "producir mucho", sino calibrar el entorno con una tarea de bajo riesgo.

Por ejemplo:

Resume la estructura de este repositorio y explícame sus directorios clave y el flujo de desarrollo.
No edites archivos todavía; solo análisis.

Con un prompt así validas cómo entiende el repo y con qué nivel de detalle responde.

2. En la segunda iteración, pide un cambio pequeño

Ahora ya puedes pasar a una edicion acotada:

Corrige solo el texto de este componente.
Limita los cambios a un único archivo y resume el diff final.

La clave aqui es no abrir demasiado el alcance. Codex puede asumir tareas amplias, pero al principio la estabilidad mejora si acotas objetivo y superficie.

3. En la tercera iteración, incluye verificación

No te quedes en "editar"; fuerza el cierre del ciclo:

Corrige este fallo de test.
Después ejecuta solo los tests relacionados y resume en 3 líneas qué has cambiado.

Ese habito de validar despues de editar marca una diferencia grande en calidad.

Si no paras en "generar" y trabajas en bucle read -> plan -> edit -> test -> review, suben la fiabilidad y la trazabilidad. El control humano del centro representa la regla de aceptar solo cambios que puedes explicar.

Uso básico en el día a día

Primero que entienda, luego que toque código

En repos existentes, suele funcionar mejor:

Resume la responsabilidad de este modulo y sus dependencias.
Después propon dos opciones de cambio mínimo.
Todavía no edites archivos.

Eso te permite validar comprension antes de abrir diffs.

Define siempre el criterio de finalizacion

Codex es más estable cuando sabe exactamente qué significa "hecho".

Ejemplo flojo:

Mejora esta pagina

Ejemplo util:

Acorta la introducción de esta página.
Haz que el primer pantallazo responda "qué es" y "por qué importa".
Mantén la estructura actual de H2 y no añadas nuevos bloques de código.

Trabaja los diffs con mentalidad de review

En App, el review pane te deja revisar tanto cambios de Codex como otros cambios locales no commiteados, con staged/unstaged e inline comments por línea. Eso convierte "corrige esto" en feedback concreto y verificable.

Si usas App como superficie principal, te conviene leer también Parallel Code Agents, porque conecta muy bien con la lógica de worktrees y review.

5 tips prácticos

Tip 1: no empieces por implementación, empieza por plan

Cambiar una frase en el prompt suele ahorrar iteraciones:

Primero dame un plan de 3 pasos para la corrección.
Después ejecuta la implementación.

Aplica igual a bugs, refactors y cambios de contenido técnico.

Tip 2: escribe alcance, objetivo y limites en cada tarea

Con instrucciones ambiguas, Codex tiende a abrir alcance. Para mantener control, incluye siempre:

• que puede tocar
• que resultado debe conseguir
• que no debe tocar

Ejemplo:

Modifica solo `components/header.tsx`.
Objetivo: reducir el espaciado de navegacion.
No cambies logica ni anadas dependencias.

Tip 3: mueve las reglas estables a AGENTS.md

Repetir el mismo contexto en cada prompt no escala. En best practices de Codex, las reglas duraderas van a AGENTS.md.

Elementos mínimos recomendados:

• estructura del repo
• comandos de build / test / lint
• convenciones de código
• expectativas de PR
• definición de done

/init en CLI te crea un punto de partida para AGENTS.md, pero conviene ajustarlo al flujo real de tu equipo.

Si separas bien responsabilidades, cada capa hace su trabajo: prompt para la tarea del turno, AGENTS.md para reglas del repo, skills para procedimientos reutilizables y automations para ejecuciones periódicas.

Tip 4: usa subagents para paralelizar exploración y review

A fecha de 16 de marzo de 2026, los subagent workflows están activos por defecto en Codex y se ven en App y CLI. Codex solo lanza subagents especializados cuando se lo pides de forma explícita y luego consolida resultados.

Encaja muy bien en:

• exploración de repos grandes
• review de PR por varios ejes
• comparación de alternativas
• planificación en varios pasos

Prompt ejemplo para review paralelo:

Compara esta rama con main y haz review.
Asigna en paralelo los ejes security, bugs, test flakiness y maintainability a subagents distintos,
y cuando terminen, entrega un único resumen consolidado.

La ventaja es clara: no metes toda la carga en una unica cadena de razonamiento.

La forma más clara de usar subagents es repartir criterios en paralelo y después volver a un resumen único de decisión.

Limitaciones a tener en cuenta:

• no arrancan solos si no los pides
• cada subagent puede consumir modelo y herramientas por separado, por lo que sube el coste en tokens
• si divides una tarea fuertemente acoplada, puedes aumentar el coste de integración

Paralelizar no es un fin en sí mismo: funciona cuando el trabajo es realmente divisible.

Tip 5: exige siempre test o review al final

La mejora real no es "escribir más rápido", sino "cerrar con verificación". Tras cada cambio, fuerza al menos una de estas dos acciones:

• ejecutar tests relacionados
• lanzar /review con otra perspectiva

En App, los inline comments sobre diff acortan mucho el bucle de correccion.

Best practices

1. Escala de pequeño a grande

La progresión recomendada:

1. solo análisis
2. cambio en un archivo
3. bugfix pequeño
4. corrección con tests
5. cambios multifichero
6. subagents y automation

Con esta secuencia detectas antes limites de contexto, reglas faltantes y puntos de riesgo.

2. Empieza con permisos conservadores

La recomendación de base en best practices de OpenAI es empezar con permisos por defecto y ampliar solo cuando tengas evidencia de necesidad. Es la forma más segura de contener errores tempranos.

En repos compartidos o cerca de produccion, review y approval no son opcionales.

3. Guarda reglas duraderas en configuracion, no en prompts largos

Si metes demasiadas reglas en cada prompt, diluyes el objetivo de la tarea. Mejor separar:

• reglas permanentes en AGENTS.md
• procedimientos repetibles en skills
• tareas periódicas en automations

Los skills de Codex (con SKILL.md + references + scripts opcionales) son muy útiles para checks recurrentes y procesos de revisión.

4. Si ejecutas varios threads en paralelo, usa worktree

Cuando varias tareas conviven en el mismo repo, worktree evita que los contextos se mezclen. En Codex App, worktree está pensado justo para paralelizar sin romper el estado local principal.

Casos típicos:

• bugfix en una rama y docs en otra
• una tarea en background mientras sigues desarrollando
• probar una idea sin contaminar tu entorno principal

Sin worktree, el coste de revisión e integración sube rápido.

5. No "aceptes" cambios: selecciona cambios

No conviene aplicar diffs en bloque sin filtro. Usa stage, revert e inline comments para quedarte solo con lo valido. El mejor uso de Codex no es piloto automatico total, sino borrador rapido + asistente de validacion.

Cómo usar Codex según tu perfil

Si estás empezando

Empieza por comprensión y correcciones pequeñas, no por generación masiva:

• qué hace esta función
• por qué aparece este error
• cuál es el cambio mínimo razonable

Así mejoras aprendizaje y productividad a la vez.

Si desarrollas en solitario

Codex encaja muy bien en ciclos de especificar, cambiar, testear y revisar. Los subagents son especialmente útiles cuando separas exploración técnica y revisión final.

Si trabajas en equipo

En equipos, importa menos el "prompt engineering individual" y más la estandarización: AGENTS.md, reglas de review, worktrees y skills compartidos. Eso reduce la variabilidad entre personas y turnos.

Cuando no encaja tan bien

Si buscas delegación ciega sin definir contexto ni revisar resultados, Codex no es la herramienta correcta. Aporta más donde hay disciplina de instrucciones y control de diffs.

FAQ

¿Es Codex apto para principiantes?

Sí. La mejor entrada no es un proyecto enorme, sino explicación de código, diagnóstico de errores y cambios acotados.

¿Debo empezar por CLI o por App?

Si trabajas cómodo en terminal, CLI es la vía más directa. Si priorizas visibilidad de diffs y trabajo paralelo, App suele ser mejor punto de partida.

¿Cuándo conviene usar subagents?

Cuando puedes separar perspectivas (seguridad, bugs, tests, mantenibilidad) y consolidar después. En tareas muy acopladas puede ser contraproducente.

¿Cómo reparto AGENTS.md y skills?

AGENTS.md define reglas y expectativas del repo. Los skills encapsulan procedimientos reutilizables. Una buena referencia mental es "acuerdo operativo" vs "workflow reutilizable".

¿Puedo confiar automáticamente en los cambios de Codex?

No. Debes validar con tests y review de diffs antes de aceptar cambios.

Related Guides

• Hub de AI Coding
• Parallel Code Agents
• Cómo crear un agente estilo Claude Code con Claude Agent SDK
• Best Vibe Coding Tools 2026
• Codex vs Claude Code Skills