SHIFT, cinco meses depois: a história de uma frota que virou outra coisa

Hoje, se você abrir um pull request em quase qualquer repositório da CERC, poucos minutos depois um agente já deixou comentários nele. Ninguém o chamou. Ele tem um nome, uma “alma” configurada, um modelo próprio — e um lugar num escritório em pixel art onde você pode vê-lo, ao vivo, sentar na mesa, digitar, tomar um café quando está ocioso e soltar confete quando termina.

Em fevereiro, nada disso existia. O SHIFT era um único container rodando no notebook de alguém, que mal conseguia abrir um PR sem apanhar no caminho.

A distância entre essas duas frases é a história deste post. E o mais interessante é que quase nada dela estava no plano.

O sonho que a gente lançou

A ideia original era limpa e, confessamos, um pouco romântica: você descreve uma tarefa em português, um agente entende, clona o repositório, escreve o código e te devolve um pull request pronto para revisão. O herói do produto era o agente que escreve. Era isso que a demo mostrava, era isso que nos deixava sem dormir de empolgação.

Por trás disso havia uma aposta mais séria, que chamamos de mentalidade shift-left: para um agente entregar algo bom, a pessoa que descreve a tarefa precisa pensar melhor — decompor o problema, ser clara na intenção, antecipar dependências. A promessa não era só automatizar código. Era que, ao aprender a conversar com a máquina, o engenheiro ficasse mais engenheiro.

Esse era o roteiro. O que se seguiu foi a coisa aprendendo a andar sozinha e, no caminho, escolhendo ser bem maior do que a gente imaginou.

A linha do tempo, em seis saltos

Seis meses, cerca de 30 mil tarefas, dezenas de pessoas, centenas de repositórios. Mas os números só ganham sentido quando você conta o que aconteceu entre eles.

Um elenco, não um agente

Por um bom tempo, todo o comportamento do agente vivia num único script de umas quinhentas linhas. Funcionava, mas era um monólito — mudar uma coisa arriscava quebrar três. Em vez de continuar remendando, reescrevemos aquilo como um sistema modular. E, junto, nasceu o conceito que mudou como pensamos a plataforma: os Shifties.

Um Shifty é a “alma” de um agente — um nome, um prompt, um modelo, um conjunto de ferramentas e um jeito de entregar. Em vez de um agente genérico, passamos a ter um elenco. E o elenco cresceu depressa:

• um desenvolvedor que implementa features e corrige bugs abrindo PRs — em um ou em vários repositórios de uma vez;
• uma bancada de revisores — do generalista ao especialista de domínio, passando por um focado em QA e testes;
• um gerador de documentação multi-repositório, que cruza vários repositórios e transforma testes de contrato em documentação navegável e unificada;
• um triador de Jira que lê e classifica tickets de um domínio de negócio sem sequer clonar repositório;
• um corretor de workloads Kubernetes que ajusta recursos e HPA a partir das recomendações do KRR, e um analisador multi-repositório que enxerga uma mudança cruzando vários serviços;
• um especialista em remediação de segurança que varre os repositórios atrás de configurações inseguras — política de SSL/TLS ausente ou mal configurada em charts Helm e falta de Subresource Integrity (SRI) em scripts e folhas de estilo de origem externa — e abre PRs com a correção: calcula os hashes SRI, força HTTPS e habilita a política de SSL onde ela falta.

Dois traços atravessam o elenco. Quase todos são multi-repositório — uma única tarefa pode clonar e trabalhar em vários repositórios ao mesmo tempo, algo que o gerador de documentação usa o tempo todo para montar uma visão unificada a partir de código espalhado por serviços diferentes. E alguns são harness-specific: trazem o próprio conjunto de ferramentas e configuração, clonado antes da tarefa, para se especializarem ainda mais.

Hoje são cerca de quinze desses, e a lista continua. Alguns nasceram na interface, foram usados por uma equipe, deram certo, e viraram parte do catálogo. De um único trabalhador anônimo, o SHIFT virou uma equipe com especialidades.

E, porque uma equipe merece um lugar para trabalhar, construímos The Office — um escritório 2D, visto de cima, em pixel art, renderizado à mão num canvas. Não é enfeite: é observabilidade disfarçada de brinquedo. Cada agente ativo entra pela porta, senta numa mesa e digita enquanto trabalha; solta um balãozinho de pensamento quando raciocina; vagueia até o sofá, o café ou o bebedouro quando fica ocioso; fica cabisbaixo quando dá erro; comemora com confete quando conclui. A aparência de cada um é determinística, então você aprende a reconhecer os “colegas” de longe. Num dia movimentado, um gerente bate o olho no escritório e entende o estado da operação inteira num segundo. (Sim, ele tem modo Copa do Mundo com a bandeira do Brasil e, na época, ganhou decoração de Carnaval. Trabalhar com agentes não precisa ser sisudo.)

