Ejecutar la primera tarea

📚 Navegación de la serie: El artículo anterior 05 · Conectar modelos de terceros como DeepSeek detalló el método para usar proveedores externos de modelos. Con la configuración completada, en este capítulo pasamos a la práctica: dejaremos que Codex modifique código de forma real para completar un flujo completo de requerimientos, edición y revisión de cambios (diff). El próximo artículo 07 · Funciones de la aplicación de escritorio detallará las capacidades de la interfaz gráfica.

Permíteme compartir una tontería que cometí cuando empecé a usar Codex.

Fue la primera noche tras instalar la CLI de Codex, y estaba impaciente por ver si realmente podía modificar código. Entré directamente con cd en un repositorio principal de la empresa, que llevaba dos años de desarrollo y contenía cientos de archivos, y le dije sin rodeos: «refactoriza el módulo de usuarios, es un caos». Codex pasó unos quince segundos leyendo archivos, la terminal se llenó de líneas que pasaban velozmente y me presentó una enorme lista de cambios que afectaban a siete u ocho archivos. Pensando «no debería haber problema», acepté los cambios sin revisarlos en detalle.

El resultado fue que refactorizó el código, pero modificó la firma de dos funciones que yo no le había pedido tocar, rompiendo las pruebas locales inmediatamente. Pasé casi una hora revisando los cambios línea por línea para deshacer lo incorrecto y quedarme con lo útil. La lección de esa noche no fue que Codex no funcionara, sino que me salté el paso más importante: revisar el diff de cambios.

Esta es la lección principal que quiero transmitirte. En este capítulo no usaremos proyectos grandes; crearemos una base de código de tres líneas para completar en cinco minutos el flujo de: proponer un requerimiento → dejar que Codex modifique los archivos en el sandbox → revisar los cambios en el diff → aceptar o revertir. Analizaremos el proceso tanto en la CLI como en la aplicación de escritorio.

Al leer este artículo, obtendrás:

• El proceso completo desde abrir la terminal o la aplicación hasta completar tu primera tarea real.
• Incorporar la revisión de diffs en tus hábitos de desarrollo (la diferencia clave entre un usuario principiante y uno experimentado).
• Los pasos detallados con los resultados esperados para la aplicación de escritorio y la CLI.
• Consejos prácticos para evitar errores comunes (cómo corregir instrucciones y cómo revertir cambios fallidos).

⚠️ Los comandos específicos, parámetros y comportamientos predeterminados se basan en la documentación oficial de Codex; la nomenclatura de los modelos y los textos de la interfaz pueden variar con las sucesivas versiones.

---

01 Prácticas de inicio: Utiliza un proyecto de prueba

Para ir directo al grano: cuando uses Codex por primera vez, no trabajes sobre tus repositorios reales; crea un proyecto de prueba con unas pocas líneas de código.

¿Por qué? Mi experiencia al principio lo ilustra claramente: los proyectos reales tienen muchos archivos y dependencias complejas, por lo que Codex pasará mucho tiempo leyendo el contexto y te presentará una lista de cambios que difícilmente podrás evaluar al completo; es precisamente cuando te sientes abrumado cuando tiendes a aceptar cambios sin revisar. Un proyecto de prueba tiene pocas líneas, por lo que verás cada cambio al instante, permitiéndote practicar con tranquilidad.

Analogía: Aprender a montar en bicicleta en un descampado. Nadie empieza a practicar en una avenida principal en hora punta; es preferible buscar un lugar despejado donde si te caes no ocurra nada grave, para familiarizarte con el equilibrio y los frenos. El proyecto de prueba es ese descampado: si el código se rompe, lo borras y lo recreas en treinta segundos sin estrés.

Recomendaciones para perfiles específicos:

• Si no estás acostumbrado a la línea de comandos: ver pasar las líneas de lectura de archivos en la terminal puede ponerte nervioso; evita añadir la presión de estar modificando código real.
• Si provienes de otras herramientas: si acostumbras a usar Claude Code y asumes que Codex se comporta igual, sus ritmos de sandbox y aprobación pueden sorprenderte (como explicamos en los capítulos 02 y 05); familiarízate primero con la herramienta en un entorno de pruebas.
• Si tienes prisa por entregar resultados: precisamente por la prisa es mejor verificar primero el flujo básico con una prueba rápida para asegurar que la integración es correcta antes de aplicarla en tareas reales.

