Lectura del articulo oficial de Codex: como llevar Codex al maximo

Wed, 27 May 2026 08:21:18 +0800

La mayoria de los desarrolladores empiezan a usar Codex con tareas de codigo: leer un repositorio, modificar un diff, ejecutar pruebas o abrir un pull request.

Ese sigue siendo el escenario central de Codex. Pero gran parte del trabajo en una computadora ya esta rodeado de codigo y herramientas: ejecutar comandos shell, navegar paginas web, llamar API, exportar documentos, responder mensajes y activar automatizaciones. A medida que estas capacidades se conectan con Codex, deja de ser solo un asistente de codigo en sentido estricto y se parece mas a un sistema para ayudarte a completar trabajo en la computadora.

Codex app vuelve este cambio mas concreto. Un thread puede conservar contexto, llamar herramientas, mostrar resultados y avanzar entre varias rondas de prompts, en vez de empezar de cero en cada conversacion.

Para sacar mas partido de Codex, la clave es combinar estas capacidades:

Hilos duraderos para conservar contexto a largo plazo
Entrada por voz, steering y queuing para que el usuario siga controlando el proceso
browser, computer use, MCP servers y connectors para que Codex salga del repositorio
thread automations y Goals para que las tareas sigan avanzando cuando el usuario se va
Barra lateral para revisar codigo, documentos, presentaciones, paginas web y otros artefactos
Memoria compartida para escribir el contexto importante fuera del thread

Hilos duraderos

Durable threads se refiere a hilos largos que pueden conservar el contexto de trabajo entre varias sesiones.

Pinned threads es una entrada muy practica. Sirve para esos flujos de trabajo a los que vuelves una y otra vez, por ejemplo:

Thread de Chief of Staff
Thread de publicacion
Thread de revision de documentos
Thread de monitoreo externo

No son chats temporales, sino espacios de trabajo persistentes. Codex puede volver al mismo thread mas adelante y reutilizar decisiones, preferencias e informacion de fondo anteriores, evitando reconstruir el contexto desde cero cada vez.

Los atajos tambien lo vuelven mas fluido. Command-1 a Command-9 permiten saltar directamente a los threads guardados.

Entrada por voz

El valor de la entrada por voz esta en capturar ideas que todavia no se han ordenado como texto formal.

Codex incluye entrada por voz. Es especialmente util para esos puntos de partida difusos que se sienten naturales al decirlos, pero raros al escribirlos:

1
2
3

我记得 Slack 里好像有个叫 Ben 的人提过这个。
具体细节我不记得了。
帮我去找一下。

Para un agent que puede buscar, organizar contexto y reportar resultados, esto normalmente ya basta para empezar.

La voz tambien encaja bien con volcados de ideas de dos o tres minutos. Transcripciones de reuniones, notas dictadas de planificacion y registros originales sin ordenar suelen ser mas utiles que un resumen de una frase, porque conservan la incertidumbre, los puntos clave y los hilos de pensamiento incompletos.

Steering y queuing

La voz se vuelve aun mas util cuando se combina con control explicito.

Steering significa insertar una nueva direccion mientras Codex ejecuta una tarea, para que cambie de rumbo antes de terminar el paso actual.

Por ejemplo, al revisar una pagina web, el usuario puede anotar en la barra lateral e interrumpir la tarea actual al mismo tiempo:

1
2
3

这里再小一点。
这两个元素之间的间距不对。
这句文案写错了。

Queuing es distinto. No interrumpe la tarea actual, sino que pone el siguiente paso en la cola:

`1`	`这项工作完成后，把预览链接发给 Slack 里的 reviewer。`

Steering cambia lo que Codex esta haciendo ahora. Queuing cambia lo que deberia hacer despues. Ambos mantienen al usuario cerca del trabajo mientras la tarea se despliega.

Herramientas y alcance accesible

Cuando un thread ya tiene continuidad, la siguiente pregunta es: que puede operar?

Codex puede expandirse hacia afuera por capas:

