Time de 3 pessoas envia centenas de PRs por semana com agentes

Como a Kenn faz engenhagem agêntica

Wes McKinney descreve como a Kenn Software, com um time de três pessoas, consegue mesclar centenas de pull requests por semana mantendo taxa de bugs empiricamente baixa em milhões de linhas de código de produção. Ele critica pipelines totalmente autônomos, sem humano no loop - para ele, quem promete agentes rodando em loop uns sobre os outros, com o operador longe do teclado e boa qualidade no final, está desinformado ou vendendo algo. Ao mesmo tempo, admite uso intenso de tokens: seu consumo dos últimos 30 dias custaria US$ 56.836 em tarifas de API, não fosse o subsídio de assinaturas de agentes de código.

Fluxo de trabalho: planejamento, arquitetura e cuidado

A equipe adota a definição de Jesse Vincent, criador do framework Superpowers: a diferença entre “vibe coding” e engenhagem agêntica está em “planejamento, arquitetura e... se importar com o resultado”. A Kenn resume: “vibe coding é não se importar em escala”.

O processo segue etapas bem definidas:

Começar com as ferramentas certas: Superpowers e roborev, sistema próprio de revisão e verificação local contínua.
Projetar em conjunto: o humano participa de todas as decisões importantes de design; gosto e arquitetura não são delegados a agentes.
Pedir segunda opinião: quando há dúvida, uma sessão separada de agente, preferencialmente de outra família de modelo, desafia a decisão antes que ela se consolide.
Escrever a especificação: após fechar o design, o Superpowers gera uma spec precisa, voltada para implementação.
Revisão adversarial da spec: outro agente revisa, problemas são corrigidos e o ciclo se repete até convergir.
Planejar e implementar em pedaços pequenos: o Superpowers cria o plano; a implementação usa subagentes (sobretudo com Claude) ou execução inline (sobretudo com Codex). Commits frequentes validam conformidade com a spec, enquanto o roborev faz verificação assíncrona.
Revisão por branches para caçar bugs: o trabalho dos modelos de fronteira atuais (5.6-Sol e Fable) é descrito como muito desleixado e quase nunca apto para produção sem endurecimento. Em mudanças grandes, a equipe chega a gastar centenas de dólares em tokens para eliminar bugs.
Tornar o trabalho durável: specs e planos não ficam nos repositórios; são convertidos em “documentos de arquitetura vivos”, úteis para humanos e para agentes futuros.
Explicar a mudança, abrir o PR e assumir o merge: agentes digitam e conferem, mas o humano é responsável pelo resultado. Descrições de PR devem ser claras, focadas em resultados, sem “robospeak”.

A “Clanker Constitution”

A equipe chama seus agentes de “clankers” e criou um conjunto de princípios operacionais, mantido no GitHub, para melhorar o comportamento padrão desses agentes. As diretrizes incluem: honrar o pedido (instruções são contrato; revisar não significa editar), agir com julgamento (prosseguir em trabalho seguro e reversível, perguntar só quando a decisão muda o resultado ou é destrutiva; nunca mesclar sem autorização), terminar o serviço, proteger trabalho existente (nunca sobrescrever ou alterar sem permissão), verificar a realidade (testar comportamento real, não mocks; nunca alegar sucesso sem evidência nova), comunicar para humanos (ir direto ao ponto) e aprender no lugar certo (orientações duráveis em arquivos de instrução compartilhados, não em memórias privadas do agente).

Ferramentas próprias

A “stack legada” (GitHub.com, IDEs, terminais crus) se mostrou inadequada para o volume e a concorrência desejados. A Kenn construiu então ferramentas próprias:

Kenn Forge: um “neo-IDE” local com cache dos dados do GitHub, permitindo alternar entre PRs quase instantaneamente, além de melhorias de UX e workspaces de agente inline com um clique.
Ghosthub: terminal especializado em multiplexers (tmux, Herdr, Zellij) e desenvolvimento remoto.
Kata: issue tracker “agent-native”, funcionando como sistema de registro de intenção; um daemon central sincroniza tarefas entre máquinas e agentes via federação.
AgentsView e roborev: “motores de accountability” que monitoram sessões, tokens e a correção do trabalho dos agentes.

Perspectiva

McKinney resume os últimos 12 meses como uma odisseia de tentativa e erro em processos, ajuste de prompts/harnesses e ferramentas customizadas. A Kenn mantém viés por workflows centrados no operador humano, minimizando “code slop” nos repositórios e nunca delegando trabalho crítico a loops autônomos.