Gasto mais de R$1.500/mês em IA e faturo mais de R$40.000/mês, O segredo é o workflow!

João Pedro Viana Freitas · Terça-feira às 11:26

Este artigo não é sobre qual ferramenta usar ou qual prompt funciona melhor. É sobre o que aprendi ao observar onde o uso de IA realmente quebra, e como construí um sistema para resolver isso de forma estruturada e repetível.

Desculpem-me por falar abertamente sobre quanto ganho, só queria chamar a atenção de vocês. Hoje em dia atenção é um recurso escasso, e o que eu quero é que você evolua também!!

https://github.com/J-Pster/Psters_AI_Workflow

O repositório é público e aberto a contribuições.

Como a maioria usa IA hoje

A adoção de IA entre desenvolvedores cresceu de forma explosiva, mas o padrão de uso se consolidou em torno de uma prática que eu chamo de one-shot prompting: você descreve o que quer, o modelo gera uma resposta, você aceita ou ajusta manualmente, e parte para a próxima tarefa.

Esse modelo tem uma atratividade óbvia. Parece produtivo porque produz código rápido. A sensação de velocidade é imediata.

O problema é que essa velocidade é superficial. O que está acontecendo nos bastidores é mais preocupante:

A IA não sabe nada sobre a arquitetura do seu projeto.
A IA não conhece as decisões que foram tomadas na semana passada.
A IA ignora os padrões que o time decidiu adotar.
A IA não tem acesso ao que já foi documentado.
A IA não sabe o que quebra quando você muda um arquivo específico.

Em outras palavras: o modelo responde com competência genérica aplicada a um contexto que ele não entende. O resultado é código tecnicamente corrente, mas frequentemente inconsistente com a realidade do projeto.

Com o tempo, esse padrão gera dívida técnica silenciosa: decisões duplicadas, padrões contraditórios, documentação defasada e regressões que só aparecem quando você já está em produção.

O problema central: IA sem memória

Todo modelo de linguagem tem uma limitação fundamental: ele não tem memória persistente entre sessões. Cada novo chat começa do zero.

Para um projeto de software real, que tem meses de histórico, decisões arquiteturais acumuladas, padrões estabelecidos e contexto distribuído em dezenas de arquivos, isso é um problema sério.

A solução intuitiva é "colocar tudo no prompt". Mas isso não escala. Prompts enormes são caros, lentos, e o modelo começa a perder coerência com o excesso de informação.

A solução real é outra: criar um sistema onde o contexto relevante é carregado de forma estruturada antes de qualquer geração de código. Não tudo, mas o que importa para aquela tarefa específica.

Isso muda completamente a qualidade das respostas.

Por que o Extreme Programming oferece um modelo mental útil aqui

Antes de entrar nos detalhes técnicos do workflow, vale entender a base conceitual.

Extreme Programming (XP) é uma metodologia ágil criada nos anos 90 por Kent Beck. Ela se opunha ao modelo de desenvolvimento em cascata, onde você planeja tudo, implementa tudo, e descobre os problemas no final, e propunha um ciclo curto e repetível:

Pegar uma história pequena.
Planejar em pouco tempo.
Implementar em incremento pequeno.
Testar e validar.
Refatorar.
Integrar.
Coletar feedback.
Repetir.

O que XP resolve é exatamente o que one-shot prompting ignora: a ideia de que software complexo não é entregue em uma jogada, mas em ciclos controlados com feedback frequente.

Quando comecei a estruturar meu uso de IA, percebi que estava reinventando os mesmos princípios, mas aplicados a um contexto de execução com agentes:

🔁 User Story + Planning → /brainstorm + /plan

📦 Small Increment → /work-plan por fase

✅ Test and Validate → /review com múltiplos agents

🔧 Refactor + Improve → achados de review + /work para ajustes

📚 Shared Understanding → documentação obrigatória em todo ciclo

🎯 Sustainable Rhythm → execução em fases + commits estruturados

A diferença fundamental é que XP foi desenhado para times humanos. O Psters AI Workflow é desenhado para orquestar IA como parceira de engenharia, com as mesmas disciplinas que um time de alta performance usa.

O que torna um workflow de IA diferente de usar IA sem workflow

A palavra "workflow" aqui não é metáfora. É literal.

Um workflow de IA tem três propriedades que mudam completamente o resultado:

1) Fluxo padronizado e repetível

