Acho que muitas pessoas que desejam desenvolver um novo projeto de software frequentemente se deparam com dificuldades logo no início do processo, já que começar com um repositório vazio parece muito intimidante. Então pensei em apresentar rapidamente meu fluxo de trabalho mais recente, que reduz drasticamente o esforço e o tempo necessários para começar. A parte mais importante, sem dúvida, é ter uma boa ideia ou algo para criar que seja realmente útil para muitas pessoas, se funcionar corretamente e cumprir bem o seu propósito. Não posso te ajudar muito com essa parte, mas o conselho comum de resolver seus próprios problemas e dificuldades (não específicas de um nicho) é uma ótima maneira de começar. Eu me pego pensando em ideias de projetos o tempo todo. De qualquer forma, o próximo passo é escrever a ideia informalmente, como você faria em um e-mail rápido para um amigo próximo. Você não tenta criar um plano formal, apenas a maneira mais rápida de transmitir a ideia básica e o que ela faz, especificando quaisquer partes da pilha de tecnologia ou bibliotecas que você sabe que deseja usar. As capturas de tela anexadas mostram um exemplo disso para uma ideia que tive aleatoriamente há alguns dias. Levei talvez 10 ou 15 minutos para escrever. Não precisa ser longo e pode citar outras fontes para manter a concisão. Essa descrição inicial se torna o prompt para o GPT-5 Pro. Normalmente, leva pelo menos 15 ou 20 minutos para executar (curiosamente, mais tempo do que leva para escrever o prompt). Você pode tentar outros modelos, mas o desempenho será muito pior. Então, frequentemente pego o mesmo prompt e o passo para o Grok4 Heavy ou o Opus4.1, e repasso essas ideias para o GPT-5 Pro, incentivando-o a incorporar quaisquer boas ideias que encontrar nas outras propostas. Se houver algo realmente inteligente nesses planos, o GPT-5 Pro o reconhecerá e o incorporará. Em seguida, pedirei ao Pro para criar um documento de plano detalhado e específico em Markdown com base na sua primeira resposta e salvarei esse documento como um arquivo em uma pasta de projeto recém-criada. Então, costumo repetir esse processo algumas vezes, iniciando uma nova conversa Pro no aplicativo web e fornecendo todo o arquivo de plano Markdown, instruindo-o a aprimorar o plano de várias maneiras para torná-lo mais confiável, robusto, eficiente, intuitivo, fácil de usar e outros adjetivos positivos. E eu encorajarei o Pro a fazer uma pesquisa exaustiva na web sobre a documentação mais recente, blogs, tutoriais, etc., para encontrar bibliotecas melhores ou maneiras melhores de fazer as coisas. Em seguida, pegarei as revisões propostas, colarei no Codex e pedirei ao Codex que integre as revisões ao documento de planejamento em Markdown existente. Após 2 ou 3 rodadas disso, as coisas se estabilizam e você obtém um plano realmente bom e bem elaborado. Essa é a chave de tudo, porque quando as coisas ainda estão na fase de planejamento, é muito mais fácil ajustá-las e aprimorá-las, já que você ainda não tem nenhum código. Meça duas vezes, corte uma, etc. Aqui está o link para o documento do plano resultante da solicitação inicial para esta ideia: https://t.co/mXHOZH9b2p Nesse ponto, começo a adicionar um arquivo AGENTS.md; começo com um já existente e peço ao Pro (na mesma sessão em que o documento de planejamento mais recente foi escrito) para personalizá-lo para este novo projeto e conjunto de tecnologias, preservando tudo o que for genérico. Se houver bibliotecas de importância crítica, às vezes também crio um guia de boas práticas específico (por exemplo, se você estiver criando um servidor MCP, eu gero um guia de boas práticas específico para a biblioteca fastmcp, mas onde também explico como estruturar o projeto, etc.). Nesse ponto, peço ao Codex, em uma única sessão, que comece a construir a estrutura do projeto, criando pastas e arquivos de espaço reservado em branco, criando o arquivo .gitignore, etc. É aqui que meu processo diverge drasticamente da abordagem típica. Primeiro, utilizo o projeto Beads de Steve Yegge e instruo o Codex a transformar o documento de planejamento em uma série de tarefas e subtarefas usando Beads. Em seguida, uso o tmux para criar várias sessões do Codex, até 8 simultaneamente (acho que mais do que isso também funcionaria bem)...
Em seguida, inicio meu projeto de e-mail para agentes do MCP e peço a eles que se registrem no Mail e se apresentem aos seus colegas agentes, que leiam o arquivo AGENTS.md e o documento do plano na íntegra (referenciando este arquivo pelo nome) e que revisem as tarefas do Beads em uma mensagem inicial. Depois disso, é apenas um processo de repetição do mesmo conjunto de mensagens padronizadas, onde eu digo para eles escolherem uma tarefa com miçangas e começarem a trabalhar nela, os incentivo a continuar algumas vezes, depois a revisar o trabalho, a verificar o e-mail da agência e responder a quaisquer mensagens recebidas que precisem de resposta, e a comunicar o que estão fazendo aos seus colegas agentes. Gravei ontem um vídeo de 23 minutos mostrando como essa parte funciona no projeto de exemplo apresentado nesta publicação, o que esclarece tudo: https://t.co/KedUEzSRRG Depois de gravar isso, descobri como automatizar até mesmo essa última parte, de forma que eu possa enfileirar automaticamente várias mensagens para todos os agentes, mantendo-os ocupados por horas, usando o tmux para transmitir os comandos. Vou colocar o link para essa publicação abaixo. Esse é o processo básico. Se você o seguir, poderá criar softwares surpreendentemente complexos e poderosos em poucos dias, com talvez 1 ou 2 horas de "tempo humano" efetivo, mas muitas, muitas horas de trabalho de agentes (como horas-homem). E cada hora de trabalho autônomo do agente com o GPT-5 Codex, quando ele não está constantemente esperando por instruções humanas, equivale provavelmente a 10 ou 20 horas de trabalho humano. Eles pensam e digitam muito rápido!
Aqui está o link para o meu tópico sobre como fechar o ciclo de automação com o tmux:
E aqui está o link para o projeto MCP Agent Mail que torna tudo isso possível: github.com/Dicklesworthst…