Abre la terminal (Terminal en macOS o PowerShell en Windows) y ejecuta los comandos para crear un directorio de prueba:

mkdir hello-codex
cd hello-codex

Estos comandos crean una carpeta llamada hello-codex y acceden a ella. mkdir (make directory) crea el directorio y cd (change directory) accede a él.

A continuación, crea un archivo de Python básico. En macOS o Linux puedes ejecutar:

echo 'def add(a, b):
    return a + b' > main.py

En Windows con PowerShell, puedes abrir el Bloc de notas para crear el archivo main.py con el siguiente contenido:

def add(a, b):
    return a + b

💡 Resumen en una frase: Para tu primera prueba con Codex, utiliza un proyecto sencillo para analizar los cambios con facilidad y poder deshacer y rehacer sin riesgos.

---

02 Definir la instrucción: El flujo de pensar, actuar y observar

Con el proyecto creado, dedica un momento a estructurar tu instrucción antes de iniciar la herramienta.

¿Por qué es importante? Codex no lee la mente; la calidad de los cambios propuestos depende de la precisión de tus requerimientos. En el capítulo 02 vimos que actúa como un agente (Agent) en un ciclo continuo: analiza la instrucción, realiza acciones en segundo plano (leer y modificar archivos o ejecutar comandos) y verifica el resultado. Se resume en: Pensar → Actuar → Observar.

Analogía: Encargar una tarea a un contratista. Si le dices «arregla esta habitación», el resultado dependerá de su criterio y posiblemente no coincida con lo que esperas; si le especificas «pinta la pared de blanco, instala una toma de agua en la terraza y finaliza el próximo viernes», el contratista sabrá exactamente qué hacer y cómo evaluar el resultado. Cuanto más específicos sean los requerimientos y los criterios de aceptación, más preciso será el trabajo de Codex. La documentación oficial en el apartado de escritura de prompts recomienda:

• Facilitar la validación autónoma: incluye en tus instrucciones los comandos de prueba, validaciones de código o linters a ejecutar para que Codex compruebe su trabajo de forma autónoma.
• Dividir las tareas complejas: desglosa las refactorizaciones grandes en pasos pequeños y definidos para facilitar su revisión; si no sabes por dónde empezar, pídele a Codex que genere una propuesta de plan primero.

Compara los siguientes ejemplos de instrucciones:

Instrucción vaga ❌	Instrucción precisa ✅
«Optimiza esta función»	«Añade anotaciones de tipo a add y lanza un error TypeError si los parámetros no son numéricos»
«¿Por qué falla esta prueba?»	«Ejecuta pytest, localiza la causa del error en el log, aplica la corrección y vuelve a ejecutar para verificar que pasa»
«Refactoriza el proyecto»	«Antes de realizar cambios, propón un plan de refactorización detallado para que pueda revisarlo»

La última opción es mi práctica recomendada para tareas complejas: solicita un plan antes de permitir que modifique archivos. De este modo, revisas la estrategia del agente y autorizas la ejecución de los pasos con mayor seguridad.

💡 Resumen en una frase: Codex trabaja en un bucle de «pensar → actuar → observar»; redactar instrucciones específicas con criterios de aceptación claros evita que el agente tome decisiones incorrectas; pide planes previos para tareas complejas.

---

03 Primera tarea: Lectura de archivos sin modificaciones

Para tu primer ejercicio real, sugiero pedirle que analice el código en lugar de modificarlo.

¿Por qué? Por dos motivos prácticos: primero, confirmas que Codex tiene acceso de lectura a tus archivos locales en lugar de asumir su estructura; segundo, los análisis de código no alteran los archivos, lo que supone un entorno seguro para familiarizarse con la interfaz.