Cada tipo de tarefa segue uma sequência de etapas conhecida. Feature nova: brainstorm → plan → work-plan → review → commit. Fix pontual: work → review → commit.

Isso não é burocracia. É o mesmo motivo pelo qual pilotos de avião usam checklist: não porque são incapazes de voar sem ele, mas porque sistemas complexos operados sob pressão têm mais segurança com processo explícito do que com intuição.

Quando a sequência é sempre a mesma, você elimina a fricção de decidir "como" a cada vez e concentra energia no "o quê".

2) Contexto explícito antes de qualquer geração

Toda vez que a IA vai implementar algo, ela primeiro lê:

documentação de módulos existentes,
soluções e padrões já registrados,
regras do projeto (convenções de commit, padrões de entidade, estrutura de pastas),
o plano da fase atual.

Isso não é opcional. É a primeira etapa obrigatória, e o workflow não avança enquanto esse carregamento não acontece.

O resultado prático é que a IA gera código que se encaixa no projeto existente, não código genérico que você vai ter que adaptar manualmente.

3) Documentação como ativo de produtividade

A maioria trata documentação como tarefa extra, feita depois que o trabalho "real" termina. No meu workflow, documentação é parte do ciclo de execução.

Depois de cada fase implementada, o agente atualiza:

o documento do módulo afetado,
o status do plano (marcando tarefas como concluídas),
os padrões reutilizáveis identificados.

Isso cria um efeito composto: cada ciclo deixa o sistema mais bem documentado do que estava, o que melhora a qualidade dos próximos ciclos. O contexto que a IA vai receber na próxima sessão é melhor do que o que ela recebeu nesta.

Em projetos sem esse padrão, acontece o inverso: a documentação envelhece, o contexto se degrada e a qualidade das respostas piora com o tempo.

O papel dos subagents, e por que eles rodam em paralelo

Este é um dos pontos mais técnicos do workflow e o que mais surpreende quem o vê funcionando pela primeira vez.

Nos comandos mais ricos, /brainstorm e /plan, ao invés de uma única instância de IA respondendo a tudo, o workflow spawna múltiplos agentes especializados simultaneamente.

Por exemplo, durante o /brainstorm:

Um agente mapeia o código existente no repositório (repo-research-analyst).
Um segundo analisa impactos de integração em outros serviços (integration-impact-analyst).
Um terceiro examina arquitetura e necessidades de infraestrutura.

Esses três agentes rodam em paralelo, cada um com um escopo claro e delimitado.

Por que isso importa?

Especialização reduz alucinação. Um agente com instrução específica ("mapeie os arquivos existentes e retorne caminhos exatos, nomes de serviços e DTOs") entrega resultado muito mais preciso do que um agente generalista respondendo a "faça uma análise completa do projeto".

Paralelismo reduz latência. Em vez de esperar uma análise sequencial, as três perspectivas chegam ao mesmo tempo. O agente orquestrador (o chat principal) consolida os resultados e passa para a próxima fase.

Cada agente tem um arquivo de instruções dedicado. O repo-research-analyst, por exemplo, tem um documento específico que define exatamente o que ele deve fazer, como deve estruturar a resposta e quais heurísticas aplicar. Isso cria comportamento consistente e previsível.

O mesmo padrão se repete no /plan, que usa até nove agentes especializados dependendo do contexto da feature:

pesquisa de repositório,
pesquisa de aprendizados passados,
análise de fluxo de especificação,
planejamento de impacto de migração de banco,
análise de melhores práticas,
revisão de arquitetura,
sentinela de segurança,
oracle de performance,
pesquisa de documentação de frameworks.

Cada agente responde ao orquestrador com texto estruturado. O orquestrador consolida e produz o plano final, que já nasceu com visibilidade de todos esses ângulos.

Forçar padrões: rules, skills e hooks

Um workflow de IA é tão bom quanto a consistência com que é seguido. Para garantir isso, o sistema usa três mecanismos complementares.

Rules (regras automáticas)

São instruções que se aplicam sempre que determinados arquivos estão em contexto. Exemplos:

Quando o agente toca arquivos de migração TypeORM, ele carrega automaticamente as regras de geração de migration (nunca criar manualmente, sempre via CLI, sempre revisar o arquivo gerado).
Quando o agente vai fazer um commit, ele carrega as convenções de mensagem de commit.
Quando qualquer implementação envolve uma biblioteca externa, ele carrega a instrução de consultar a documentação via Context7 MCP antes de gerar código.

