Dissemos para Traçar a Linha pelo Raio de Impacto. Alguém Compilou.

Em 18 de julho argumentamos que a linha entre o que a IA decide e o que um humano decide deve ser definida uma vez por classe de ação, por raio de impacto e reversibilidade, e aplicada no harness em vez de rediscutida em reunião. Três dias depois, a Hud publicou quatro receitas de workflow agêntico em um repositório público com licença MIT. A primeira se chama Blast Radius. Ela pontua o raio de impacto de um pull request em produção numa escala de 0 a 100.

Não tivemos nenhuma participação nisso. É justamente o que torna o caso útil. Um argumento que só convence quem o escreveu é uma posição. Um argumento que reaparece de forma independente como código funcionando é um desenho convergindo de duas direções.

A Hud é uma startup em estágio inicial, com US$ 21 milhões levantados, vendendo exatamente a capacidade que essas receitas demonstram. Registre esse viés e leia as receitas mesmo assim, porque elas têm licença MIT e são curtas o bastante para auditar em uma tarde. Dá para ler a lógica de pontuação, discordar de um peso e alterá-lo. É um artefato de outra natureza em relação a uma promessa de governança num deck de fornecedor.

Quatro receitas e o que cada uma decide

O repositório traz Blast Radius, Weekly Report, Dead-Code Cleanup e Rollback Check. Cada uma é um workflow agêntico nomeado, não um prompt de assistente genérico, o que já reduz o espaço do que pode dar errado.

A Blast Radius recebe um pull request e produz uma nota de impacto em produção de 0 a 100. A Dead-Code Cleanup encontra funções com zero invocações e abre um pull request removendo-as, o que só funciona se alguma coisa estiver contando invocações em produção. A Rollback Check avalia um deploy e devolve um veredito.

Essa contagem vem do produto da Hud, que o próprio site nomeia Runtime Code Sensor: “uma nova camada de runtime que roda junto com seu código em produção. Ela detecta erros, degradações de performance e picos de CPU, capturando o contexto forense profundo necessário para gerar agenticamente correções seguras em nível de código.” As receitas se apoiam nessa telemetria. São, na leitura mais direta, uma demonstração de por que você compraria o sensor.

Um número onde deixamos um princípio

Nosso texto apresentou dois eixos e disse para prendê-los a uma classe de ação em código, uma vez. Não disse como é esse ato de prender. Uma nota de 0 a 100 é uma resposta possível, e ela carrega propriedades que um argumento não tem. É comparável entre pull requests. Aceita limiar. Uma mudança de limiar vira um diff com autor e data.

Essa última propriedade é o que liga o repositório ao texto que publicamos hoje de manhã. O prompt de permissão por ação não é um controle, porque chega no instante da ação, mirando quem estiver no teclado, sob a pressão de tempo daquele momento. Uma nota calculada antes do merge e comparada com um limiar definido semanas antes é decidida com antecedência, se aplica a uma classe em vez de uma instância e deixa registro de quem a definiu. Mesma intenção de governança, perfil de falha oposto.

Os pesos também são onde a discordância deveria acontecer. Uma função de pontuação que trata um arquivo de migração e uma mudança de texto da mesma forma está errada de um jeito que dá para apontar com o dedo. Ler os pesos da Hud e rejeitar metade deles é uma hora mais produtiva do que debater se raio de impacto importa.

Cinco vereditos no lugar de um booleano

Em fevereiro argumentamos que rollback automático é necessário e insuficiente, porque um gatilho por taxa de erro avisa que algo se mexeu sem dizer por quê, e reverter em modo binário costuma ser a resposta errada para um sinal legítimo.

A Rollback Check devolve um entre cinco valores: ROLLBACK, INVESTIGATE_OUTBOUND, INVESTIGATE_ENVIRONMENTAL, WARN e CLEAN. Dois desses cinco mandam investigar e nomeiam a direção. INVESTIGATE_ENVIRONMENTAL cobre o caso em que o deploy é inocente e o host, a dependência ou o formato do tráfego mudou por baixo dele. WARN cobre degradação real que fica abaixo do limiar em que alguém reverteria.

Cada veredito encaminha para uma ação humana diferente. É a resposta graduada que nosso texto de fevereiro pediu, expressa como enum em vez de ensaio. Um enum também é testável. Dá para escrever um caso que afirma que um incidente ambiental conhecido produz INVESTIGATE_ENVIRONMENTAL, e vê-lo falhar quando alguém afrouxar a lógica.

O ganho fica na mesa, o custo fica no sistema

