Reverificação IA-sobre-IA: O Harness Aterrissa na Resposta a Incidentes

Há uma frase no post da incident.io sobre rodar um incidente com o AI SRE que carrega mais peso do que a prosa sugere. O autor descreve postar a remediação proposta pelo Claude Code de volta no canal do incidente e então comenta, quase de passagem, que “tudo que você faz no Claude e posta no canal é reverificado pelo AI SRE. Se você cometeu um erro ou esqueceu algo, ele vai te alertar.”

Esse é o padrão. Segure-o.

O agente investigador está checando o agente que conserta. Uma IA está lendo a saída da outra e devolvendo objeções. O humano permanece no loop como a parte que afirma, mas a etapa de verificação, que é a primeira a evaporar às 2 da manhã, fica preservada por um modelo diferente daquele que escreveu o conserto.

Já escrevemos sobre o harness como a diferença entre agentes que funcionam e agentes que derivam. Já escrevemos sobre por que monitorar agentes em escala exige instrumentação diferente e sobre o stack de contenção de quatro andares que o time de plataforma precisa ter de pé. O AI SRE é o primeiro produto que vimos a nomear, em voz alta, o próximo padrão: reverificação IA-sobre-IA, lançada na resposta a incidentes.

Merece uma leitura cuidadosa, com as ressalvas mantidas honestamente.

O Que a incident.io de Fato Construiu

O post descreve um único incidente real, rodado mais ou menos no seguinte formato. O Slack notifica o engenheiro de plantão. O AI SRE já começou uma investigação paralela: examina deploys recentes, telemetria, taxas de erro, incidentes passados no mesmo perímetro, o código relevante e o contexto do canal no Slack. O app desktop para macOS exibe o status do incidente na notch — presente sem ser intrusivo. O engenheiro fixa o incidente, abre o Claude Code e roda /incident, que sincroniza os achados do AI SRE para dentro da sessão de codificação. O Claude Code rascunha uma remediação. O Claude posta a ação proposta automaticamente no canal do incidente; o engenheiro não troca de janela para narrar no Slack. O AI SRE lê o post e reverifica. O PR é aberto e mergeado. A resolução, escreve o autor, “levou minutos” — a maior parte deles esperando o deploy.

Releia. A novidade estrutural não é a velocidade nem o fluxo de chat-para-PR. A novidade estrutural é que o agente que investiga o incidente não é o mesmo agente que propõe o conserto, e o investigador tem a última palavra sobre se o conserto bate com o diagnóstico.

Essa é uma separação de responsabilidades que a maioria dos fluxos de IA em produção não tem. Em arranjos de agente único, o mesmo modelo que decide o que está errado também decide o que mudar. Erros se compõem em silêncio. O loop de reverificação força uma passagem de bastão explícita: a saída do que conserta vira entrada do que investiga, e o investigador já estava ancorado na telemetria de fato, não na narração que o Claude faz da telemetria.

Por Que Isso É o Padrão de Harness, Não Teatro Multiagente

Demos multiagente são ambientes em decks de fornecedores há dois anos. A maioria é teatro: agentes conversando com outros agentes num grafo, sem nenhuma redução real de modos de falha, frequentemente com mais modos de falha porque cada nova chamada de modelo é mais uma chance de alucinar. A reverificação IA-sobre-IA parece similar de longe e é estruturalmente diferente de perto.

Três propriedades a separam do teatro.

Primeiro, o verificador é ancorado em contexto independente. O AI SRE olhou para deploys, telemetria e histórico de incidentes antes de o Claude Code escrever qualquer coisa. Ele não está revisando o raciocínio do Claude; está checando a saída do Claude contra uma verdade construída de forma independente. O equivalente arquitetural é a diferença entre revisão de código feita por alguém que leu o spec e revisão feita por alguém que só leu o diff.