O agente não precisa ser lembrado. As regras chegam junto com o contexto.

Skills (habilidades encapsuladas)

São roteiros reutilizáveis para tarefas que têm um padrão bem definido. O skill de commit, por exemplo, encapsula toda a lógica de:

listar todos os arquivos modificados nos repositórios do workspace,
classificar cada arquivo pelo ticket ao qual pertence,
agrupar por ticket,
criar um commit por grupo com mensagem estruturada.

Isso roda igual toda vez. Não tem variação, não tem improviso.

Hooks (guardrails de sessão)

Os hooks são automações que rodam em eventos específicos:

afterFileEdit: toda vez que um arquivo é editado, um tracker registra se foi um arquivo de código ou de documentação.
stop: quando a sessão encerra, o sistema verifica se houve edição de código sem atualização de documentação correspondente. Se sim, emite um lembrete antes de fechar.
beforeShellExecution (git commit): intercepta o comando de commit e verifica se a mensagem segue a convenção do projeto.
afterShellExecution (typeorm:generate): lembra o desenvolvedor da cadeia atômica de migrations que precisa ser executada após a geração.

Esses guardrails não bloqueiam o trabalho, eles lembram. É a diferença entre um colega experiente ao lado e trabalhar sozinho.

A questão da documentação como memória operacional

Existe uma distinção importante que vale explicitar: documentação no contexto desse workflow não é documentação para usuário final, nem para onboarding de novos membros. É documentação para IA.

A pergunta que guia cada atualização de doc é: "Se um agente abrir esse arquivo antes de implementar alguma coisa, ele vai entender exatamente o que existe, o que foi planejado, onde mexer com segurança e o que não pode quebrar?"

Isso muda o nível de especificidade exigido. Um documento de módulo, por exemplo, precisa conter:

quais serviços existem e o que cada um faz,
quais endpoints existem e suas assinaturas,
quais entidades são manipuladas,
o que já foi implementado vs o que está planejado para fases futuras,
quais invariantes não podem ser violados,
quais são os pontos frágeis conhecidos.

Quando um agente lê esse documento antes de implementar, ele não inventa. Ele trabalha com o que existe.

Escolher o modelo certo para cada etapa

Um ponto que a maioria negligencia: nem toda etapa do workflow deve usar o mesmo modelo.

A distinção mais importante que aprendi na prática é entre planejamento e execução.

Planejamento: use o modelo mais capaz disponível

/brainstorm e /plan são as etapas mais críticas de toda a feature. É aqui que o plano nasce, e se o plano estiver errado ou superficial, nenhuma qualidade de execução vai corrigir isso. Retrabalho de implementação é barato. Retrabalho de arquitetura é caro.

Para essas etapas, use os modelos mais inteligentes disponíveis: Claude Sonnet, Opus, ou equivalentes de alta capacidade. A diferença de qualidade no raciocínio, na identificação de edge cases e na estrutura do plano é substancial.

O custo adicional do modelo mais caro no /plan é irrelevante comparado ao custo de uma feature mal planejada que vai exigir três ciclos de retrabalho.

Execução: o modelo de médio porte é suficiente, e mais eficiente

/work-plan e /work executam um plano que já existe. As decisões foram tomadas. A arquitetura foi definida. O agente precisa seguir as instruções com precisão, não inventar nada novo.

Nessa etapa, modelos de porte médio em modo automático entregam excelente resultado com latência menor e custo significativamente inferior. Usar um modelo de ponta para executar tarefas mecânicas bem definidas é desperdício de recurso.

O modelo mental

O planejamento define o que vai ser construído e como. A execução apenas materializa essa decisão.

Errar no planejamento com modelo mais barato e depois executar com modelo caro é a ordem inversa. Invista capacidade intelectual, do modelo e sua, na fase que define o destino. Deixe a execução ser eficiente.

🧠 /brainstorm → modelo de alta capacidade (Sonnet, Opus, equivalentes)

📋 /plan → modelo de alta capacidade, a etapa mais crítica

⚙️ /work-plan → modelo médio em auto ou modo padrão

🔨 /work → modelo médio em auto ou modo padrão

🔍 /review → modelo de alta capacidade (revisão exige raciocínio profundo)

