Forem: Oscar Santos

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

Oscar Santos — Tue, 13 Jan 2026 01:02:50 +0000

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?

Dejar de buscar para empezar a construir: Integrando el ecosistema de IA de GitHub en mi Toolbox

Oscar Santos — Wed, 31 Dec 2025 07:14:56 +0000

Hace no mucho tiempo, programar se sentía como un ejercicio de arqueología digital. Mi navegador solía tener 20 pestañas abiertas: múltiples búsquedas en Google con diferentes variaciones del mismo error, n hilos de Stack Overflow y documentación dispersa. Básicamente, pasábamos más tiempo buscando cómo hacer las cosas que haciéndolas. Y, no es que estuviera mal, simplemente construíamos software a otro ritmo.

Pero algo fundamental cambió. Dejé de ser un buscador de respuestas para convertirme en un arquitecto de soluciones, y las herramientas basadas en IA de GitHub fueron el catalizador de esa transición.

1. El "Antes": La fatiga del contexto

El ciclo (y seguro te suena familiar): escribes código -> encuentras un bloqueo -> Alt-Tab al navegador -> buscas -> filtras mentalmente qué solución aplica a tu problema -> adaptas el código -> Alt-Tab de vuelta al editor.

Desde finales de 2023, este ciclo cambió. Ya no estamos hablando de una evolución lineal año con año, sino de un incremento exponencial gracias a capacidades agénticas que se integran en el flujo de trabajo.

2. El "Toolbox": Eligiendo la herramienta correcta

La clave para ser productivo en 2025 fue entender que no existe una "IA mágica" que lo resuelva todo por arte de magia. Claro, hay mil herramientas ahí fuera, pero hoy quiero contarte cómo uso el ecosistema de GitHub específicamente, porque tiene piezas especializadas y el truco está en saber cuál invocar y por qué.

Así es como se ve mi toolbox hoy:

GitHub Copilot en el IDE: El Agente

El autocompletado de líneas a inicios de 2024 fue impresionante pero, la evolución hacia un "modo agente" (Copilot Edits) lo ha sido aún más.

Caso de uso: Refactorización rápida y cambios multi-archivo.
La diferencia: En lugar de ir archivo por archivo cambiando una interfaz manualmente, ahora le doy la instrucción en lenguaje natural. En ocasiones creo un archivo PLAN.md (que yo mismo escriba u otro agente escriba) y/o PRD.md (Product Requirements Document con los lineamientos de negocio para las features) y dejo que Copilot ejecute la edición basándose en ese plan/documento.
💡 Mi consejo: Aprovecha que IDEs como VS Code permiten añadir contexto explícito (archivos, salida de terminal, resultados de pruebas, etc.). Si no le das el contexto, no esperes milagros. Asegúrate de que "vea" lo que tú ves, porque no siempre el agente va buscar y recuperar el contenido del archivo que esperas.

GitHub Copilot Coding Agents

Esto va un paso más allá de la edición en tiempo real.

Caso de uso: Tareas complejas o asíncronas.
La diferencia: Aquí no me quedo mirando cómo escribe. Puedo enviar un trabajo a un agente remoto para que resuelva un issue o una solicitud más grande. Al tomarse su tiempo "pensando" (aprovechando el test-time compute) y utilizando tools, la calidad del resultado suele ser superior.
💡 Mi consejo: Sé muy específico. Divide y vencerás. Si tienes una tarea gigante, sepárala y asígnala a múltiples agentes; incluso puedes customizar cada uno para que se comporte de cierta forma.

GitHub Copilot CLI: El Traductor

La terminal es donde el "flow" se muere cuando olvidas un flag.

