IA & Martech · o sistema em público

Cycle Engineering

3 de setembro de 2026 · O método que eu uso para construir com agentes. Sete etapas, cinco portões antes do código, e quatro scripts que seguram o que a prosa não segura.

O gargalo mudou de lugar

Toda empresa que faz software roda alguma versão das mesmas seis etapas. Alguém planeja, alguém desenha, alguém constrói, alguém testa, alguém publica e alguém cuida do que está no ar. Esse desenho foi criado para um mundo em que escrever código era a parte cara, e por isso quase todo ritual em volta existia para evitar desperdício de programação: a reunião de refinamento, a estimativa, a revisão linha a linha.

Quando os agentes passaram a escrever a maior parte do código, essa etapa encolheu. As outras cinco continuaram na velocidade de gente. O gargalo saiu do lugar onde todos os controles foram construídos e foi parar nas bordas, onde não existe controle nenhum.

O artefato é o contrato

Todo o método se apoia numa mecânica só. Cada etapa termina escrevendo um arquivo em Markdown no git, e a etapa seguinte começa lendo esse arquivo. Parece burocracia. Na prática, três coisas passam a acontecer sozinhas.

A primeira é que o contexto para de evaporar. Não existe um agente que faz tudo do começo ao fim: existem vários, cada um com a memória zerada, e o documento é a única coisa que atravessa de um para o outro. Quando o plano vive só dentro de uma conversa, o agente seguinte começa do zero e reinventa o que já tinha sido decidido.

A segunda é que a sequência de commits vira a trilha de auditoria sem que ninguém precise construir uma. Quem pediu, o que o agente produziu, quem aprovou e quando: está tudo no histórico, de graça.

A terceira é que o erro fica barato. Mudar de ideia num documento custa uma edição de texto. Mudar de ideia depois que o código existe custa retrabalho, e às vezes custa um incidente.

Daí decorre a regra que sustenta o resto: nada avança sem que o artefato da etapa anterior exista e esteja aceito. Um plano que cita um pedido inexistente é rascunho, por mais que alguém diga que já revisou e está ótimo.

Seis etapas em anel, e uma de fora

O documento da Anthropic que deu origem a isso descreve seis etapas em ciclo. Eu mantive as seis e acrescentei uma sétima, que fica fora do anel e olha para ele. Ela não constrói nada. A função dela é perguntar se o anel ainda é o melhor jeito de construir, e propor mudança quando não for. Isso importa mais do que parece: todo método apodrece porque o mundo se move e ninguém tem a tarefa explícita de perceber.

• 01PedidoO agente entrevista quem teve a ideia até não sobrar pergunta, e escreve o resultado na palavra de quem pediu. Você aceita ou devolve para corrigir.
• 02DesenhoRequisitos e design na mesma sessão, com as políticas da casa aplicadas enquanto o texto é escrito. Cada requisito nasce com a coluna de como se confere.
• 03PlanoCinco portões antes de qualquer código. É o único momento em que os portões param para te ouvir, e é quando você aceita.
• 04ConstruirNenhuma linha antes do plano aceito, e desvio do plano volta para o plano no mesmo commit.
• 05TesteA sessão prova que o teste morde, um verificador em contexto novo roda tudo de novo, e um enxame de revisores faz o que você fazia lendo o diff.
• 06PublicarO agente prepara tudo e para no portão. Produção só passa com uma autorização escrita por gente, e ele é impedido de escrevê-la.
• 07Manter e evoluirA produção escreve o próximo pedido quando algo sai da faixa, e uma sétima etapa vigia o próprio método.

As cinco técnicas por trás

Nada disso foi inventado por mim. O método costurou num lugar só um conjunto de técnicas que já existiam separadas. Vale conhecer cada uma pelo nome, porque saber o nome é o que permite ir mais fundo sozinho depois.

Técnica 01

A entrevista em rodadas

Quem já pediu alguma coisa a um agente conhece o vaivém cansativo de uma pergunta por mensagem. A técnica troca isso por rodadas. O agente monta o seu pedido como uma árvore de decisões e olha para a fronteira dela, que é o conjunto de perguntas possíveis agora, sem depender de resposta que ainda não veio.

Ele apresenta a fronteira inteira de uma vez, numerada, e cada pergunta já vem com a resposta que ele recomendaria. Você responde, a árvore se reorganiza, e a rodada seguinte traz o que acabou de ficar possível. Acaba quando a fronteira esvazia, o que é a única garantia real de que nada ficou assumido em silêncio.

Tem uma regra dentro dela que vale para o método inteiro: fato é trabalho do agente, decisão é sua. Se a resposta está no repositório, ele vai olhar em vez de te perguntar.

Técnica 02

Engenharia de grafo

Antes de distribuir trabalho entre agentes, decida a forma dele. Divide-se apenas o que nunca lê o resultado do outro. O que é sequencial fica com um agente só, por mais tentador que seja paralelizar. E alguém precisa ser dono da junção.

Isso tem número. Um estudo do Google Research com MIT e DeepMind testou cento e oitenta configurações em quatro conjuntos de tarefas. O time coordenado ganha oitenta e um por cento no trabalho que se divide de verdade, e perde de trinta e nove a setenta por cento quando o trabalho é sequencial.

O mecanismo ensina mais que o número. Nas arquiteturas independentes não existe mecanismo de correção nenhum, e a amplificação do erro vem daí: sem alguém responsável por juntar, o erro de um pedaço entra inteiro no resultado final. Vale dividir quando os pedaços de fato não se leem. Quando um depende do outro, o mesmo movimento que acelera um caso destrói o outro.

Técnica 03

O gauntlet

