Meu workflow de desenvolvimento: discovery, agentes de IA, VPS e feedback

Um relato de como organizei um processo que vai da primeira pergunta de produto ao feedback de quem usa o software — e por que ele me permite manter várias frentes abertas ao mesmo tempo.

Durante muito tempo, meu jeito de desenvolver era relativamente simples: surgia uma ideia, eu abria um agente, passava o contexto e começava a implementar.

Essa abordagem é ótima para protótipos pequenos. O problema aparece quando existem vários projetos andando ao mesmo tempo, decisões tomadas semanas atrás, bugs que parecem ser de código mas começam em um requisito, releases para preparar e pessoas usando o que você construiu.

Hoje tenho algo próximo de oito projetos em paralelo, incluindo ferramentas open source, aplicativos desktop e jogos. O que tornou isso viável não foi descobrir um prompt milagroso ou escolher um único modelo de IA. Foi montar um processo que preserva contexto, distribui execução e exige validação antes de considerar algo concluído.

Este é o workflow que uso nos meus projetos pessoais. Não é um modelo universal nem um manual corporativo. É um sistema que evoluiu com erros reais e que continuo ajustando conforme aparecem novas ferramentas e problemas.

Antes de entrar em cada etapa, este é o mapa completo. Clique em uma etapa para ver o que entra, o que sai e para onde ela leva; o feedback da última volta para discovery e backlog.

01A primeira entrega é entender o problema

Não começo um projeto abrindo o editor. Começo com discovery.

Uso principalmente o ChatGPT para formular o problema, comparar abordagens, estudar restrições, levantar hipóteses e desenhar possíveis caminhos. Quando preciso trabalhar com materiais de referência adicionais, também recorro ao NotebookLM.

O objetivo não é pedir a uma IA que me diga “qual aplicativo construir”. É chegar a um entendimento minimamente sólido sobre por que o projeto deveria existir, para quem, que valor entregaria e quais partes ainda não compreendo.

Nesta etapa gosto de transformar ideias vagas em perguntas concretas. Qual é o problema principal? O que seria uma primeira versão útil? Quais são as dependências? O que acontece no fluxo feliz — e o que acontece quando ele falha? Existe algo que pode ser eliminado em vez de implementado?

A discovery não precisa ficar gigante. Precisa ser suficientemente boa para orientar as primeiras decisões.

02Eu não valido a discovery sozinho

Depois da primeira análise, envio o material para outro agente, com uma função de QA da própria discovery.

Ele não entra para concordar com o documento. Entra para questioná-lo. Quero que procure hipóteses frágeis, cenários esquecidos, inconsistências, riscos técnicos e perguntas que ainda não foram feitas.

Esse segundo olhar costuma ser valioso justamente porque a primeira versão de uma ideia tende a carregar nossos próprios pressupostos. É fácil confundir algo que foi bem explicado com algo que foi efetivamente validado.

O retorno gera mais uma rodada de perguntas. Eu revisito a proposta, volto às referências quando necessário e só então avanço para a estruturação da execução.

Discovery, para mim, não é um documento escrito uma vez. É uma hipótese que precisa sobreviver a perguntas difíceis.

03Transformo entendimento em material executável

Com o problema mais claro, organizo o projeto. Dependendo da complexidade, isso envolve PRD, escopo, backlog, dependências, roadmap e critérios de aceite.

Aqui aprendi uma distinção importante: um backlog não é uma coleção de desejos. Cada item precisa existir dentro de uma intenção maior, e a ordem importa. Uma tarefa tecnicamente fácil pode ser uma péssima prioridade se a base de que ela depende ainda não está pronta.

Os critérios de aceite, por sua vez, reduzem espaço para improviso. “Implementar navegação por controle” é uma intenção; dizer como o foco se comporta, como volta, o que acontece quando não existe elemento selecionável e como testar o resultado começa a ser uma especificação verificável.

O roadmap permanece ajustável. Eu quero uma direção clara, mas não quero que o planejamento me impeça de reagir a descobertas novas. Esse equilíbrio entre documentação e adaptação tornou mais simples trabalhar com vários projetos sem reinventar o processo a cada troca de contexto.

04O computador que estou usando não é o centro do desenvolvimento

Depois do planejamento, a execução vai para o T3 Code rodando a partir da minha VPS.

Tenho um desktop Windows e um MacBook. Ambos servem como pontos de acesso ao mesmo ambiente de desenvolvimento remoto. A infraestrutura fica online continuamente, sem depender de eu manter uma das máquinas pessoais ligada.