$browser: adecuado para inspeccion de paginas web, anotaciones y review en la barra lateral
@chrome: adecuado para flujos de navegador que dependen de la sesion iniciada del usuario en Chrome
@computer: adecuado para tareas que solo pueden completarse mediante una GUI de escritorio

MCP servers y connectors extienden la misma idea a mas flujos de trabajo. Slack, Gmail y Calendar son importantes porque muchas tareas no aparecen primero como codigo, sino como mensajes, correos y problemas de agenda.

Skills sirve para fijar trabajo repetitivo. Cuando un proceso ya demostro ser util, puedes empaquetarlo como skill para que Codex no tenga que aprender esos pasos de nuevo la proxima vez.

Continuar el trabajo desde cualquier lugar

Codex mobile app cambia el tiempo que el usuario necesita estar sentado frente a la computadora.

Una tarea puede empezar en Mac, porque los archivos, permisos y el entorno local estan ahi; despues el usuario puede alejarse del escritorio y seguir confirmando, complementando o cambiando la direccion desde el telefono.

Esto resulta valioso en muchas situaciones pequenas: cuando Codex ejecuta una tarea larga, el usuario puede levantarse; si Codex necesita confirmacion, puede responder desde fuera; si la direccion esta mal, tambien puede redirect a tiempo. Lo que realmente se queda en su sitio es el entorno local, no la persona.

Automatizacion

Automations puede ejecutar trabajo de Codex segun un horario.

Si una tarea periodica debe empezar de nuevo desde cierto workspace, como un informe diario o una revision regular del repositorio, se puede usar scheduled automation. Si la programacion debe volver a una conversacion existente y reutilizar su contexto, thread automation encaja mejor.

Thread automations se parece mas a un despertar por latido: vuelve al mismo Codex thread con un ritmo fijo.

Pinned threads requieren que el usuario vuelva de forma activa, mientras que thread automation puede comprobar cada pocos minutos o cada pocas horas, seguir ejecutandose hasta cumplir la condicion y ajustar el ritmo con el tiempo.

Por ejemplo, un thread de Chief of Staff podria ejecutarse cada 30 minutos:

1
2
3

每 30 分钟检查 Slack 和 Gmail，找出需要我注意但还没有回复的消息。
帮我判断哪些最重要。
如果有人问我问题，尽可能深入研究答案，并替我起草回复，但不要发送。

Cuando el usuario vuelve, la recoleccion de contexto mas costosa ya suele estar hecha. La decision real de enviar o no enviar sigue siendo humana.

Thread automations tambien funciona bien para bucles de feedback. Puede revisar periodicamente comentarios de pull request, comentarios de Google Docs o respuestas en Slack, y seguir empujando el trabajo periferico mientras el usuario no esta.

Por ejemplo, en un flujo de animacion: el reviewer envia feedback de video en Slack, thread automation revisa el thread de forma periodica; si hay un comentario nuevo, vuelve a renderizar la version y responde al reviewer en el mismo Slack thread. Si alguna integracion no puede completar la subida final, la automatizacion de escritorio tambien puede completar el ultimo paso mediante la GUI.

Ese bucle cruza Slack, el repositorio de codigo y aplicaciones de escritorio, pero para el usuario sigue viviendo dentro del mismo flujo de trabajo.

Goals

Goals encaja mejor con tareas que tienen un punto final claro y que un agent puede impulsar de forma continua.

Un goal debil podria ser:

`1`	`实现这个 Markdown 文件里的计划。`

Un goal mas fuerte tiene criterios de finalizacion medibles.

Por ejemplo, al migrar una herramienta interna de Python a Rust, puedes crear primero el nuevo directorio y luego definir el objetivo con claridad: la nueva implementacion solo se considera completa cuando las pruebas unitarias pasan.

En esencia, un Goal es ejecucion continua mas verificadores. El usuario necesita definir el resultado, las condiciones de parada y las senales que indican si Codex se acerca al objetivo.

Los verificadores habituales incluyen:

Suite de pruebas
benchmark
bug reproduction
validation matrix
Flujo end-to-end que debe seguir pasando de forma continua

Una tarea puede ser ambiciosa, pero sin condiciones de verificacion se parece mas a un deseo que a un goal.

Barra lateral