Analogía: El primer día de un compañero de equipo, donde le pides que lea el código y te explique su funcionamiento. No le encargas una refactorización de base de datos en su primera hora; prefieres escuchar su análisis para valorar cómo entiende el proyecto. Pedirle a Codex que explique el código es ese paso de toma de contacto.

Tanto en la CLI como en la aplicación de escritorio, escribe la siguiente instrucción (en lenguaje natural):

Explica qué hace el archivo main.py en un lenguaje sencillo

Pulsa Intro. Codex leerá el contenido de main.py de forma autónoma sin que tengas que adjuntar el archivo a la conversación. A continuación, te responderá indicando que el archivo define una función add que toma dos parámetros (a y b) y devuelve la suma de ambos.

Completar este paso confirma dos cosas: la instalación de Codex y el login son correctos, y el agente tiene acceso de lectura a los archivos de tu máquina. Con esta base verificada, podemos pasar a las modificaciones.

Clasificación de las instrucciones para tus flujos de trabajo:

Tipo de instrucción	Acción	Ejemplo	Riesgo
Análisis	Lee y explica el código	«Explica esta lógica»	Nulo; no altera archivos
Modificación	Modifica código existente	«Añade tipos a la función»	Medio; altera archivos; requiere revisar el diff
Generación	Crea nuevos archivos o funciones	«Escribe una prueba unitaria»	Medio; crea o modifica archivos; requiere revisar el diff

Al trabajar en un proyecto heredado o desconocido, suelo iniciar el flujo pidiendo: «ayúdame a analizar la estructura de este proyecto». Esto me ayuda a verificar la comunicación y a obtener un resumen del proyecto estructurado por el agente.

💡 Resumen en una frase: Comienza con tareas de análisis de código para verificar la comunicación y el acceso de lectura antes de pasar a la edición y creación de archivos.

---

04 Revisar el diff de cambios

Llegamos al paso clave: dejar que Codex modifique el código. Esta es la fase crítica donde debes prestar atención para evitar problemas.

En la misma conversación, introduce la instrucción de modificación:

Añade anotaciones de tipo a la función add en main.py y añade control de errores básico

Es importante aclarar el comportamiento predeterminado del agente: con la configuración estándar, Codex realiza las modificaciones directamente en los archivos del espacio de trabajo sin detenerse a pedir confirmación para cada archivo. ¿A qué se debe? En el capítulo 02 vimos que en el modo Auto estándar (workspace-write con aprobación on-request), las lecturas, escrituras y comandos ejecutados dentro del espacio de trabajo se consideran acciones internas autorizadas, por lo que el agente actúa sin interrumpirte; solo se detendrá a preguntar si intenta salir del espacio de trabajo (como modificar archivos del sistema o conectarse a internet). Su flujo de trabajo es:

1. Localiza el archivo a modificar (main.py) y aplica los cambios en el sandbox local.
2. Te muestra los cambios en formato diff (diferencias de código) en la terminal para que puedas revisarlos.
3. Tú realizas la validación: revisas el diff; si es correcto, mantienes los cambios; si hay errores, le pides corregirlos o los reviertes con Git (ver secciones siguientes).

La revisión del diff sigue siendo indispensable; simplemente se realiza como control posterior a la edición. El agente aplica las modificaciones y te presenta las diferencias en la terminal para que valides el resultado; dado que los cambios aún no se han confirmado en tu repositorio Git, puedes revertirlos inmediatamente si detectas fallos. Tú mantienes el control de los cambios basándote en la revisión del diff.

⚠️ Para que los comandos de git diff y las reversiones funcionen, el proyecto debe estar inicializado como repositorio Git. Si no has ejecutado git init, el control de versiones no estará disponible para comparar los cambios (aunque seguirás viendo el diff impreso en la terminal de Codex). Antes de permitir que modifique archivos, ejecuta git status para confirmar que el repositorio está limpio. En las siguientes secciones incluiremos el paso de inicializar Git.

Analogía: Un compañero que aplica cambios en una rama de desarrollo y te pide que los revises. Realiza el trabajo de forma autónoma, pero los cambios no se integran en la rama principal hasta que tú apruebes el pull request tras verificar el diff de cambios. Codex funciona bajo este esquema de edición y revisión posterior.