✅ /commit-changes → qualquer modelo

O resultado prático

Com esse sistema operando, consigo manter uma cadência de entrega que seria difícil de explicar sem o contexto do processo.

Em dias de alta demanda, já entreguei 25 tasks no mesmo dia, com distribuição aproximada de 50% pequenas, 25% médias e 25% grandes. Isso não é sprint heroico. É o resultado de um processo que elimina fricção em cada transição:

Sem tempo perdido decidindo como começar cada task (o workflow define isso).
Sem retrabalho por falta de contexto (o carregamento é obrigatório).
Sem inconsistência arquitetural (os agentes especializados capturam isso antes).
Sem documentação defasada acumulando dívida (cada ciclo atualiza).

O efeito composto é real. Um projeto operado com esse processo por semanas está em estado radicalmente melhor do que um projeto operado com one-shot prompting pelo mesmo período.

O que esse workflow não resolve

Vale ser honesto sobre os limites.

Esse processo pressupõe que você já tem clareza técnica sobre o que está construindo. Ele não substitui decisões de produto, não resolve conflitos de requisito e não é um atalho para entender tecnologias que você não conhece.

Ele também tem custo: rodar múltiplos agentes em paralelo consume tokens. Por isso o gasto mensal é significativo. A questão é que o retorno em qualidade, velocidade e consistência de entrega justifica esse investimento, pelo menos no contexto em que opero.

Conclusão

A pergunta que mais ouço quando explico esse processo é: "isso não é exagero para uma tarefa simples?"

Para uma tarefa simples isolada, pode ser. Mas software real não é feito de tarefas simples isoladas. É feito de centenas de decisões acumuladas, padrões que precisam ser respeitados, dependências não documentadas e contexto que existe apenas na cabeça das pessoas.

O que esse workflow faz é transformar esse contexto implícito em contexto explícito, e dar à IA condições de operar com ele de forma estruturada.

O resultado não é só velocidade. É consistência, que em projetos reais é muito mais valiosa do que velocidade pontual.

Se quiser explorar o workflow completo, com todos os commands, agents, skills, hooks e documentação bilíngue:

https://github.com/J-Pster/Psters_AI_Workflow

O repositório é público e aberto a contribuições.

João Pedro Viana Freitas · Terça-feira às 11:27

Para o moderador que ira analisar, eu nao achei outro topico melhor para esse artigo, se achar que outro topico e melhor por favor me informe.

Lucca Vinicios · Terça-feira às 13:39

Cara, esse tópico é muito útil. Eu já aplico boa parte disso, mas no começo cometi vários erros, principalmente com desperdício e otimização de tokens.

Achei muito interessante a forma como você estruturou o workflow, principalmente essa parte de contexto e padronização. Vou dar uma analisada com calma no repositório pra entender melhor como você organizou tudo.

Curti bastante a abordagem faz muito sentido pra quem está trabalhando com IA de forma mais séria. Bora trocar uma ideia depois, acho que dá pra aprender bastante contigo.

Filipe Andrade Nascimento · Terça-feira às 13:44

2 horas atrás, João Pedro Viana Freitas disse:

Este artigo não é sobre qual ferramenta usar ou qual prompt funciona melhor. É sobre o que aprendi ao observar onde o uso de IA realmente quebra, e como construí um sistema para resolver isso de forma estruturada e repetível.

Desculpem-me por falar abertamente sobre quanto ganho, só queria chamar a atenção de vocês. Hoje em dia atenção é um recurso escasso, e o que eu quero é que você evolua também!!

https://github.com/J-Pster/Psters_AI_Workflow

O repositório é público e aberto a contribuições.

Como a maioria usa IA hoje

A adoção de IA entre desenvolvedores cresceu de forma explosiva, mas o padrão de uso se consolidou em torno de uma prática que eu chamo de one-shot prompting: você descreve o que quer, o modelo gera uma resposta, você aceita ou ajusta manualmente, e parte para a próxima tarefa.

Esse modelo tem uma atratividade óbvia. Parece produtivo porque produz código rápido. A sensação de velocidade é imediata.

O problema é que essa velocidade é superficial. O que está acontecendo nos bastidores é mais preocupante:

A IA não sabe nada sobre a arquitetura do seu projeto.

A IA não conhece as decisões que foram tomadas na semana passada.

A IA ignora os padrões que o time decidiu adotar.