La barra lateral coloca los artefactos de trabajo junto a la conversacion que los genero. El usuario no tiene que exportar archivos, cambiar de contexto y luego volver a describir el problema. El artefacto puede ser codigo, pero tambien puede ser un deck, PDF, pagina web, hoja de calculo u otro artifact generado durante el trabajo.

Es especialmente adecuada para cuatro tipos de trabajo:

Inspeccionar un artifact
Anotar lugares que necesitan cambios
Operar una interfaz web
Revisar cambios

Markdown, hojas de calculo, tablas de datos, documentos y presentaciones se pueden ver directamente en la barra lateral. El usuario puede inspeccionar, anotar y corregir sin convertir el proceso en otra ronda de traspaso.

Si se trata de un deck o PDF, puede permanecer junto al thread que lo produjo y aceptar review y arreglos en cualquier momento.

El navegador tambien es una superficie de trabajo similar. Codex puede abrir la pagina renderizada, inspeccionarla, responder a las anotaciones del usuario en la pagina y seguir corrigiendo el mismo objeto. Una pagina web es tanto resultado de salida como superficie de control.

Estas superficies encajan especialmente bien en la barra lateral:

Artifacts estaticos ligeros como index.html
Storybook
Remotion Studio
Presentaciones en navegador
Aplicaciones de analisis de datos

Un unico archivo index.html puede convertirse en un artifact interactivo de larga vida, sin necesidad de servidor. Thread automations tambien puede refrescar periodicamente un artifact estatico para que el usuario vea nuevos resultados al volver.

Memoria compartida

Los threads largos son utiles, pero el contexto importante no deberia existir solo dentro del historial de conversacion.

Shared memory significa guardar el contexto persistente fuera del thread, para que el trabajo futuro pueda continuar desde un lugar explicito y revisable.

Una practica estable es anclar los threads persistentes en un Obsidian vault. En la practica puede ser muy simple: un conjunto de archivos normales, faciles de revisar, editar, mover y conservar a largo plazo. Un equipo puede ponerlo en cloud storage, Git, Dropbox, Google Drive u otra capa de sincronizacion.

Un vault podria verse asi:

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

El AGENTS.md de nivel superior puede explicar como debe mantener Codex ese espacio de trabajo: que informacion debe escribirse, donde debe ir y cuando no conviene crear ruido.

Un AGENTS.md practico podria escribirse asi:

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

No se trata de copiar la estructura de un vault concreto. Lo mas importante es ensenar al agent donde debe vivir el contexto a largo plazo, que informacion vale la pena conservar y cuando no deberia tocar archivos una y otra vez.

El repositorio guarda codigo. El vault guarda contexto en movimiento: personas relacionadas, que ocurrio, donde esta el bloqueo, quien es responsable, cual es el siguiente paso y esos detalles que desaparecerian entre sesiones si no se escriben.

Codex tambien tiene memoria propia de primera parte, que se puede configurar en Settings > Personalization > Memories. Sirve para registrar preferencias, flujos repetitivos y puntos de friccion comunes, pero funciona mejor como complemento del written context explicito que como sustituto. Chronicle tambien avanza en la misma direccion: ayudar a Codex a construir memoria a partir del contexto reciente de la pantalla.

Expandirse mas alla del codigo

Codex sigue empezando desde el codigo. Pero ahora el mismo sistema tambien puede tocar mas trabajo alrededor del codigo: MCP servers, interfaces de navegador, control de escritorio, thread automations y artifacts revisables.

Esto cambia la forma de controlar Codex. Steering sirve para interrumpir trabajo en curso. Queuing sirve para poner en cola el siguiente paso. Thread automations mantiene activos los threads despues de que el usuario se va. Goals anade puntos finales claros y senales de verificacion a las tareas largas.

Cuando estas capacidades se conectan, Codex puede llevar un flujo de trabajo desde la instruccion hasta la ejecucion, y luego hasta el artifact review. Incluso si la tarea ya salio del repositorio de codigo, puede seguir completandose dentro del mismo sistema.

Enlace original: Getting the most out of Codex

Automatizacion on KnightLi Blog