Caso de uso: Comandos de sistema y herramientas instaladas.
La diferencia: En lugar de googlear la sintaxis exacta de ffmpeg o los flags de mis herramientas que son difíciles de recordar, escribo mi intención. La herramienta actúa como puente, traduciendo mi consulta a un comando ejecutable.
💡 Mi consejo: Ojo con los atajos de teclado (key shortcuts). Manténlos limpios y separados, porque es muy incómodo que el Intellisense y Copilot se peleen por sugerirte cosas cuando solo quieres escribir un comando rápido. Y más importante, entiende el comándo sugerido, por tú seguridad y por comprender qué estás haciendo, tú sigues siendo el programador y responsable de lo que ocurra.

GitHub Copilot Spaces: El Contexto (La verdad única)

Nota: Mucha gente lo confunde con Codespaces, pero Spaces va de conocimiento.

Caso de uso: Dudas sobre reglas de negocio, prácticas del equipo o arquitectura interna.
La diferencia: Agrupar repositorios y documentación interna en un "Space" es oro puro para el equipo. Ahora, al preguntar, la respuesta no viene de un foro genérico de internet, sino de la "verdad" del proyecto y las guías de estilo.

GitHub Spark: El Prototipado

Caso de uso: Micro-apps y herramientas internas.
La diferencia: Todos tenemos ese backlog de herramientas internas que nunca hacemos "por falta de tiempo" (o pereza de configurar el server). Con Spark, paso de la idea a una URL funcional en segundos usando lenguaje natural. Se acabó la excusa de la infraestructura para prototipar.

3. El cambio de mentalidad: De "Coder" a "Reviewer"

Este nuevo toolbox trajo consigo un cambio de rol inevitable.

Antes, mi valor se medía en gran parte por mi capacidad de recordar sintaxis y escribir lógica desde cero. Hoy, paso menos tiempo escribiendo boilerplate y más tiempo leyendo y auditando.

Me he convertido en un "Reviewer" constante. La IA propone la implementación, pero yo soy el responsable final de la arquitectura, la seguridad y la corrección. No es que trabaje menos, es que mi esfuerzo mental se ha desplazado de la memorización al criterio.

4. Tabla de decisiones

Para resumir cómo he logrado integrar este ecosistema lo sintetizo en la siguiente tabla.

Herramienta	Cuándo la uso (Caso de Uso)	El cambio "Antes vs. Ahora"
Copilot IDE	Escribir código core, refactorizar y tests.	De escribir línea por línea a supervisar ediciones en múltiples archivos.
Copilot Coding Agents	Delegar tareas como si fuera otro integrante del equipo e implementación de features completas	De crear mis propias propuestas desde cero en varias ramas a delegar tareas a un/unos agente(s) que implementen diversas propuestas.
Copilot CLI	Operaciones de sistema, scripts.	De googlear flags olvidados a declarar intenciones.
Copilot Spaces	Consultas de arquitectura/negocio.	De buscar en wikis desactualizadas a chatear con el contexto del repo.
GitHub Spark	Prototipos, herramientas internas.	De "lo hago cuando tenga tiempo" a "desplegado hoy".

Conclusión: Qué espero del 2026

Al cerrar este año, me doy cuenta de que la programación, irónicamente, se ha vuelto más humana. Al delegar la arqueología digital y la sintaxis repetitiva a la IA, he recuperado tiempo para lo que realmente importa: resolver problemas complejos y crear valor.

Para el 2026, espero que la línea entre estas herramientas se difumine aún más, y que los agentes tengan mayor autonomía, permitiéndome operar a un nivel de abstracción todavía más alto.

Aunque puede parecer contradictorio, no recomiendo dejar de aprender sobre programación en 2026, ya que aunque los modelos generativos de hoy pueden superar a cualquier humano en estas tareas, aquellos humanos que tengan las habilidades de programación y lo complementen con las capacidades de los modelos generativos, pueden llegar a crear mejores artefactos que los generados exclusivamente por IA.

Calendario de Adviento

Esta publicación forma parte de una serie de contribuciones de la comunidades, te exhorto a revisar el resto de artículos, charlas, u otro tipo de contenido en este enlace.