⚠️ Si prefieres que el agente solicite confirmación antes de aplicar modificaciones físicas en los archivos, debes cambiar el modo de permisos ejecutando /permissions para cambiar al modo read-only (sólo lectura, requiere aprobación previa para editar archivos) o solicitar planes de cambios en texto en tu instrucción antes de la ejecución.

Cómo interpretar un diff

El diff muestra la comparación línea por línea entre el estado anterior y el nuevo; recuerda estas reglas básicas:

• Las líneas que comienzan con - (o en color rojo) representan el código eliminado.
• Las líneas que comienzan con + (o en color verde) representan el código añadido.
• Las líneas sin marcas corresponden al contexto circundante para ayudarte a localizar el fragmento modificado.

En tu archivo main.py, la función original:

def add(a, b):
    return a + b

Se modificará a una estructura similar a la siguiente (el código exacto puede variar según la generación):

def add(a: float, b: float) -> float:
    if not isinstance(a, (int, float)) or not isinstance(b, (int, float)):
        raise TypeError("Los parámetros a y b deben ser numéricos")
    return a + b

Se han agregado anotaciones de tipo (a: float) y validación de tipos de datos. Al revisar el diff, hazte estas tres preguntas básicas:

1. ¿Se han aplicado los cambios en los archivos y funciones solicitados? (Evita que modifique partes del código ajenas a la instrucción).
2. ¿La lógica y estructura del código propuesto son correctas?
3. ¿Se ha eliminado algún fragmento de código que debía conservarse?

Si el resultado de la revisión es satisfactorio, conserva el código; si detectas inconsistencias, pídele que lo corrija en el chat o reviértelo con Git. Dedicar unos segundos a verificar este diff es lo que evita la introducción de fallos en tus proyectos.

Cuándo te solicitará autorización previa

En el modo Auto estándar, las modificaciones en el espacio de trabajo no requieren confirmación previa. Las solicitudes de aprobación se mostrarán al intentar realizar acciones fuera del sandbox, principalmente:

Acción propuesta	Comportamiento en modo Auto	Interfaz de usuario
Lectura y escritura en el espacio de trabajo	Ejecución directa; muestra el diff al finalizar	Sin confirmación previa
Ejecución de comandos internos (ej. tests)	Ejecución directa	Sin confirmación previa
Comandos que requieran red (ej. instalar paquetes)	Detención previa y solicitud de confirmación	Cuadro de aprobación interactivo
Modificación de archivos fuera del espacio de trabajo	Detención previa y solicitud de confirmación	Cuadro de aprobación interactivo

Cuando aparezca el cuadro de aprobación, revisa la acción propuesta: si es correcta y segura, autorízala; de lo contrario, recházala e introduce aclaraciones.

Regla de seguridad: evita desactivar las solicitudes de aprobación (como usar el modo never o acceso total) en tus primeros pasos. Si permites que el agente actúe sin filtros, modificará múltiples archivos sin previo aviso, dificultando el seguimiento de los cambios en caso de error. Mantén los filtros estándar para supervisar el proceso cómodamente.

💡 Resumen en una frase: Con la configuración estándar, Codex aplica los cambios en tu espacio de trabajo y te presenta el diff de diferencias para su revisión; las autorizaciones previas se reservan para accesos de red o externos al espacio de trabajo.

---

05 Cómo corregir las propuestas del agente

Rechazar una propuesta o diff de cambios no significa cancelar la tarea y empezar de nuevo; es la oportunidad para ajustar el enfoque del agente.

Codex mantiene la conversación estructurada en hilos (Threads); el hilo conserva el contexto acumulado de la sesión, incluyendo las instrucciones anteriores, las respuestas del modelo y los análisis de archivos. Si un diff no es correcto, describe la corrección en la conversación y Codex modificará su propuesta basándose en ese contexto.

