Autor de um CRM em Django montou um pipeline com cinco papéis de IA que conduz a tarefa sozinho até a captura de tela

Cena familiar: você abre o Claude ou o Codex, joga um prompt e recebe um «pronto». Abre o código e lá estão os mesmos formulários, só com as variáveis renomeadas. O autor da análise publicada no Habr veio do desenvolvimento de bancos de dados e, no outono de 2025, começou a construir um CRM para aluguel de carros e aeroclubes. Ele passou por isso quatro vezes seguidas e acabou construindo um pipeline que conduz a tarefa sozinho e traz as provas.

Por que um único prompt não basta

Ele estava criando, em Django, recursos compartilhados para carros, instrutores e locais. Os formulários eram parecidos, e a ideia era reaproveitar código. O Codex informou que a refatoração estava concluída, mas a revisão mostrou que quase nada havia mudado. Mais três rodadas em chats diferentes deram o mesmo resultado. A principal queixa do autor: ele só entendia o que o modelo tinha feito no final. O conhecimento entre os chats precisava ser transferido manualmente, e a compressão de contexto perdia detalhes.

Ele precisava de um sistema em que fosse possível ver de antemão como o modelo entendeu a tarefa, em que o trabalho fosse dividido em etapas e em que cada etapa fosse verificada por outra parte. Verificar tudo sozinho não era viável.

Cinco papéis e um arquivo

Os papéis nasceram de um conjunto de wrappers de console para o Codex CLI, o Claude Code e o GLM. No início eram quatro:

• o arquiteto constrói a solução de alto nível (modelos GPT no Codex);
• o planejador define o conjunto de arquivos e esboça um rascunho do código;
• o programador escreve as alterações;
• o revisor verifica o resultado. Esse papel foi entregue ao GLM, inclusive para caber nos limites das assinaturas.

Quando o trabalho paralelo em cinco git worktrees consumiu a atenção do autor, surgiu o gerente. É um papel quase mecânico, que passa a vez adiante. O autor o implementou como agente, e não como script, porque queria poder perguntar «em que status estamos». Hoje há dois revisores, divididos por áreas de responsabilidade.

O que une todos é um artefato de coordenação: o arquivo de plano. Quem o mantém é o arquiteto; os demais acrescentam suas seções, e o gerente apenas lê e passa adiante. No cabeçalho ficam registrados o status e quem tem o direito de defini-lo: Ready for Planner, Ready for Coder, Ready for Review, Done. É a mesma ideia dos frameworks SDD, como Spec Kit, OpenSpec, BMAD e Kiro. A tarefa vive no arquivo e sobrevive à compressão de contexto.

Há também um detalhe curioso: os papéis não gostavam de reler o plano e confiavam na «memória». Certa vez o arquiteto declarou que era a vez do planejador, embora este já tivesse terminado. A cura é simples. O status é fornecido por um helper; o papel pergunta a ele e não inventa nada.

Como isso funciona em uma tarefa real

A tarefa veio do CRM para aeroclubes: agendar avião, instrutor e aluno por horário. O planejador percebeu que não havia lugar no modelo de dados para o campo «Aula da seção do AUC» e fez ao arquiteto uma pergunta marcada como «bloqueador». O arquiteto indicou para onde mapear os campos, e o programador começou o trabalho sem dúvidas.

O revisor devolveu o formulário ao programador duas vezes. Na segunda, o teste chegou a consolidar o erro e passava, por isso testes verdes sozinhos não bastam. Na terceira vez, o revisor rodou as verificações (119 e 67 testes, verificação de migrações, doc-lint), tirou capturas de tela seguindo o cenário do plano e conferiu cada uma com o plano. O arquiteto abriu seis capturas e não aceitou a tarefa de primeira: três arquivos do commit não faziam parte do conjunto declarado. Após a correção, aceitou. O humano entrega a tarefa na entrada e confere se plano, revisão, testes e capturas de tela batem.

O pipeline ainda se aprimora sozinho. Depois de cada plano, os papéis fazem um docs closeout: sugerem o que falta concluir e como melhorar o processo. As sugestões se acumulam em registros, e a triagem decide o que implementar. O autor também busca ideias externas. Os golden paths, receitas curtas do tipo «para um formulário típico, abra estes 3–5 documentos», e o doc gardening vieram de um artigo da OpenAI sobre harness engineering. A busca QMD em markdown foi testada e descartada: a busca de texto completo no SQLite bastou. Contra loops, há um limite: após 12 iterações em um mesmo plano, o gerente interrompe o trabalho.

Limitações e o que levar para o seu projeto

É a experiência de uma pessoa em um projeto, sem medições do tipo «economizei tantas horas». O autor nunca conseguiu reduzir os formulários a um código único, parando em um «nível compreensível de uniformidade». Nem todas as alterações passam pelo pipeline, apenas aquelas que exigem um rastro no repositório. A verificação por outro modelo agora acontece principalmente fora do pipeline. Os modelos específicos que ele cita não são o principal: eles mudam mais rápido que o processo.

O que vale levar para o seu projeto:

• Exija provas, não relatórios: testes, capturas de tela, conferência com o plano.
• Crie um arquivo de tarefa único com status e uma regra sobre quem define cada status.
• Não peça ao modelo que calcule o status; delegue isso a um helper.
• Permita que os papéis façam perguntas bloqueantes antes de escrever código.
• Defina um limite de iterações para que os agentes não patinem indefinidamente.

A principal lição: o prompt serve para uma solução pontual. Assim que o projeto precisa evoluir e ser mantido, é preciso um processo em que o resultado possa ser verificado a olho nu.