3093. Creando proyectos con Codex

Marketing Online•2 de junio de 2026•15:59•

RSS Público

Compartir episodio:Descargar

Descripción del Episodio

Hoy os cuento el flujo de trabajo que sigo cuando creo proyectos con Codex, y buenas prácticas para mejores resultados y gastar menos tokens.

Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Estamos ya en pleno curso de Supabase, en el que aprenderemos a construir el backend completo de una aplicación moderna, desde la base de datos hasta la autenticación, el almacenamiento de archivos y el tiempo real, sin necesidad de crear un servidor propio. ¡A por él!

Ahora sí, vamos al lío. Hoy quiero contaros cómo estoy organizando todos mis proyectos desde que trabajo con Codex, porque sinceramente, estoy encantadísimo. He probado otras alternativas y sigo haciendo pruebas de vez en cuando, pero a día de hoy, para mí, Codex es claramente el ganador.

Todo parte de una estructura muy simple. Cada proyecto tiene su propia carpeta. En mi caso trabajo en un VPS, un servidor virtual privado, pero realmente esto da igual. Lo podéis hacer perfectamente en local, en vuestro Mac o PC, con GitHub para las copias de seguridad y listo. El funcionamiento es exactamente el mismo.

Dentro de esa carpeta tengo distintos chats, cada uno especializado en una funcionalidad concreta. Pero antes de llegar a eso, siempre empiezo igual. Creo un chat general y le explico al agente qué es el proyecto, qué objetivo tiene y qué queremos construir. A partir de ahí le pido que cree un archivo llamado agents.md, que vendría a ser el manual de instrucciones del proyecto.

Ese archivo es clave porque no es algo estático que se crea una vez y ya está. Se va actualizando constantemente a medida que avanzamos. Todo lo importante queda documentado ahí. Cómo funciona el proyecto, qué decisiones hemos tomado, qué mejoras hemos hecho, qué excepciones existen… absolutamente todo.

Así pues, en lugar de tener una única conversación gigantesca donde se mezcla todo, creo un chat separado para cada funcionalidad. Por ejemplo, en un proyecto puedo tener un chat para facturación, otro para generación de imágenes, otro para prompts, otro para la web, otro para la app… Cada uno especializado en lo suyo.

La razón principal es el contexto. Los chats tienen una memoria limitada. Puede ser enorme, sí, pero sigue teniendo límites. Cuando una conversación se hace demasiado larga, acaba compactándose y se pierde información por el camino. Entonces empiezan los problemas. Le pides algo que hizo hace diez días y ya no recuerda cómo lo resolvió.

En cambio, si cada chat está especializado en una sola tarea, el contexto permanece limpio y enfocado. El chat de facturación solo sabe de facturación. El de la app solo sabe de la app. Y eso hace que todo vaya mucho más rápido y sea mucho más eficiente.

De hecho, lo comparo con la especialización médica. No es lo mismo un médico que hace un poco de todo que alguien que lleva años haciendo exactamente la misma operación una y otra vez. Ese especialista detecta patrones, optimiza procesos y mejora continuamente. Pues con los agentes pasa algo muy parecido.

Además, esta organización también reduce mucho el consumo de tokens. Porque si el agente ya tiene fresco el contexto de una funcionalidad concreta, no necesita ponerse a buscar otra vez cómo iba todo, ni releer documentación, ni reconstruir información perdida. Simplemente sigue trabajando donde lo dejó.

Todo lo relevante debe acabar documentado en agents.md. Porque ese archivo es el nexo común entre todos los chats. Si un día borráis una conversación, cambiáis de equipo o el contexto se compacta y desaparece información, podéis crear un chat nuevo, pedirle que lea el agents.md y seguir trabajando sin perder el conocimiento acumulado.

Esto se puede hacer manualmente, diciéndole directamente al agente que documente un cambio importante, o automáticamente mediante hooks. Básicamente, le indicáis que cada vez que se descubra algo nuevo o se modifique una lógica relevante, revise si eso ya está documentado. Si no lo está, lo añade automáticamente al agents.md.

También hay otra función muy útil, los side chats. Son pequeños chats laterales que podéis abrir para hacer preguntas puntuales sin contaminar el contexto principal del proyecto. Por ejemplo, si estáis trabajando en facturación y necesitáis consultar algo fiscal muy concreto, podéis abrir un side chat, resolver la duda y cerrarlo después. Así no ensuciáis el contexto importante del proyecto principal.

Y desde que trabajo así, sinceramente, ya no hay vuelta atrás. Todo está mucho más ordenado, los agentes responden mejor, gastan menos tokens y cada funcionalidad evoluciona de forma mucho más coherente.

Además, esta filosofía no es exclusiva de Codex. En Claude también se puede hacer algo parecido usando un archivo claude.md en lugar de agents.md. La idea es exactamente la misma. Tener una memoria compartida del proyecto y agentes especializados en tareas concretas.

Así que si estáis trabajando con agentes de IA para crear proyectos, automatizaciones o SaaS, os animo muchísimo a probar esta forma de organizaros. Porque cuando empiezas a dividir responsabilidades, documentar correctamente y tratar cada conversación como un especialista independiente, cambia completamente la experiencia de trabajo. :)

Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería.

Nos escuchamos mañana con más marketing online. Como siempre, a las 07:07. Hasta entonces… ¡Muy buenos lunes, y mejor semana!

Episodios Recientes

3121. Preguntas y Terminal12 de julio de 2026