Analogía: Pedir que corrijan un plato en un restaurante. Si el plato no está a tu gusto, no te vas a otro local; le indicas al camarero qué corregir y la cocina prepara una nueva versión basándose en tu comanda original. En Codex, el hilo mantiene el contexto de tu instrucción y solo debes describir la modificación necesaria.

Por ejemplo, si le pides a Codex que configure un sistema de caché y su propuesta introduce dependencias de librerías externas que no quieres instalar, puedes indicarle en el chat:

Evita usar librerías externas; utiliza la librería estándar de Python con functools.lru_cache

El agente descartará la propuesta anterior y generará una nueva versión del código utilizando la librería estándar, sin necesidad de reiniciar la conversación o volver a explicar tu proyecto.

Diferencias en el flujo de trabajo:

Enfoque ineficiente ❌	Práctica recomendada ✅
Asumir que un rechazo cancela el progreso	Considerar el rechazo como un paso de ajuste en el flujo
Modificar el código a mano si el agente se equivoca	Describir el error en el chat para que el agente aplique la corrección
Reiniciar la conversación ante propuestas incorrectas	Iterar en el mismo hilo de chat para aprovechar el contexto

💡 Resumen en una frase: Si un cambio propuesto no es correcto, describe el ajuste necesario en la misma conversación; Codex modificará el código basándose en el contexto acumulado sin tener que reiniciar la sesión.

---

06 Git como mecanismo de recuperación de cambios

Si aceptas una propuesta de cambios y el código modificado presenta fallos en tu entorno local, puedes revertir los cambios de forma segura siempre que hayas creado un commit de Git previo.

Esta es una recomendación básica para trabajar con agentes de programación: realiza commits en tu repositorio Git antes y después de dejar que el agente aplique modificaciones, de modo que puedas regresar al estado anterior si el resultado no es el esperado.

Analogía: Guardar la partida antes de enfrentarte a un obstáculo en un videojuego. Creas un punto de restauración al que puedes regresar si el intento falla, evitando perder tu progreso. El comando git commit es ese punto de restauración antes de dejar que Codex modifique los archivos.

Flujo de comandos recomendado antes de iniciar el agente:

git init
git add -A && git commit -m "Estado previo a los cambios de Codex"

Si los cambios aplicados por el agente no funcionan y prefieres descartarlos por completo, puedes revertir el espacio de trabajo al estado del último commit ejecutando:

git restore .

⚠️ El comando git restore . descarta todas las modificaciones no guardadas en el espacio de trabajo, regresando los archivos al estado del último commit. Utilízalo únicamente si decides descartar por completo las modificaciones de esa sesión; si parte de los cambios son útiles, prefiere corregirlos mediante el chat de Codex.

Si solo deseas revertir cambios específicos, pídeselo al agente en la misma conversación:

No me convence esta última modificación, revierte los cambios al estado anterior

Mecanismos de recuperación de cambios:

Método	Ejecución	Ámbito de uso	Consideraciones
Instrucción de reversión	Escribir en el chat que deshaga la acción	Ajustes finos sobre cambios recientes	Depende de la interpretación del contexto por el modelo
Reversión con Git	Ejecutar git restore . en la terminal	Descartar por completo el bloque de cambios aplicado	Requiere haber guardado el estado con git commit previamente

Mi recomendación de seguridad: ejecuta git commit antes de encargar cambios complejos a Codex. Esto te da la seguridad de poder descartar cualquier propuesta fallida en segundos con git restore . y volver a plantear la instrucción con un enfoque diferente.

💡 Resumen en una frase: Mantén tu código seguro: realiza un commit de Git antes de iniciar las modificaciones y usa git restore . para revertir el espacio de trabajo si el resultado del agente no es el esperado; usa el chat para correcciones menores.

---

07 Práctica con la CLI: Flujo paso a paso

Realicemos la práctica de la primera tarea en la CLI. Abre tu terminal y sigue los pasos detallados:

Paso 1: Crear el proyecto y registrar el estado en Git (macOS / Linux)

mkdir hello-codex && cd hello-codex
echo 'def add(a, b):
    return a + b' > main.py
git init && git add -A && git commit -m "Commit inicial de prueba"

