OpenAI Build Week en Monterrey: así se vivió el primer meetup de Codex en casa
Crónica del primer meetup de Codex en Monterrey, parte de la Global Build Week de OpenAI: speakers, demos locales, MCPs y el workflow que dejó el evento.

Miguel Fernandez
Autor

OpenAI Build Week en Monterrey: así se vivió el primer meetup de Codex en casa
El 14 de julio de 2026, en las oficinas de Apex Systems en Monterrey, se celebró el primer meetup de la comunidad de Codex en la ciudad, organizado por Aileen Villanueva dentro de la Global Build Week (13 al 21 de julio), la semana que OpenAI montó para empujar a developers de todo el mundo a construir con su agente de programación. La entrada fue gratuita y el cupo se llenó.
Ir a un evento en tu propia ciudad siempre cambia la perspectiva. No fue un DevDay, ni una keynote. Fue gente de Monterrey, con proyectos de acá, aprendiendo en persona. Esa es la parte que vale mucho la pena contar.
Quiénes hablaron y qué mostraron
La agenda fue compacta, sin relleno. Tres speakers principales, dos demos locales y espacio para networking real al final. Esto fue lo que se presentó.
Juan Ortiz del Toro - Del prompt a producción: mi workflow con Codex
Juan es conocido en la comunidad local por su trabajo con agentes y por compartir su proceso en Instagram como @juanortiz.dev. Su charla fue la más cercana al día a día: cómo llevar una idea en prompt a algo que corre en producción sin perder el control del código. Habló de la diferencia entre prototipar rápido y mantener disciplina de testing, y por qué Codex vale más cuando ya tienes una base de tests sólida que cuando estás improvisando sobre la marcha.
Lo más útil de su presentación: la parte donde mostró tickets reales de Jira, los corrió por Codex con el plugin de Atlassian, y dejó que el modelo propusiera el primer pull request. Esa demo condensó el workflow que yo también estuve probando durante la semana.
Ricardo Herrera - Codex + MCP: Convirtiendo un LLM en un compañero de desarrollo
La segunda charla bajó a tierra el Model Context Protocol. Ricardo mostró cómo un LLM, sin skills específicas, se queda corto: responde, sí, pero no actúa. Los MCPs cambian eso. Permiten que Codex lea tickets, consulte Figma, hable con Stripe, levante un deploy en Vercel, todo desde una sola conversación.
El punto fuerte de su enfoque fue separar tres ideas que muchos mezclan:
- Tokens son el recurso limitado. Cada llamada a un MCP cuesta. Hay que diseñarlos para ahorrar.
- Contexto es lo que el modelo tiene en memoria. Si lo alimentas mal, responde mal, por más inteligente que sea.
- Acción es lo que el modelo puede ejecutar. Sin MCPs, no hay acción real. Con MCPs, Codex pasa de "responde preguntas" a "ejecuta cambios".
Su demostración incluyó configurar un MCP desde cero, conectarlo a un repo local, y dejar que Codex debuggeara un error de configuración leyendo los logs por su cuenta. Eso es exactamente lo que la Build Week quería celebrar.
Demos locales: Opalit-ai y Superworker.ai
Después de las dos charlas hubo un bloque de demos de builders locales.
- Alejandro Ramírez mostró Opalit-ai, un proyecto en desarrollo que usa Codex como motor principal para automatizar el flujo de ventas de un empleado por medio de WhatsApp.
- Juan Carlos Garza, de founders.inc, presentó Superworker.ai, una herramienta que lee el contexto completo de negocios de Shopify y analíticas de marketing, para responder la pregunta más común en emprendimientos: qué está moviendo las ventas y qué acciones tomar.
Ambos casos sirven como referencia: no necesitas un modelo nuevo, necesitas un workflow disciplinado.
ChatGPT Work vs Codex: la confusión que sigue apareciendo
Algo que se repitió en preguntas del público fue la diferencia entre ChatGPT Work y Codex. Vale la pena dejarlo por escrito porque sigue generando ruido:
- ChatGPT Work está pensado para investigar, analizar y completar tareas del día a día. Es donde piensas, redactas y sintetizas.
- Codex está pensado para construir, debuggear y mantener software. Es donde vive el código.
La confusión sigue siendo el error más común de la semana. Tratas a Codex como un chat y terminas perdiendo tiempo y tokens. Cada producto tiene su herramienta.
Tres modos de trabajo dentro del stack
Uno de los hilos que más se repitió entre charlas fue que no existe un solo flujo con Codex, sino varios modos según la etapa en la que estés:
- ChatGPT Pro para planificar features de varios pasos: explorar el codebase, revisar archivos del proyecto, y hasta contexto de mercado y precios antes de tocar código.
- Deep Research cuando el plan necesita más investigación de fondo antes de definirse, con ejemplos mostrados sobre un repo real.
- Codex Goal, el modo enfocado en fijar el objetivo del agente sobre un repo específico y dejarlo ejecutar con ese norte claro.
La idea central: elegir el modo correcto según si estás explorando, investigando o ya ejecutando, en lugar de forzar todo por el mismo chat.
Lo que cambió después del meetup
Antes del meetup tenía una idea del workflow con Codex. Después del meetup tengo una versión más aterrizada:
- Tickets via MCP de Atlassian. El plugin de Rovo lee el ticket, extrae contexto y lo guarda en la memoria del chat. Ahorras tokens, evitas explicar dos veces lo mismo.
- Diseño via MCP de Figma. Pasas del diseño al componente sin re-interpretar el archivo.
- Deploy via Vercel. Su sección de skills te permite cargar guías reutilizables. Puedes meterle "10 años de buenas prácticas en React" como skill y reutilizarla en cualquier agente.
- Monitoreo via Langfuse y Sentry. Si vas a mandar agentes a producción, necesitas tracing y observabilidad desde el día uno.
Esa cadena la confirmé viendo lo que presentaron los speakers. Es la práctica y técnicas que están siendo ejecutadas en proyectos de la ciudad.
El balance honesto
Codex no es magia. Si lo alimentas con mal contexto, devuelve mal código. Si te saltas el plan, refactorizas lo que ya construiste. Y los MCPs siguen siendo territorio nuevo donde la documentación llega tarde.
Pero el workflow completo, tickets via Rovo, diseño via Figma, deploy via Vercel, tracing via Langfuse, todo orquestado por Codex y conectado vía MCPs, funciona. La diferencia entre el developer que improvisa y el que estructura su stack con MCPs se nota en el tiempo que le lleva cerrar un ticket, no en cuántos tickets logra abrir.
Quedarme en Monterrey, con gente que también está empujando proyectos con Codex, fue la mejor parte de la Build Week. La próxima vez que OpenAI organice algo así, espero que vuelva a haber un meetup local. Si quieres sumarte, vale la pena seguir el registro oficial del evento en Luma y estar atento a futuros avisos en la comunidad de Codex.
¿Tu equipo está evaluando meter Codex y MCPs a su flujo de desarrollo pero no saben por dónde empezar? En fencode ayudamos a empresas a diseñar workflows de desarrollo a la medida, con o sin agentes de por medio. Agenda una consultoría sin costo.
Tags:
Preguntas Frecuentes del Artículo
Resolvemos las dudas específicas sobre este tema.