A IA não tem acesso ao que já foi documentado.

A IA não sabe o que quebra quando você muda um arquivo específico.

Em outras palavras: o modelo responde com competência genérica aplicada a um contexto que ele não entende. O resultado é código tecnicamente corrente, mas frequentemente inconsistente com a realidade do projeto.

Com o tempo, esse padrão gera dívida técnica silenciosa: decisões duplicadas, padrões contraditórios, documentação defasada e regressões que só aparecem quando você já está em produção.

O problema central: IA sem memória

Todo modelo de linguagem tem uma limitação fundamental: ele não tem memória persistente entre sessões. Cada novo chat começa do zero.

Para um projeto de software real, que tem meses de histórico, decisões arquiteturais acumuladas, padrões estabelecidos e contexto distribuído em dezenas de arquivos, isso é um problema sério.

A solução intuitiva é "colocar tudo no prompt". Mas isso não escala. Prompts enormes são caros, lentos, e o modelo começa a perder coerência com o excesso de informação.

A solução real é outra: criar um sistema onde o contexto relevante é carregado de forma estruturada antes de qualquer geração de código. Não tudo, mas o que importa para aquela tarefa específica.

Isso muda completamente a qualidade das respostas.

Por que o Extreme Programming oferece um modelo mental útil aqui

Antes de entrar nos detalhes técnicos do workflow, vale entender a base conceitual.

Extreme Programming (XP) é uma metodologia ágil criada nos anos 90 por Kent Beck. Ela se opunha ao modelo de desenvolvimento em cascata, onde você planeja tudo, implementa tudo, e descobre os problemas no final, e propunha um ciclo curto e repetível:

Pegar uma história pequena.

Planejar em pouco tempo.

Implementar em incremento pequeno.

Testar e validar.

Refatorar.

Integrar.

Coletar feedback.

Repetir.

O que XP resolve é exatamente o que one-shot prompting ignora: a ideia de que software complexo não é entregue em uma jogada, mas em ciclos controlados com feedback frequente.

Quando comecei a estruturar meu uso de IA, percebi que estava reinventando os mesmos princípios, mas aplicados a um contexto de execução com agentes:

🔁 User Story + Planning → /brainstorm + /plan

📦 Small Increment → /work-plan por fase

✅ Test and Validate → /review com múltiplos agents

🔧 Refactor + Improve → achados de review + /work para ajustes

📚 Shared Understanding → documentação obrigatória em todo ciclo

🎯 Sustainable Rhythm → execução em fases + commits estruturados

A diferença fundamental é que XP foi desenhado para times humanos. O Psters AI Workflow é desenhado para orquestar IA como parceira de engenharia, com as mesmas disciplinas que um time de alta performance usa.

O que torna um workflow de IA diferente de usar IA sem workflow

A palavra "workflow" aqui não é metáfora. É literal.

Um workflow de IA tem três propriedades que mudam completamente o resultado:

1) Fluxo padronizado e repetível

Cada tipo de tarefa segue uma sequência de etapas conhecida. Feature nova: brainstorm → plan → work-plan → review → commit. Fix pontual: work → review → commit.

Isso não é burocracia. É o mesmo motivo pelo qual pilotos de avião usam checklist: não porque são incapazes de voar sem ele, mas porque sistemas complexos operados sob pressão têm mais segurança com processo explícito do que com intuição.

Quando a sequência é sempre a mesma, você elimina a fricção de decidir "como" a cada vez e concentra energia no "o quê".

2) Contexto explícito antes de qualquer geração

Toda vez que a IA vai implementar algo, ela primeiro lê:

documentação de módulos existentes,

soluções e padrões já registrados,

regras do projeto (convenções de commit, padrões de entidade, estrutura de pastas),

o plano da fase atual.

Isso não é opcional. É a primeira etapa obrigatória, e o workflow não avança enquanto esse carregamento não acontece.

O resultado prático é que a IA gera código que se encaixa no projeto existente, não código genérico que você vai ter que adaptar manualmente.

3) Documentação como ativo de produtividade

A maioria trata documentação como tarefa extra, feita depois que o trabalho "real" termina. No meu workflow, documentação é parte do ciclo de execução.

Depois de cada fase implementada, o agente atualiza:

o documento do módulo afetado,

o status do plano (marcando tarefas como concluídas),

os padrões reutilizáveis identificados.