Usuarios de Windows: los comandos mkdir y cd son idénticos; crea el archivo main.py con el Bloc de notas introduciendo la función add en dos líneas, y ejecuta la secuencia de comandos de Git en PowerShell.

Resultado esperado: la carpeta hello-codex contiene el archivo main.py con la función básica de suma y se ha registrado el commit inicial en el historial de Git. Puedes listar los archivos para confirmarlo.

Paso 2: Iniciar Codex en el directorio de trabajo

codex

Resultado esperado: se inicia la interfaz de la CLI de Codex en la terminal, mostrando la línea de entrada esperando tus instrucciones. Si solicita inicio de sesión, completa el login según las instrucciones del capítulo 03.

⚠️ Inicia siempre la CLI de Codex en el directorio específico del proyecto. Codex define su espacio de trabajo y sandbox a partir del directorio en el que ejecutas el comando codex; si lo inicias en la raíz del sistema o en tu carpeta personal, el agente intentará leer archivos en ubicaciones incorrectas.

Paso 3: Solicitar análisis del código (operación sin riesgo)

Explica qué hace el archivo main.py en un lenguaje sencillo

Resultado esperado: Codex lee el contenido del archivo local y explica en el chat que se trata de una función de suma. Ver esta explicación confirma que el agente lee correctamente tus archivos locales.

Paso 4: Solicitar modificaciones y revisar el diff

Añade anotaciones de tipo a la función add en main.py y añade control de errores básico

Resultado esperado: con la configuración por defecto, Codex aplica las modificaciones en main.py e imprime el diff de cambios en la terminal, mostrando el código añadido (en verde con marca +) y el eliminado (en rojo con marca -). Evalúa los cambios con las tres preguntas de validación. Si solicita autorización para alguna tarea de red, acéptala en el prompt.

Paso 5: Validar los cambios en el archivo local

Sal de la sesión de Codex (pulsando Ctrl + C o escribiendo /exit) y comprueba el contenido del archivo en la terminal:

cat main.py

(En Windows con PowerShell, ejecuta type main.py).

Resultado esperado: el archivo local contiene el código modificado con las anotaciones de tipo y la validación de parámetros, coincidiendo con la propuesta del diff de la CLI.

Verifica el estado del repositorio Git:

git diff

Resultado esperado: la terminal de Git muestra las diferencias aplicadas sobre tu commit inicial, coincidiendo con el diff presentado por Codex.

💡 Resumen en una frase: Flujo en la CLI: crea el proyecto e inicializa Git → arranca codex en la carpeta → pide un análisis para verificar → encarga los cambios y revisa el diff → cierra la sesión y comprueba con cat y git diff.

---

08 Práctica en la aplicación de escritorio

Si utilizas la aplicación de escritorio (disponible para macOS y Windows), puedes completar el mismo flujo de trabajo utilizando la interfaz gráfica.

El proceso lógico es idéntico al de la CLI; la diferencia radica en el uso de controles visuales para la revisión del diff. Los pasos a seguir son:

1. Inicia la aplicación de escritorio y loguéate con tu cuenta de ChatGPT o API key (ver diferencias de acceso en el capítulo 03).
2. Selecciona la carpeta del proyecto en el asistente inicial. Elige la carpeta hello-codex que creamos en el ejercicio anterior (o crea una nueva carpeta vacía para la prueba).
3. Confirma el modo Local: antes de enviar tus mensajes, asegúrate de que está marcado el selector Local en la esquina inferior izquierda del cuadro de entrada para que actúe sobre tus archivos y no en la nube.
4. Envía las instrucciones en el cuadro de chat: introduce primero la instrucción de análisis:

Explica qué hace el archivo main.py en un lenguaje sencillo

Una vez que te responda explicando la función de suma, introduce la instrucción de modificación:

Añade anotaciones de tipo a la función add en main.py y añade control de errores básico

