Pitch: Cansei de Ser Babá de Agentes de IA, Então Construí um Scrum Team de IA · sohei56

Uma demonstração de 2 minutos do app para Mac sobre o qual este artigo fala.

A IA me deixou mais rápido. Então por que eu estava exausto?

Peça a um coding agent para implementar algo e, alguns minutos depois, um diff enorme volta. Com testes. Até uma nota de design.

Só que era aí que o trabalho de verdade começava.

Verificar se o diff de fato satisfaz os requisitos — isso era comigo. Perceber que os testes apenas repetem a implementação com outras palavras — também comigo. Desconfiar do animado "Pronto!" e realmente rodar a coisa — de novo, comigo.

Adicione um segundo e um terceiro agente e surge um novo trabalho: acompanhar quem está fazendo o quê, desembaraçar mudanças conflitantes, reexplicar o contexto para um agente que o perdeu. Meu tempo escrevendo código caiu a zero e, ainda assim, dias inteiros estavam sumindo em supervisão de IA.

A IA é mesmo rápida para escrever código. Mas passei a achar que isso apenas deslocou o gargalo — de escrever para controlar o sistema que escreve.

AI coding agents can generate more code than a human can review.
The bottleneck is no longer writing code. It is controlling the system that writes it.

Quando a geração passa a superar a revisão, parece haver apenas duas opções: parar de revisar e confiar na saída, ou reduzir a geração até a velocidade da revisão humana. A primeira abre mão da qualidade; a segunda abre mão de quase todo o sentido de usar IA.

Cansei desse dilema e fui procurar uma terceira opção. Este artigo é a história de construí-la — não um agente mais inteligente, mas uma estrutura organizacional que governa agentes.

Onde as duas abordagens usuais desmoronaram para mim

Pelo que consigo perceber, a prática atual se concentra em torno de dois polos.

Polo 1: Vibe coding — improvisar em uma janela de chat

Dispare instruções para um agente conforme elas surgem na sua cabeça, olhe o que volta, dispare a próxima. É o caminho mais rápido para um protótipo — mas, passados alguns dias de vida do projeto, vi isso desabar vez após vez.

As decisões não deixam rastro. Uma semana depois, ninguém — nem eu, nem a IA da próxima sessão — consegue explicar por que a arquitetura está do jeito que está
Requisitos e implementação se distanciam. A especificação vive no histórico de rolagem do chat, mudando à medida que você avança, até que ninguém saiba mais o que significa "correto"
Os testes viram algo secundário. É difícil reunir energia para escrever testes de algo que já parece funcionar
A IA não enxerga o raio de impacto. Código fora da janela de contexto é como se não existisse

Passei a acreditar que o problema central do vibe coding não é a velocidade — é a amnésia. Humano e IA seguem em frente sem qualquer memória do que foi julgado.

Polo 2: Desenvolvimento pesado guiado por especificação — decidir tudo antecipadamente

O polo oposto: congelar uma especificação completa antes de a IA tocar em qualquer coisa. Você ganha ordem — e um conjunto diferente de problemas.

Escrever a especificação é trabalho pesado. O humano acaba carregando a parte mais difícil de novo
Ela briga com o desenvolvimento cheio de incógnitas. Decidir tudo antecipadamente é exatamente o que você não consegue fazer quando aprende construindo
Se a especificação estiver errada, a IA implementa a coisa errada em velocidade máxima. Agentes não questionam o mapa que você lhes entrega

Juntando as peças: o vibe coding quebra porque não há inspeção, e o desenvolvimento pesado guiado por especificação quebra porque não há adaptação.

A engenharia de software já esteve aqui antes — cowboy coding versus waterfall. E as equipes humanas encontraram uma resposta no meio-termo décadas atrás: construir em iterações curtas, inspecionar software funcionando, adaptar na próxima iteração. Scrum.

O que eu precisava não era de um agente mais inteligente — era de uma organização

A conclusão a que finalmente cheguei:

The problem was not that the coding agent was insufficiently intelligent.
The problem was that it had no delivery system around it.

As equipes humanas têm o mesmo problema, se você parar para pensar. Coloque seis engenheiros brilhantes numa sala, diga "boa sorte" e vá embora — o progresso fica invisível, a qualidade varia muito, a integração vira uma bagunça. É por isso que equipes reais têm papéis, revisões, gates de teste, retrospectivas. As equipes produzem resultados confiáveis não por deixar os indivíduos mais inteligentes, mas por dar à organização uma estrutura na qual os erros são detectados e corrigidos.

Então tentei dar aos agentes de IA a mesma estrutura:

Product Owner — decide o que construir. Um humano — ou, no modo autônomo descrito adiante, um agente
Scrum Master — coordenação e fluxo; não escreve código
Developer agents (vários) — cada um implementa um item do backlog por vez
Reviewer agents (vários) — verificam design, implementação e testes a partir de pontos de vista separados
Sprint Review — inspeciona software funcionando
Retrospective — alimenta os padrões de falha nas melhorias do próximo Sprint