Isso cria um efeito composto: cada ciclo deixa o sistema mais bem documentado do que estava, o que melhora a qualidade dos próximos ciclos. O contexto que a IA vai receber na próxima sessão é melhor do que o que ela recebeu nesta.

Em projetos sem esse padrão, acontece o inverso: a documentação envelhece, o contexto se degrada e a qualidade das respostas piora com o tempo.

O papel dos subagents, e por que eles rodam em paralelo

Este é um dos pontos mais técnicos do workflow e o que mais surpreende quem o vê funcionando pela primeira vez.

Nos comandos mais ricos, /brainstorm e /plan, ao invés de uma única instância de IA respondendo a tudo, o workflow spawna múltiplos agentes especializados simultaneamente.

Por exemplo, durante o /brainstorm:

Um agente mapeia o código existente no repositório (repo-research-analyst).

Um segundo analisa impactos de integração em outros serviços (integration-impact-analyst).

Um terceiro examina arquitetura e necessidades de infraestrutura.

Esses três agentes rodam em paralelo, cada um com um escopo claro e delimitado.

Por que isso importa?

Especialização reduz alucinação. Um agente com instrução específica ("mapeie os arquivos existentes e retorne caminhos exatos, nomes de serviços e DTOs") entrega resultado muito mais preciso do que um agente generalista respondendo a "faça uma análise completa do projeto".

Paralelismo reduz latência. Em vez de esperar uma análise sequencial, as três perspectivas chegam ao mesmo tempo. O agente orquestrador (o chat principal) consolida os resultados e passa para a próxima fase.

Cada agente tem um arquivo de instruções dedicado. O repo-research-analyst, por exemplo, tem um documento específico que define exatamente o que ele deve fazer, como deve estruturar a resposta e quais heurísticas aplicar. Isso cria comportamento consistente e previsível.

O mesmo padrão se repete no /plan, que usa até nove agentes especializados dependendo do contexto da feature:

pesquisa de repositório,

pesquisa de aprendizados passados,

análise de fluxo de especificação,

planejamento de impacto de migração de banco,

análise de melhores práticas,

revisão de arquitetura,

sentinela de segurança,

oracle de performance,

pesquisa de documentação de frameworks.

Cada agente responde ao orquestrador com texto estruturado. O orquestrador consolida e produz o plano final, que já nasceu com visibilidade de todos esses ângulos.

Forçar padrões: rules, skills e hooks

Um workflow de IA é tão bom quanto a consistência com que é seguido. Para garantir isso, o sistema usa três mecanismos complementares.

Rules (regras automáticas)

São instruções que se aplicam sempre que determinados arquivos estão em contexto. Exemplos:

Quando o agente toca arquivos de migração TypeORM, ele carrega automaticamente as regras de geração de migration (nunca criar manualmente, sempre via CLI, sempre revisar o arquivo gerado).

Quando o agente vai fazer um commit, ele carrega as convenções de mensagem de commit.

Quando qualquer implementação envolve uma biblioteca externa, ele carrega a instrução de consultar a documentação via Context7 MCP antes de gerar código.

O agente não precisa ser lembrado. As regras chegam junto com o contexto.

Skills (habilidades encapsuladas)

São roteiros reutilizáveis para tarefas que têm um padrão bem definido. O skill de commit, por exemplo, encapsula toda a lógica de:

listar todos os arquivos modificados nos repositórios do workspace,

classificar cada arquivo pelo ticket ao qual pertence,

agrupar por ticket,

criar um commit por grupo com mensagem estruturada.

Isso roda igual toda vez. Não tem variação, não tem improviso.

Hooks (guardrails de sessão)

Os hooks são automações que rodam em eventos específicos:

afterFileEdit: toda vez que um arquivo é editado, um tracker registra se foi um arquivo de código ou de documentação.

stop: quando a sessão encerra, o sistema verifica se houve edição de código sem atualização de documentação correspondente. Se sim, emite um lembrete antes de fechar.

beforeShellExecution (git commit): intercepta o comando de commit e verifica se a mensagem segue a convenção do projeto.

afterShellExecution (typeorm:generate): lembra o desenvolvedor da cadeia atômica de migrations que precisa ser executada após a geração.

Esses guardrails não bloqueiam o trabalho, eles lembram. É a diferença entre um colega experiente ao lado e trabalhar sozinho.

A questão da documentação como memória operacional