Plugado no ecossistema

O salto de algumas centenas para milhares de tarefas por mês não veio de mais gente clicando “criar tarefa”. Veio de o SHIFT deixar de ser um site que você visita e virar um serviço com o qual outros sistemas conversam.

Hoje uma tarefa pode nascer de muitos lugares:

• da interface web, quando uma pessoa descreve o que quer;
• de webhooks do Azure DevOps, a cada pull request aberto;
• de webhooks do Jira, a cada ticket que precisa de triagem;
• de chamadas diretas à nossa API interna por outros serviços — por exemplo, a conta de serviço do datagov (governança de dados) disparando tarefas, ou o portal de SRE, que aciona automaticamente a correção de workloads;
• exposto de forma controlada via Apigee, nosso gateway de API, para que integrações externas ao cluster também alcancem a plataforma com segurança;
• de agendamentos, para o que precisa rodar sozinho de tempos em tempos.

O agente deixou de ser algo que você usa e passou a ser algo que participa. Ele responde a eventos, é chamado por máquinas tanto quanto por gente, e se encaixa no fluxo de entrega em vez de ficar ao lado dele.

No mesmo espírito de “se integrar a tudo”, o SHIFT também aprendeu a rotear o Claude pelo Databricks AI Gateway, usando a identidade da própria infraestrutura no GCP — sem nenhum segredo estático guardado em lugar nenhum. Onde faz sentido, o motor de raciocínio dos agentes passa pela plataforma de dados que a empresa já usa, em vez de uma integração paralela.

E, para dar conta de enxergar tudo isso, movemos a parte analítica para o BigQuery. Não por moda: quando a frota passa de milhares de execuções por mês, você quer perguntar coisas como “quanto cada time gastou”, “qual Shifty roda mais”, “como o volume evolui” — e obter a resposta numa query só, sobre todo o histórico, em vez de varrer coleção por coleção. Os dashboards que sustentam este post inteiro saem daí.

Governança: liberdade com guarda-corpos

Uma plataforma que qualquer pessoa — e qualquer serviço — pode acionar, rodando modelos que custam dinheiro real em repositórios de produção, não pode ser um vale-tudo. Boa parte do trabalho dos últimos meses foi menos glamourosa que criar agentes: foi construir os guarda-corpos que tornam seguro deixar a frota crescer.

Nada disso é acessório. Numa registradora, controle e rastreabilidade são parte do produto: saber quem gastou o quê, com qual modelo e em qual repositório é o que permite dar autonomia sem perder o pé. A governança não freia a adoção — é o que deixa a gente acelerar sem medo.

A revisão que ninguém pediu

Todo pull request aberto na CERC passa por uma revisão automática. Não uma amostra, não um opt-in: 100% dos PRs, poucos minutos depois de abertos, sem que ninguém precise pedir.

E sem atrito no dia a dia. O agente lê o PR em paralelo, deixa os comentários e some — o autor segue seu fluxo normal, agora com um par de olhos a mais que nunca cansa nem esquece. O efeito é duplo: a barra de qualidade sobe para toda a engenharia, de graça, e problemas são identificados cedo — muitas vezes antes de chegarem à produção. Não vamos entrar nos detalhes do que ele encontra, mas o valor não é sutil.

E não é uma revisão rasa, de uma vez só. Ela é iterativa e contextualizada: a cada nova versão do PR, o agente olha o diff entre as branches — o que de fato mudou — e lê todo o histórico de comentários e revisões anteriores daquele PR. Ele não repete o que já foi dito, acompanha se o que apontou antes foi de fato resolvido e ajusta a conversa à medida que o código evolui. É mais perto de um revisor humano que acompanha o PR do começo ao fim do que de um linter que dispara e esquece.

E aqui está a maior surpresa dos cinco meses: o herói que a gente projetou era o agente que escreve código. O que mais entrega, no fim, é o que revisa — calado, incansável, em todo pull request.

O modelo mais barato que ficou melhor

Aqui está uma lição que mexeu com nossos instintos.