Resultado esperado: en el modo Local, la aplicación aplica los cambios en tu carpeta local y abre el panel de revisión de cambios (review pane), mostrando el diff de líneas añadidas y eliminadas de forma gráfica. El panel refleja los cambios pendientes de confirmar en tu repositorio local. La interfaz gráfica facilita la revisión visual de diffs extensos y proporciona botones para confirmar (commit), descartar o revertir los cambios directamente desde la aplicación. Si los cambios son correctos, confírmalos; si no, pídele ajustes en el chat o descártalos.

Comparativa de uso de las interfaces:

Parámetro	CLI (Línea de comandos)	Aplicación de escritorio
Disponibilidad	✅ macOS, Windows y Linux	❌ Solo macOS y Windows
Curva de aprendizaje	Requiere familiaridad con la terminal	✅ Visual y de clics, más accesible
Visualización de diffs	Salida de texto estándar en la terminal	✅ Panel gráfico interactivo con colores y scroll
Gestión de proyectos	Múltiples terminales	✅ Selección visual de proyectos en la barra lateral
Lógica de ejecución	Identificación de espacio de trabajo y sandbox	Idéntica; el agente analiza y edita localmente de la misma manera

Recomendación de uso: utiliza la CLI para tareas integradas en tu flujo de trabajo de terminal; si vas a realizar refactorizaciones que afecten a múltiples archivos, abre la aplicación de escritorio para aprovechar el panel gráfico de revisión de diffs, facilitando la comparación visual de los cambios.

💡 Resumen en una frase: La aplicación de escritorio (disponible en Mac y Windows) traslada el mismo flujo de edición a un entorno visual; asegúrate de marcar el modo Local antes de enviar mensajes y utiliza el panel gráfico de revisión para confirmar o descartar cambios cómodamente.

---

09 Resumen del flujo de trabajo

Cualquiera de las interfaces de Codex sigue esta secuencia de desarrollo para modificar código:

El punto de control crítico es la revisión del diff: el agente aplica los cambios en el sandbox local y te los presenta; debes revisar que las modificaciones se limiten a lo solicitado, verificar la lógica propuesta y decidir si integras los cambios en tu rama o si los reviertes. Este paso de control humano es la garantía de calidad de tu base de código.

💡 Resumen en una frase: El núcleo de trabajo con Codex se resume en: proponer el cambio → Codex edita localmente → revisas el diff en pantalla → aceptas o reviertes; incorporar el commit previo de Git y la revisión sistemática del diff te evitará problemas de integración de código.

---

10 Resumen

En este capítulo has completado tu primera tarea de desarrollo con Codex:

Concepto	Detalle práctico
Entorno de pruebas	Utiliza proyectos pequeños para familiarizarte con las lecturas y escrituras del agente sin riesgos
Instrucciones	Emplea requerimientos específicos con criterios de aceptación; solicita planes detallados para tareas complejas
Análisis previo	Inicia el flujo solicitando explicaciones de código para validar el acceso del agente a los archivos locales
Edición y diff	En la configuración estándar, Codex edita en el espacio de trabajo y presenta el diff; revisa siempre las diferencias antes de archivar
Corrección	Modifica el enfoque del agente describiendo las correcciones en el mismo hilo de chat para aprovechar el contexto
Git como respaldo	Realiza commits antes de que Codex actúe; utiliza git restore . para descartar cambios fallidos de forma limpia

Has verificado el acceso local de la herramienta en tu máquina, aprendido a interpretar las diferencias de líneas en el diff y comprendido los mecanismos para corregir propuestas e integrar o descartar los cambios aplicados en tus archivos. Este ciclo básico de edición y validación es la base para todas las tareas de programación con Codex.

El próximo capítulo 07 · Funciones de la aplicación de escritorio detallará las capacidades adicionales de la aplicación de escritorio de Codex, incluyendo el trabajo en múltiples proyectos en paralelo, la gestión de ramas con worktrees aislados, el uso del navegador integrado y la automatización de tareas recurrentes.

---

Lecturas recomendadas

• Uso de la CLI en modo desatendido: ejecutar tareas en scripts y CI
• Codex Cloud: delegación y ejecución de tareas de desarrollo en la nube
• Manual de uso de la CLI de Codex