Existe uma distinção importante que vale explicitar: documentação no contexto desse workflow não é documentação para usuário final, nem para onboarding de novos membros. É documentação para IA.

A pergunta que guia cada atualização de doc é: "Se um agente abrir esse arquivo antes de implementar alguma coisa, ele vai entender exatamente o que existe, o que foi planejado, onde mexer com segurança e o que não pode quebrar?"

Isso muda o nível de especificidade exigido. Um documento de módulo, por exemplo, precisa conter:

quais serviços existem e o que cada um faz,

quais endpoints existem e suas assinaturas,

quais entidades são manipuladas,

o que já foi implementado vs o que está planejado para fases futuras,

quais invariantes não podem ser violados,

quais são os pontos frágeis conhecidos.

Quando um agente lê esse documento antes de implementar, ele não inventa. Ele trabalha com o que existe.

Escolher o modelo certo para cada etapa

Um ponto que a maioria negligencia: nem toda etapa do workflow deve usar o mesmo modelo.

A distinção mais importante que aprendi na prática é entre planejamento e execução.

Planejamento: use o modelo mais capaz disponível

/brainstorm e /plan são as etapas mais críticas de toda a feature. É aqui que o plano nasce, e se o plano estiver errado ou superficial, nenhuma qualidade de execução vai corrigir isso. Retrabalho de implementação é barato. Retrabalho de arquitetura é caro.

Para essas etapas, use os modelos mais inteligentes disponíveis: Claude Sonnet, Opus, ou equivalentes de alta capacidade. A diferença de qualidade no raciocínio, na identificação de edge cases e na estrutura do plano é substancial.

O custo adicional do modelo mais caro no /plan é irrelevante comparado ao custo de uma feature mal planejada que vai exigir três ciclos de retrabalho.

Execução: o modelo de médio porte é suficiente, e mais eficiente

/work-plan e /work executam um plano que já existe. As decisões foram tomadas. A arquitetura foi definida. O agente precisa seguir as instruções com precisão, não inventar nada novo.

Nessa etapa, modelos de porte médio em modo automático entregam excelente resultado com latência menor e custo significativamente inferior. Usar um modelo de ponta para executar tarefas mecânicas bem definidas é desperdício de recurso.

O modelo mental

O planejamento define o que vai ser construído e como. A execução apenas materializa essa decisão.

Errar no planejamento com modelo mais barato e depois executar com modelo caro é a ordem inversa. Invista capacidade intelectual, do modelo e sua, na fase que define o destino. Deixe a execução ser eficiente.

🧠 /brainstorm → modelo de alta capacidade (Sonnet, Opus, equivalentes)

📋 /plan → modelo de alta capacidade, a etapa mais crítica

⚙️ /work-plan → modelo médio em auto ou modo padrão

🔨 /work → modelo médio em auto ou modo padrão

🔍 /review → modelo de alta capacidade (revisão exige raciocínio profundo)

✅ /commit-changes → qualquer modelo

O resultado prático

Com esse sistema operando, consigo manter uma cadência de entrega que seria difícil de explicar sem o contexto do processo.

Em dias de alta demanda, já entreguei 25 tasks no mesmo dia, com distribuição aproximada de 50% pequenas, 25% médias e 25% grandes. Isso não é sprint heroico. É o resultado de um processo que elimina fricção em cada transição:

Sem tempo perdido decidindo como começar cada task (o workflow define isso).

Sem retrabalho por falta de contexto (o carregamento é obrigatório).

Sem inconsistência arquitetural (os agentes especializados capturam isso antes).

Sem documentação defasada acumulando dívida (cada ciclo atualiza).

O efeito composto é real. Um projeto operado com esse processo por semanas está em estado radicalmente melhor do que um projeto operado com one-shot prompting pelo mesmo período.

O que esse workflow não resolve

Vale ser honesto sobre os limites.

Esse processo pressupõe que você já tem clareza técnica sobre o que está construindo. Ele não substitui decisões de produto, não resolve conflitos de requisito e não é um atalho para entender tecnologias que você não conhece.

Ele também tem custo: rodar múltiplos agentes em paralelo consume tokens. Por isso o gasto mensal é significativo. A questão é que o retorno em qualidade, velocidade e consistência de entrega justifica esse investimento, pelo menos no contexto em que opero.

Conclusão