No começo, o padrão era usar o modelo mais forte — e mais caro — para tudo, na suposição confortável de que qualidade vinha do modelo. Conforme o volume crescia, a conta crescia junto, e ficou claro que essa suposição precisava ser testada. Colocamos o Haiku 4.5 como padrão da maioria das tarefas esperando o pior: um recuo de qualidade em troca de economia.

Não foi o que aconteceu. A qualidade subiu.

O motivo é meio constrangedor: para fazer um modelo menor brilhar, fomos obrigados a finalmente escrever prompts decentes — instruções mais claras, estrutura melhor, regras de execução mais rígidas. Tínhamos passado meses pagando por cavalos de potência de um modelo caro para compensar prompts preguiçosos. Quando o prompt melhorou, o modelo barato passou a entregar tão bem quanto — em vários casos, melhor, porque instruções afiadas produzem revisões mais consistentes que um modelo poderoso lendo um pedido vago.

O resultado apareceu direto na conta: o custo por tarefa caiu cerca de 45% enquanto o volume seguia subindo. A alavanca mais barata nunca foi o modelo. Sempre foi o prompt — a gente só descobriu isso quando o orçamento nos obrigou a olhar.

A virada de verdade é na cabeça

Se há uma coisa que cinco meses ensinaram, é que a parte difícil nunca foi a tecnologia. O modelo, no fim, é o pedaço estável da equação — o que menos deu trabalho. A parte difícil, a que ainda estamos no meio, é a mudança de mentalidade.

Colocar um agente para automatizar uma tarefa que já existe é o movimento óbvio — e o menos interessante. Automatizar o processo velho só te dá o processo velho um pouco mais rápido. A pergunta que o SHIFT nos obriga a fazer é outra: se um agente pode assumir uma parte disto, como eu redesenharia o trabalho inteiro? Não é encaixar um agente no fluxo de ontem. É olhar para o fluxo de ontem e perguntar se ele ainda deveria existir.

Quando isso acontece de verdade, o gargalo se desloca. Deixa de ser digitar código e passa a ser pensar com clareza — decompor o problema, definir o certo, escrever a especificação que um agente (ou um humano) consegue executar sem adivinhação. É a mentalidade shift-left saindo do slide e entrando na rotina, só que por um caminho que não tínhamos previsto: não foi o engenheiro que mudou para falar com a máquina; foi o trabalho que precisou ser repensado para caber num mundo com máquinas capazes.

Por isso a nossa aposta, daqui pra frente, é tanto de cultura quanto de código. A plataforma é a parte fácil. O difícil é o resto: educar as pessoas para usar IA bem, criar a segurança para questionar o jeito de sempre, e empurrar — com carinho, mas empurrar — cada time a reimaginar seus fluxos em vez de só acelerá-los. A vantagem competitiva não vai ficar com quem tem o melhor modelo; todo mundo vai ter acesso aos mesmos modelos. Vai ficar com quem tiver a coragem de redesenhar como trabalha.

E isso é desconfortável, de propósito. Repensar a forma de trabalhar significa abrir mão de hábitos que funcionavam. Mas é exatamente aí que está o valor — e é para lá que estamos levando a energia da CERC: menos em ferramentas mágicas, mais em gente e cultura, que é onde a mudança de verdade mora.

O que a gente aprendeu, de verdade

Construir o agente foi o fim de semana. Criar a frota foi o trabalho. O que consumiu a engenharia de verdade não foi o modelo — foi tudo em volta: dar personalidade e propósito a cada agente, plugá-los em cada canto do ecossistema, ver a operação inteira de relance, pagar por dezenas de milhares de execuções sem que a conta escale junto, e — a parte mais difícil — ajudar as pessoas a repensar o próprio trabalho.

Projetamos uma fábrica de pull requests e operamos um ecossistema. Achamos que o herói seria quem escreve; foi quem revisa, incansável. Assumimos que qualidade vinha do modelo mais caro; ela veio do prompt mais claro. E imaginamos uma ferramenta que amplificaria pessoas; o que ela mais amplifica, no fim, é a necessidade de repensar como as pessoas trabalham.

A frota continua crescendo, mais rápido do que a gente planejou. O trabalho, daqui pra frente, é o mesmo de sempre em engenharia de plataforma — mantê-la barata, integrada e confiável — só que agora com colegas de pixel art, e com a certeza de que a próxima grande evolução vai ser menos sobre a máquina e mais sobre nós.

Este post foi escrito por: Allan Martins | COE - Arquitetura.