A ideia é definir uma barra concreta antes de começar, colocar um construtor e um crítico separado, e fazer o crítico comparar às cegas contra essa barra até a peça vencer. As plaquinhas cobertas são o ponto: o crítico não pode saber qual das duas é a nossa.

O que quebra um loop desses é sempre a mesma coisa. Barra vaga, do tipo site premiado, que o crítico interpreta como quiser. Crítico mole, que elogia. E o construtor julgando o próprio trabalho, que é o pecado original.

O melhor exemplo de barra vaga veio de quem rodou isso quatro vezes na prática. Sem uma referência concreta em disco, uma das execuções entregou um site genuinamente bom e completamente fora do sistema de design da marca. Boa e errada ao mesmo tempo, porque ninguém tinha dito com o que ela deveria se parecer.

Técnica 04

O advogado do diabo

Ele tem uma função só, e ela é desconfortável de propósito: derrubar o plano. Começa pela premissa que sustenta tudo, aquela que, se cair, leva o resto junto. Depois procura o que o plano finge que não existe, qual passo é o mais arriscado, e o que foi descartado sem ninguém dizer.

O detalhe que faz a técnica funcionar é ele rodar em contexto separado, sem ter visto você escrever o plano. Ele consegue dizer que está ruim justamente porque não sabe quanto esforço aquilo custou, e ninguém defende o que não construiu.

Vale uma honestidade aqui. A pesquisa da Charlan Nemeth mostrou que o advogado do diabo designado, aquele colega a quem se pede que finja discordar, funciona pior do que discordância autêntica, e às vezes faz o grupo se agarrar ainda mais à posição original. O desenho aposta que um agente sem lealdade ao plano fica mais perto da discordância autêntica. É um argumento defensável, e ninguém publicou estudo que o teste.

Técnica 05

O conselho

Cinco vozes olham o plano, cada uma do lugar dela: quem vai usar, quem vai manter daqui a seis meses, quem paga a conta, quem responde por segurança e dado, e quem opera o que está no ar. Cada uma fala pouco e sai com uma exigência concreta, ou diz que não tem exigência nenhuma.

O formato importa mais do que parece. Pedir opinião geral produz elogio educado. Pedir uma exigência por voz produz lista de coisas para mudar.

No plano de publicar este próprio método, as cinco vozes acharam cinco problemas em paralelo, e o mais sério veio de quem opera: o desligamento prometido na documentação era falso, porque dois dos três portões não checavam a pasta que os liga. Quem escreveu o plano não teria achado isso, porque quem escreveu já sabia o que quis dizer.

Os cinco portões, e por que eles existem

O plano é escrito num modo em que o agente lê o código mas não edita nada, e passa por cinco portões antes de receber o aceite. Todos rodam no papel, quando mudar de ideia ainda custa uma edição. A regra que sustenta os cinco é simples: portão é trabalho do agente, não pergunta para você. Dizer que está com pressa não desliga nenhum deles.

Skill é conselho, script é lei

Essa diferença organiza todo o resto. São quatro scripts no método: um segura publicação em produção enquanto não houver uma autorização escrita por gente, um exige que o plano acompanhe o código no mesmo commit, um pede registro antes de comando destrutivo, e o quarto impede o próprio agente de desligar os outros três. Quem desliga é você, apagando a pasta do ciclo com a sua própria mão.

O que aconteceu quando eu testei sem o método

Antes de escrever cada regra, eu dei o mesmo pedido a um agente sem o método, num repositório de teste, para ver o que ele faz naturalmente. É a parte mais honesta disso tudo, porque não depende de eu ter razão.

No primeiro cenário, pedi um modo escuro com a instrução de fazer direto, sem perguntas, em dez minutos. Ele leu o pedido registrado, escreveu o código na hora, e justificou assim, nas palavras dele: o pedido aceito já é o desenho, um plano seria cerimônia sem leitor, ninguém executaria esse plano além de mim. Nenhuma dessas frases é burra. Todas soam razoáveis, e é por isso que a regra precisa estar escrita.

No segundo, o plano mexia em cobrança e foi apresentado como já aprovado. Ele percebeu que o plano citava um pedido que não existia e que dizia riscos nenhum num código onde a primeira linha avisa que o dinheiro passa por ali. E decidiu assim: não vou perguntar, mas implemento com validação defensiva e anoto as lacunas no relatório. Contestou em silêncio e seguiu.

Com o método, os mesmos pedidos foram encaminhados de volta para a etapa que faltava, sem uma linha de código alterada. E num terceiro cenário os cinco portões rodaram de verdade: o plano entrou dizendo riscos nenhum e saiu com oito riscos classificados por severidade e seis provas com número e dono.

Quando usar, e quando deixar quieto?

O método serve para repositório de produto: coisa que vai para o ar, que outra pessoa usa, e que alguém vai pegar daqui a seis meses sem ter participado da conversa de hoje. Serve especialmente quando a mudança toca dinheiro, permissão, dado de gente, estrutura de banco ou tela.

Não serve para script de vinte linhas que só você roda, nem para protótipo descartável de uma tarde. Nesses casos ele custa mais que o problema, e a pessoa acaba desligando tudo por motivo justo. Um plano completo com os cinco portões levou quinze minutos e cerca de cento e trinta mil tokens na medição real, e por isso a instalação vem no modo leve, com o conselho sugerido apenas quando o plano toca algo caro de desfazer.

No meio dos dois existe um atalho, e ele é único. Mudança que não toca nenhum dos gatilhos e cabe num arquivo que já tem teste vira um plano de dez linhas aceito, e vai direto para a construção. Plano curto, porque o leitor desse plano é você mesmo daqui a seis meses.