DEV Community

Oscar Santos
Oscar Santos

Posted on

Dejar de buscar para empezar a construir (Parte 2): Una perspectiva alternativa con el ecosistema CODEX

En el post anterior, hablé sobre cómo el ecosistema de GitHub (Copilot, Spark, etc.) fue el catalizador que me ayudó a dejar de ser un buscador de respuestas para convertirme en un arquitecto de soluciones. Esa transición de mentalidad es lo fundamental.

Sin embargo, en tecnología, casarse con una sola herramienta limita nuestra perspectiva. Últimamente he estado explorando una alternativa que plantea la colaboración con la IA desde un ángulo ligeramente diferente: el ecosistema CODEX.

No se trata de decir qué herramienta es "mejor", sino de entender qué filosofía de trabajo se adapta mejor a tu flujo de trabajo. Mientras que mi flujo anterior se basaba en la predicción (autocompletado inteligente), mi experiencia con CODEX se ha sentido más centrada en la instrucción, contexto profundo, y persistencia.

Aquí te comparto mis hallazgos al probar esta alternativa.


1. El Cerebro: AGENTS.md + MCP (El Énfasis en la Integración)

Es importante aclarar que conceptos como archivos de contexto o integración de herramientas no son exclusivos de una sola plataforma; el stack de GitHub también permite configurar instrucciones personalizadas. Sin embargo, lo que he notado con CODEX es el énfasis y la facilidad de integración que le dan a estos conceptos. No se sienten como una configuración oculta, sino como el núcleo del flujo de trabajo.

  • La experiencia con AGENTS.md

Codex pone la jerarquía de contexto en primer plano. Definir "quién es el programador" mediante archivos Markdown (~/.codex/agents.md global, por proyecto o por carpeta) se siente como una parte nativa del proceso de onboarding del agente, facilitando que la IA respete mis preferencias (como el uso de ciertas librerías de test) sin tener que repetirlas.

  • MCP (Model Context Protocol) "Out-of-the-box"

La integración con MCP es muy fluida. En lugar de configuraciones complejas, la herramienta invita a conectar datos externos casi de inmediato. La naturalidad con la que el agente sale del código para buscar un dato real (sin alucinar mocks) y volver al editor es lo que destaca aquí. Por ejemplo "busca el último ticket o item del backlog".


2. El Editor: Controlando la "Intensidad" del Razonamiento

En VS Code, ambas herramientas son excelentes, pero encontré un detalle con Codex que me resultó muy útil: el control manual del "Reasoning Effort" (Esfuerzo de Razonamiento).

En lugar de una "caja negra", tener un selector explícito me permitió optimizar mi flujo:

  • Low Reasoning: Perfecto para tareas mecánicas y rápidas (documentación, scripts sencillos, archivos de configuración).
  • High Reasoning: Lo activo manualmente cuando enfrento refactorizaciones complejas o necesito entender un repositorio heredado (Legacy) desde cero.

Es un pequeño detalle de control que empodera al usuario avanzado que sabe exactamente qué nivel de "inteligencia" requiere la tarea.


3. La Terminal: Asistencia Efímera vs. Entorno Persistente

Aquí es donde encontré la diferencia filosófica más marcada.

GitHub Copilot CLI es fantástico para la inmediatez: "No recuerdo cómo hacer un ffmpeg, dame el comando". Es rápido, resuelve el bloqueo y te deja seguir. Es un asistente traductor.

Codex CLI, por otro lado, se sintió más como un compañero de trabajo persistente.

  • Persistencia Real: Lo que más me gustó fue la capacidad de retomar sesiones (codex resume). Podía estar depurando un error complejo, cerrar la terminal, y al volver, el agente recordaba el historial y el estado del error anterior. No empezaba de cero.
  • Automatización Estructurada: La posibilidad de definir mis propios comandos complejos (como /sql_query_generator) mediante archivos Markdown en ~/.codex/prompts/ me permitió crear flujos de trabajo repetibles, algo que va más allá de un simple alias de shell.

Si vives en la terminal, esta persistencia marca una gran diferencia.


4. Trabajo Pesado: Delegación y Revisión

Finalmente, el comando /review de Codex ofreció una experiencia de "Code Review" muy interesante. Más allá de un linter (que busca errores de sintaxis), la herramienta fue capaz de señalar inconsistencias en la lógica de negocio.

En mis pruebas, introduje bugs lógicos sutiles (código sintácticamente correcto pero funcionalmente erróneo) y la herramienta fue capaz de detectar la inconsistencia en la lógica de negocio, ofreciendo una auditoría que va más allá del linter tradicional.

Es una capacidad que complementa perfectamente la revisión humana, actuando como un primer filtro de calidad semántica.


Tabla de Enfoques: ¿Cuál es para ti?

Para visualizarlo mejor, he comparado cómo se sienten estos dos enfoques en mi día a día:

Área Enfoque Ecosistema GitHub (post anterior) Enfoque Alternativo (CODEX)
Contexto Configurable via instrucciones. AGENTS.md + MCP (Integración nativa y prioritaria de datos externos).
Filosofía IDE Copilot in VSCode (Con selección de modelos e integración de contexto). CODEX in VSCode (Con selección de modelos, así como su Reasoning Effort y contexto).
Terminal Traductor de comandos: "Dime cómo hacerlo". Espacio de trabajo: Entorno persistente y comandos customizables.

Conclusión

Explorar el ecosistema CODEX no ha hecho que "abandone" mis herramientas anteriores, pero sí me ha dado una nueva perspectiva sobre lo que es posible.

Si buscas velocidad y asistencia inmediata, el flujo tradicional es imbatible. Pero si buscas persistencia, control granular sobre el razonamiento y una estructura más estricta para tus agentes, vale la pena explorar estas alternativas.

Al final del día, lo importante no es la marca de la herramienta, sino que ésta te permita crear soluciones de mejor valor para el usuario.

¿Y tú? ¿Estás de acuerdo con la utilización de la IA como apoyo en el desarrollo de software?

Top comments (0)