A pergunta que mais ouço quando explico esse processo é: "isso não é exagero para uma tarefa simples?"

Para uma tarefa simples isolada, pode ser. Mas software real não é feito de tarefas simples isoladas. É feito de centenas de decisões acumuladas, padrões que precisam ser respeitados, dependências não documentadas e contexto que existe apenas na cabeça das pessoas.

O que esse workflow faz é transformar esse contexto implícito em contexto explícito, e dar à IA condições de operar com ele de forma estruturada.

O resultado não é só velocidade. É consistência, que em projetos reais é muito mais valiosa do que velocidade pontual.

Se quiser explorar o workflow completo, com todos os commands, agents, skills, hooks e documentação bilíngue:

https://github.com/J-Pster/Psters_AI_Workflow

O repositório é público e aberto a contribuições.

meu brother, o nome disso ai é Ralph Loop, já tem comunidade, site e tudo mais feito em cima disso, tem até plugin pro claude

já estão fazendo automatização do bot consumir tasks direto do Jira, quebrar o escopo em partes menores, produzir os subagentes e implementar automaticamente num container controlado... tudo automático...

Não estou criticando, inclusive gostei do insight envolvendo XP, não tinha pensado antes. o que quis dizer é que o conceito já existe lá fora a um tempo, e já tem heavy user disso ai. e tudo bem tu não ter conhecido antes/ adaptado para sua realidade

Editado Terça-feira às 13:46 por Filipe Andrade Nascimento
Esclarecimento

Henrique Magalhães · Terça-feira às 14:44

3 horas atrás, João Pedro Viana Freitas disse:

É sobre o que aprendi ao observar onde o uso de IA realmente quebra, e como construí um sistema para resolver isso de forma estruturada e repetível.

Desculpem-me por falar abertamente sobre quanto ganho, só queria chamar a atenção de vocês. Hoje em dia atenção é um recurso escasso, e o que eu quero é que você evolua também!!

Amigo fiquei interessado em saber mais. Você aprendeu isso sozinho, há um trilha?

eu uso a ia ainda como amador total e tenho uma curiosidade real de saber como eu poderia usar de forma a me gerar alguma renda (mesmo que eu precise pagar uma mensalidade de uma IA fucking mega blaster), porem fico perdidaço nos zilhoes de conteudos que vejo.

Tem interesse em dar uma aula particular ou uma assessoria particular neste sentido?

Sobre falar o valor, cara aqui sempre podemos e devemos, estamos numa comunidade que n/ao tem esse tabu

Sergio T · ontem às 00:02

Esse cenario ai é basicamente o que o harness engineering prega, basicamente o dev eh o estrategista e os agents os executores, onde a gente entrega todo o tooling e guardrails necessarios para que os agents trabalhem e entreguem todo o trampo

recomendo a leitura desses artigos q sao bons pra introducao

https://openai.com/pt-BR/index/harness-engineering/

https://techcommunity.microsoft.com/blog/appsonazureblog/the-agent-that-investigates-itself/4500073

Editado ontem às 09:07 por Sergio T

Sergio T · ontem às 00:06

12 horas atrás, João Pedro Viana Freitas disse:

Para uma tarefa simples isolada, pode ser. Mas software real não é feito de tarefas simples isoladas. É feito de centenas de decisões acumuladas, padrões que precisam ser respeitados, dependências não documentadas e contexto que existe apenas na cabeça das pessoas.

isso eh um ponto interessante, pois os modelos ja codam melhor que todos nos, seguem os guidelines, testam 100% o que esta sendo entregue, valida todas as premissas, validam todo o codigo, fazem o code review e ainda documentam.

eu ja achava que iriamos codar ainda, hj eu ja acho q nao iremos mais

achava q fariamos pelo menos o code review, mas sera q faz sentido fazermos o review do codigo sendo que nos nao teremos mais o contexto de tudo? sera q o review vai se transformar em verificar se as premissas foram atendidas?

Sergio T · ontem às 00:16

uma coisa que me chamou a atencao eh q eh um fork do template de plugins do cursor.

tua intencao eh jogar no marketplace ele? nao olhei mto o projeto ainda, mas vou dar uma fucada, curti

parabens

COMUNICADOS

TOP 5 respondedores

🐟 TOP Sardinhas

Gasto mais de R$1.500/mês em IA e faturo mais de R$40.000/mês, O segredo é o workflow!