Hace meses que casi no abro Visual Studio Code como lo abría antes.
Y no, no es que haya dejado de programar. De hecho, diría que programo más que nunca. Lo que ha cambiado es la forma en la que trabajo.
Te dejo primero el video por si prefieres verlo ahí. En él enseño el cambio completo de flujo, con el antes y el después.
Si prefieres leerlo, te lo resumo aquí.
Antes: programar era cargar contexto una y otra vez
Durante años, resolver una tarea o un bug empezaba mucho antes de escribir código.
Primero tenía que abrir Jira, leer bien el ticket, entender qué había pasado y cuál era el caso concreto. Luego iba al proyecto, buscaba los ficheros relacionados, revisaba funciones, seguía el rastro del código y empezaba a montar una hipótesis.
Si era un bug real de producción, tocaba ir a los logs: AWS, Vercel, Sentry o donde estuviera la información. Después había que cruzar esos logs con usuarios, fechas, horas y datos de base de datos.
Solo entonces podía empezar a probar una solución.
Ese flujo funcionaba, pero tenía un coste enorme: recopilar contexto. Mucho del trabajo no era programar, sino encontrar la información correcta entre herramientas distintas.
Antes: muchas herramientas, mucho contexto manual y demasiados cambios de foco.
Ahora: mi trabajo se parece más a dirigir que a buscar
Con Codex, mi flujo ha cambiado bastante.
Lo tengo conectado a las fuentes que uso en mi día a día: Jira, Slack, correo, GitHub, base de datos, logs y repositorios. Cuando aparece una tarea, puedo pedirle que investigue el ticket, revise la conversación, mire el código relacionado, busque trazas en logs y me proponga una causa raíz con un plan de solución.
Mi papel no desaparece. Cambia.
Ahora dedico menos energía a buscar contexto desde cero y más a decidir si el análisis tiene sentido, si la solución encaja con el producto y si la implementación realmente resuelve el problema del usuario.
Codex puede investigar, proponer, implementar, validar, desplegar, cerrar un ticket e incluso avisar por Slack cuando producción ya está actualizada. Pero sigo siendo yo quien dirige el trabajo, revisa las decisiones y entiende cómo debe comportarse la aplicación para los clientes.
Ahora: Codex reúne contexto, propone planes y ejecuta; yo reviso, decido y valido.
La parte importante
No veo Codex como un sustituto del desarrollador. Al menos no como yo lo estoy usando.
Lo veo como una forma de multiplicar la capacidad de trabajo. Quita una parte muy pesada del día a día: recopilar información, mantener contexto, hacer tareas repetitivas y coordinar los siguientes pasos.
Eso me permite trabajar con más foco, atender bugs pequeños sin romper el flujo principal y llegar antes a la parte que realmente importa: entender el problema, tomar buenas decisiones y entregar una solución fiable.
Para mí, este ha sido uno de los cambios profesionales más grandes de los últimos años.
Por eso voy a empezar a compartir más sobre cómo uso Codex en proyectos reales: cómo lo configuro, cómo lo conecto a mis herramientas, cómo le pido investigaciones útiles y cómo reviso lo que hace antes de llevarlo a producción.
Si quieres aprender a usar Codex como una herramienta real de trabajo, no solo como un chat para generar código, estate atento a Cuarzo.dev porque vienen más ejemplos prácticos.