Para evitar um mal-entendido: isto não é "fazer a IA brincar de escritório". Ter agentes realizando uma daily stand-up não serviria para nada. O valor não está em reproduzir as cerimônias do Scrum — está em redesenhar cada uma delas como um loop de controle que contém os modos de falha da IA:

Revisão não é um ritual de aprovação — é verificação adversarial por um agente com um contexto separado
Testes não são um cobertor de segurança — são um gate de aprovação/reprovação escrito apenas a partir da especificação, por um agente que não pode ler a implementação
Sprint Review não é uma reunião de status — é um checkpoint que recusa autorrelatos e conta apenas software funcionando
A retrospective não é um debrief — é uma mudança de configuração para que a mesma falha não aconteça duas vezes

A ideia é reaproveitar aquilo que o Scrum humano passou décadas refinando — "obter resultados confiáveis de um conjunto de indivíduos não confiáveis" — como um mecanismo de governança para IA. Na prática, a IA segue essa estrutura de forma bem mais obediente do que os humanos jamais seguiram.

O que é o Maul Team

Construí essa estrutura como o Maul Team. Em uma frase:

O Maul Team é um sistema local, multiagente, de entrega de software que roda um loop Scrum de verdade sobre o Claude Code.

O framework em si — definições de agentes, workflows, gerenciamento de estado — é open source com licença MIT, utilizável a partir da CLI. Sobre ele, construí um app nativo para Mac (MaulTeam.app) para facilitar operar o framework. O app é source-available: o código-fonte é público, o uso pessoal e interno em empresas é atualmente gratuito, e a redistribuição não é permitida.

O que o app para Mac oferece:

Supervisione tudo em uma única janela: a conversa com o Scrum Master, o Work Log da equipe, o quadro do backlog e o código do projeto
Rode até seis developer agents em paralelo
Desenvolva cada item do backlog em seu próprio worktree git isolado, mesclando apenas o que passa nos gates
Persista todo o estado localmente — interrompa e retome a qualquer momento
Um modo human-in-the-loop e também um modo autônomo que continua rodando Sprints enquanto você dorme

Chega de listar recursos. É mais rápido mostrar o que de fato acontece.

O que de fato acontece — construindo um pequeno app

Eis o fluxo real quando você lhe entrega um objetivo como "construa uma CLI simples de gerenciamento de tarefas":

Você informa o Product Goal. No começo, esse é todo o trabalho do humano
Um Requirements Analyst faz perguntas de volta. "Onde os dados devem persistir?" "Você precisa de sincronização entre dispositivos?" Ele não vai rodar com requisitos vagos — eles são fixados em um documento de requisitos primeiro
O backlog é dividido em itens. Cada um é uma unidade de comportamento visível ao usuário — um PBI (Product Backlog Item)
O humano aprova o objetivo do Sprint
Vários Developers implementam em paralelo, cada um trabalhando em seu próprio worktree, para que ninguém atropele as mudanças de ninguém

Development Pipeline

Os PBIs fluem pelo quadro Scrum enquanto o trabalho de cada agente é transmitido em tempo real para o Work Log.

Design, implementação e testes cada um recebe revisão — por agentes em contextos separados, opcionalmente com cross-review por um modelo diferente (Codex)
Apenas PBIs que passam nos gates são mesclados. Toda merge roda uma verificação de regressão
A Sprint Review inspeciona o produto funcionando. Os achados vão para o backlog do próximo Sprint

O que eu pediria para você observar não é a velocidade do sucesso — é onde os erros são interrompidos. Rodando isso diariamente, cenas como estas são rotina:

A UI estava pronta, mas faltava um requisito de persistência → detectado não pela revisão de código, mas pela revisão de conformidade de requisitos, e devolvido. Nenhum humano precisou apertar os olhos sobre diffs para achar isso
Todos os testes unitários passaram, mas o gate de regressão no momento da merge pegou uma quebra em comportamento existente → merge recusada, item devolvido ao seu developer
Os requisitos eram ambíguos e, em vez de adivinhar, o agente escalou: "a especificação não está clara" → o Product Owner humano responde em uma linha e o trabalho retoma. Código escrito com confiança em cima de um palpite silencioso é o modo de falha mais assustador que conheço, então o sistema é projetado para forçar a escalação em vez do palpite

Não confie no "Pronto!" de um agente — conte apenas o que sobrevive aos gates. Essa única regra mudou a natureza da minha supervisão, de "desconfiar de tudo" para "auditar o design de alguns poucos gates". A superfície que eu preciso vigiar encolheu de incontáveis diffs para um punhado de loops.

"Isso não é só rodar agentes em paralelo?"

Pergunta justa — há uma família crescente de ótimas ferramentas (Orca é uma bem conhecida) que espalham um prompt para N agentes em worktrees isolados, deixam eles competirem e deixam você comparar os resultados e mesclar o vencedor.

Penso nelas como orquestradores de comparação: tentativas paralelas, humano escolhe. São ótimas para explorar variantes de solução rapidamente — mas o humano continua sendo o sistema de qualidade, e a carga de julgamento aumenta com o paralelismo: agora você revisa N saídas em vez de uma.

