Creo que muchas personas que quieren desarrollar un nuevo proyecto de software a menudo se atascan al principio del proceso, ya que comenzar con un repositorio vacío les parece muy desalentador. Así que pensé en repasar rápidamente mi flujo de trabajo más reciente, que reduce drásticamente el esfuerzo y el tiempo necesarios para empezar. Lo más importante, con diferencia, es tener una buena idea o algo que crear que realmente sea útil para mucha gente si funciona correctamente y cumple bien su función. No puedo ayudarte mucho con esto, pero el consejo habitual de buscar soluciones a tus propios problemas (que no sean específicos de un nicho) es una excelente manera de empezar. A mí se me ocurren ideas para proyectos constantemente. En cualquier caso, el siguiente paso es plasmar la idea por escrito de manera informal, como si se tratara de un correo electrónico rápido a un amigo cercano. No se trata de convertir esto en un plan formal, sino simplemente de la forma más rápida de transmitir la idea básica y su funcionamiento, y especificar cualquier parte de la pila tecnológica o las bibliotecas que sepas que quieres usar. Las capturas de pantalla adjuntas muestran un ejemplo de esto, basado en una idea que se me ocurrió hace un par de días. Tardé unos 10 o 15 minutos en redactarlo. No tiene por qué ser extenso y puede incluir referencias a otras fuentes para mayor concisión. Esta descripción inicial se convierte entonces en la solicitud para GPT-5 Pro. Suele tardar al menos 15 o 20 minutos en ejecutarse (curiosamente, más de lo que se tarda en escribir la solicitud). Podrías probar con otros modelos, pero el rendimiento será mucho peor. Luego, suelo tomar la misma sugerencia y dársela a Grok4 Heavy u Opus4.1, y les paso esas ideas a GPT-5 Pro, animándolos a que adopten cualquier buena idea que vean en las otras propuestas. Si hay algo realmente ingenioso en esos planes, GPT-5 Pro lo reconocerá y lo incorporará. Luego le pediré a Pro que cree un documento de plan detallado y granular en formato Markdown basado en su primera respuesta, y lo guardaré como un archivo en una carpeta de proyecto recién creada. Luego, suelo iterar sobre esto varias veces, iniciando una nueva conversación Pro en la aplicación web, proporcionando el archivo completo del plan en Markdown e indicándole que mejore el plan de diversas maneras para hacerlo más fiable, robusto, eficiente, intuitivo, fácil de usar y otros buenos adjetivos. Y animaré a Pro a que realice una investigación exhaustiva en la web sobre la documentación, blogs, tutoriales, etc. más recientes para encontrar mejores bibliotecas o formas de hacer las cosas. Luego, tomaré las revisiones propuestas, las pegaré en Codex y le pediré a Codex que integre las revisiones en el documento de plan Markdown existente. Tras dos o tres rondas de esto, las cosas se estabilizan y se obtiene un plan realmente bueno y bien desarrollado. Esta es la clave de todo, porque cuando las cosas aún están en la fase de planificación, es mucho más fácil ajustarlas y mejorarlas, ya que todavía no hay código. Más vale prevenir que curar. Aquí tenéis un enlace al documento del plan resultante de la solicitud inicial para esta idea: https://t.co/mXHOZH9b2p En este punto, comienzo a agregar un archivo AGENTS.md; parto de uno que ya tengo y le pido a Pro (en la misma sesión en la que se redactó el último documento del plan) que lo personalice para este nuevo proyecto y pila tecnológica, conservando todo lo genérico. Si hay algunas bibliotecas de importancia crítica, a veces también creo una guía de buenas prácticas especializada (por ejemplo, si estás creando un servidor MCP, generaré una guía de buenas prácticas especializada para la biblioteca fastmcp, donde también explico cómo estructurar el proyecto, etc.). En este punto, le pido a Codex que, en una sola sesión, comience a construir la estructura del proyecto, creando carpetas y archivos de marcador de posición en blanco, creando el archivo .gitignore, etc. Aquí es donde mi proceso se desvía drásticamente del enfoque típico. Primero utilizo el proyecto Beads de Steve Yegge y le indico a Codex que convierta el documento del plan en un conjunto de tareas y subtareas utilizando Beads. Luego uso tmux para crear varias sesiones de Codex, hasta 8 a la vez (creo que incluso más funcionarían bien)…
Luego inicio mi proyecto de correo electrónico para agentes de MCP y les indico que se registren por correo electrónico y se presenten a sus compañeros agentes, que lean el archivo AGENTS.md y el documento del plan en su totalidad (haciendo referencia a este archivo por su nombre) y que revisen las tareas de Beads en un mensaje inicial. Después de eso, es simplemente un proceso de repasar el mismo conjunto de mensajes predefinidos donde les digo que elijan una tarea y comiencen a trabajar en ella, los animo a que continúen con ella varias veces, luego a que revisen su trabajo, después a que revisen su correo de agente y respondan a cualquier mensaje que hayan recibido que necesite una respuesta, y a que comuniquen lo que están haciendo a sus compañeros agentes. Ayer grabé un vídeo de 23 minutos donde muestro cómo funciona esta parte en el proyecto de ejemplo que aparece en esta publicación, lo que aclara todo: https://t.co/KedUEzSRRG Tras grabar eso, descubrí cómo automatizar incluso esta última parte para poder encolar automáticamente un montón de mensajes para todos los agentes y mantenerlos ocupados durante horas usando tmux para difundir los comandos. Enlazaré a esa publicación más abajo. Ese es el proceso básico. Si lo sigues, puedes crear software sorprendentemente complejo y potente en un par de días, requiriendo quizás 1 o 2 horas de "tiempo humano" real, pero muchas, muchísimas horas de trabajo de agentes (como horas de trabajo humano). Y cada hora de trabajo autónomo del agente con gpt-5-codex, cuando no está constantemente esperando instrucciones humanas, equivale probablemente a 10 o 20 horas de trabajo humano. ¡Piensan y escriben rapidísimo!
Aquí tenéis el enlace a mi hilo sobre cómo cerrar el bucle de automatización con tmux:
Y aquí tenéis el enlace al proyecto MCP Agent Mail que hace posible todo esto: github.com/Dicklesworthst…