A pesquisa de 2025 do DORA, retomada no relatório de ROI de 2026, ordena dez resultados por tamanho de efeito. Efetividade individual aparece em primeiro. Instabilidade de entrega de software aparece em segundo. Throughput aparece em sétimo. Nas palavras do DORA: “O maior efeito foi medido na efetividade individual. O efeito sobre instabilidade foi o segundo maior, maior do que os impactos em performance organizacional, qualidade de código e assim por diante.”

O throughput melhorou. O sumário executivo de 2025 do DORA é explícito: “A adoção de IA agora melhora o throughput de entrega de software, uma mudança relevante em relação ao ano passado. Ainda assim, ela continua aumentando a instabilidade da entrega. Isso sugere que, enquanto os times se adaptam para velocidade, seus sistemas subjacentes ainda não evoluíram para gerenciar com segurança o desenvolvimento acelerado por IA.” A pesquisa por trás disso rodou de 13 de junho a 21 de julho de 2025, com 4.867 respondentes de mais de 100 países, reportada em pesos beta padronizados com intervalos de credibilidade de 89% em vez de percentuais de manchete.

Leia essa ordenação como demonstrativo contábil. O indivíduo recebe o maior benefício. O sistema absorve o segundo maior custo. Uma nota de raio de impacto e um veredito enumerado de rollback são, ambos, controles de instabilidade, o que os coloca exatamente onde mora o segundo maior efeito.

Onde as receitas param

May Walter, cofundadora e CTO da Hud, deu uma palestra em julho descrevendo por que isso é difícil. Agentes de código raciocinam sobre o código no nível de função e arquivo. Métricas de produção vivem no nível de serviço e endpoint. Os dois não falam a mesma língua, e ela chama a ponte entre eles de prod-to-code. Esse enquadramento é dela, falado no palco. A documentação da Hud não registra o termo.

Ela nomeia dois modos de falha que valem a pena independentemente do que você ache do produto. O plausível não verificado é uma correção que soa certa, parece real e não se sustenta quando conferida contra produção. A correção preguiçosa é o agente capturar uma exceção em vez de descobrir por que ela foi lançada. Ambos sobrevivem à revisão de código de um humano cansado.

O time dela deliberadamente não abre pull requests automaticamente: “ninguém quer acordar com, sabe, uma chuva de 80 pull requests, por menores que eles sejam. Não é assim que as pessoas operam.” E sobre quando a autonomia é conquistada: “Se algo funciona 80% das vezes e você está usando com o cursor na sua IDE, tudo bem, porque você está ali, você está em contexto, e consegue ajudar a corrigir e direcionar. Se estamos falando de uma automação que roda de forma autônoma, precisamos ter uma confiança muito alta.”

Esse limiar é o mesmo que traçamos por raio de impacto, alcançado pelo lado de quem opera. A Hud publica um estudo de caso da ZoomInfo afirmando que invocações de lookup de dependências caíram 98% e o pico de memória caiu 62%, o que é o relato do próprio fornecedor sobre o resultado de um cliente, não medição independente, e não altera o argumento do limiar em nenhuma direção.

Faça isto agora

Clone o repositório e leia as regras de pontuação da Blast Radius contra o inventário de classes de ação que você já tem. Se você não tem esse inventário, as regras de pontuação servem como primeiro rascunho dele. Marque cada peso que você mudaria e por quê. O produto dessa hora é a sua própria função de pontuação, e agora ela é sua.

Depois faça a coisa menor e mais valiosa. Encontre o ponto do seu pipeline de deploy em que um booleano decide entre reverter e seguir, e substitua-o por pelo menos quatro vereditos nomeados, cada um encaminhado para um dono nomeado. Você não precisa do sensor de runtime da Hud para isso. Você precisa admitir que “alguma coisa está errada” e “o deploy está errado” são achados distintos que seu pipeline hoje colapsa em um só.

Escrevemos que a linha operacional é construível hoje. Alguém construiu uma versão dela e a entregou sob uma licença que permite auditar o raciocínio. O trabalho que resta é decidir se os números deles são os seus números.

---

Fontes

• Hud. “hud-agentic-workflows-recipes.” Julho de 2026.
• Hud. “Agentic Workflows Recipes.” Julho de 2026.
• May Walter, Hud. “From Blind Spots to Merged PRs.” AI Engineer, julho de 2026.
• DORA, Google Cloud. “The ROI of AI-assisted Software Development.” 2026.
• DORA, Google Cloud. “2025 State of AI-assisted Software Development.” 2025.

A Victorino ajuda times de engenharia a transformar raio de impacto de princípio em controle pontuado e com limiar aplicado no pipeline: contato@victorino.com.br | www.victorino.com.br