Isso mudou minha rotina por três motivos. Primeiro, posso retomar o trabalho de praticamente qualquer computador. Segundo, o estado do ambiente permanece concentrado em um lugar. Terceiro, consigo deixar tarefas extensas rodando por 15 ou 20 horas, quando elas não exigem uma decisão minha a cada passo.

A VPS também me dá um ponto estável para execução de agentes, repositórios e testes automatizados. Não significa que todo teste possível rode nela — alguns aplicativos precisam de plataformas ou dispositivos específicos —, mas ela sustenta boa parte do fluxo sem prender minha rotina a uma máquina local.

05LippStack: a camada de práticas compartilhadas

Um elemento central dessa organização é o LippStack, meu repositório público de skills e mods para agentes de desenvolvimento.

Ele não existe apenas para guardar prompts reutilizáveis. A proposta é colocar boas práticas à disposição dos agentes no momento em que a tarefa pede cada prática, sem precisar despejar todas as instruções em todo contexto.

O repositório reúne, entre outros componentes:

• Skills de produto: discovery, problem statement, PRD, priorização, roadmap, stories e planejamento.
• Skills de engenharia: investigação de causa raiz, QA exploratório, regressão e preparação de entrega.
• Skills de design: análise visual, animação, prototipagem e testes de interfaces com dados extremos.
• Mods de desenvolvimento: indicadores de progresso, contexto, notificações e guardrails para ações destrutivas.

Também gosto de duas regras explícitas nessa base: investigar a causa raiz antes de corrigir sintomas e criar teste de regressão para bugs encontrados no QA. O LippStack ajuda a tornar essas práticas repetíveis em vez de dependerem da minha memória.

Não é uma camada mágica que elimina decisões. É uma maneira de padronizar a forma de perguntar, implementar, revisar e entregar.

06As plataformas que sustentam o dia a dia

Antes de falar dos agentes, vale mostrar o resto da caixa de ferramentas. Os agentes fazem a maior parte da execução, mas o workflow depende de um conjunto de plataformas que cobre o que acontece antes e depois do código: reuniões, voz, pesquisa, planejamento, memória, deploy e tarefas recorrentes.

Na entrada, uso o Granola para transcrever e resumir as reuniões que faço, e o Superwhisper com modelo local para conseguir fazer as coisas falando.

Na discovery, o NotebookLM fica com as pesquisas mais profundas, e o ChatGPT com a conversação: resolver problemas de QA, ou simplesmente conversar e ter mais ideias. O que vira decisão vai para o Notion, onde salvo notas, critérios de aceite e backlog.

Depois do código, o Dokploy Self Hosted gerencia os deploys nas minhas cinco VPS de maneira mais organizada. O AI Memory e o Obsidian guardam o contexto, e o Hermes Agent e o OpenMausBot cuida das tarefas recorrentes que preciso organizar e programar.

A divisão entre AI Memory e Obsidian tem uma lógica própria, que explico na seção 09.

07Meu orquestrador não precisa escrever tudo

Com o contexto preparado, entra a parte mais característica do processo: a orquestração.

Uso o Opus 5.5 como orquestrador principal. Seu trabalho é entender a demanda, quebrá-la em partes, decidir o que pode ser delegado, receber os resultados e fazer a primeira aprovação.

A decisão central aqui é não exigir que um único agente seja, ao mesmo tempo, pesquisador, arquiteto, executor, crítico e QA. Isso tende a concentrar erros e tornar uma sessão longa demais. Prefiro separar responsabilidades.

A escolha do subagente considera a natureza da tarefa, o custo de mantê-la rodando e o nível de profundidade necessário.

Para implementação em geral, costumo usar o Opus 5.5 como executor de tarefas delegadas.

Quando enfrento uma implementação especialmente complexa, recorro ao Fable 5.1.

Para tarefas rápidas e objetivas, prefiro o Gemini 3.8 Flash.

Quando tenho uma tarefa longa ou recorrente, com muitas requisições, uma alternativa frequente é o DeepSeek 4.1 Flash.

Para geração de imagens e assets visuais, prefiro o Codex.

Também utilizo GPT 6.1 Sol, GPT 6 Astra e Sonnet 5.5 em demandas de análise, desenvolvimento e apoio, conforme o contexto.

Esses são os nomes que uso para descrever o meu conjunto atual de agentes. Não se trata de um ranking universal de modelos: a melhor rota pode mudar com a tarefa e com o resultado observado.

08O fluxo só fecha depois da revisão independente

Quando um subagente conclui uma tarefa, o resultado retorna ao Opus 5.5. Ele verifica a entrega, confronta o resultado com o objetivo e faz uma primeira avaliação.