Segundo, o humano mantém autoridade de decisão por desenho. O fluxo não é “IA propõe, IA executa”. É “IA propõe, IA checa, humano afirma, depois executa”. O Claude pergunta ao engenheiro “quer que eu faça o commit e abra um PR?” O engenheiro diz sim. O AI SRE já fez sua revisão antes desse sim acontecer. O humano não é redundante; o humano é o botão de merge.

Terceiro, a verificação é preservada justamente quando humanos a pulariam. Às 2 da manhã, com receita queimando, um engenheiro que acabou de ver o Claude gerar um patch plausível não vai rodar 30 minutos de revisão. Vai mergear. O loop de reverificação substitui a revisão que o humano não consegue fazer naquela hora pela revisão que outro agente consegue. Esse é o trabalho real do padrão de harness: fazer a disciplina sobreviver ao momento em que disciplina é mais cara.

Já argumentamos antes que o harness é o que separa “usamos agentes de IA” de “operamos agentes de IA”. Esta é a forma operacional.

As Ressalvas Honestas

Este não é um produto lançado. A própria incident.io diz, com todas as letras: “ainda não lançamos completamente” — a UX ainda está em refinamento. O post é uma narrativa da empresa sobre a própria experiência interna. Não é uma referência de cliente, não é um benchmark, não é um relatório de terceiros.

O “levou minutos” não é um número de MTTR. É uma anedota, com a maior parte do tempo gasto esperando uma pipeline de deploy. Não há modos de falha documentados, não há discussão de casos de borda, não há casos em que o AI SRE deixou passar algo que o Claude Code errou, não há casos em que ele alertou sobre um falso positivo e adicionou ruído. O autor sinaliza que o time está “priorizando correção sobre velocidade”, que é a prioridade certa e também a resposta que se dá quando velocidade ainda não chegou onde se quer.

Nada disso desqualifica o padrão. Deixa claro o que está sendo afirmado. O padrão é real e nomeado. O produto que o implementa está nas etapas finais de estar pronto para vender.

O Que Muda para Líderes de SRE e Plataforma

Se você opera resposta a incidentes, três coisas acabaram de se mover.

Você consegue nomear o que está comprando. “Reverificação IA-sobre-IA” agora é uma expressão com uma implementação de referência. Quando um fornecedor faz pitch de “IA para incidentes”, a pergunta deixa de ser “isso ajuda?” e passa a ser “onde está a etapa de verificação, e o verificador está ancorado em algo além da saída do que conserta?” Se a resposta for “o mesmo agente investiga e propõe”, você está olhando para automação de agente único, não para o padrão de harness. Categoria diferente, perfil de risco diferente, provavelmente preço diferente.

A fronteira da autoridade de decisão está virando uma superfície configurável. IA propõe, humano afirma é o padrão seguro. IA propõe, IA checa, humano afirma é o padrão defensável para operações de alto risco. IA totalmente autônoma propõe e executa é uma terceira categoria que o mercado ainda não acomodou em resposta a incidentes, e provavelmente não acomodará nos próximos dois anos. Saber em qual modo você opera, em qual classe de incidente, é a nova decisão de política.

O harness está virando uma decisão de construir-ou-comprar. Times internos vêm fazendo reverificação na mão: uma segunda chamada de modelo relendo a saída do primeiro, talvez com um system prompt diferente. O AI SRE é o primeiro produto a transformar o verificador em um agente separado, ancorado em telemetria independente. Se o lado “comprar” dessa questão está em vôo na sua organização, este é o momento de olhar o que já saiu antes de terminar de construir.

O padrão não está pronto. O padrão está nomeado. Nomear é o que torna uma categoria comprável, e uma vez que uma categoria é comprável, os próximos dois anos de operação de IA serão discutidos nesses termos, com ou sem a adoção do seu time.

Fontes

How It Feels to Run an Incident with AI SRE — incident.io, abril de 2026.

A Victorino ajuda líderes de SRE e plataforma a desenhar padrões de reverificação IA-sobre-IA, em que a saída de um agente vira entrada de outro — sem perder a autoridade humana de decisão: contato@victorino.com.br | www.victorino.com.br