O Maul Team mira um trabalho diferente: um sistema de entrega. Uma equipe, papéis explícitos, e erros interrompidos pela estrutura — testes black-box, revisões adversariais, gates de merge, regras de escalação — antes que um humano olhe. Paralelismo aqui significa seis agentes avançando seis itens do backlog pela mesma maquinaria de qualidade, não seis rascunhos do mesmo prompt.

Se você quer explorar variantes, um orquestrador de comparação é a ferramenta certa. Se você quer entregar uma construção de vários dias e manter sua carga de revisão constante, você quer governança. Construí a segunda coisa porque a primeira não resolvia o gargalo em que eu estava me afogando.

Loop Engineering — projete os loops, não os prompts

Daqui em diante, isto é para leitores curiosos sobre a maquinaria.

Se eu tivesse que comprimir a filosofia de design do Maul Team em um único termo, seria Loop Engineering. Eu o defino assim:

Prompt engineering improves the instruction.
Context engineering improves what the agent knows.
Loop engineering improves what happens after the agent is wrong.

Agentes vão errar. Então aquilo em que vale a pena apostar, acho eu, não é "esperteza que evita erros", mas "estrutura na qual os erros são detectados, corrigidos e aprendidos". O Maul Team implementa isso como três loops aninhados:

O loop do pipeline de desenvolvimento (por PBI) — design → implementar → testar → revisar, repetido até que as condições de aprovação sejam atendidas. O agente que escreve os testes não pode ler o código-fonte da implementação (black-box), então não consegue escrever testes lisonjeiros. O término não é "o agente diz que está tudo bem" — é decidido mecanicamente por uma composição de condições de sucesso, estagnação, divergência e um teto rígido
O loop do Sprint — depois que todos os PBIs do Sprint são mesclados, o repositório inteiro é auditado. O drift pós-integração que a revisão item a item não enxerga — implementações duplicadas, divergência da especificação, questões de segurança — é detectado e alimentado no backlog do próximo Sprint. As melhorias decididas na retrospective seguem pelo mesmo caminho
O loop de execução autônoma — inicie o Maul Team em modo autônomo e um watchdog externo itera Sprints inteiros rumo ao objetivo do produto. Um agente também ocupa o assento de Product Owner, e toda decisão vai para um log de auditoria. Válvulas de segurança (tetos de iterações, tempo de relógio e falhas consecutivas), recuperação automática de limites de taxa da API e um relatório matinal tornam o "continuou rodando enquanto eu dormia" uma afirmação real e delimitada

Entendo o desconforto de empurrar nessa direção. A cautela em relação à rendição cognitiva — o envolvimento humano se esvaziando à medida que você delega mais — é legítima, acho eu. A resposta do Maul Team é: retire o humano do trabalho braçal, nunca da governança. O julgamento humano se concentra em refinar a visão do produto e em avaliar o que foi construído realmente colocando a mão — e toda decisão é registrada e auditável depois do fato.

Main Screen

Explorer, a conversa com o Scrum Master, o Work Log e o quadro de Sprint/PBI — tudo em uma única janela.

Para quem é — e para quem não é

Para ser honesto, o arcabouço robusto tem um custo: velocidade e consumo de tokens são ambos sacrificados. Prefiro que você saiba disso de antemão e use onde faz sentido.

Combina bem se você:

Já usa o Claude Code
Quer entregar à IA uma construção que leva de meio dia a vários dias
Quer agentes paralelos em worktrees, sem fazer o gerenciamento você mesmo
Não confia incondicionalmente na saída da IA
Quer um registro durável de design, testes, revisões e decisões
Quer tudo rodando localmente — sem entregar seu código a um serviço externo

Não combina bem se você:

Quer um protótipo de um único arquivo agora (o Claude Code puro é mais rápido)
Considera revisão de código e testes desnecessários
Não tem um ambiente ou assinatura do Claude Code
Espera um produto no-code finalizado

Limites, e o que ainda não está pronto

Requer a Claude Code CLI (2.1.172+). Os custos de uso do Claude são à parte
macOS 14+ para o app — um binário universal para Apple Silicon e Intel, assinado e notarizado pela Apple. O framework de CLI também roda em Linux
Ele não garante que a IA esteja certa. Os gates aumentam a taxa de detecção de erros; não a tornam zero
Adotar as formas do Scrum não produz automaticamente um bom produto. Decidir o que vale a pena construir continua sendo trabalho do Product Owner — geralmente o seu
A Codex CLI para cross-review entre modelos é opcional; tudo roda sem ela

Se você experimentar

Baixe o MaulTeam.app, aponte-o para um pequeno projeto existente e rode apenas um Sprint.

🎬 Demonstração de 2 minutos
💻 GitHub — o framework é MIT
✅ Requisitos: macOS 14+ / Claude Code CLI 2.1.172+ / uma assinatura do Claude

Fiquei bastante afeiçoado a isto como meu setup diário de desenvolvimento com IA, então pretendo continuar criando esta equipe por um bom tempo. Feedback e issues são muito bem-vindos.

(Este artigo é uma reescrita em português do meu original em japonês no Zenn.)

Comentários são bem-vindos em inglês ou português.