Depois, entra outra instância de Fable 5.1 atuando como QA, separada da execução que está sendo revisada. Esse agente procura problemas, compara o resultado com os critérios definidos e sinaliza se a entrega está aprovada ou se precisa de ajustes.

O ciclo pode voltar para a implementação quantas vezes forem necessárias. Em vez de assumir que “o agente terminou” significa “a feature está pronta”, tento criar pontos de controle claros.

A revisão humana continua relevante, principalmente nas decisões de escopo, qualidade percebida e comportamento final do produto.

Orquestração não deveria transformar ausência de supervisão em sinônimo de autonomia.

09Memória não pode depender da sessão atual

Um fluxo com vários agentes e projetos precisa responder a uma pergunta básica: como recuperar o contexto certo sem reconstruí-lo do zero?

É aí que entram meu segundo cérebro e minha base de continuidade: AI Memory, do Akita, e Obsidian.

Uso essas ferramentas como parte da memória do trabalho — decisões, histórico, estágio de desenvolvimento, pendências e contexto que deve sobreviver à troca de sessões. O objetivo é que cada projeto tenha uma trajetória recuperável, e não dependa de eu lembrar de tudo na próxima vez que abrir um agente.

Cada uma tem um papel. O AI Memory organiza toda a memória dos projetos, independente do local que eu use. O Obsidian é o segundo cérebro que auxilia projetos e tarefas de outros cenários: se eu simplesmente conversei sobre algo, o AI Memory não vai suprir isso, mas o Obsidian supre.

O Git e a documentação técnica continuam importantes nesse processo. Memória conversacional ajuda a recuperar o porquê; repositório, testes e documentos ajudam a confirmar o que existe de fato.

É assim que tento reduzir o maior custo de tocar muitos projetos: não o tempo gasto codando, mas o tempo gasto entendendo novamente onde parei.

10Postaí: a release também é uma conversa

Desenvolver o aplicativo é só parte do trabalho. Se ninguém experimenta, aponta dificuldades ou reage às mudanças, a evolução do produto fica presa ao meu próprio ponto de vista.

Para reduzir esse atrito, criei o Postaí, uma ferramenta de publicação automatizada para X, Reddit e LinkedIn.

Ela se conecta ao contexto mantido no AI Memory e no Obsidian. Assim, uma atualização em um projeto como o Console Mode pode virar uma comunicação baseada no que realmente mudou, sem que eu precise reconstruir toda a história do release a cada publicação.

O objetivo não é apenas produzir posts. É facilitar a chegada de novidades às pessoas certas e trazer feedback de volta ao produto. Uma crítica, sugestão ou dúvida recorrente pode se tornar nova pergunta de discovery, item de backlog ou mudança de prioridade.

11Um exemplo de ponta a ponta

Imagine que eu queira adicionar uma nova função ao Console Mode. Este é um exemplo ilustrativo do caminho que ela percorreria.

1. Discovery: investigo a necessidade no ChatGPT, consulto referências e identifico os cenários principais.

2. QA da descoberta: outro agente questiona lacunas e força decisões que ainda não tomei.

3. Especificação: documento escopo, dependências, backlog e critérios observáveis de aceite usando a base de práticas do LippStack.

4. Execução remota: abro o ambiente do T3 Code na VPS e passo a demanda ao Opus 5.5 para decomposição e delegação.

5. Implementação especializada: um ou mais subagentes realizam as partes adequadas a cada capacidade.

6. Revisão e QA: o resultado retorna ao orquestrador e depois passa pela revisão independente, com correções quando necessário.

7. Continuidade: registro o estado e o contexto para que a próxima sessão parta do ponto certo.

8. Comunicação e feedback: o Postaí usa esse contexto para apoiar a divulgação; o que voltar da comunidade alimenta a próxima iteração.

Não preciso executar todas as etapas com o mesmo peso para cada ajuste pequeno. O valor está em ter um processo previsível que cresce com a complexidade da demanda.

12O que este sistema resolve — e o que ele não resolve

A maior vantagem não é uma promessa de velocidade infinita. É reduzir o atrito entre pensar, delegar, validar e retomar.

Justamente por isso separo as fases. Quero que as perguntas difíceis apareçam cedo, que as entregas passem por mais de um olhar e que seja possível rastrear de onde veio cada decisão importante.

O benefício de trabalhar em vários projetos não é fingir que todos são iguais. É fazer com que cada projeto tenha um estado legível, uma direção explícita e uma forma repetível de avançar.