Victorino — Reflexões

A Cloudflare Nomeou o Cargo Que Não Sobrevive à IA: Medidores

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Em maio de 2026, a Cloudflare cortou 1.100 funcionários. Primeira demissão em massa nos 16 anos de história da empresa. O número da manchete não é o que importa. O rótulo que Matthew Prince colou nas pessoas demitidas é.

Ele os chamou de “medidores”. Média gerência. Financeiro. Jurídico. Auditoria interna. Reconhecimento de receita. Funções cujo produto de trabalho é a verificação do trabalho de outra pessoa.

É a primeira vez que um CEO de big tech nomeia coordenação como a camada cortável quando a IA absorve execução. O enquadramento pesa mais do que a demissão. Toda apresentação de board nos próximos dois trimestres vai pegar emprestada a palavra. Todo CFO vai perguntar quais centros de custo caem sob a nova taxonomia. A pergunta que vale brigar não é se medidores devem ser cortados. É o que entra no lugar, porque execução de IA sem supervisão equivalente à do medidor é o modo de falha que ninguém ainda está precificando.

O que Prince de fato disse

O autor do Hackyexperiments capturou a retórica com clareza: “Um fundador que corta 20% escreve um artigo no Wall Street Journal e é chamado de corajoso.” O mesmo autor argumenta que “uma empresa de 5 a 10 pessoas começando hoje pode, de forma crível, enfrentar incumbentes com milhares”. E a afirmação técnica embaixo da filosofia: a variância de produtividade de engenheiros agora é “diretamente mensurável via uso de tokens”.

Três movimentos aninhados nessas frases. Cada um é uma tese que vimos circulando há um ano.

Primeiro movimento: o custo de tocar uma empresa caiu o suficiente para que a camada de medição seja a camada mais cara que sobra. Engenheiros entregam mais código por hora. Designers iteram mais rápido. Atendimento processa mais tickets por agente. O gargalo virou a turma cuja função era confirmar que essas coisas aconteceram certo.

Segundo movimento: a IA tornou a camada de execução auditável em formato legível por máquina. Uso de tokens. Rastreabilidade no nível de commit. Passes automáticos de revisão. A função “medidor” era uma gambiarra para não ter essa telemetria. Quando a telemetria existe, o headcount construído para compensar a ausência dela vira opcional.

Terceiro movimento: cortar essa camada agora é vitrine, não confissão. O enquadramento cultural saiu de “tivemos que demitir” para “nos reestruturamos em torno da IA”. Prince é o primeiro CEO de big tech a publicar o novo vocabulário em voz alta.

Por que essa taxonomia vai se espalhar

CIOs e CFOs queriam essa linguagem há dois anos. Conseguiam ver o custo. Não conseguiam ver a coorte. O organograma não tinha uma linha rotulada “pessoas que medem outras pessoas”. Prince acabou de desenhar a linha. Quando a linha existe, ela pode ser reorganizada, reduzida ou substituída. É assim que linguagem operacionaliza mudança.

Espere o termo nas calls de resultado em um trimestre. Espere a McKinsey reempacotar em deck em dois. Espere uma peça da Harvard Business Review com matriz 2x2 no quarto trimestre.

O risco não é a linguagem. O risco é a suposição que vem embaixo. A suposição é que medição é overhead. Essa suposição está pela metade errada.

O que os medidores de fato faziam

Tire a política do organograma e olhe para as funções. Auditoria interna pega erros materiais antes do regulador. Reconhecimento de receita mantém a empresa fora da lista de restatement. Revisão jurídica garante que os acordos assinados não custem dez vezes o valor do contrato quando algo quebra. Aprovações financeiras são a diferença entre um SOX 404 limpo e um pesadelo na Seção 302.

Isso nunca foi overhead de coordenação. Era supressão de passivo. A função medidor era o firewall humano entre a empresa e as consequências da execução sem checagem. A IA não elimina esse firewall. Muda do que ele é feito.

Essa é a parte do enquadramento de Prince que se perde na tradução. Ele não disse “não precisamos mais de supervisão”. Disse “não precisamos mais dessa quantidade de humanos fazendo essa supervisão”. Não são a mesma frase. A primeira é uma estratégia. A segunda é uma realocação de força de trabalho. Boards que leem as duas como idênticas estão comprando o segundo risco em tamanho.

O que substitui o headcount de medidor

Três peças de maquinaria, em ordem. Cada uma corresponde a uma função que a camada demitida fazia manualmente.

Verificação contínua de controles. O que a auditoria interna amostrava trimestralmente, a instrumentação agora lê em toda transação. Controles afirmam. Anomalias escalam. O comitê de auditoria recebe um painel com timestamp de frescor, não uma pasta seis semanas depois do fechamento do trimestre. Ferramentas como AuditBoard, Workiva e a suíte SAP GRC se moveram nessa direção em 2025. O trabalho que resta não é capacidade; é disciplina de implementação.

Política como código na camada de agente. Todo agente de IA que age em sistemas da empresa carrega a regra que autoriza a ação. A regra é versionada, testada e citável quando o auditor pergunta. É o que a Cloudflare demonstrou na implantação da pilha interna na escala de engenharia. A mesma arquitetura precisa se estender para financeiro, jurídico e operações, que é a lacuna sobre a qual escrevemos em o déficit de ferramental de governança fora da engenharia.

Revisão de sinal no ritmo humano. O que a máquina sinaliza tem que pousar numa mesa humana com contexto suficiente para agir em horas, não semanas. Isso não é overhead de coordenação. É o novo papel de medidor. Menos pessoas, fazendo a deliberação que a automação não consegue fazer, em casos que a automação escala corretamente. A matemática é aproximadamente um revisor humano para cada quinze a vinte que a função manual exigia, com base nos benchmarks de automação de SOX em serviços financeiros já em circulação.

Uma empresa que corta o headcount sem construir as três peças não está mais enxuta. Está rodando com o detector de fumaça desligado.

O problema dos dois relógios que isso expõe

Escrevemos sobre o problema dos dois relógios do CEO na força de trabalho este ano. O anúncio da Cloudflare colapsa os dois relógios num único momento de decisão.

Relógio um é o relógio trimestral de custo. Headcount é a maior linha. Cortar medidores aparece no próximo ciclo de resultados. A pressão para agir no relógio um é imediata e visível para toda board.

Relógio dois é o relógio de acúmulo de passivo. Controles que erodem silenciosamente produzem fraquezas materiais que afloram dezoito a trinta e seis meses depois. O custo é enorme e a atribuição é nebulosa. A pressão para agir no relógio dois é invisível até o auditor encontrar o problema.

CEOs que só precificam o relógio um vão ganhar um trimestre de margem e três anos de risco de restatement. CEOs que precificam os dois vão reduzir headcount e entregar a instrumentação de controle no mesmo trimestre. O segundo caminho é o que o enquadramento de Prince deveria convidar. A maioria das empresas vai ouvir só a primeira metade da frase.

O que fazer nos próximos 90 dias

O enquadramento de Prince vai estar em toda reunião de board antes de julho. Saia na frente.

Primeiro, mapeie a superfície de medidores. Para cada função de negócio (financeiro, jurídico, auditoria, compliance, revenue ops, sales ops, marketing ops), liste os produtos de trabalho cuja finalidade é verificação, não produção. Essa lista é a coorte que o novo vocabulário vai mirar. Saber antes da board perguntar é o ganho barato.

Segundo, desenhe a arquitetura de substituição função por função. Onde a verificação contínua de controles precisa morar. Onde a política como código precisa se estender. Onde fica a fila do revisor humano e quem ocupa. Faça isso em duas semanas. Não em um ano. O custo de não ter resposta quando a pergunta chega é uma resposta forçada que ignora o relógio dois.

Terceiro, escolha a sequência. Corte headcount só depois que a instrumentação que o substitui estiver em produção. Empresas que invertem a sequência vão pagar a multa de auditoria em 2027 e a multa de restatement em 2028.

A Cloudflare nomeou o cargo. O trabalho de substituição é o que os próximos doze meses pedem. Não confunda o anúncio com a estratégia.

Fontes

Hackyexperiments. “The Revenge of The Measurers.” Maio de 2026.

A Victorino apoia times de liderança no redesenho da maquinaria de supervisão que sobrevive ao corte dos medidores, trocando headcount de coordenação por instrumentação de governança que escala: contato@victorino.com.br | www.victorino.com.br

Rand Fishkin Acabou de Matar o 'Faça Conteúdo Bom.' O que Sobra é Produto Inimitável.

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Rand Fishkin passou vinte anos dizendo a profissionais de marketing para fazer conteúdo bom. Em 25 de maio de 2026, ele publicou um texto pedindo para pararem.

A peça se chama “Inimitable Product is the New ‘Make Great Content’” e saiu no sparktoro.com com uma previsão silenciosa do próprio autor: menos de 5.000 visitas, menos de 500 vindas de busca. Fishkin, que construiu a Moz sobre a premissa de que conteúdo de qualidade conquista distribuição durável, agora espera que o fundador do SEO moderno seja ignorado pelo canal que ele ajudou a construir. A forma como ele descreve as plataformas não tem sentimentalismo: “Vamos arruinar a Internet.”

Essa frase merece ficar isolada por um instante, porque reenquadra um debate que o marketing vem tentando suavizar há dois anos.

O que Fishkin de fato matou

O conselho “faça conteúdo bom” funcionava sobre um modelo. Você escreve algo útil. Os buscadores encontram. Os leitores clicam. Alguns compram. O artefato (o post, o relatório, o explicador) era o fosso porque o tráfego que ele gerava se acumulava.

A busca por IA quebrou o modelo na camada do artefato. ChatGPT, Perplexity, Gemini e os próprios AI Overviews do Google agora leem o conteúdo, resumem e respondem ao usuário sem mandar o clique. Fishkin chama isso de dilema do prisioneiro: todo publisher precisa permitir indexação ou perde visibilidade, e o ato de permitir indexação ensina o sistema a tornar o publisher redundante. O artefato é absorvido. O tráfego não volta.

A substituição que ele propõe é o que chama de produto inimitável. Os exemplos são deliberadamente concretos e deliberadamente diversos: facas de chef ultrassônicas, ternos sob medida, caixas de presente curadas, cerâmica refinada por milênios de técnica, as instalações imersivas de arte da Meow Wolf, manutenção de jardins, serviços financeiros. Eles não compartilham uma indústria. Compartilham uma propriedade estrutural. Nenhum deles sobrevive sendo resumido. Não dá para responder “o que é um terno sob medida” de um jeito que substitua o terno. Não dá para resumir a Meow Wolf de um jeito que substitua atravessar a Meow Wolf. O produto resiste ao canal.

É essa a parte do argumento de Fishkin que viaja.

Serviços profissionais tem o mesmo problema

Líderes de engenharia vêm dizendo uma versão disso há dezoito meses, no vocabulário deles. O fosso não é o código que o seu time escreve, porque o assistente eventualmente vai escrever código nessa qualidade. O fosso é o arnês em volta do código: o processo de revisão, a suíte de testes, a disciplina de deploy, as convenções nomeadas, a memória institucional de por que a coisa foi construída do jeito que foi.

A tese de marketing de Fishkin é a mesma tese chegando pela outra ponta do prédio. Quando a IA consegue comprimir e re-apresentar qualquer artefato, a vantagem durável sai do artefato e vai para o sistema que o produz e valida. O sistema é inimitável porque é construído a partir da história específica do operador, dos dados específicos, das decisões específicas e da prestação de contas específica.

Para uma consultoria, isso não é abstrato. Três deslocamentos concretos seguem.

Primeiro, a entrega deixa de ser o fosso. Toda firma minimamente equipada hoje consegue produzir um deck crível de estratégia de IA em uma tarde. O deck é o artefato. A IA resume. O comprador pode pedir ao Claude ou ChatGPT um deck parecido e receber algo 80% tão bom pelo preço de uma assinatura. Se a sua oferta é o deck, a sua oferta foi comoditizada.

Segundo, metodologia nomeada vira o fosso. Uma metodologia que tem nome próprio, origem específica, conjunto específico de decisões codificadas na sua sequência, e histórico específico do operador é mais difícil de resumir. A IA descreve o que a metodologia diz. Ela não reproduz o julgamento que produziu a metodologia, os casos em que ela falhou, as iterações que a refinaram, ou a disposição do operador em sustentá-la num projeto específico. A metodologia é o terno sob medida. O deck é a cópia de prateleira.

Terceiro, medição proprietária vira o fosso. É a parte que Fishkin sinaliza quando lista serviços financeiros. O valor de um gestor de patrimônio não é o explicador sobre fundos de índice; a IA produz esse explicador de graça. O valor é a infraestrutura de medição que transforma a carteira específica de um cliente específico em uma recomendação específica sob condições específicas de mercado, com prestação de contas se der errado. A infraestrutura de medição é o produto inimitável. O explicador é a isca que não funciona mais.

A Releezy nasceu dessa tese, por acidente

Começamos a Releezy porque líderes de engenharia ficavam fazendo uma pergunta que ninguém respondia com confiança: o nosso time está mensuravelmente melhor com IA do que sem. O produto é uma disciplina de medição que roda sobre os dados do próprio time, produz um placar que compara humanos e IA nos mesmos eixos, e dá ao líder uma resposta defensável para o board.

Lendo o texto de Fishkin, o posicionamento fica mais nítido. O mercado não precisa de mais um explicador sobre produtividade com IA. A internet está afogada nesses explicadores, e a busca por IA vai resumir todos eles numa única tela de resultado. O que o mercado precisa é da coisa inimitável: um sistema de medição amarrado ao trabalho específico de um time específico, produzindo evidência que ninguém consegue replicar sem acesso aos dados desse time e aos padrões desse time.

No vocabulário de Fishkin, o explicador é o artefato e a medição é o terno. O explicador pode ser resumido. O terno precisa ser cortado.

É também por isso que temos resistido a montar a Releezy como uma jogada de marketing de conteúdo. O instinto natural, depois de duas décadas de condicionamento por SEO, seria publicar uma centena de posts sobre “métricas de produtividade com IA” e torcer para o funil encher. A previsão de Fishkin sobre o próprio post é o tiro de aviso. Se o fundador do SEO moderno espera menos de 500 visitas de busca para uma peça desse calibre, a matemática do funil não fecha mais. A audiência vem da coisa inimitável existindo no mercado, sendo comentada por operadores que a usam, e sendo defensável quando questionada. O conteúdo apoia a coisa inimitável. O conteúdo não substitui.

O que fazer agora

Se você toca uma firma de serviços profissionais, três movimentos concretos nos próximos sessenta dias.

Dê nome à sua metodologia. Se a abordagem da sua firma não tem nome próprio, sequência específica e conjunto específico de escolhas que a distingam da abordagem genérica de um concorrente, a IA vai tratar a sua firma como intercambiável com esse concorrente. Nomear não é branding. Nomear é o ato de se recusar a ser resumido.

Identifique a única medição que só você consegue produzir. Toda firma vê algo nos dados do cliente que ninguém mais vê. Na maioria das firmas, esse algo está enterrado em planilhas e nunca foi produtizado. Produtize. A medição, devidamente embalada, é o terno. Todo o resto que você vende é a cópia de prateleira.

Audite seu conteúdo por substituibilidade. Pegue seus últimos dez posts. Cole cada um no Claude ou no ChatGPT e peça uma versão concorrente. Se a versão da IA sair 80% tão boa, esse post está ensinando o modelo a te substituir. Substitua-o por algo que a IA não reproduz: um framework nomeado com a sua digital, uma medição que ninguém mais tem, um caso em que você sustenta uma decisão específica com um cliente específico. Inimitável, no sentido de Fishkin, é a coisa que não sobrevive ao resumo.

O fosso se moveu. Fishkin enxergou de dentro do marketing. Líderes de engenharia enxergaram de dentro da IDE. Os dois estão olhando para o mesmo deslocamento.

Fontes

SparkToro. “Inimitable Product is the New ‘Make Great Content’,” por Rand Fishkin. Maio de 2026.

A Victorino ajuda firmas de serviços profissionais a traduzir “produto inimitável” em metodologia de governança nomeada, medição proprietária e dados primários que sobrevivem à sumarização por IA: contato@victorino.com.br | www.victorino.com.br

HBR Finalmente Nomeou: 'A Cada 30 Minutos Alguém Cria Algo Que Eu Preciso Olhar'

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Um gerente entrevistado pela Harvard Business Review colocou palavras em algo que líderes de engenharia vinham resmungando há um ano: “A cada 30 minutos, alguém cria algo que eu preciso olhar.” Liz Fosslien e Mollie West Duffy publicaram essa frase em 25 de maio de 2026, dentro de um texto intitulado Managers Are Struggling to Keep Up with the AI Productivity Boom. A imprensa de gestão finalmente alcançou a realidade operacional.

O reflexo dentro do recorte da HBR é treinar o gerente. Direção mais clara. Foco no que importa. Loops de feedback mais rápidos sem microgestão. Tudo verdade. Tudo insuficiente. O que o artigo descreve não é um problema de coaching. É um problema de governança com embalagem de coaching, e a diferença importa porque coaching escala com o gerente e governança escala com o sistema.

O Que De Fato Quebrou

A saída de um time acelerado por IA não é uma versão mais rápida da saída anterior. É um artefato diferente, produzido numa cadência diferente, exigindo um tipo diferente de atenção da pessoa no topo da fila.

Antes de agentes e copilotos, um gerente de oito engenheiros absorvia talvez dez artefatos dignos de revisão por dia. Pull requests, propostas de design, atualizações de status, uma ou duas escalações. O modelo mental por trás da prática clássica de gestão assume esse volume. One-on-ones, syncs semanais, revisões trimestrais, julgamentos pontuais. Todo o aparato roda na premissa de que a maior parte do que o time produz entre os toques não precisa do gerente.

Essa premissa acabou. Quando cada contribuidor individual entrega três a cinco vezes o que entregava antes, a fila na mesa do gerente não cresce três a cinco vezes. Cresce de forma pior que linear, porque cada artefato chega num momento em que o anterior ainda não foi totalmente processado, e o custo de troca de contexto se acumula. O gerente que era o gargalo de direção vira o gargalo de verificação, integração e priorização. Os três ao mesmo tempo.

Esse é o fato operacional por trás da frase da HBR. O gerente não é lento. O gerente está corretamente reconhecendo que a descrição do cargo mudou silenciosamente e ninguém renegociou.

Três Coisas Quebram Primeiro

Quando o time acelera e a camada de gestão não é redesenhada, três coisas específicas quebram antes de qualquer outra. Nomeá-las é o primeiro passo para consertar.

Profundidade de fila. O número de artefatos esperando atenção do gerente em qualquer momento. Pré-IA, esse número oscilava entre zero e quatro. Pós-aceleração, oscila entre quinze e quarenta. Não existe máximo teórico porque o time não tem mecanismo para saber que já passou da taxa de processamento do gerente. Não estão sendo rudes. Estão fazendo o que foi pedido, mais rápido do que o sistema consegue absorver as consequências.

Latência de feedback. O tempo entre um artefato ser produzido e o produtor receber sinal útil de volta. Pré-IA, isso girava em torno de um dia. Pós-aceleração, com a fila funda e o gerente triando, se estende para três dias, cinco dias, às vezes uma semana inteira. O produtor segue produzindo na ausência de sinal, construindo em cima de premissas que não foram validadas. Quando o feedback chega, o produtor já entregou outras quatro coisas em cima daquela não revisada. Reverter o curso agora é caro.

Alocação de atenção. Quais artefatos o gerente escolhe ler com cuidado, quais bate o olho, quais pula. Pré-IA, isso era implícito e sobrevivente porque a fila era pequena o suficiente para que até seleção aleatória funcionasse a maior parte do tempo. Pós-aceleração, atenção é o recurso mais escasso do sistema e está sendo gasta sem política explícita. O gerente cai no padrão de recência, ou de quem gritou mais alto, ou do que está no topo da tela. Nenhuma dessas correlações casa com o que de fato importa para o negócio.

Releia o recorte da HBR contra essas três e as recomendações aterrissam diferente. Direção mais clara é governança de profundidade de fila: menos artefatos disputam revisão porque o time sabe de antemão o que conta. Loops de feedback mais rápidos sem microgestão é engenharia de latência de feedback: o loop fecha por estrutura, não pelo gerente estar disponível mais horas. Foco no que importa é alocação de atenção, tornada explícita em vez de baseada em sensação.

Por Que Isso É Governança, Não Coaching

O recorte de coaching diz: esse gerente precisa ficar melhor no novo ritmo. Melhor em priorização, mais rápido em feedback escrito, mais disciplinado com blocos de trabalho profundo.

O recorte de governança diz outra coisa. O sistema mudou. As restrições mudaram. A descrição do papel não foi reescrita para acompanhar. Nenhuma quantidade de heroísmo individual fecha essa distância, porque o próximo gerente contratado para a mesma estrutura vai bater na mesma parede na mesma semana.

Vimos o mesmo formato em O Impasse Mexicano Dentro dos Times de IA: o time trava não porque indivíduos estão falhando, mas porque ninguém tem autoridade para declarar quem decide o quê. Vimos por outro ângulo em O CEO de Dois Relógios: CEOs em escala rodando duas cadências operacionais incompatíveis numa agenda única. E vimos dentro da função de PM em Agentes de IA para Product Managers: o papel do PM expande mais rápido do que o organograma admite, e o engenho individual disfarça a dívida estrutural até a estrutura ceder.

O gerente da HBR é o mesmo padrão em outra camada. A correção não é fazer o gerente trabalhar mais duro contra uma descrição de cargo não renegociada. A correção é renegociar, por escrito, com governança explícita sobre as três coisas que quebram primeiro.

Como Governança Funciona Na Prática

Governança de profundidade de fila. Publique um máximo. Diga em voz alta quantos artefatos abertos um gerente vai segurar de cada vez, e o que acontece quando a fila ultrapassa esse limite. Opções que de fato funcionam: uma camada designada de revisão entre pares para qualquer coisa abaixo de um limiar de criticidade, um corte rígido em que novos artefatos roteiam para um pool de revisores em vez do gerente, uma auditoria semanal de fila em que itens parados são mortos em vez de carregados. O princípio: a fila é um recurso com teto, não uma caixa de entrada com capacidade infinita.

Engenharia de latência de feedback. Estabeleça um tempo-alvo de retorno para cada classe de artefato e instrumente. Vinte e quatro horas para revisão de código em certo nível de criticidade, quarenta e oito para propostas de design, mesma semana para memorandos escritos de estratégia. Quando a métrica escorrega, a resposta é estrutural: mais revisores, artefatos menores, templates assíncronos de feedback que baixam o custo de uma resposta útil. Não “o gerente deveria responder mais rápido”. Isso é coaching. Mudança estrutural é governança.

Alocação de atenção, tornada explícita. Decida de antemão quais categorias de artefato o gerente lê com cuidado, quais bate o olho, quais delega. Escreva. Compartilhe com o time para que saiba que tipo de atenção esperar ao produzir um artefato dado. O ato de escrever força a priorização que o gerente vinha fazendo implicitamente sob pressão. O ato de compartilhar remove o custo social de não ler tudo.

Nada disso é exótico. É o mesmo tipo de disciplina de governança que já aplicamos a resposta a incidentes, a controle de acesso, a aprovações financeiras. A novidade é aplicar a atenção gerencial como um recurso que pode ser desenhado, orçado e protegido.

Faça Isso Agora

Se você gerencia gerentes, nesta semana: pegue um gerente e um time. Sente com eles por uma hora. Conte a fila. Meça a latência média de feedback das últimas duas semanas. Peça ao gerente para listar, por escrito, quais categorias de artefato hoje lê com cuidado, quais bate o olho, quais pula. Leve esse artefato para a próxima reunião de liderança.

Você não vai precisar argumentar a favor de governança depois disso. Os números argumentam sozinhos. A razão pela qual a HBR finalmente conseguiu publicar a frase é que a aritmética ficou impossível de esconder. A razão pela qual o trabalho é seu, não do gerente, é que o gerente não consegue governar o sistema dentro do qual ele opera.

O time ficou mais rápido. A descrição do cargo não. O trabalho dos próximos dois trimestres é fechar essa distância deliberadamente, com alavancas explícitas sobre profundidade de fila, latência de feedback e alocação de atenção. Caso contrário, o time produtivo vira o time ingovernável, e você perde o gerente junto com o ganho de throughput.

Fontes

Harvard Business Review. “Managers Are Struggling to Keep Up with the AI Productivity Boom,” por Liz Fosslien e Mollie West Duffy. Maio de 2026.

A Victorino ajuda times de liderança a substituir o heroísmo de gestão na era da IA por governança explícita sobre profundidade de fila, latência de feedback e alocação de atenção: contato@victorino.com.br | www.victorino.com.br

A HuggingFace Acabou de Escrever o Vocabulário Que Já Usávamos: Agente = Modelo + Harness

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Em 25 de maio, a HuggingFace publicou um Glossário de Agentes. A definição-âncora é uma linha. “Agente = Modelo + Harness.” Sérgio Paniego e Aritra Roy Gosthipaty escreveram o texto porque, segundo o próprio enquadramento, a confusão no ICLR 2026 em torno de termos sobrepostos havia virado dívida operacional para o campo. Eles queriam um vocabulário compartilhado. Escreveram um.

Para qualquer pessoa vendendo, comprando ou governando agentes de IA, esta é a publicação mais importante do mês. Não porque as definições sejam novas. Usamos exatamente esses termos há mais de um ano. Mas porque um grande laboratório de modelos agora detém a referência canônica. Quando um time de compras pesquisa “o que é harness de agente”, é na HuggingFace que vai cair. O vocabulário virou terreno neutro.

Isso muda a conversa. Especificamente, muda quem precisa fazer o trabalho de tradução.

A Definição Que Encerra um Ano de Discussão

A decomposição central da HuggingFace é precisa o suficiente para entrar em contrato. O scaffold é a camada que define comportamento: o system prompt, as descrições de ferramentas, a lógica de parsing de respostas. O harness é a camada de execução: o código que chama o modelo, lida com invocações de ferramentas e decide quando parar. O modelo fica no centro. Tudo mais é scaffold ou harness ao redor.

A frase que faz o trabalho pesado é aquela em que Paniego e Gosthipaty aterrissam direto: “Se você não é o modelo, você é o harness.” Essa sentença é grade de compras. Reduz toda categoria difusa de produto a um binário. Ou você entrega os pesos, ou entrega o código que os orquestra. Não existe terceira categoria.

Sub-agentes recebem o mesmo tratamento. Um sub-agente tem capacidade de raciocínio, e é isso que o distingue de uma ferramenta (uma chamada de função) ou de uma skill (conhecimento empacotado). Ferramentas executam. Skills informam. Sub-agentes decidem. Aceita essa taxonomia, e a camada em que um fornecedor compete fica inequívoca. Dá para mapear qualquer produto de IA em uma dessas quatro funções em menos de trinta segundos.

Esse mapeamento é a nova habilidade de procurement.

Por Que o Endosso do Laboratório Importa Mais Que os Termos

Já escrevemos sobre essa decomposição em a definição de harness e mapeamos suas aplicações cross-disciplinares. Os termos não são novos. A Anthropic usa em posts de pesquisa aplicada. Praticantes no Twitter usam. A documentação interna de qualquer time sério de agentes usa, com variações locais.

O que faltava era uma citação única que um comprador pudesse mandar a um fornecedor sem que parecesse advocacy. Se mandássemos a um prospect o post da Victorino definindo harness, o subtexto implícito era “adote nosso framework”. Se mandássemos o post da Anthropic, o subtexto era “adote o framework do laboratório cujo modelo você talvez esteja considerando comprar”. A posição da HuggingFace no ecossistema é mais próxima da neutralidade. Eles hospedam modelos de todos os laboratórios. São infraestrutura, não concorrente. O glossário soa como o campo se autodefinindo.

Essa neutralidade é o que torna o glossário grade de compras. Um CIO pode agora exigir, em um RFP, que fornecedores descrevam sua oferta como modelo, harness, scaffold, sub-agente, ferramenta ou skill, e citar a definição da HuggingFace como referência. O fornecedor não consegue discutir com a fonte. O fornecedor precisa traduzir o próprio marketing para os termos do glossário.

Este é o momento em que o vocabulário deixa de ser ferramenta interna e vira arma de procurement.

As Três Perguntas de Comprador Que Agora Têm Resposta Limpa

Antes de 25 de maio, três perguntas apareciam em toda avaliação de fornecedor e produziam respostas confusas todas as vezes. Cada uma agora tem forma limpa.

A primeira é “em que camada você vende?” Antes do glossário, fornecedores diziam “somos uma plataforma completa de agentes” ou “somos um framework de agentes”. As duas frases eram marketing, não arquitetura. Com o glossário, a pergunta vira: você entrega o modelo, o harness, o scaffold, ou alguma combinação? Um fornecedor que não consegue responder isso em uma frase está vendendo uma categoria, não um produto.

A segunda é “o que acontece nas costuras?” Se um fornecedor vende o harness, que suposições de modelo o harness assume? Se vende scaffold (um conjunto de prompts e descrições de ferramentas), que suposições de harness ele exige? O glossário torna as costuras visíveis. Os contratos agora podem especificar qual lado é dono de cada uma.

A terceira é “onde mora a sua governança?” A maior parte da governança de agentes é implementada no harness, porque é a camada que decide quando chamar uma ferramenta, quando parar e como registrar log. O scaffold pode codificar intenção, mas o harness aplica. Quando um time de procurement entende isso, a revisão de segurança muda de forma. Em vez de perguntar ao fornecedor “sua plataforma é segura”, o time pede “me mostre os comportamentos de harness que aplicam política e os padrões de scaffold que a declaram”. Dois entregáveis específicos em vez de um difuso.

Cada uma dessas três perguntas exigia trinta minutos de explicação de vocabulário antes que a resposta substantiva pudesse começar. O glossário remove o preâmbulo. As conversas ficam mais curtas e mais afiadas ao mesmo tempo.

O Que Deixa de Ser uma Unidade Coerente

O movimento escondido no post da HuggingFace é que “agente” deixa de ser uma unidade que se compra ou se avalia. Um agente é uma composição. O modelo é comprado de um laboratório. O harness é comprado de um fornecedor de plataforma ou construído internamente. O scaffold é escrito pelo time que usa o agente. As ferramentas são integradas. As skills são curadas.

Quando alguém diz “estamos avaliando o agente do Fornecedor X”, está cometendo um erro de categoria. O Fornecedor X vende uma ou duas camadas. O agente só existe quando as cinco camadas estão montadas. A avaliação precisa acontecer no nível da camada.

Isso vai ser desconfortável para fornecedores que construíram o pitch em torno de “o agente”. É libertador para compradores que precisavam de um framework para decompor o que estavam comprando. A alavanca pende para o comprador que consegue mapear o pitch do fornecedor sobre o glossário em tempo real.

O Que Fazer Esta Semana

Pegue a URL do glossário da HuggingFace e coloque nos próximos três RFPs de fornecedor. Especificamente, na seção de arquitetura, acrescente: “Conforme o Glossário de Agentes da HuggingFace, identifique quais das camadas a seguir a sua oferta provê: modelo, harness, scaffold, sub-agente, ferramenta, skill. Para cada camada que você provê, descreva as suposições de interface feitas sobre as camadas adjacentes.”

Depois, antes da próxima call com fornecedor, gaste dez minutos mapeando o site de marketing dele nessas camadas. Note quais camadas estão explícitas, quais estão implícitas e quais estão obscuras. As obscuras são suas perguntas de abertura. Você vai descobrir que a maioria dos pitches colapsa duas ou três camadas em um termo difuso, e que a pergunta certa de discovery é simplesmente “de qual camada você está falando agora?”

Se você entrega agentes internamente, espelhe o mesmo exercício na sua própria arquitetura. Escreva o one-pager que mapeia cada camada do seu stack para os termos do glossário. Circule entre os times de segurança, plataforma e produto. A primeira versão vai expor três lugares em que dois times queriam dizer coisas diferentes com a mesma palavra. Corrigir esses três é o valor que compõe ao longo do tempo quando se adota o vocabulário.

A guerra de vocabulário acabou. A HuggingFace cravou os termos. Os times que adotarem primeiro vão rodar procurement mais limpo, revisões de segurança mais limpas e handoffs internos mais limpos pelos próximos dezoito meses. Os times que continuarem usando “agente” como unidade vão gastar esses mesmos dezoito meses explicando o que querem dizer.

Fontes

HuggingFace. “Agent Glossary: harness, scaffold, and the AI agent terms worth getting right,” por Sérgio Paniego e Aritra Roy Gosthipaty. Maio de 2026.

A Victorino ajuda lideranças de procurement e engenharia a traduzir o vocabulário de harness em critérios de avaliação de RFP para fornecedores de agentes de IA: contato@victorino.com.br | www.victorino.com.br

Jen Nunca Pode Sair de Férias: Quando a Especialista É o Ponto Único de Falha

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Jen trabalhava no Reed Group, hoje Alight Absence Management. No papel, a função dela parece tediosa. Ela processava arquivos de folha de pagamento com códigos de duas letras em colunas chamadas “Action” e “Action Reason Code”. Uma combinação como PAY/SRT não dizia nada para um analista novo. Para a Jen, significava um afastamento parcial com um tratamento específico de compliance, e ela identificava o caso em três segundos numa planilha com milhares de linhas.

Ninguém mais conseguia.

Essa última frase é o problema inteiro. Jason Cole, o CTO que conta a história da Jen no blog da darthealth, descreve a situação sem melodrama. Jen nunca conseguia tirar férias de verdade. Não daquelas em que você desliga o e-mail. Porque toda vez que algo incomum passava pelo pipeline da folha, o sistema não sinalizava. A Jen sinalizava. E se a Jen estava na praia, o caso incomum ficava parado na fila, ou pior, era processado errado.

Essa é a textura de uma falha de governança que não tem cara de falha de governança. Não há vazamento. Não há achado de auditoria. Não há regulador batendo na porta. Há apenas um ser humano que virou uma parede estrutural, e uma empresa que aceitou silenciosamente que essa parede nunca pode ser reformada sem derrubar o prédio.

A Pergunta de Diagnóstico

Quando você descobre uma Jen na sua operação, o instinto é tratar como problema de pessoal. Contratar mais duas Jens. Treinar juniores em cross-training. Pagar um bônus de retenção grande o suficiente para comprar a lealdade dela pelo próximo ano fiscal.

Nada disso resolve o problema. O cross-training assume que o conhecimento pode ser transferido numa conversa. Não pode. O reconhecimento de padrão da Jen não estava no PowerPoint dela. Estava nas mãos dela, construído ao longo de milhares de arquivos em que ela viu o que acontecia quando PAY/SRT era classificado errado dois trimestres depois. Contratar mais Jens assume que o mercado de trabalho produz Jens. Não produz. A Jen é um artefato da história específica de uma empresa específica, processada por uma carreira específica de uma pessoa específica.

A pergunta de diagnóstico correta é a que Cole fez. Não “como substituímos a Jen”, mas “por que a empresa depende da Jen, em primeiro lugar?” A resposta é que o sistema de folha nunca codificou o que o sistema de folha realmente fazia. Os códigos nunca foram documentados porque as pessoas que os usavam não precisavam de documentação. Os padrões nunca foram escritos porque os padrões viviam na memória muscular da equipe que os lia.

Isso é dívida técnica. Só que carregada por uma pessoa em vez de uma página de Confluence.

Documentação É uma Fotografia

Aqui está a frase de Cole que justifica todo o texto. “Documentação é uma foto do que alguém lembrava no dia em que escreveu. Sabedoria é saber o que fazer quando dados com o mesmo cheiro mas uma cara diferente aparecem na próxima vez.”

Leia duas vezes. A implicação é brutal para qualquer organização que passou a última década rodando iniciativas de gestão do conhecimento. O runbook é uma foto de um momento. A sabedoria é o olho do fotógrafo, que o runbook nunca consegue capturar. Toda trilha de auditoria, todo procedimento operacional padrão, todo deck de onboarding é necessariamente incompleto da mesma forma. O caso incomum, aquele que tem cheiro de PAY/SRT mas não é exatamente PAY/SRT, é justamente o caso que a documentação não cobre.

É por isso que a resposta padrão para o problema da Jen falha. Você escreve o runbook. O runbook cobre os casos que a Jen já viu várias vezes. O próximo caso incomum aparece. O runbook não cobre. A Jen continua tendo que olhar. A Jen continua sem poder tirar férias. O runbook não resolveu nada para os casos que realmente importam, que são justamente aqueles que precisavam do julgamento da Jen.

A armadilha é tratar documentação como destino. Documentação é uma estação intermediária. O destino é um sistema que consegue fazer o que a Jen faz, ou seja, reconhecer que algo é incomum e saber o que fazer a respeito. Ou, nos casos em que não consegue fazer a segunda parte, pelo menos saber como escalar a primeira.

O Que Cole de Fato Construiu

A resposta do Reed Group foi algo que Cole chama de Data Nexus. A arquitetura importa menos do que o comportamento operacional. O Nexus aprende o reconhecimento de padrão da Jen. Ele olha para o arquivo de folha e aplica as mesmas heurísticas que a Jen construiu ao longo dos anos. Quando vê um padrão familiar, processa o caso. Quando vê algo ambíguo, algo com o mesmo cheiro mas uma cara diferente, ele não chuta. Marca o registro para revisão humana e diz ao humano o que tornou o caso suspeito.

O sistema cuida dos casos com precedente. A Jen cuida dos casos sem precedente. Essa única mudança reescreve toda a economia da função.

Vale citar Cole diretamente. “A Jen com o Data Nexus vira o Dr. House, consultando apenas nos casos realmente interessantes, enquanto o sistema aprende.” O House não atendia todos os pacientes que entravam no Princeton-Plainsboro. Ele atendia os pacientes que tinham derrotado o pipeline diagnóstico padrão. Esse é o trabalho de um especialista. A Jen, antes do Nexus, estava fazendo o equivalente a diagnosticar de faringite a lúpus, todos os dias, o dia inteiro. O Nexus não substituiu a Jen. Promoveu a Jen.

Esse é o padrão de governança. Codifique o conhecimento tácito que já tem precedente. Escale os casos novos para o humano com o julgamento para resolvê-los. O sistema fica mais rápido no trabalho rotineiro ao longo do tempo. O humano passa a ser pago pelo trabalho que exige expertise de verdade. E o humano, finalmente, consegue tirar férias, porque a fila rotineira continua andando sem ela.

Por Que Esse É um Padrão de 2026, Não de 2018

A gente vinha contando essa história de forma errada por uma década. A versão que continuávamos contando era “IA vai substituir trabalhadores do conhecimento”. Essa história sempre foi simples demais, e quem fazia o trabalho operacional de verdade sentia que era simples demais. Substituir a Jen por quê? Por um modelo que nunca viu um arquivo de folha do Reed Group? Por um SaaS de fornecedor que não sabe o que PAY/SRT significa no contexto de compliance específico da sua empresa?

A versão de 2026 dessa história é diferente. O Nexus não é um modelo genérico. É um sistema construído ao redor da Jen, que aprendeu com a Jen e que roda ao lado da Jen como instrumento dela. Ele só existe porque a Jen existiu antes. O conhecimento institucional foi o insumo, não o produto a ser deletado.

O padrão transferível é este. Toda frase do tipo “temos uma pessoa que sabe X” na sua organização é dívida técnica. Não é uma peculiaridade simpática. Não é sinal de cultura forte. É dívida. Tem custo de carregamento (as férias que a pessoa não consegue tirar, o conhecimento que sai pela porta quando ela sai, as filas que acumulam quando ela fica doente) e custo de refinanciamento (o projeto que finalmente codifica o conhecimento num sistema). Hoje, em 2026, o custo de refinanciamento está mais baixo do que nunca, porque as ferramentas para capturar, codificar e escalar viraram commodity.

As empresas que vão operar IA bem nos próximos três anos são as que vão sair procurando suas Jens de forma deliberada. Não para substituí-las. Para finalmente quitar a dívida que vinham carregando nas costas delas.

Faça Isso Agora

Escolha uma operação da sua empresa e faça uma única pergunta. Se essa pessoa tirasse três semanas de férias, sem e-mail, sem Slack, o que ficaria parado na fila e o que seria processado errado?

Essa resposta é sua candidata a Jen. A próxima pergunta é que fração do trabalho dela tem precedente (codificar) e que fração é genuinamente nova (escalar). Trate a codificação como projeto de software, não como projeto de documentação. Trate a escalação como problema de desenho de workflow, não como problema de contratação. E coloque a humana na cadeira que exige o julgamento dela, não na cadeira que exige que ela faça a mesma tarefa de reconhecimento dez mil vezes seguidas.

Depois mande ela tirar férias. O sistema que você construiu vai dizer se você terminou o serviço de verdade.

Fontes

Reed Group / darthealth.com. “Jen Can Never Leave,” por Jason Cole. Maio de 2026.

A Victorino ajuda lideranças de operações a converter dependências de especialista único em workflows governados e aumentados por IA, transformando a Jen do seu time na especialista que finalmente tira férias de verdade: contato@victorino.com.br | www.victorino.com.br

Karpathy Aposentou o Vibe Coding. O Substituto É Gestão de Produto.

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Andrej Karpathy cunhou “vibe coding” no início de 2025. Em maio de 2026, segundo o relato de Jeff Gothelf, declarou o termo obsoleto e o substituiu por uma lista de atividades que qualquer líder de produto honesto reconhece de imediato.

Esse reconhecimento é a história.

A Lista Que Karpathy Usou Para Aposentar o Próprio Termo

Como Gothelf reconstrói a lista, Karpathy descreve o que a engenharia agêntica realmente exige: escrever specs de design, supervisionar planos, inspecionar diffs, escrever testes, construir loops de avaliação, gerenciar permissões, preservar qualidade.

Leia a lista duas vezes. Note o que não está nela. Digitar código. Decorar sintaxe. Escolher framework. Configurar build tool. As atividades que definiam “desenvolvedor” em 2015 estão ausentes. As atividades que definiam “gerente de produto” estão todas presentes.

Gothelf traça o paralelo de forma direta. Cada item da lista de Karpathy mapeia para uma atividade clássica de PM: definição de problema, priorização, validação de outcome, métricas de sucesso, alinhamento de escopo, julgamento de qualidade. O vocabulário mudou. O trabalho, não.

Por Que Essa É a Admissão Que Importa

Por dois anos, a conversa sobre desenvolvimento com IA foi uma conversa de engenharia. Quantas licenças de Cursor. Qual modelo. Qual agent loop. Qual IDE. A suposição implícita: isso é um problema de ferramentas, resolvido por compras e treinamento de engenharia.

A aposentadoria que Karpathy fez do próprio termo fura essa suposição. O trabalho de julgamento nunca foi o gargalo de engenharia. Era o gargalo de PM disfarçado de engenharia.

Quando um desenvolvedor aceita uma sugestão ruim da IA e dá deploy, a falha não foi o modelo alucinar. A falha foi ninguém ter escrito uma spec afiada o suficiente para tornar a alucinação óbvia. Quando um agente executa um comando perigoso, a falha não foi o agente. Foi a fronteira de permissão ausente. Quando um loop de avaliação não produz nada útil, a falha não foi o loop. Foi a ausência de uma métrica de sucesso com a qual alguém tenha concordado.

Cada uma delas é uma atividade de PM. Nenhuma é curada com mais licenças de Claude.

A Frase Que Deveria Estar na Parede de Todo CTO

A frase mais afiada de Gothelf cai aqui. “A versão administrativa de cada uma dessas atividades é automatizável agora, e será automatizada. A versão de julgamento é o trabalho.”

A versão administrativa de escrever uma spec é preencher um template. A versão de julgamento é saber o que o cliente ainda não consegue articular. A versão administrativa de inspecionar um diff é ler o arquivo. A versão de julgamento é saber quais 200 linhas de refactor são liquidamente positivas e quais são uma regressão vestida de código limpo. A versão administrativa de um loop de avaliação é instrumentá-lo. A versão de julgamento é escolher a métrica certa a medir.

A primeira coluna está sendo devorada por agentes em ciclos trimestrais. A segunda coluna é o que sobra. Karpathy, na prática, está dizendo a líderes de engenharia que vêm fazendo staffing da primeira coluna e ignorando a segunda.

O Que as Organizações Estão Fazendo de Errado Agora

Três padrões que vemos repetidamente em 2026:

Times de engenharia adicionando capacidade de IA sem capacidade de PM. Uma engenharia de 40 pessoas instala o Claude Code, vê um lift de 25% na primeira medição de throughput e decide que o gargalo agora é “mais tooling de IA”. Seis meses depois, o lift achatou. A investigação revela que o que falta não é mais tooling. É que os mesmos cinco gerentes de produto agora limitam o dobro do output de engenharia, e as specs que escrevem não se adaptaram a um mundo em que o executor lê literalmente.

PMs tratados como redatores de ticket, não como autores de spec. Na maioria das empresas, o papel de PM degradou na última década para gestão de stakeholders, triagem de tickets e teatro de roadmap. O pensamento de produto de verdade, o julgamento do cliente, a articulação de trade-offs, foi sendo espremido. Agentes de IA expõem isso na hora. Um agente alimentado com um ticket do tipo “melhorar o fluxo de onboarding” vai produzir alguma coisa. Se essa coisa está certa exige o trabalho de julgamento que PMs vêm sendo cada vez mais dispensados de fazer.

“Desenvolvedor assistido por IA” como título de cargo, sem equivalente em produto. Os anúncios de vaga em maio de 2026 estão cheios de “engenheiro aumentado por IA” e “engenheiro agêntico”. O cargo correspondente em produto não existe com a mesma nitidez. O mercado segue recrutando executores para um ambiente em que execução é cada vez mais automatizada, e subfinanciando os papéis de julgamento para um ambiente em que julgamento é a restrição que aperta.

O Que Fazer Segunda-Feira

Audite a qualidade das specs antes de auditar a escolha do modelo. Puxe as últimas dez specs que sua equipe entregou a agentes de IA. Pergunte: um júnior inteligente mas literal, sem contexto do seu produto, construiria a coisa certa a partir disso? Se a resposta for não, o gargalo está a montante do modelo. Nenhuma mudança de tooling vai resolver.

Empurre o trabalho de julgamento para o início do ciclo. Se o PM só entra na fase de teste de aceite, você já pagou pela iteração de engenharia. Com agentes produzindo código em minutos, esse custo de iteração caminha para zero, o que significa que o custo de julgamento domina. PMs precisam estar na sala quando a spec está sendo escrita, não quando o PR está em revisão.

Reframe desenvolvimento com IA como questão de staffing de produto. Pare de perguntar “temos engenheiros suficientemente fluentes em IA?” Comece a perguntar “temos pessoas suficientes que conseguem articular o problema certo de forma clara o bastante para um agente resolver?” São perguntas diferentes, com respostas diferentes, e a segunda é a que determina o resultado.

Pare de contratar PMs que não conseguem ler um diff. A versão de julgamento de “inspecionar diffs” exige letramento técnico. Um PM que nunca leu código não consegue avaliar se o refactor do agente está certo, só se a demo parece certa. Num mundo em que a demo sempre parece certa, isso não basta mais.

Construa o loop de avaliação como artefato de produto, não de engenharia. Critérios de avaliação para saída de IA são decisões de produto. O que conta como “bom”, quais thresholds de aceite valem, o que é regressão, não são perguntas técnicas. São perguntas de produto vestidas de técnica. Trate como tal.

O reframe que Karpathy está forçando é desconfortável para organizações que passaram dois anos se convencendo de que a virada de IA era um problema de compra e treinamento em engenharia. Não era. Sempre foi um problema de disciplina de produto. As ferramentas só tornaram impossível seguir ignorando.

As empresas que fizerem staffing para essa realidade agora vão compor ganhos. As que seguem contratando mais executores para um ambiente em que execução é grátis vão passar 2027 se perguntando por que o investimento em IA não trouxe os retornos que o deck prometia.

Fontes

Jeff Gothelf. “Karpathy Said Vibe Coding Is Obsolete. What He Described Instead Is Product Management.” Maio de 2026.

A Victorino ajuda times de liderança a reposicionar desenvolvimento assistido por IA como problema de staffing de produto, construindo a disciplina de spec, validação de outcome e julgamento que determina se o stack agêntico de fato gera valor: contato@victorino.com.br | www.victorino.com.br

O Maintainer do Redux Documentou o Workflow de Agentes Mais Honesto de 2026

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Em 7 de maio de 2026, Mark Erikson publicou a Parte 2 da sua série sobre workflow de IA. Erikson mantém o Redux. O trabalho do dia a dia dele é na Replay. É a pessoa que responde quando uma engenheira frontend sênior abre um bug de gerenciamento de estado às três da manhã, e ela respondeu a tantos desses bugs por tantos anos que tem opiniões que valem a leitura.

A manchete do texto não é o stack de ferramentas. A manchete é o que ele se recusou a fazer e o que ele admitiu, em público, que ainda não sabe resolver.

O stack em si é interessante. OpenCode com a interface CodeNomad. Claude Opus 4.5 e 4.6 via API. MCPs próprios chamados grepika, tilth e cachebro. Um script Bun próprio, o devplans.ts, que cuida das passagens entre sessões. Boa parte disso é substituível. Ferramenta troca a cada seis semanas. Disciplina não.

A disciplina parece uma lista de coisas que muita gente fingiu já ter superado. Erikson não superou. Ele roda uma sessão orquestradora pai que dispara sessões filhas interativas de subtarefa, e se limita a um único fluxo de trabalho concorrente. Palavras dele: “Estou escolhendo intencionalmente limitar o workflow ao que eu consigo gerenciar dentro da minha própria cabeça.” Recusa os modos de permissão YOLO. Usa filtragem de comandos por regex em vez de segurança baseada em chamada de agente. Faz commit no Git à mão.

Se você leu isso e sentiu vontade de discutir com ele, as próximas duas seções são para você.

O que Erikson Recusou, e por que Cai Diferente em 2026

Três recusas se destacam. Cada uma delas pressiona algo que algum fornecedor ou pensador influente vem vendendo nos últimos doze meses.

A primeira recusa é o modo de permissão YOLO. A maioria dos runners de agente vem com uma chave de “vai” que desliga o prompt em cada chamada de ferramenta. Erikson não vira essa chave. O argumento a favor de virá-la é vazão. O argumento contra, que Erikson faz simplesmente por não usar, é que uma rodada de agente sem prompt é uma rodada que você não consegue reconstruir. Trocou um loop mais lento por um loop mais rápido sem registro de quais decisões o modelo tomou em seu nome. Quando alguma coisa quebra, você não sabe por onde começar a ler.

A segunda recusa é segurança baseada em chamada de agente. Várias arquiteturas de segurança recentes roteiam toda chamada de ferramenta por um agente guardião que decide se ela é permitida. O pitch é que um LLM entende intenção e consegue bloquear chamadas perigosas que uma regex não bloqueia. Erikson escolheu a regex. A regex tem a propriedade de ser determinística, auditável e não pode ser alucinada por cima. Dois engenheiros lendo a mesma regex enxergam o mesmo conjunto de comandos permitidos. Dois engenheiros lendo o log recente de um agente guardião não enxergam.

A terceira recusa é subtarefas concorrentes. A fronteira dos workflows agênticos é muitos sub-agentes em paralelo, hierarquias, enxames. Erikson roda um por vez. O motivo não é que a tecnologia não consegue mais. O motivo é que ele não consegue modelar mentalmente mais de um em voo, e se recusa a operar um sistema cujo estado ele não consegue manter na cabeça. Aplique esse teste aos agentes em produção da sua casa. Quantos deles produzem saída que qualquer engenheiro do seu time consegue reconstruir depois? Se a resposta for “nenhum”, isso é um achado, não uma conquista.

Nenhuma dessas três posições é radical isoladamente. O que chama atenção é que um maintainer do calibre do Erikson publique as três juntas e não fique constrangido em dizer “eu me limito”. A mensagem implícita é que as pessoas embarcando nos stacks de agente mais barulhentos, mais rápidos e mais paralelos podem estar embarcando porque ainda não tiveram de conviver com as consequências.

Os Dois Problemas Abertos que Ele Foi Honesto a Respeito

A contribuição mais importante do post não são as recusas. São as duas superfícies que Erikson nomeou abertamente como não resolvidas.

A primeira é memória e contexto de longo prazo. Erikson é explícito. Quando ele precisa reconstruir o que ele e o agente decidiram duas sessões atrás, ele escava sessões anteriores à mão. Não existe memória de longo prazo funcionando. A sessão é a memória. Continuidade entre sessões é um problema de arqueologia manual, e o paliativo é o script devplans.ts dele, que costura na mão as passagens entre sessões.

A segunda é revisão de código e verificação de intenção. O enquadramento exato dele: “revisão de código e garantir a intenção ainda são difíceis.” Essa é a parte que lideranças de engenharia têm mais chance de ler errado. Ele não está dizendo que agentes não conseguem escrever código. Está dizendo que ninguém, inclusive ele, tem um jeito confiável de confirmar que o código que o agente produziu reflete a intenção que o humano tinha no início. A superfície de verificação ainda é humana.

As duas são superfícies que fornecedores correm para preencher. A corrida é real, e alguém eventualmente vai entregar algo útil em cada pista. Hoje, em maio de 2026, o praticante mais respeitado publicando sobre o tema diz que nenhuma das duas pistas está fechada. Sua premissa operacional deve casar com a dele.

Existe uma conexão entre as três recusas e os dois problemas abertos que vale nomear. As recusas existem porque os problemas abertos existem. Se memória de longo prazo funcionasse, o caso para rodadas YOLO sem estado seria muito mais forte, porque daria para reconstruir o que aconteceu. Se revisão confiável de código por IA existisse, o caso para subtarefas paralelas de alta vazão seria muito mais forte, porque cada saída seria verificável de forma independente. A disciplina que ele pratica não é arbitrária. É exatamente a disciplina que um praticante sênior adota quando as duas primitivas estruturais ainda estão faltando.

Por que Isso Importa para o Seu Stack

Já escrevemos antes sobre por que o harness é a sua memória e por que subtração vence adição em design de harness. O post do Erikson é a validação de campo dessas posições, escrita por alguém que não está construindo um serviço da Victorino.

Leia o post dele contra a sua configuração de agente em produção. Três perguntas valem ser feitas.

Os seus agentes rodam com modelos de permissão que um revisor externo conseguiria reconstruir? Se o seu time usa modos YOLO em produção, vocês aceitaram implicitamente que não conseguirão explicar decisões individuais depois. Erikson escolheu não fazer essa troca. A pergunta é se o seu time fez a escolha de propósito ou por omissão.

A sua camada de segurança é determinística ou baseada em modelo? Um agente guardião é um complemento útil para um filtro determinístico. É uma substituição perigosa. A regex é chata, e é exatamente esse o ponto. Chato é auditável.

Vocês têm uma regra escrita de quantas subtarefas concorrentes cada operador gerencia? Se não têm, têm uma na prática e não estão medindo. O número não precisa ser um. Erikson escolheu um para si. Um time operando em escala vai escolher mais. Mas o número precisa ser uma decisão, não uma propriedade emergente do que a ferramenta vier configurada de fábrica.

Onde a Fronteira de Fato Está

O post puxa uma linha mais nítida do que a maioria das lideranças se dispõe a puxar em público entre resolvido e não resolvido. A parte resolvida é engenharia mão na massa com um agente que obedece a um filtro determinístico, faz commit quando um humano manda fazer commit e trabalha em uma coisa de cada vez. Essa parte funciona hoje e funciona bem. A parte não resolvida é continuidade entre sessões e verificação de intenção.

Os pitches de fornecedor em volta de produtos de memória e revisão de código por IA não estão errados em existir. Apontam para superfícies reais. Mas apontam para superfícies que o melhor maintainer praticante do setor diz que ainda não estão fechadas. Se você está orçando investimento em agentes para os próximos dois trimestres, pese o orçamento na direção das partes que Erikson confirma estarem resolvidas, e trate as partes de memória e revisão como apostas de pesquisa, não como primitivas de produção.

Faça Isso Agora

Abra o documento de operação de um agente em produção do seu time. Encontre três coisas.

Encontre o modelo de permissão. Anote se os seus operadores rodam com aprovação por prompt, filtros determinísticos ou modo YOLO. Se for YOLO, agende uma revisão com o engenheiro responsável esta semana. A pergunta não é se você confia no agente. A pergunta é se você consegue reconstruir as decisões dele caso um cliente pergunte.

Encontre o limite de concorrência. Anote o número máximo de subtarefas concorrentes que um único operador roda. Se o número não está escrito, escreva hoje. Escolha um número que você consiga defender. Erikson escolheu um. Seu time pode escolher três. O número em si importa menos do que o fato de alguém ser dono dele.

Encontre a história da memória. Anote como um operador reconstrói o que foi decidido três sessões atrás. Se a resposta for “ele faz grep em logs antigos”, vocês estão rodando o mesmo paliativo que o Erikson, e isso é aceitável. Se a resposta for “nosso produto de memória cuida disso”, verifique essa afirmação contra um caso real antes de apostar um release nela.

A régua que Erikson colocou nesse post não é uma régua alta. É uma régua honesta. Acompanhe.

Fontes

Mark Erikson / blog.isquaredsoftware.com. “My Thoughts on AI, Part 2: Agent Setup, Workflow, and Tools.” Maio de 2026.

A Victorino ajuda lideranças de engenharia a codificar a disciplina de agentes que os maintainers de ponta praticam, com guardas explícitas para as lacunas que os fornecedores ainda não fecharam: contato@victorino.com.br | www.victorino.com.br

Microsoft Cancela Claude Code. A Economia de Tokens Atinge a Big Tech.

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Em 25 de maio de 2026, o TheNextWeb reportou que a divisão Experiences and Devices da Microsoft, responsável por Windows, Microsoft 365, Outlook, Teams e Surface, vai migrar a maior parte dos engenheiros para fora das licenças diretas de Claude Code até 30 de junho. O substituto é o GitHub Copilot CLI, que ainda pode chamar o Claude por baixo, via camada de roteamento gerenciado. Internamente a Microsoft chama isso de “otimização de custo”. A leitura substantiva é outra.

É a primeira admissão pública de uma hyperscaler de que a economia unitária de IA agêntica não fecha aos preços atuais de token.

Pare para considerar quem está tomando a decisão. A Microsoft é a maior investidora individual da OpenAI. A Microsoft é dona do GitHub, o canal pelo qual a maior parte do tooling enterprise de IA para código é vendida. A Microsoft tem o bolso mais fundo de software. Se alguém poderia absorver a conta de token, é a Microsoft. E a divisão que está puxando o plugue não é back office. É a que entrega os produtos que pagam por tudo o mais. Quando a divisão mais bem dotada da empresa mais bem dotada de software do mundo começa a triar licenças de IA por ROI em vez de adoção, a mensagem não é sutil.

A história não é a Microsoft escolhendo Copilot CLI em vez de Claude Code. A história é que a governança de procurement virou a camada estrutural de qualquer estratégia de tooling de IA.

Os Números Que Ninguém Orçou

A reportagem do TheNextWeb trouxe pontos de dado que deveriam recalibrar toda conversa de orçamento de IA em 2026.

Engenheiros da Uber estão gastando entre US$500 e US$2.000 por mês, por pessoa, em tokens de IA para código. Palavras do próprio CTO: “o orçamento que eu achei que precisaria já foi varrido.” A Uber não é uma adotante tímida de IA. A Uber é o estudo de caso que empresas citam quando querem justificar adoção agressiva liderada por engenheiro. Essa mesma empresa está dizendo publicamente que a curva de gasto ultrapassou o modelo de planejamento.

O framework OpenClaw, que orquestra o Claude em loops agênticos estendidos, segundo os relatos consome de US$1.000 a US$5.000 por dia para usuários em planos de assinatura de US$200 por mês. Não é estouro de 10x. É estouro de 150x a 750x, por dia, contra o plano de tabela. Anthropic e outras estão absorvendo a diferença hoje porque a posição estratégica vale mais que a margem unitária. Esse subsídio tem uma data de validade que ninguém publicou.

O número da Gartner é o que deveria fazer todo CFO se endireitar na cadeira. Apenas 28% dos projetos de infraestrutura de IA entregam plenamente o business case. 25% dos orçamentos de IA planejados para 2026 devem escorregar para 2027. O escorregão não é problema de entrega. É problema de dinheiro. A conta chegou antes do valor.

Coloque esses números ao lado da retirada da Microsoft e a foto fica nítida. O fornecedor com o balanço mais forte, a integração mais profunda com o provedor do modelo, e os dados de adoção mais densos dentro dos próprios muros, acabou de decidir que licenciamento direto por seat para o agente de código mais querido da indústria não compensava na margem. Isso é sinal de procurement, não sinal de produto.

O Que a Microsoft de Fato Fez

As manchetes vão dizer que a Microsoft escolheu Copilot CLI em vez de Claude Code. Leia o movimento estruturalmente.

A Microsoft não bloqueou o Claude. O Copilot CLI continua roteando para o Claude quando a camada de roteamento julga que é o melhor modelo para a tarefa. O que a Microsoft removeu foi a licença direta por seat. Engenheiros deixam de ter assinatura ilimitada de Claude Code faturada fora de qualquer envelope de procurement. Passam a acessar o Claude por um cano gerenciado que a Microsoft controla, precifica e instrumenta.

É o padrão de procurement que a TI corporativa aplicou a toda onda anterior de tooling caro. Licenças de banco, plataformas de observabilidade, computação em nuvem. A primeira fase é “engenheiro pode reembolsar”. A segunda é “a conta comeu o orçamento”. A terceira é um gateway gerenciado onde o fornecedor segue sendo consumido, mas o gasto fica delimitado, atribuível e renegociável. A Microsoft acabou de comprimir as três fases em dezoito meses.

A hyperscaler rodando o playbook contra si mesma é a notícia. Todo CTO fora da Microsoft tem agora a mesma pergunta na mesa. Se a divisão de engenharia mais estrategicamente importante da Microsoft não conseguiu absorver seats diretos de Claude Code, quem na sua organização consegue?

A Trajetória Uber

O CTO da Uber não disse “erramos a conta”. Disse que o orçamento que ele achou que precisaria já foi varrido. O verbo é passivo. O custo não excedeu o forecast. O custo demoliu o forecast. É o que acontece quando uma organização compra tooling de IA por reembolso de despesa e descobre depois que o custo unitário é variável, o teto por engenheiro é aberto, e os provedores de modelo têm todo incentivo comercial para deixar o consumo subir até o fim do subsídio.

Toda empresa enterprise que deixa engenheiros reembolsarem ferramentas de IA sem governança de orçamento está na trajetória Uber. Queimar o orçamento do ano em quatro meses. Descobrir em maio que não sobrou envelope para o segundo semestre. Triar no susto. O momento da triagem é o que a Microsoft acabou de fazer em público. A maioria das enterprises vai fazer em privado, em agosto ou setembro, quando o financeiro puxar o livro de gasto de IA e reconciliar contra o plano original.

O padrão que defendemos há meses se aplica diretamente aqui. Quando um benchmark público chegou com teto padrão de US$100 por provedor por mês dentro do protocolo de procurement para agentes, o mercado estava dizendo aos times de plataforma interna como se parecem padrões disciplinados. A retirada da Microsoft é a mesma lição do mercado, recontada do lado da compra. O teto existe porque a curva de gasto, deixada solta, quebra o modelo.

O Que Continua de Pé

Três coisas seguem verdadeiras depois do anúncio da Microsoft, e são a fundação sobre a qual qualquer estratégia de tooling de IA precisa se apoiar agora.

Primeiro, o valor é real onde está governado. Engenheiros usando ferramentas de IA para código dentro de pipeline medido continuam entregando mais rápido que os mesmos engenheiros sem elas. A retirada é sobre seats sem teto, não sobre a capacidade subjacente. A capacidade ganha o próprio lugar quando o gasto tem teto e a saída tem medição.

Segundo, os provedores de modelo vão racionalizar. Anthropic, OpenAI e os demais não conseguem subsidiar estouros de 150x indefinidamente. Preços vão se mover. Rate limits vão apertar. Tiers de assinatura vão se fragmentar. As empresas que montaram fluxos internos de IA em cima dos preços atuais de tabela, sem plano para o dia em que esses preços se moverem, vão reprecificar toda a estratégia de IA no calendário de outra pessoa.

Segundo-e-meio: governança não é freio para adoção, é a condição da adoção sustentada. As organizações que entregam disciplina de procurement e de orçamento primeiro são as que continuam usando as ferramentas quando as outras precisam recuar. Argumentamos o mesmo quando a governança virou feature de produto. O padrão se repete: a disciplina que parecia overhead em 2025 é o kit de sobrevivência em 2026.

Terceiro, a pergunta de workload-harness fit importa mais, não menos. Se você gasta de US$500 a US$2.000 por engenheiro por mês em tokens de IA, a designação de qual carga roda em qual harness deixou de ser decisão de developer experience. Virou decisão de economia unitária. Toda carga que vai pelo harness mais caro quando um mais barato resolveria é linha de custo que o financeiro vai acabar achando.

O Que Fazer Agora

Pare o próximo ciclo de reembolso de ferramentas de IA até que seu CFO consiga responder a uma pergunta. Qual é o teto mensal publicado por engenheiro para ferramentas de IA de código, por ferramenta, por time, neste trimestre? Se a resposta é “não temos”, você está na trajetória Uber. A correção não é reunião. A correção é um teto escrito, uma camada de metering que o aplique, e um gateway gerenciado que roteie engenheiros por ele.

A Microsoft acabou de publicar a lição no maior volume possível. As empresas que ainda estarão rodando seu stack de tooling de IA no Q4 são as que levam essa lição a sério esta semana, não as que esperam o próprio financeiro tocar o alarme em agosto.

Fontes

TheNextWeb. “Microsoft retreats on Claude Code as AI costs bite.” Maio de 2026.

A Victorino ajuda times enterprise a montar a camada de governança de procurement e orçamento que transforma sprawl de ferramentas de IA em gasto medido e responsável: contato@victorino.com.br | www.victorino.com.br

O Loop Científico Tem Quatro Papéis. A IA Ocupa Só Um.

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

No dia 25 de maio, Alejandro Piad Morffis publicou um ensaio curto chamado AI is doing something weird to Science. Ele faz o que a maioria das análises sobre IA e ciência não faz. Recusa o binário “IA está substituindo cientistas” versus “IA é só uma ferramenta”. No lugar, decompõe o que cientistas de fato fazem em quatro papéis e pergunta quais deles sobrevivem ao contato com um modelo de linguagem grande.

Os quatro papéis são: poser, proposer, verifier, curator. Leia devagar. A maioria das discussões sobre IA em trabalho intelectual colapsa os quatro num único nome chamado “o humano” ou “o especialista”. Piad separa os papéis, e quando eles estão separados, fica óbvio qual sustenta a estrutura. Não é o que a maioria assume.

Isso importa muito além da ciência. Os mesmos quatro papéis estão presentes em revisão jurídica, análise financeira, produção de marketing e qualquer outro workflow intelectual em que a IA agora gera candidatos. Se a sua organização não consegue apontar o verificador, você não tem governança. Tem decoração.

O que Piad realmente propôs

Os quatro papéis, na estrutura do próprio Piad:

Poser. Decide o que vale a pena resolver. Nomeia a pergunta. Define o enquadramento. Na conta de Piad, esse papel permanece exclusivamente humano. Não porque LLMs não consigam gerar perguntas, mas porque a escolha de qual pergunta importa é um ato de gosto, julgamento e responsabilidade que nenhum modelo sustenta.

Proposer. Gera candidatos a solução, rápido. É onde o LLM mora. Piad é preciso sobre o título: “Não descobridor, não autor, não cientista. O que gera candidatos rápido o bastante para o verificador achar algo no palheiro.” O trabalho do proposer é volume e variedade, não correção.

Verifier. Checa se um candidato é de fato verdadeiro. Nos quatro casos documentados por Piad, o verificador nunca é outro LLM. É lógica formal (Lean), um checador combinatório de provas, um experimento de laboratório, uma medição de cristalografia. O verificador não pode ser enganado por falsidades plausíveis, que é exatamente o que LLMs produzem com excelência.

Curator. Decide quais candidatos que sobreviveram merecem ser perseguidos adiante. Aqui o papel volta a ser humano. O verificador diz que algo é verdadeiro; o curador diz que é interessante, que cabe num programa de pesquisa, que avança o campo. Verdade é necessária, mas não suficiente.

A frase central de Piad é direta: “O verificador é o que importa. Um loop com um proposer fraco e um verifier forte ainda produz ciência válida, só que devagar.” Inverta a frase e a implicação é brutal. Um loop com proposer forte e verifier fraco produz besteira rápida em escala.

Os casos não são novos. A nomeação é.

Piad percorre quatro exemplos. O trabalho de Claude’s Cycles em combinatória, em que o Claude propôs construções candidatas e um checador formal verificou. A matemática de Terence Tao assistida por Lean, em que Tao dirige a pergunta e cura o resultado enquanto o Lean faz a verificação. AlphaFold, em que o modelo propõe estruturas de proteínas e a cristalografia verifica. GNoME, em que o modelo propõe materiais candidatos e a síntese física verifica.

Ele também volta a 1976. A prova de Appel-Haken do teorema das quatro cores usou a mesma estrutura de loop: um humano colocou a pergunta, um programa gerou configurações candidatas, um verificador checou cada uma e humanos curaram o resultado sobrevivente numa prova. Estamos rodando esse loop há cinquenta anos. Só nunca tínhamos nomeado os papéis.

Esse é o movimento que torna o ensaio útil. Piad não descobriu uma arquitetura nova. Deu nome a um padrão que já estava rodando, e quando o padrão tem nome, dá para testar.

O teste, exportado

Pegue os quatro papéis para qualquer aplicação de IA fora da ciência e pergunte:

Revisão jurídica. Um escritório usa um LLM para resumir contratos e sinalizar riscos. Quem é o poser? (O sócio que decide quais cláusulas importam.) Quem é o proposer? (O modelo.) Quem é o verifier? (Aqui fica desconfortável. Frequentemente a resposta é “outro associado lendo o resumo”, que é só um proposer mais lento. Um verificador real seria um motor de regras no nível da cláusula, um checador de citações contra jurisprudência, um diff estruturado contra um template conhecido como bom.) Quem é o curator? (O sócio de novo, decidindo quais riscos sinalizados merecem conversa com o cliente.)

A maioria das aplicações de IA jurídica hoje tem poser, proposer, curator, e nenhum verifier. O associado faz teatro de verificação. O modelo produz falsidades plausíveis. O associado, sob pressão de tempo, lê o texto como resumo competente. O curador herda material não verificado como se tivesse sido verificado.

Análise financeira. Mesmo exercício. Quem coloca a pergunta? (O CFO.) Quem propõe a análise? (O modelo rodando sobre os dados.) Quem verifica? (Um motor de reconciliação, um cálculo determinístico, uma referência cruzada contra o razão original. Não outro LLM “checando” o primeiro.) Quem cura? (O CFO, de novo.)

Quando o verificador falta, times financeiros acabam com narrativas elegantes que não citam nada checável. O padrão sobre o qual Piad alerta na ciência aparece idêntico na sala de diretoria.

Produção de marketing. Um time usa IA para produzir cem variações de anúncio. Poser: estrategista da marca. Proposer: o modelo. Verifier: … checagem de conformidade com brand guidelines? Revisão jurídica? Teste A/B contra comportamento real de usuário? A maioria dos times pula direto do proposer para o curator e chama o olho do diretor de criação de verificador. O diretor de criação não escala para cem variações, então a verificação silenciosamente não acontece.

Nos três casos, o modo de falha é o mesmo: um LLM faz proposer e verifier ao mesmo tempo. O framework de Piad nomeia por que isso não pode funcionar. O proposer otimiza para plausibilidade. O verifier precisa otimizar para verdade. Você não faz as duas coisas com o mesmo instrumento.

Por que “humano no loop” é a abstração errada

A maioria dos frameworks de governança de IA exige um “humano no loop”. A decomposição de Piad expõe a imprecisão. Qual humano? Fazendo qual trabalho? Em qual estágio?

Um humano agindo como curator depois que o verifier fez seu trabalho é governança. Um humano agindo como poser antes do proposer rodar é governança. Um humano agindo como verifier sobre a saída de um proposer LLM, sem infraestrutura de checagem formal por trás dele, é performance. Está sendo pedido que ele faça, lendo, o que um sistema não-LLM precisa fazer por construção.

É por isso que tantas aplicações de “revisão humana” degradam. Os revisores são honestos. Também são humanos, cansados, lendo prosa plausível. Não conseguem verificar o que o sistema não tornou verificável.

O que fazer esta semana

Três ações, ordenadas por alavancagem:

Rode o teste dos quatro papéis no seu workflow de IA mais usado. Escreva os quatro nomes. Atribua cada um a uma pessoa ou sistema. Se o slot do verifier é “o humano revisando o output”, você não tem verificador.
Nomeie o que precisaria ser verdade para um verificador real existir. Raramente é outra IA. Normalmente é um motor de regras, um checador formal, um sistema determinístico de registro ou um ambiente de teste. Frequentemente ainda não existe. Esse é o trabalho.
Pare de chamar revisores de “verificadores”. Revisores são curadores. Decidem o que merece atenção. Não estão equipados para pegar falsidades plausíveis em escala. A honestidade da nomeação por si só muda como líderes alocam orçamento.

Piad nos deu uma ferramenta. A ferramenta é pequena o bastante para usar numa segunda-feira e afiada o bastante para expor onde a governança termina e o teatro começa.

Fontes

blog.apiad.net. “AI is doing something weird to Science,” por Alejandro Piad Morffis. Maio de 2026.

A Victorino ajuda times de liderança a exportar o teste dos quatro papéis de Piad para workflows jurídicos, financeiros e de marketing, nomeando o verificador independente que transforma “humano no loop” de postura em estrutura: contato@victorino.com.br | www.victorino.com.br

SaaStr Construiu uma VP de Sucesso do Cliente com IA no Replit. Sem Engenheiros.

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Amelia é Chief AI Officer da SaaStr. Ela construiu a Qbee, uma VP de Sucesso do Cliente movida a IA, dentro do Replit. Sem engenheiros. A Qbee hoje gerencia mais de 100 patrocinadores de eventos com 70% menos horas humanas e um aumento de 10x no engajamento, comparado à ferramenta legada que existia antes.

A tentação é ler isso como uma história de sucesso de vibe-coding. Uma operadora não-técnica coloca um sistema em produção, o futuro chegou, qualquer um agora constrói software. Essa leitura erra o ponto.

A história da Qbee é interessante porque documenta como é produção quando quem constrói não é engenheiro. O artefato não é o código. O artefato é a disciplina operacional diária. E essa disciplina é a mesma que líderes de engenharia vêm descrevendo o ano inteiro, traduzida para uma função que nunca precisou pensar dessa forma.

A economia não é a história

Jason Lemkin compartilhou os números em um post recente da SaaStr. O custo combinado de tokens entre todos os apps vibe-coded da SaaStr é menor que US$ 200 por mês. A matemática é absurda no melhor sentido. Uma função de nível VP que custaria salário, benefícios, equity e overhead de gestão, substituída por um app no Replit rodando em consumo de tokens.

Mas barato não é a lição. Muito software barato falha em produção. A lição é o que fez a Qbee sobreviver ao contato com 100 patrocinadores pagantes.

Três padrões operacionais. Nenhum deles é técnico.

Padrão um: construa o dashboard antes do agente

O primeiro movimento da SaaStr na Qbee não foi o agente. Foi o dashboard. Uma tela central que mostra o estado de cada patrocinador: em que ponto da jornada está, o que está atrasado, o que está em risco, o que acabou de ser entregue. O agente veio depois, construído contra o dashboard.

Essa sequência importa. O dashboard é a especificação. É o artefato visível que permite a uma não-engenheira raciocinar se o agente está fazendo a coisa certa em um dado dia. Sem ele, o agente é uma caixa-preta. Com ele, o agente é uma funcionária mensurável.

Compare isso ao padrão típico em engenharia, onde o sistema é construído primeiro e a observabilidade é enxertada depois. Amelia inverteu a ordem porque não tinha o instinto técnico de adiar a observabilidade. Ela precisava enxergar o trabalho antes de confiar qualquer automação contra ele.

Esse padrão é transferível. Se você lidera marketing, jurídico ou operações financeiras e pensa em colocar um agente autônomo na sua função, construa primeiro o dashboard. Torne o trabalho visível para um revisor humano em uma única tela. Depois aponte o agente para ela.

Padrão dois: agent hopping para dados sensíveis

O padrão mais silenciosamente importante no post da Qbee é o que Lemkin chama de agent hopping. Dados sensíveis, contratos, finanças internas, compromissos de patrocinadores, não vivem no contexto do agente. Vivem nos sistemas seguros onde devem viver. A Qbee chama APIs para ler e escrever nesses sistemas, mas nunca segura os dados brutos em memória ou em prompts.

Essa é a versão de sucesso do cliente de um padrão que levou dois anos para times de engenharia internalizarem: o agente é um coordenador, não um cofre. O estado de registro fica nos sistemas de registro. O agente se move entre eles.

Para líderes fora da engenharia, isso reformula a conversa de segurança de dados por completo. A pergunta não é “é seguro colocar nossos dados de cliente em um LLM”. A pergunta é “conseguimos estruturar o trabalho de forma que o agente nunca toque os dados brutos, apenas as operações sobre eles”. A resposta à primeira pergunta é frequentemente não. A resposta à segunda é geralmente sim.

Isso conecta diretamente ao problema de encaixe entre workload e harness que viemos acompanhando. O harness é o que torna o workload seguro. Agent hopping é um padrão de harness. É o que permite a uma ferramenta construída no Replit gerenciar contratos reais de patrocínio sem virar um vazamento de dados.

Padrão três: quatro a seis pontos de personalização por mensagem

A terceira regra operacional da SaaStr é aquela em que a maioria dos times vai falhar. Cada mensagem que a Qbee envia carrega de quatro a seis pontos únicos de personalização. Não merge tags. Não “Olá {primeiro_nome}”. Sinais reais extraídos do comportamento do patrocinador, histórico, tier, estado atual e interações recentes.

Esse é o trabalho que separa um agente autônomo de verdade de um mail merge sofisticado. E é o trabalho que explica o número de 10x no engajamento. Patrocinadores respondem porque as mensagens lêem como escritas especificamente para eles, porque foram.

A disciplina aqui não é técnica. É editorial. Alguém precisa decidir quais sinais importam, quais combinações fazem uma mensagem parecer pessoal em vez de invasiva e quais sinais estão fora do limite. Times de engenharia não têm como tomar essas decisões. O dono da função precisa tomar.

Esse é o mesmo padrão que identificamos no lançamento do Composer da Klaviyo: governança de agente de marketing exige julgamento de marketing, não julgamento de engenharia. A Qbee estende isso para sucesso do cliente. Governança de agente de CS exige julgamento de CS sobre quais sinais constituem cuidado e quais beiram a vigilância.

A disciplina de envio

A SaaStr também envia um cliente por tier primeiro. Não jogam a lista inteira de patrocinadores na Qbee no dia um. Escolhem um patrocinador em cada tier (topo, meio, base), rodam o agente contra esses três e observam o que acontece por uma semana. Depois expandem.

Isso é canary deployment traduzido para trabalho voltado ao cliente. O custo de um release ruim em engenharia é um rollback. O custo de um release ruim em sucesso do cliente é um patrocinador que se sente maltratado, possivelmente em público. O ritmo de envio precisa ser mais lento e mais deliberado, porque o raio de impacto é humano.

Manutenção diária é o outro inegociável. A Qbee não é um sistema de “ligar e esquecer”. Amelia checa o dashboard todo dia. Ajusta prompts, aposenta padrões que falharam, adiciona novos sinais conforme a base de patrocinadores evolui. O agente não roda sozinho. O agente roda o trabalho, e uma humana roda o agente.

Isso conecta ao padrão mais amplo sobre o qual viemos escrevendo. Governança vira feature de produto. Na escala da Qbee, governança vira uma revisão diária de 30 minutos. Instanciações diferentes, mesmo princípio: a disciplina operacional é o que torna a autonomia sustentável.

O que isso significa para todos os outros

A síntese de Lemkin sobre a oportunidade merece ser citada na íntegra:

“A distância entre o que clientes precisam e o que CSMs conseguem humanamente entregar é o lugar mais valioso para implantar IA no seu negócio B2B agora.”

Ele tem razão sobre a oportunidade. A parte interessante é que a mesma lógica se aplica a toda função onde a distância entre necessidade do cliente e capacidade humana virou constrangedora. Suporte. Onboarding. Renovação. Account management. Programas de parceria.

Em cada uma dessas funções, o playbook da Qbee transfere:

Construa o dashboard primeiro. Torne o trabalho visível.
Desenhe para agent hopping. Dados sensíveis nunca entram no agente.
Exija quatro a seis pontos de personalização por mensagem enviada.
Envie um cliente por tier. Expanda por evidência.
Trate manutenção diária como inegociável.

Nenhuma dessas é disciplina técnica. Todas são disciplinas operacionais que o dono da função precisa assumir. O app no Replit é a parte fácil. A disciplina é a parte difícil.

Faça isso agora

Se você lidera uma função fora da engenharia e está pensando em um agente autônomo para um fluxo recorrente, de alto volume, intensivo em personalização, não comece pelo agente. Comece pelo dashboard. Passe uma semana esboçando a tela que permitiria a você, em uma segunda-feira qualquer, ver o estado do trabalho e responder “o agente está dentro ou fora do trilho”. Se você não consegue desenhar essa tela, ainda não está pronto para enviar o agente. Se consegue, está na metade do caminho. A outra metade são os 30 minutos diários que você se compromete a dedicar para rodá-lo.

Fontes

SaaStr. “Top 10 Learnings From Building Our Own AI VP of Customer Success: Qbee,” por Jason Lemkin. Maio de 2026.

A Victorino ajuda times fora da engenharia a colocar agentes autônomos em produção com a disciplina operacional diária que transforma a lacuna entre necessidade do cliente e capacidade humana em cobertura mensurável e governada: contato@victorino.com.br | www.victorino.com.br

benn.substack Acaba de Nomear o que a Releezy Entrega: 'Vitórias Acima do Claude.'

Thiago Victorino — Tue, 26 May 2026 00:00:00 GMT

Divulgação antes do argumento. A Victorino vende medição relativa à baseline para trabalho com IA. É justamente por isso que este texto existe: um analista de fora acabou de nomear a unidade que entregamos, e prefiro citar ele do que a mim mesmo.

No dia 22 de maio, a benn.substack publicou um ensaio chamado “WAC”. A sigla vem do beisebol, onde “Wins Above Replacement” mede quantas vitórias adicionais um jogador entrega em relação ao substituto genérico que viria da liga de acesso. Benn propõe um análogo para compra de software. Wins Above Claude. Vitórias Acima do Claude. Valor gerado acima do que o Claude default integrado com seus MCPs já entrega de fábrica, antes de qualquer wrapper, agente ou “feature de IA” vendida por fornecedor entrar no jogo.

O enquadramento é amigável para compras, levemente sarcástico, e estruturalmente correto. Também encerra um debate que a indústria vinha evitando.

A era do benchmark acabou porque a baseline andou

Benchmarks comparam modelos contra um conjunto de testes fixo. O teste é constante. O modelo é a variável. Esse regime funcionava enquanto modelos de fronteira avançavam uma ou duas vezes por ano. Não funciona mais. Benn cita o llm-stats.com: 62 modelos de IA lançados em 126 dias. A constante deixou de ser constante. Qualquer pontuação de benchmark com data de publicação acima de seis semanas está descrevendo uma indústria diferente.

Pior: benchmarks avaliam modelos em condição de teste. A decisão de compra é sobre entregáveis produzidos dentro das ferramentas, da cultura, do código e do fluxo de trabalho da empresa. Nada disso está no benchmark. Um modelo que pontua 78% no SWE-bench pode ser inútil dentro de um monorepo específico, com um sistema de build específico, sob uma cultura de code review específica. Um modelo de 62% pode ser transformador no mesmo ambiente. O benchmark não consegue dizer qual.

A WAC consertou o lado errado da equação. Em vez de fixar o teste e variar o modelo, você fixa o contexto de implantação, sua empresa, suas ferramentas, seus fluxos, e varia o que entra em campo. A baseline passa a ser “o Claude default com os MCPs padrão, trabalhando nos seus problemas reais”. Qualquer fornecedor vendendo um agente, um wrapper ou uma feature de IA precisa demonstrar valor acima dessa baseline. Não contra uma avaliação sintética. Contra a coisa que o comprador já consegue contratar sozinho por US$ 20 por assento.

Por que isso generaliza além do Claude

A sigla é simpática, mas o princípio é portátil. Troque por qualquer default suficientemente capaz. Vitórias Acima do ChatGPT Enterprise. Vitórias Acima do Gemini Workspace. Vitórias Acima do Copilot. A mecânica é a mesma: já existe um assistente baseline dentro do fluxo de trabalho que entrega uma fração não-trivial do serviço, e a única medição honesta é o ganho marginal que um fornecedor pago adiciona em cima dele.

Isso não é hipotético. Pergunte a qualquer líder de engenharia o que os desenvolvedores efetivamente usam no dia a dia. A resposta envolve Claude, ChatGPT ou Copilot mais vezes do que qualquer ferramenta de IA aprovada pela área de compras. A baseline já está lá. Só não está no placar.

Essa é a consequência para a área de compras. Toda pitch de fornecedor de “produtividade com IA” em 2026 está vendendo um delta. A maior parte está fingindo que a baseline é zero. A contribuição do benn é nomear a mentira em voz alta. A baseline não é zero. A baseline é o que o assistente default já entrega dentro do seu contexto, e você precisa medir antes de avaliar a promessa de melhoria de qualquer fornecedor.

A analogia com contratação, que é a parte mais útil

Benn aponta a prática de contratação da Linear. Trials remunerados de dois a cinco dias, em vez de entrevistas tradicionais. O candidato executa trabalho real, no código real, com o time real, e o time mede saída real. Passou no trial, é contratado. Não passou, recebe pelo trabalho feito e a separação é respeitosa.

Por que isso importa para compra de IA: resolve o mesmo problema que os benchmarks não resolveram. Você não consegue avaliar um candidato, humano ou IA, no vácuo. A performance é contextual. Depende do código, das ferramentas, das normas do time, da cultura de revisão. A Linear descobriu que a única forma de saber se um engenheiro sênior é de fato sênior no contexto deles é colocá-lo no contexto e medir saída. O mesmo vale para um fornecedor de IA. A única forma de saber se um agente entrega valor acima da baseline do Claude no seu ambiente é implantá-lo no seu ambiente, ao lado da baseline, e medir.

A implicação: toda decisão relevante de compra de IA nos próximos 18 meses vai envolver alguma versão de trial remunerado. Não uma demo. Não um slideshow de prova de conceito. Uma implantação real, com trabalho real designado, medida contra a baseline, por tempo suficiente para gerar confiança estatística. Fornecedores que recusam esse formato estão dizendo que o delta deles não sobrevive ao contato com a realidade.

O que o comprador efetivamente precisa construir

WAC como expressão faz trabalho real. WAC como sistema de medição é mais difícil, e é aqui que a maior parte das empresas vai descobrir o custo de ter evitado o problema.

Para medir Vitórias Acima do Claude, o comprador precisa de quatro coisas que provavelmente não tem. Primeira, uma definição do que “vencer” significa para o trabalho em questão (tickets entregues, casos resolvidos, leads qualificados, contratos minutados, a unidade varia). Segunda, uma baseline instrumentada da versão “assistente default” desse trabalho ao longo de uma janela de tempo crível (semanas, não horas). Terceira, uma amostra do mesmo trabalho executada com a ferramenta do fornecedor no lugar, idealmente em split A/B ou sequencial sob condições pareadas. Quarta, um modelo de atribuição que sobrevive aos confundidores óbvios (diferenças de habilidade entre operadores, mix de dificuldade dos tickets, efeitos de calendário).

Isso não é benchmark. É infraestrutura operacional de medição. A maior parte das empresas também não opera essa infraestrutura para times humanos, e parte de por que o problema parece estranho aplicado à IA está aí. O Google acabou de expandir a caixa de busca pela primeira vez em 25 anos para acomodar queries de IA mais longas. A interface mudou porque o comportamento mudou. A interface de medição também precisa mudar. WAC é a versão do lado do comprador dessa mudança de interface.

Por que estamos reivindicando isso agora

A razão de termos publicado este texto na mesma semana que o benn é que “Vitórias Acima do Claude” é o nome do lado comprador para o que a Victorino vinha argumentando do lado vendedor há nove meses. Chamamos de medição relativa à baseline, ganho sobre o default, agente versus piso. Nenhum desses pegou. WAC vai pegar, porque a comunidade compradora de IA já está treinada em benchmarks, e substituto de benchmark ganha tração mais rápido do que categoria nova.

Prefiro operar dentro do vocabulário do benn do que do meu. O trabalho é o mesmo. Meça a baseline antes de acreditar na promessa. Construa o harness de trial antes de assinar contrato. Trate qualquer fornecedor que não passa em trial estilo Linear no seu contexto como fornecedor que não testou o próprio discurso.

Uma ressalva. O perigo de nomear uma categoria é que a categoria se dilui. “WAC-compliant” vai aparecer em deck de fornecedor dentro de um trimestre, e a maior parte desses decks vai estar vendendo o número errado. A defesa é mecânica, não retórica. Se o fornecedor não consegue descrever (a) qual é a sua baseline, (b) como ela foi medida, © em que janela, (d) qual delta ele reivindica em cima dela, com qual confiança, o selo WAC é decorativo. Faça as quatro perguntas sempre.

Faça isto agora

Antes da próxima reunião com fornecedor de IA, rode um exercício de três passos. Escolha um fluxo de trabalho que você está cogitando pagar para melhorar. Meça como o assistente default Claude ou ChatGPT performa nesse fluxo nas próximas duas semanas, instrumentado, com pelo menos três operadores. Essa é a sua baseline. Agora exija que todo fornecedor que entrar reivindique um delta específico acima desse número, com janela de medição proposta e intervalo de confiança. Quem articula isso ganha trial remunerado. Quem não articula ganha uma reunião de retorno depois que se organizar.

A forma mais rápida de tornar a compra de IA honesta é parar de deixar a baseline invisível. O benn acabou de dar nome à baseline. Use.

Fontes

benn.substack. “WAC (Wins Above Claude).” Maio de 2026.

A Victorino ajuda times de compra e venda a construir a medição relativa à baseline que transforma promessas de fornecedores de IA em deltas verificáveis: contato@victorino.com.br | www.victorino.com.br

Quando a Microsoft não absorve a conta, seu CFO já decidiu

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

Três sinais independentes caíram em dez dias. Eles não se anunciam como relacionados. São.

Em 14 de maio, o The Verge reportou que a Microsoft está cancelando licenças do Claude Code para milhares de engenheiros da organização Experiences and Devices. Windows. Microsoft 365. Outlook. Teams. Surface. As licenças foram distribuídas em dezembro de 2025. Menos de seis meses depois, fontes internas disseram a Tom Warren que o corte estava marcado para o fim de junho de 2026, e que a decisão era, ao menos em parte, financeira.

Em 19 de maio, James Wang, no Weighty Thoughts, publicou uma análise mostrando que de 67% a 75% da queda anual de preço em inferência vem de software, não de hardware. O mesmo texto reporta que o Qwen 3.6 27B, modelo open-weight rodando em uma RTX 3090 Ti de 2022, hoje empata com o Claude Sonnet em tarefas relevantes para produção: briefings diários, anotação de gráficos e triagem de pesquisa.

Em 24 de maio, o TheNextWeb confirmou que a DeepSeek tornou permanente o corte de 75% no V4 Pro. Novo piso: US$ 0,003625 por milhão de tokens de input, US$ 0,87 por milhão de output. A mesma carga que custa US$ 2,50 in / US$ 10,00 out no GPT-5, ou US$ 5,00 / US$ 25,00 no Claude Opus 4.7, agora roda em um modelo de fronteira chinês por frações de centavo.

Lidos nos dias em que saíram, são três conversas diferentes. Lidos juntos, são uma só: a premissa de que o preço de API fechada na fronteira é o piso do seu custo de IA acabou de quebrar. A Microsoft, a empresa com o maior desconto possível com o segundo maior fornecedor do mercado, decidiu que a conta estava alta demais. Esse é o canário.

A maioria do barateamento é software, e isso muda a estrutura

O número que importa na análise do Wang não é a manchete da queda. É a decomposição.

Por três anos, “LLMflation” foi tratada como história de hardware. Chips melhores, mais chips, roadmap da Nvidia, yield da TSMC. A narrativa de “1000x em três anos” de Guido Appenzeller carregava essa premissa implícita. O que estava barateando era silício. Bastava esperar o próximo nó e a próxima geração.

A medição do Wang inverte isso. De dois terços a três quartos do barateamento vem de software: eficiência de dados de treino, destilação, roteamento MoE, decodificação especulativa, compressão de KV-cache, quantização e o próprio stack de inferência. O hardware contribui com o restante.

Isso importa por uma razão. Ganho de hardware compõe no ritmo da fundição, e quem captura é a nuvem dona do silício. Ganho de software compõe no ritmo da comunidade open-source, e quem captura é quem consegue rodar inferência, inclusive você, em hardware commodity, no seu datacenter. Quando a curva é puxada por software, on-prem deixa de ser penalidade de custo. Vira opção de paridade com superfície de controle diferente.

E essa paridade já não é teórica. A afirmação do Wang é específica. Qwen 3.6 27B em uma GPU gamer de quatro anos empata com o Sonnet em três famílias de tarefa nomeadas. Não em benchmarks de código. Não em olimpíadas de matemática. Nas cargas reais que a maioria das empresas compra modelo de fronteira para fazer: resumo de briefing, leitura de gráfico, triagem de pesquisa. O custo de hardware da paridade é uma 3090 Ti usada, cerca de US$ 700 no mercado secundário. O custo recorrente é eletricidade, que o Wang precifica em US$ 0,20 a US$ 0,50 por milhão de tokens em inferência open-weight na nuvem.

Por três anos, o argumento de on-prem foi “talvez você economize em dois anos se a hyperscaler continuar subindo preço”. Para o Q3 de 2026, o argumento é “você empata com a saída da API fechada hoje, a custo de eletricidade, em hardware que talvez você já tenha”.

A Microsoft é o canário

Agora sobreponha o sinal do Verge. A Microsoft tem os melhores termos comerciais possíveis com a Anthropic. É o bolso mais fundo da indústria. Seus desenvolvedores são, possivelmente, os usuários corporativos mais agressivos de IA no mundo. E ela decidiu que a conta de Claude Code por assento, seis meses depois, não fechava.

A matéria do Verge é cuidadosa. Cita duas razões: o alinhamento estratégico da Microsoft com suas próprias ferramentas internas de código e integrações OpenAI, e o custo. As duas não se separam. A razão de custo existe porque as alternativas são reais. Se a Anthropic fosse o único fornecedor viável de fronteira, a Microsoft absorveria a conta como as empresas absorveram Oracle por duas décadas. Não é, e a Microsoft fez a matemática.

Essa matemática agora está disponível para qualquer CFO. Se a Microsoft não absorve uma conta de Claude Code por assento na escala de hyperscaler, sua área financeira não deveria assumir que a sua casa absorve na escala corporativa. A pergunta certa deixou de ser “quanto a gente consegue negociar o preço por assento”. Virou “qual é o portfólio multi-modelo que nos mantém dentro do envelope de custo quando nosso uso dobrar, e ele vai dobrar”.

Esse é o ponto de convergência. DeepSeek mostra que o piso da API fechada está se movendo. Wang mostra que o teto open-weight alcançou tarefas reais. Microsoft mostra que o maior cliente do mercado já está roteando por fora. Três sinais, três fontes, uma conclusão: IA fechada, fornecedor único, virou posição, não default.

Framework de avaliação para o Q3 de 2026

Um framework que sobrevive a essa reprecificação tem três camadas. Não são glamourosas. São o que sua área financeira vai pedir no próximo trimestre.

Camada um: benchmark de custo por tarefa, não por assento. Pare de precificar IA por assento. Precifique por tarefa. Um resumo de briefing diário de 8.000 tokens in e 1.500 tokens out custa US$ 0,035 no Claude Opus 4.7, US$ 0,012 no GPT-5, US$ 0,001 no Gemini 3.5 Flash, e essencialmente eletricidade em um Qwen self-hosted. Multiplique pelo seu volume semanal e a licença por assento vira erro de arredondamento ou prêmio de 10x, dependendo de qual tarefa em qual modelo. Sua área financeira precisa ver essa grade antes da próxima renovação.

Camada dois: portfólio de três faixas de modelo, roteado por tarefa. Faixa um é fronteira-fechada (Claude, GPT-5, Gemini Pro) para o trabalho que realmente exige o teto: raciocínio novo, geração de alto risco, orquestração complexa de ferramentas. Faixa dois é fechada-média (Flash, Haiku, GPT-5 mini) para o alto volume de rotina: extração, classificação, formatação, drafts simples. Faixa três é open-weight self-hosted ou cloud barata (Qwen, Llama, DeepSeek) para as cargas onde a paridade do Wang se sustenta: briefing, triagem, anotação, Q&A interno. A lógica de roteamento é a camada de governança. Sem ela, você vai de default para a faixa um em tudo e paga a conta da Microsoft.

Camada três: avaliação de on-prem, com números reais. Não slide de estratégia. Modelo real de compra. Quanto custa subir um nó único de inferência capaz de servir 100 usuários internos no Qwen 3.6 27B? Hardware: US$ 4.000 a US$ 8.000 por servidor GPU de geração atual. Energia: US$ 300 a US$ 600 por mês. Engenharia: um engenheiro de infraestrutura a 20% de alocação no primeiro trimestre, 5% em regime permanente. Total Ano 1: US$ 40.000 a US$ 70.000. Compare com 100 assentos de Claude Code a US$ 200 por assento por mês, que dá US$ 240.000 por ano. A matemática não exige otimismo. Exige aritmética.

Faça isto agora

Três ações, neste trimestre, antes que o orçamento do Q3 feche.

Primeira: liste suas 10 maiores cargas de IA por volume de tarefa e modelo atual. Se você não tem essa lista, seu orçamento de IA é opinião, não medição. Monte a grade.

Segunda: rode um teste paralelo de inferência por uma semana nas três maiores cargas, usando um modelo de fronteira, um modelo de custo médio e um open-weight. Pontue por qualidade de saída, latência e custo por tarefa. O resultado vai te surpreender em pelo menos uma direção. Sempre surpreende.

Terceira: peça à sua equipe de infraestrutura um modelo de custo on-prem de uma página para as cargas onde a paridade open-weight se sustenta. Não é compromisso. É número. Coloque ele ao lado da cotação de renovação da API fechada quando ela chegar.

Os líderes que sobrevivem à reprecificação da curva de custo não vão ser os que escolheram o fornecedor certo em 2024. Vão ser aqueles cujo portfólio foi construído para assumir que o piso ia se mover, o teto ia descer, e o maior cliente do mercado ia fazer a conta antes deles. O cancelamento da Microsoft não é exceção. É indicador líder. Os CFOs que leram o sinal em maio vão renegociar em julho. Os que não leram vão absorver a conta até a sangria forçar a conversa.

A decisão que a Microsoft tomou em maio é a decisão que seu CFO vai tomar até o Q4. Se você traz o framework ou se o framework é imposto sobre você, isso é a única coisa ainda aberta.

Fontes

TheNextWeb. “DeepSeek V4 Pro 75 Percent Price Cut Permanent.” Maio de 2026.
Weighty Thoughts. “AI’s Plummeting Prices Are a Software Story.” Maio de 2026.
The Verge. “Microsoft Starts Canceling Claude Code Licenses.” Maio de 2026.

A Victorino apoia líderes de finanças e engenharia no desenho de portfólios multi-modelo de IA que sobrevivem à reprecificação da curva de custo: contato@victorino.com.br | www.victorino.com.br

Agentic-Agile: Contratos, Não Cerimônias

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

Daniel Epstein, Partner Tech Strategist na Microsoft, publicou um artigo em maio de 2026 defendendo que o desenvolvimento de agentes precisa de Agile. Não de prompt engineering. Não de modelos melhores. Agile. Issues com critérios de aceitação. Portões de revisão. Arquivos de instrução persistentes. Backlogs spec-first. A Microsoft chegou a publicar um repositório de template para operacionalizar a posição.

Lido ao lado do caso da PFF do mesmo mês, o argumento parece dar curto-circuito. A PFF deletou as dailies, o sprint planning, o refinamento, as retrospectivas e o papel de product manager. Dois engenheiros com agentes superaram um time de dez. Então qual é a resposta: o Agile sobrevive à era dos agentes ou não?

Os dois, porque Agile nunca foi uma coisa só.

Agile Sempre Foi Duas Coisas

Releia qualquer retrospectiva do Manifesto Ágil de 2001 e você encontra um rótulo único cobrindo duas máquinas muito diferentes ligadas no mesmo cabo.

A primeira é a pilha de coordenação. Dailies, sprint planning, refinamento, retrospectivas, demo days, gráficos de capacidade. Todo artefato dessa camada responde a uma pergunta sobre humanos: quando você está livre, o que está te bloqueando, quanto trabalho uma pessoa consegue segurar na cabeça por quatorze dias, como evitamos que o time queime. A pilha de coordenação é ergonomia. Otimiza a atenção humana escassa, lenta e opinativa para que um grupo pequeno de engenheiros consiga entregar software coerente sem se atropelar.

A segunda é a pilha de contrato. Issues com critérios de aceitação, definition of done, documentos de design, contratos de API, especificações de teste, checklists de revisão, arquivos de instrução persistentes. Todo artefato dessa camada responde a uma pergunta sobre o trabalho em si: o que essa mudança significa, como sabemos que está correta, o que não pode quebrar, o que precisa continuar verdadeiro depois do merge. A pilha de contrato é especificação. Codifica intenção com precisão suficiente para que outra pessoa, inclusive uma versão futura de você mesmo, execute sem ambiguidade.

Por vinte anos as duas pilhas pareceram uma só porque rodavam dentro da mesma cerimônia. A daily atualizava a coordenação e expunha lacunas no contrato ao mesmo tempo. A retro melhorava a coordenação e apertava contratos na mesma reunião. Separar as duas era desnecessário. Os agentes tornaram a separação necessária.

Por que os Agentes Derrubam a Pilha de Coordenação

Hora de engenheiro deixou de ser o recurso escasso.

Essa frase única é a história inteira. Cobrimos a evidência operacional em uma análise recente sobre a PFF e a inversão organizacional. Mike Spitz, CTO da Pro Football Focus, rodou um experimento de três meses no começo de 2026 em que dois engenheiros com agentes enfrentaram dez engenheiros sem eles. O time de dois entregou 25 vezes mais deploys, 10 vezes mais complexidade ponderada de tickets, e elevou o CSAT de uma linha de base de 7.5 para 8.6. No caminho, deletaram o papel de PM, o sprint planning, as dailies, o refinamento e as retrospectivas. A reunião curta de meia hora em dias alternados foi tudo que sobrou.

Isso é o que acontece quando o recurso que uma cerimônia protegia se torna abundante. A daily otimiza uma restrição, a velocidade de digitação humana coordenada entre agendas, que não vincula mais quando uma frota de agentes roda em paralelo. A pilha de coordenação não quebra de forma dramática. Ela simplesmente deixa de pagar o aluguel. As cerimônias viram teatro, e os líderes que continuam rodando por inércia estão pagando salário para manter rituais que protegiam uma restrição que se moveu.

Por que os Agentes Amplificam a Pilha de Contrato

O oposto é verdadeiro para a segunda pilha.

Epstein diz direto: “Isso não é um problema de modelo; é um problema de processo. Atualizar o modelo não resolve critérios de aceitação faltando.” O projeto Minthe que ele tocou expôs o modo de falha em um nível de detalhe que os entusiastas de prompt raramente encaram. Múltiplos agentes rodando em paralelo derivaram uns dos outros. O comportamento divergiu da spec. O código parecia correto isoladamente e incoerente no agregado. A única fonte estável de verdade que sobreviveu ao caos foi o tracker de issues do GitHub, onde os critérios de aceitação eram explícitos o bastante para ancorar cada agente de volta a uma definição única de pronto.

A razão é estrutural. Um engenheiro humano com um ticket vago faz uma pergunta, puxa o PM para o corredor, ou simplesmente toma uma decisão de bom senso baseada em anos de contexto sobre o produto. Um agente com um ticket vago inventa uma resposta. Ele não tem contexto compartilhado fora do artefato à frente dele. O artefato é o contrato. Se o contrato é frouxo, o agente preenche a folga com asneira plausível que compila, passa nos próprios testes e entrega regressão.

A outra frase de Epstein, a que vale imprimir e colar na parede: “Se você está pegando violações de arquitetura na revisão final em vez de durante a execução da história, sua governança chegou tarde.” Essa é a pilha de contrato dita como governança. Os critérios de aceitação, as restrições arquiteturais, os arquivos de instrução persistentes no repositório, os portões de revisão entre Plan, Issue, Implement, Review, Merge e Docs no template da Microsoft. Cada um desses artefatos move a intenção arquitetural de “revisão final” para “execução da história”, onde o agente pode de fato obedecer.

A pilha de contrato costumava ser um coadjuvante silencioso. Agora é a única coisa segurando o trabalho.

O Movimento: Promova a Camada de Contrato, Não Recoloque Cerimônias

O erro que a maior parte dos líderes está prestes a cometer é ler Epstein, entrar em pânico com os problemas de coerência que o Minthe expôs, e reparafusar a pilha de coordenação em cima de uma frota de agentes. Dailies com agentes. Sprint planning com agentes. Retros em que alguém apresenta métricas de agente. É movimento desperdiçado. A pilha de coordenação resolvia uma restrição que sumiu. Reinstalá-la não ajuda os agentes nem ajuda os humanos.

O movimento certo é o oposto. Promova a pilha de contrato a status operacional de primeira classe. Trate critério de aceitação com a seriedade que uma geração anterior reservou ao sprint planning. Faça dos arquivos de instrução persistentes artefatos versionados que circulam por pull request como código. Tire restrições arquiteturais do conhecimento tribal e coloque-as em regras legíveis por máquina que governam execução, não revisão. O diagrama de fases que a Microsoft entrega no template, Plan para Issue para Implement para Review para Merge para Docs, não é um fluxo que você adota porque parece arrumado. É um fluxo que você adota porque cada transição é um ponto onde a validação de contrato pode ser aplicada antes que a deriva acumule.

Dito de outra forma: o Agile não sobreviveu à era dos agentes. A metade contratual do Agile sobreviveu, e ela agora carrega a carga que a metade de coordenação dividia.

Isso Generaliza Para Além da Engenharia

A mesma decomposição aparece em todo lugar em que o modelo operacional começa a incluir agentes.

Times de marketing estão descobrindo que o briefing de campanha é o novo contrato. Onde uma analista júnior costumava preencher os espaços em branco com instinto de marca, um agente preenche com o que o briefing permite. Um briefing frouxo produz uma campanha tecnicamente dentro da spec e fora da marca. O briefing de marketing costumava ser o ponto de partida para uma conversa entre humanos. Está virando um artefato vinculante, o tipo que merece os mesmos portões de revisão que os engenheiros aplicam a decisões arquiteturais.

Times jurídicos estão rodando a mesma jogada. O formulário de intake de caso, o memo de deal, o documento de orientação para redlines. Costumavam ser contexto para uma associada humana. Estão virando o contrato que governa o que um agente pode minutar, marcar em vermelho ou escalar. Escritórios que investem em apertar artefatos de intake estão se distanciando dos demais. Escritórios que tratam intake como overhead administrativo estão vendo a saída do agente derivar para passivo.

Times de design são os próximos, e o artefato de contrato lá é o próprio design system. Um design system costumava ser um guia. Está virando a camada de regras que um agente operando no canvas precisa respeitar. Os times tratando seu design system como contrato versionado vão começar a parecer muito diferentes dos times que ainda o tratam como documentação.

A linha que atravessa os três é a mesma linha que traçamos na engenharia. O briefing é o contrato. O contrato é a superfície de governança. O agente é o executor. Promova a camada de contrato ou aceite a deriva.

Faça Isso Agora

Escolha uma frente de trabalho que já tem agentes operando. Engenharia serve. Campanhas de marketing, intake jurídico ou enforcement de design system funcionam igualmente bem.

No próximo sprint ou na próxima semana, faça exatamente uma coisa: pegue o artefato que o agente trata como fonte de verdade, seja um ticket, um briefing, um formulário de intake ou um arquivo de tokens do design system, e reescreva com critérios de aceitação completos. Não só “o que deveria acontecer”, mas “o que não pode acontecer”, “o que precisa continuar verdadeiro depois do trabalho concluído” e “o que conta como evidência”. Depois, faça todo agente rodar gate contra esse artefato antes de mergear, publicar ou protocolar.

Você vai descobrir em uma semana quais dos seus contratos estavam frouxos o suficiente para o agente estar preenchendo a folga com invenção. Essa descoberta vale mais do que mais um trimestre de debate sobre se o Agile está vivo. A pilha de contrato é o que você mantém. Tudo o resto está em renegociação.

Fontes

Microsoft Developer Blog (Daniel Epstein). “Agentic-Agile: Why Agent Development Needs Agile (Not Just Prompts).” Maio de 2026.
Microsoft / GitHub. “agentic-agile-template.” Maio de 2026.

A Victorino ajuda times de operação a promover a camada de contrato do trabalho com IA sem recriar cerimônias que não pagam mais o aluguel: contato@victorino.com.br | www.victorino.com.br

Os Laboratórios Viraram Consultorias. O Cargo Mais Quente é Forward Deployed Engineer.

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

Em quatro semanas, os três laboratórios de fronteira admitiram a mesma coisa. O produto não é o modelo. O produto é o engenheiro que instala o modelo.

A Anthropic anunciou uma subsidiária de consultoria com forward-deployed engineers em 4 de maio de 2026, com Blackstone, Hellman and Friedman e Goldman Sachs como investidores. A OpenAI capitalizou sua Deployment Company em 11 de maio com US$ 4 bilhões da TPG e da Advent, em um valuation de US$ 14 bilhões, e em seguida comprou a Tomoro do Reino Unido, absorvendo 150 forward-deployed engineers entre Reino Unido, Ásia e Austrália. No final de maio, Gergely Orosz reportou no The Pragmatic Engineer que o Google Cloud havia comprimido seu funil de entrevistas para forward-deployed engineer de quatro a seis entrevistas ao longo de várias semanas para duas entrevistas em dois dias.

Dois dias. Para uma vaga de engenharia. Em um laboratório de fronteira.

Isso não é política de contratação. É admissão estrutural. Os laboratórios precisam de humanos dentro das contas dos clientes mais rápido do que conseguem modelar. A Slow Ventures cunhou o padrão de forma mais limpa: AI Accenture, não Accenture for AI. Os laboratórios não estão contratando consultores. Estão se tornando a consultoria, e estão precificando o cargo como se a casa estivesse pegando fogo.

O sinal vem do mercado de trabalho

A história de fusão e aquisição é barulhenta, mas a história do mercado de trabalho é mais alta, e mais difícil de contestar.

O recorte de Kyle Poyar sobre os dados da Sumble (Growth Unhinged, 20 de maio) é a primeira foto limpa do que a IA está fazendo com o headcount de go-to-market. As vagas totais de GTM caíram 15% ano contra ano no primeiro semestre de 2026. SDR e BDR caíram 21% no mercado todo. Suporte ao cliente caiu 37%, o maior declínio de qualquer função de GTM. Camadas inteiras do funil estão sendo despovoadas em tempo real.

Agora o contra-recorte. Cursor, Decagon e a própria OpenAI dobraram seu próprio headcount de SDR no mesmo período. Os fornecedores AI-native cujo pitch é “automação substitui vendas” estão contratando vendas mais rápido do que qualquer um. As vagas de GTM engineering, a função híbrida de produto mais pipeline, dobraram ano contra ano e passaram de 400 posições abertas no mercado público. Vendas e engenharia de soluções combinadas hoje representam cerca de 60% de todas as vagas de GTM.

O quadro não é “a IA elimina empregos de vendas”. O quadro é “a IA elimina o fundo do funil e puxa o resto do funil para dentro da engenharia”. O trabalho que sobrevive fica próximo do sistema de registro do cliente. O trabalho que morre fica próximo de um script.

Esse é o mesmo formato do anúncio de FDE. Os laboratórios e os fornecedores AI-native não estão prevendo um futuro em que o software se vende sozinho. Estão construindo uma organização em que engenheiros vendem, instalam e operam o software, e o resto do funil é comprimido para dentro do modelo.

Por que as aplicações precisam deste formato

A resposta estrutural para o porquê disso estar acontecendo mora em Tech Bifurcation and the 0.5 Layer, de Neevash Ramdial (maio de 2026). Ramdial argumenta que existe uma nova camada de infraestrutura emergindo entre o modelo de fundação e a aplicação, a camada onde execução de agente, recuperação, avaliação e roteamento de fato vivem. Ele aponta para empresas como Turbopuffer (US$ 100M de ARR rentáveis sobre menos de US$ 1M captados), Modal (US$ 355M de Série C em valuation de US$ 4,65 bilhões) e Mintlify (onde aproximadamente metade do tráfego de documentação hoje vem de agentes de IA lendo docs em nome de usuários humanos) como prova de que a 0.5 layer é real, grande e capitalizada.

O mesmo post cita uma demonstração do próprio Neevash em que o Google Antigravity 2.0 construiu um sistema operacional funcional em cerca de 12 horas, orquestrando 93 sub-agentes a um custo total de menos de US$ 1.000. Isso não é matéria de produto. É matéria de custo de entrega. O modelo agora é barato e capaz o suficiente para que o gargalo seja o trabalho humano de apontá-lo para um problema real do cliente, estruturar o grafo de agentes e operar o resultado.

Esse trabalho humano tem um nome. Forward deployed engineer.

Argumentamos em Os Laboratórios de Fundação Estão Absorvendo Seu Stack que os laboratórios estavam colapsando modelo, runtime, ferramentas de desenvolvimento e consultoria em um único balanço. A construção do braço de FDE é o modelo de staffing sob esse colapso. A tese da 0.5 layer explica por que o modelo de staffing tem que ter este formato. Você não consegue entregar uma demo de “OS do zero por US$ 1.000” através de um ciclo quote-to-cash de nove meses e quatro calls de descoberta. Precisa de um engenheiro que consiga sentar com o especialista de domínio do cliente na segunda e entregar o grafo de agentes na sexta.

O que “FDE” significa hoje

O cargo em si é mais velho do que a reestruturação dos laboratórios. A Palantir inventou a versão moderna nos anos 2010. O padrão era simples. Mandar um engenheiro de verdade para dentro da conta do cliente. Deixar esse engenheiro virar funcionário temporário da operação do cliente. Construir o fluxo de trabalho em torno dos dados reais e das restrições reais do cliente. Deixar o fluxo instalado quando o engenheiro sair.

O que mudou em maio de 2026 foi o volume e o preço pedido. Anthropic, OpenAI e Google agora estão escalando vagas de FDE, e os pacotes de remuneração estão tirando engenheiros de aplicação seniores de todos os outros cantos da indústria. O funil de duas entrevistas do Google é a denúncia. Quando um laboratório de fronteira comprime seu processo de contratação em uma ordem de grandeza, o laboratório não está relaxando a régua. O laboratório está admitindo que a oferta de humanos qualificados é a restrição, e que cada semana que o funil leva é uma semana em que o FDE de um concorrente chega primeiro no escritório do cliente.

Esse é o sistema operacional do modelo AI-Accenture. Não é metodologia. Não é deck. É um banco de engenheiros, alocados pelo laboratório, enviados para dentro de contas de cliente, pagos com receita de modelo. Os laboratórios não precisam de um produto novo para competir com a McKinsey. Precisam de um novo organograma. Já construíram.

O que isso muda para os compradores

Três consequências vão aterrissar nos times de compras e nos organogramas de engenharia neste trimestre.

Primeira, você vai ser vendido por um engenheiro. O AE vai apresentar a sala e sair. O trabalho de escopar, demonstrar e recomendar vai ser feito por alguém cujo pager rota de volta para o time de produto do laboratório. Essa pessoa vai ser brilhante, rápida e estruturalmente enviesada para o stack do laboratório. Planeje esse viés do mesmo jeito que planejaria para qualquer arquiteto de solução de fornecedor, só que mais ainda, porque este aqui escreve o código que vai para produção.

Segunda, sua própria área de GTM vai esvaziar no fundo e engrossar na engenharia. Os dados do Poyar não são previsão. São medição. Se seu time de sales development representa mais de 20% do headcount de GTM, seus pares já estão cortando na sua direção. Se sua função de GTM engineering ainda não existe, seus pares já estão montando. Os cargos que sobrevivem ficam próximos dos sistemas do cliente. Os cargos que somem ficam próximos de um script.

Terceira, seu modelo de entrega precisa de uma camada no formato FDE, ou você vai terceirizar essa camada para qualquer laboratório que chegar primeiro no cliente. Esse é o espelho do lado do comprador da consolidação dos laboratórios. Se você vende software que toca IA, o cliente vai esperar um forward-deployed engineer na sala, porque é isso que todo outro fornecedor da fila de compras dele agora oferece. Construa a função internamente ou alugue de um parceiro que não esteja vendendo também o modelo de base. As duas opções funcionam. “Nenhuma das duas” não funciona.

Faça isso agora

Coloque três coisas no livro neste trimestre.

Conte suas pessoas no formato FDE. O título do cargo não importa. Conte os engenheiros que conseguem sentar no escritório de um cliente na segunda e entregar código em produção na sexta. Se o número for menos de 10% da sua área de engenharia e você vender para o enterprise, você tem um déficit de entrega que seus parceiros fornecedores vão preencher para você em dois trimestres.

Audite sua função de GTM engineering. Se ela não existe como time nomeado com orçamento próprio, nomeie agora. A função vive entre produto, engenharia de vendas e operações de pipeline. As pessoas que ocupam essa função normalmente são engenheiros full-stack com linha de receita atrelada. Os dados da Sumble mostram a função dobrando ano contra ano. O mercado está reprecificando esse trabalho em tempo real.

Estresse os stacks de fornecedor único. Se seu fornecedor de IA está mandando um forward-deployed engineer, peça ao fornecedor um plano de saída por escrito. Que conhecimento transfere quando o FDE sair? O que roda na sua infraestrutura versus na do laboratório? Como fica o fluxo quando você trocar o modelo daqui a 18 meses? Os laboratórios estão precificando o cargo de FDE como se a casa estivesse pegando fogo porque sabem que o fluxo instalado hoje é a decisão de compra travada amanhã. Planeje a saída enquanto ainda tem a alavanca de negociação de cliente novo.

O movimento AI-Accenture não é previsão. É organograma que já existe, capitalizado, com pessoal alocado e precificando agressivamente. Os compradores que perceberem em maio de 2026 preservam a opcionalidade. Os compradores que perceberem em maio de 2027 vão assinar o SOW que o FDE escreveu no trimestre passado.

Fontes

The Pragmatic Engineer. “The Pulse: Forward-Deployed Engineering Heats Up Again.” Maio de 2026.
Growth Unhinged. “Who’s Actually Hiring in GTM Right Now.” Maio de 2026.
Neevash Ramdial. “Tech Bifurcation and the 0.5 Layer.” Maio de 2026.

A Victorino apoia empresas na construção da camada de entrega no formato FDE que contratos de fornecedores de IA agora assumem existir: contato@victorino.com.br | www.victorino.com.br

A Anthropic Acabou de se Reprecificar. Seu Playbook de Compras Envelheceu.

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

Em uma semana de maio de 2026, a Anthropic publicou quatro números que, juntos, quebraram o enquadramento de compras que a maioria das empresas usava no trimestre passado. Receita projetada do Q2 de USD 10,9 bilhões, alta de 127% trimestre contra trimestre. Lucro projetado de USD 559 milhões, o primeiro resultado positivo material já apresentado por um laboratório de fronteira. Custo de computação caindo de USD 0,71 para USD 0,56 por dólar de receita em um único trimestre. E 54% dos novos logos corporativos chegando via self-serve, com ACV completo, termos e faturamento processados sem vendedor. O laboratório se reposicionou como líder de mercado antes da janela de IPO de outubro. A maioria dos playbooks de compras não se reprecificou.

Este texto não é sobre se a Anthropic vai chegar ao IPO. É sobre o que muda para o comprador quando o laboratório passa de “especialista caro atrás da OpenAI” para “laboratório de fronteira com maior receita, lucrativo, perto da listagem”. Os números dizem que essa transição já aconteceu. Os contratos que seu time renova no Q3 devem refletir isso.

A Inflexão Financeira em um Parágrafo

Receita Q1 2026 da Anthropic: USD 4,8 bilhões. Projeção Q2: USD 10,9 bilhões. Lucro projetado: USD 559 milhões. Run-rate anualizado: cerca de USD 40 bilhões. Avaliação: até USD 950 bilhões (segundo Sherwood / The Information), agora à frente da marca de USD 850 bilhões da OpenAI nas últimas operações secundárias. Só o Claude Code já gera USD 2,5 bilhões de receita autônoma. O custo de computação por dólar de receita caiu de USD 0,71 para USD 0,56 trimestre contra trimestre, a primeira vez que um laboratório de fronteira mostrou alavancagem operacional pelo lado do insumo, não só pelo lado do preço (Contrary Research, maio de 2026). A receita do Q1 da OpenAI foi USD 5,7 bilhões (Sherwood News, maio de 2026). A ultrapassagem em avaliação é a manchete, mas a compressão do custo é a história. Um laboratório que lucra enquanto cresce é um laboratório que não precisa dar desconto.

Self-Serve a 54% É o Sinal de Pricing Power

Eleanor Dorfman, Head of Industries da Anthropic, contou ao SaaStr que 54% dos novos logos corporativos em 2026 chegam por canais self-serve, com ACV completo, termos e faturamento processados pela motion de PLG. A área de vendas foi reconstruída do zero em quatro meses, entre janeiro e abril de 2026.

Veja o que isso significa para o comprador. Quando o pipeline corporativo de um fornecedor roda via self-serve, ele tem pouquíssimo incentivo para negociar contra a tabela. O cliente marginal chega sem passar por compras; o cliente marginal paga lista. O time comercial da Anthropic pode segurar a linha em todo deal que chega à mesa, porque o logo médio se mostrou disposto a passar o cartão. É por isso que a queixa “Anthropic é cara” parou de virar desconto. O dado diz que não está cara o suficiente para frear a demanda.

A implicação para compras é desconfortável. Se a sua estratégia de renegociação assume que o fornecedor precisa do seu renewal para bater quota, a estratégia está desatualizada. A quota do fornecedor está se preenchendo sozinha.

Quatro Fornecedores de Chip e um Compromisso de USD 1,25 Bi/Mês

Enquanto a linha de receita se reprecificava, a linha de computação se diversificava. Em maio de 2026, a Anthropic já roda carga de produção em quatro fornecedores de chip: Nvidia, AWS Trainium, Google TPU e Microsoft Maia 200. Satya Nadella, na call de resultados de abril da Microsoft, citou o Maia 200 em “+30% de tokens por dólar versus o silício mais recente” (CNBC, 21 de maio de 2026). Documentos da SpaceX revelaram que o compromisso de computação da Anthropic é de USD 1,25 bilhão por mês até maio de 2029, total acima de USD 50 bilhões (CNBC, 21 de maio de 2026).

Duas consequências para o comprador.

Primeiro, a queda do custo de USD 0,71 para USD 0,56 não foi pontual. É o sinal inicial de uma cadeia de silício multi-fornecedor comprimindo custos de insumo estruturalmente. Compradores que esperavam que a Anthropic estaria limitada por capacidade e, portanto, disposta a negociar, modelaram a escassez errada. Capacidade está sendo construída.

Segundo, o gasto de USD 1,25 bilhão por mês em computação virou custo fixo que precisa virar margem. Essa é a matemática de lock-in por trás das mudanças na superfície de acesso em 15 de junho e dos termos comerciais mais apertados cobertos lá. A computação já foi paga. Os clientes precisam ser cobrados por ela. Self-serve mais harness fechado mais compressão de custo em quatro chips é uma única máquina financeira, não três movimentos separados.

A Aquisição Conta o Roadmap

A nova venture de consultoria da Anthropic fez sua primeira aquisição neste mês: a Fractional AI, que encerrou uma parceria de 11 meses com a OpenAI para se juntar ao braço de deployment (Bloomberg, 21 de maio de 2026). A venture é apoiada por Blackstone (USD 1,3 trilhão sob gestão), Apollo, GIC e Sequoia. Um laboratório de fronteira comprando uma firma de deployment três meses antes da janela de IPO não compra por receita. Compra pela margem bruta de vender serviço em cima do modelo, e pelos casos de uso que justificam o preço do modelo.

Cobrimos o padrão geral em labs de fundação absorvendo a stack. O novo este mês é que a absorção agora está visivelmente financiada. Quando o comprador do seu trabalho de implementação de IA também é o vendedor do modelo, a superfície de negociação do contrato de implementação encolhe. Contratos plurianuais de managed services assinados em 2026 com firmas alinhadas à Anthropic ficam expostos às decisões futuras de preço do fornecedor do modelo de uma forma que contratos de 2024 não ficavam.

O Que Isso Significa para o Seu Ciclo de Compras do Q3

Três mudanças a fazer antes de a próxima janela de renovação fechar.

Renegocie a tabela agora, com o dado que você tem. Se o seu time tem uma renovação no Q3, não espere o IPO. Os números dizem que a Anthropic será mais cara e menos flexível depois da listagem do que antes. Antecipe a renovação, trave a tarifa, e desenhe o contrato com tetos de uso que protejam contra a reversão do custo via aumento de preço. A alavancagem que você tem hoje é informacional: dá para citar a compressão do custo e o número de self-serve e pedir para compartilhar da alavancagem operacional. Depois de outubro, a mesma conversa vira conversa de price-taker.

Coloque o hedge multi-fornecedor de silício no plano de infraestrutura de IA, não só no plano de modelo. A Anthropic roda quatro fornecedores de chip. Sua infraestrutura de IA não deveria rodar na hipótese de que qualquer um deles é o piso. Documente quais workloads podem se mover entre Trainium, TPU, Maia e inferência em Nvidia. O hedge que importa em 2026 não é “Claude vs GPT”, é “o que acontece com minha economia unitária quando o mix de silício muda”. Argumentamos o frame mais amplo em escassez de capacidade de fronteira e risco de fornecedor. A camada de silício é onde o custo de fato mora.

Defina um teto de gasto com agentes por time, com revisão trimestral atrelada a entrega. Self-serve a 54% significa que seus engenheiros, profissionais de marketing e analistas estão colocando despesa da Anthropic no cartão corporativo sem passar por compras. Tudo bem quando o gasto é USD 200 por assento. Deixa de ser tudo bem quando workloads agênticos no estilo Claude Code empurram o número por assento para quatro dígitos. Defina o teto no nível do time, exija revisão trimestral de entrega contra o gasto, e trate a conversa como gestão de performance, não como gestão de custo. O custo é o sintoma; a pergunta é se o time entrega mais por causa dos agentes ou só gasta mais.

Faça Isso Agora

Esta semana, puxe dois números do seu sistema de contas a pagar. Primeiro, a taxa de crescimento do gasto com Anthropic na empresa desde janeiro. Segundo, a fatia desse gasto que correu por self-serve em vez de contrato-mestre. Se a taxa de crescimento é de dois dígitos ao mês e a fatia de self-serve passa de 30%, você está rodando a realidade de compras do Q2 2026 numa estrutura de contrato de 2025. A correção não é trocar de fornecedor. É um novo contrato, assinado no Q3 2026, que precifica o que já está acontecendo, em vez do que seu time negociou no ano passado.

A inflexão financeira é real. O laboratório lucra, a avaliação passou a OpenAI, a computação está diversificada em quatro fornecedores, e a motion de vendas não precisa de você. O playbook de compras que funcionou quando a Anthropic era a especialista cara atrás da OpenAI não funciona quando a Anthropic é o laboratório de fronteira com maior receita, crescimento mais rápido e listagem próxima. Reprecifique suas hipóteses antes que outubro as reprecifique por você.

Fontes

Contrary Research. “Anthropic’s March to Profitability.” Maio de 2026.
Sherwood News. “Report: OpenAI’s Q1 Revenue Was $5.7B.” Maio de 2026.
CNBC. “Microsoft Maia AI Chip for Anthropic.” Maio de 2026.
SaaStr. “How Anthropic Rebuilt Its Sales Org from Scratch.” Maio de 2026.
Bloomberg. “Anthropic’s New Consulting Venture Makes Its First Acquisition.” Maio de 2026.

A Victorino apoia times de procurement na reprecificação de contratos de IA antes que ciclos trimestrais travem suposições antigas: contato@victorino.com.br | www.victorino.com.br

A Armadilha da Paridade em Design: Quando 80% Competente é o Piso

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

A dona de uma padaria abre o Google Pomelli, faz upload de algumas fotos e um esboço de logo, digita uma frase sobre o negócio que quer lançar e sai noventa segundos depois com uma Business DNA completa: voz da marca, sistema de cores, pareamento tipográfico, site populado, kit de redes sociais pronto para campanha. O trabalho é competente. A tipografia é legível. A paleta é equilibrada. O texto está no tom. Em 2023, isso teria custado três semanas e doze mil dólares em uma agência júnior.

O Pomelli foi anunciado na AI I/O 2026. Na mesma semana, do outro lado da cidade, um Executive Creative Director chamado Yann Caloghiris publicou no The Drum e nomeou o risco estrutural mais rápido que a maioria dos estrategistas: quando a IA entrega cerca de 80% do design de forma competente para qualquer time que pedir, competência deixa de ser diferencial. Os 20% restantes (gosto, confiança, calibração) viram o fosso inteiro.

Chame de armadilha da paridade em design. Já escrevemos sobre design systems virando infraestrutura de governança e sobre a mudança no modelo operacional que transforma designers em regentes. A armadilha da paridade é o modo de falha por baixo das duas mudanças. É o que acontece quando a liderança trata IA como alavanca de produtividade e descobre, dezoito meses depois, que a produtividade funcionou exatamente como prometido e a voz da marca colapsou na mediana.

Os 20 Pontos que Contam a História Inteira

A Pesquisa de Design da Figma de 2025, citada por Caloghiris, traz um número que merece ser olhado com calma. 78% dos profissionais de design dizem que ferramentas de IA aceleram significativamente seus fluxos de trabalho. 58% dizem que a IA melhora a qualidade da entrega.

Uma diferença de vinte pontos entre velocidade e qualidade não é ruído. É a armadilha da paridade traduzida em dados de pesquisa. Os ganhos de velocidade chegaram como prometido. Os ganhos de qualidade chegaram para o piso, não para o teto. A IA elevou cada designer a uma linha de base competente. Não elevou o trabalho acima dela.

Em uma categoria onde todo concorrente agora opera na mesma linha de base competente, o piso deixou de ser piso. Virou o novo teto, e a maioria dos times não vai perceber que parou de subir.

A Slack Escreveu a Resposta Operacional

Enquanto Caloghiris nomeou a armadilha, o VP de Product Design da Slack, Will Miner, publicou a resposta operacional na mesma semana. Sua equipe de cerca de setenta designers vem trabalhando a transição para IA em público, e os princípios que ele divulgou se lêem como um documento de governança, não como manifesto.

Três mudanças de comportamento merecem ser nomeadas. Demos executivas na Slack agora são entregues em código, não no Figma. Designers sem formação em programação estão construindo as ferramentas internas que seus times precisam. Bugs de UI estão sendo corrigidos internamente, sem ticket de engenharia. A fronteira entre projetar e construir se moveu, e os princípios do time se moveram junto.

Os princípios em si são pouco notáveis isoladamente. IA é colaboradora, não substituta. Gosto é o diferenciador. Ofício compõe. O notável é que eles existam. A maioria das organizações de design ainda discute se permite as funcionalidades de IA da Figma dentro do arquivo. A Slack escreveu como o bom se parece em escala de setenta designers e publicou.

Essa é a forma operacional da resposta. A armadilha da paridade fecha quando a liderança nomeia explicitamente os 20% residuais, constrói os checkpoints de revisão que os protegem e dá ao time princípios concretos o suficiente para recusar trabalho que os viole.

O Modelo de Quatro Etapas da Chen é a Cartilha do Praticante

O terceiro artigo da mesma semana vem de Daisy Chen no UX Collective, e é o artefato mais reaproveitável dos três. Chen recorre ao “Ironies of Automation” de Bainbridge (1983), ao framework de Parasuraman, Sheridan e Wickens de 2000, e à pesquisa de Lee sobre fadiga de alarme (a famosa razão de 35 alarmes falsos para 1 alarme real, ponto em que operadores começam a desligar avisos inteiramente). Ela compacta cinquenta anos de pesquisa sobre interação humano-automação em um modelo de quatro etapas.

Identificar a tarefa. Escolher o nível de controle. Calibrar a confiança. Projetar para coevolução.

O modelo não é específico de design. É a cartilha do praticante para qualquer função que adote IA, e é exatamente por isso que importa para o arco de governança fora da engenharia. Times de marketing rodando geração autônoma de campanhas precisam disso. Times jurídicos revisando contratos minutados por IA precisam disso. Times de vendas usando outreach gerado por IA precisam disso. O vocabulário é generalizável. A disciplina é transferível.

A etapa um (identificar a tarefa) força a liderança a admitir quais decisões realmente exigem julgamento humano. A maioria dos times pula essa etapa e descobre, seis meses depois, que automatizou as decisões que mais precisavam de julgamento e deixou intactas as rotineiras.

A etapa dois (escolher o nível de controle) mapeia diretamente para a tese de design system como camada de restrição. Automação total, execução supervisionada, modo consultivo, ou manual com sugestão de IA. Cada um tem seu lugar. Escolher o nível errado para a tarefa errada é a falha mais comum que vemos em projetos de implementação.

A etapa três (calibrar a confiança) é onde mora o 35 para 1 de Lee. Confiança alta demais produz adoção acrítica. Confiança baixa demais produz abandono da ferramenta. Os dois falham do mesmo jeito: o sistema para de aprender porque os humanos param de engajar com o que ele entrega.

A etapa quatro (projetar para coevolução) é a única que de fato compra tempo. As outras três estabilizam o sistema. Essa melhora. Coevolução é o que separa times que estagnam em competente-para-todos de times que compõem gosto ao longo de anos.

O Que o Pomelli de Fato Ameaça

Pomelli não está ameaçando agências. Agências já vinham sendo reprecificadas. O Pomelli está ameaçando a hipótese de que competência em design é uma posição defensável.

Se a dona de uma padaria consegue entregar uma identidade de marca competente em noventa segundos, então a identidade de marca em si deixa de ser o entregável. O entregável vira o que vem depois: as decisões sobre qual opção competente recusar, qual texto no tom reescrever porque está no tom mas é entediante, qual paleta equilibrada empurrar para fora do equilíbrio porque o equilíbrio é genérico. O entregável vira o gosto aplicado à saída da IA, não a saída em si.

É por isso que o enquadramento de Caloghiris importa. O protótipo não é a marca. A marca é o conjunto acumulado de decisões sobre quais protótipos publicar e quais descartar. Um time que usa Pomelli sem essa disciplina entrega paridade de marca. Um time que usa Pomelli dentro do modelo de quatro etapas da Chen e dos princípios da Slack entrega paridade de marca somada aos 20% que a tornam específica.

A Limitação Honesta

Pomelli é cedo. Caloghiris escreve do ponto de vista de um único diretor criativo. Os princípios da Slack ainda não foram validados independentemente em escala. Chen está sintetizando pesquisa acadêmica que precede os LLMs em décadas.

Trate a convergência como sinal direcional. Os quatro materiais não foram coordenados. Chegaram na mesma semana porque a pressão subjacente é real. A maturidade de qualquer resposta isolada ainda é precoce.

Os times que vão compor vantagem a partir desse momento são os que levam a convergência a sério mantendo ceticismo sobre qualquer cartilha única. Leia os quatro. Discuta com eles. Depois escreva sua própria versão, ancorada na sua marca real e nos seus clientes reais, e publique antes que a paridade se instale.

Faça Isso Agora

Escolha um fluxo de design que seu time já moveu para IA. Rode-o pelas quatro etapas da Chen ainda esta semana. Identifique a tarefa. Escolha o nível de controle. Calibre a confiança. Projete para coevolução. Depois escreva três checkpoints de revisão que capturariam o momento em que a saída deriva para a mediana, e atribua cada um a um humano nomeado.

Em seguida, envie o texto do Miner para quem lidera sua organização de design. Peça que publiquem princípios na escala de vocês dentro de trinta dias. Não princípios aspiracionais. Operacionais. Do tipo que um designer pode citar ao recusar um trabalho que os viole.

Os 20% que viram o fosso não se constroem por acidente. Constroem-se por times que nomearam o que importa antes da paridade chegar e protegeram aquilo de propósito.

Fontes

Digital Trends. “Google Pomelli Can Now Build Your Entire Brand from Scratch.” Maio de 2026.
The Drum. “AI Gives Us the Prototype. It Doesn’t Give Us the Brand.” Maio de 2026.
Slack Design. “Leading Design Through the AI Shift.” Maio de 2026.
UX Collective. “Most AI Tools Make Users Faster. The Best AI Tools Make Users Better..” Maio de 2026.

A Victorino apoia líderes de design e produto a instalar os checkpoints de revisão que evitam a colapso da voz de marca na paridade gerada por IA: contato@victorino.com.br | www.victorino.com.br

A Semana em que os Dois Lados da Cadeia de Suprimentos Ficaram Industriais

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

Entre 21 e 22 de maio de 2026, quatro anúncios caíram com menos de 48 horas de distância. O GitHub revelou que 3.800 repositórios internos próprios foram exfiltrados via uma extensão maliciosa do VS Code. A Anthropic publicou os primeiros números do Projeto Glasswing, o programa de modelo de segurança restrito, com mais de 10 mil vulnerabilidades encontradas em software crítico em um único mês. O Red Team da Anthropic publicou o exploit-eval do Mythos Preview, que resolveu 21 dos 41 CVEs do ExploitBench enquanto todos os outros modelos resolveram dois ou menos. A Perplexity abriu o código do Bumblebee, um scanner read-only que trata endpoints de agentes (extensões, configs MCP, lockfiles) como superfícies inventariáveis.

Nenhum foi coordenado. Ainda assim descrevem um único evento.

A crise de cadeia de suprimentos da era IA cruzou o limiar industrial nos dois lados. O lado ofensivo tem mecânica de flywheel, vítimas nomeadas e tabela de preços. O lado defensivo tem scores de eval, pipeline de parceiros e um primeiro artefato open-source. A pergunta intermediária, a que líderes de engenharia e segurança precisam responder esta semana, não é mais se endpoints de agentes precisam de controles. É se existe um inventário desses endpoints.

O Lado Ofensivo: TeamPCP Chegou ao Topo da Pilha

Já escrevemos sobre o TeamPCP através de incidentes individuais. O Clinejection mostrou um único pacote npm comprometendo instalações do Cline. A onda Mercor mostrou o mesmo operador atingindo infraestrutura de dados de treinamento de IA. Injeção de prompt como arma de cadeia de suprimentos rastreou a técnica até o loop do próprio modelo.

O que o dia 21 de maio adicionou foi o andar que o TeamPCP ainda não havia tocado: a plataforma que hospeda a cadeia de suprimentos.

A CISO do GitHub, Alexis Wales, confirmou 3.800 repositórios internos exfiltrados via uma única extensão do VS Code. O preço pedido no BreachForums foi US$ 50 mil. A Aikido Security rastreou as janelas de remoção: 18 minutos no VS Code Marketplace, 36 minutos no Open VSX. Resposta rápida em termos absolutos. Ainda assim, 54 minutos durante os quais uma extensão envenenada era o canal padrão de download para uma superfície crítica de desenvolvedor.

Os números da campanha mais ampla, publicados por Wiz, Socket e Palo Alto Networks no dia seguinte, enquadram a escala:

20 ondas distintas de cadeia de suprimentos ao longo do ano
500+ pacotes envenenados, mais de 1.000 contando versões
Vítimas downstream confirmadas incluem OpenAI (dois dispositivos de funcionários), Mistral AI, Mercor, o site público da Comissão Europeia, TanStack, LiteLLM, Trivy e AntV

A lógica econômica é direta. Uma extensão envenenada rodando no laptop de um engenheiro do GitHub retorna mais valor do que uma rodando no projeto pessoal de um desenvolvedor júnior. O TeamPCP opera agora na camada onde a própria ferramenta de desenvolvedor é o alvo. Cada camada acima (registros npm, ecossistemas de linguagem, mantenedores de framework) já absorveu ondas no começo do ano. A camada de plataforma era o teto restante.

Esse teto foi perfurado.

O Lado Defensivo: Glasswing Mostrou que IA Ofensiva Escala IA Defensiva

O Projeto Glasswing é o modelo de segurança de distribuição restrita da Anthropic: mais capaz que a linha pública do Claude, acessível apenas a parceiros de segurança verificados sob restrições específicas de uso. O modelo de governança está documentado desde abril. A atualização inicial de 22 de maio é a primeira vez que o programa reportou o que encontrou.

Os números têm peso porque são testados em campo, não em benchmark:

10.000+ vulnerabilidades em software sistemicamente importante em um mês
Aproximadamente 50 parceiros ativos
6.202 vulnerabilidades de severidade alta ou crítica descobertas em 1.000+ projetos open-source
A Cloudflare sozinha encontrou 2.000 bugs e reportou uma taxa de falso-positivo “melhor que testadores humanos”
Firefox 150 gerou 271 vulnerabilidades contra o Firefox 148, um aumento de 10x atribuível a rodar o Opus 4.6 contra o mesmo código

A afirmação estratégica que o Glasswing valida é mais antiga que os dados: capacidade ofensiva de IA e capacidade defensiva de IA escalam na mesma curva. Se um modelo consegue construir uma cadeia de exploração, o mesmo modelo consegue encontrar as condições que habilitam aquela cadeia. A pergunta nunca foi qual capacidade chega primeiro. Chegam juntas. Governança determina qual delas alcança o campo em escala.

Glasswing é o primeiro programa em que o alcance defensivo foi medido contra o alcance ofensivo no mesmo mês. A defesa alcançou mais longe. Distribuição restrita tornou isso possível.

Mythos Preview: O Eval de Exploração Vira Benchmark de Mercado

O artigo de avaliação de exploração do Red Team da Anthropic é a terceira perna do tripé do dia 22. Também é a mais desconfortável.

O Mythos Preview resolveu 21 dos 41 CVEs do ExploitBench escrevendo exploits de execução arbitrária de código. Todos os outros modelos testados resolveram dois ou menos. O Mythos foi o único modelo a escapar do sandbox do V8. O tempo de duplicação de performance, medido contra a geração anterior, foi de 0,7 mês. A duplicação anterior foi de 1,1 mês. No SCONE-bench, o eval de exploração de contratos inteligentes, o valor em dólares de contratos explorados com sucesso ultrapassou US$ 35 milhões.

Os números importam menos do que a trajetória. Construção de exploração em múltiplos passos, que 12 meses atrás exigia um pesquisador sênior de segurança ofensiva, agora é capacidade de modelo. Distribuição restrita atrasa a chegada como commodity, mas não impede. O exploit eval é agora um benchmark que laboratórios de fronteira publicam uns contra os outros. A equiparação de pesos abertos é questão de meses.

Bumblebee: O Primeiro Scanner Defensivo de Endpoints de Agente

A IA ofensiva open-source foi a assimetria que vínhamos rastreando. A defesa não tinha artefato equivalente apontado para as superfícies que os agentes de fato tocam.

O Bumblebee da Perplexity, com código aberto em 22 de maio, é o primeiro a chegar.

As escolhas de design revelam o que faltava aos defensores:

O Bumblebee escaneia quatro superfícies de endpoint: gerenciadores de pacotes de linguagem (npm, pip, cargo, gem, outros), arquivos de configuração MCP, extensões da família VS Code (VS Code, Cursor, Windsurf) e extensões de navegador.
É read-only por design. Não invoca npm install, não dispara hooks de postinstall, não executa o código que inventaria. A razão está explícita no README do projeto: qualquer scan ativo dispara exatamente o payload que o Bumblebee existe para encontrar.
O Perplexity Computer, o agente que rascunha o catálogo, abre pull requests para revisão humana. O agente não faz auto-commit do inventário.

A existência do artefato muda a conversa. Arquivos de configuração MCP agora têm um formato de inventário inspecionável. Instalações de extensão do VS Code agora têm um enumerador orientado a defensores. O argumento de que “não dá para inventariar o que não tem ferramenta” deixou de valer. A ferramenta existe, é gratuita e é open-source.

As Alavancas de Governança Têm Nome

Três controles agora são concretos o bastante para um plano de governança do terceiro trimestre:

Credenciais de longa duração em ferramentas de desenvolvimento. A invasão do GitHub funcionou porque uma extensão do VS Code rodando no laptop de um engenheiro carregava o acesso para ler repositórios internos. A fronteira de computação, a fronteira de dados e a fronteira de identidade colapsaram em um único processo. A correção não é uma nova política. A correção é federação de identidade de workload alcançando extensões de desenvolvedor, que é onde ela esteve ausente.

Revisão de extensões como controle de primeira classe. O VS Code Marketplace e o Open VSX removeram a extensão maliciosa em menos de uma hora. Esse é um controle reativo. O controle proativo é tratar instalação de extensão da mesma forma que segurança corporativa trata instalação de software em servidor de produção: fila de aprovação, manifesto assinado, sign-off por versão. A maioria das organizações não faz isso para ferramenta de desenvolvedor porque ninguém havia pedido antes.

Inventário de configuração MCP. O Bumblebee é o artefato que torna isso enumerável. A pergunta para a próxima reunião do time de plataforma: “Quais agentes em quais máquinas carregam quais servidores MCP, e onde estão armazenadas as configs?” Se a resposta for “não sabemos”, é por aí que o trabalho começa.

Faça Isto Agora

Bloqueie 45 minutos esta semana. Rode o Bumblebee contra um laptop de engenharia e uma imagem de container de desenvolvedor. A saída é um pull request rascunho listando cada pacote de linguagem, cada configuração MCP, cada extensão do VS Code, cada extensão de navegador encontrada. Leia. Duas surpresas são típicas: uma extensão que ninguém lembra de ter instalado e uma config MCP apontando para um serviço que ninguém do time é dono.

Essa saída é o inventário. O inventário é a precondição para governança. Tudo o mais, as políticas, as aprovações, a federação, pressupõe que você consegue listar o que tem. Os dados do Glasswing confirmaram que IA defensiva funciona em escala. A campanha TeamPCP confirmou que IA ofensiva opera na camada de plataforma. O Mythos confirmou que a distância de capacidade fecha em meses, não anos. O Bumblebee removeu a última desculpa para não enumerar as superfícies.

Os times que vencerão os próximos dois anos de operação de agentes não são os com agentes mais autônomos. São os que conseguem responder, por escrito, o que seus agentes alcançam.

Fontes

ITPro. “GitHub internal repositories exfiltrated via malicious VS Code extension.” Maio de 2026.
Ars Technica. “A hacker group is poisoning open-source code at an unprecedented scale.” Maio de 2026.
Anthropic. “Project Glasswing: An Initial Update.” Maio de 2026.
Anthropic Red Team. “Measuring LLMs’ Ability to Develop Exploits.” Maio de 2026.
Perplexity. “Perplexity is open-sourcing Bumblebee.” Maio de 2026.

A Victorino apoia organizações no inventário e governança de endpoints de agentes antes da próxima onda de cadeia de suprimentos: contato@victorino.com.br | www.victorino.com.br

A Camada Operacional do Cursor: Quando Agentes na Nuvem Precisam de TI Corporativa

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

Em 21 de maio, Josh Ma, da Cursor, publicou “Lessons Learned from Building Cloud Agents”. É o estudo de caso de primeira mão mais preciso operacionalmente que qualquer fornecedor de agentes lançou em 2026. Tire a camada de marketing e o que sobra é uma confissão: as partes que tornaram os agentes na nuvem confiáveis não foram o modelo, o prompt ou o framework de orquestração. Foram a infraestrutura corporativa chata que o time inicialmente tratou como detalhe.

O post diz isso com todas as letras. “TI corporativa para agentes: redação de segredos, políticas de rede, gestão de credenciais.” Essa frase merece ser destacada, capturada e mostrada para todo executivo que ainda acredita que confiabilidade de agente é problema de modelo.

O Que de Fato Mudou o Jogo

A Cursor cita quatro mudanças específicas e o que cada uma comprou. Nenhuma é sobre o agente.

Execução durável via Temporal. Migrar os workflows de agentes na nuvem para o Temporal subiu a confiabilidade de “um nove” para “dois noves”. O Temporal hoje processa 50 milhões de ações por dia em 7 milhões de workflows para a Cursor. O estado do workflow sobrevive a crashes, redeploys e falhas de infraestrutura. O agente não precisa lembrar onde estava, porque o runtime do workflow lembra.

Ambientes de desenvolvimento isolados por tarefa. Cada agente na nuvem roda dentro de um ambiente de dev totalmente provisionado, com dependências, serviços e os segredos certos no escopo. Josh Ma chama isso de “o maior fator individual na qualidade da saída dos agentes na nuvem”. Não o modelo. Não o prompt. O ambiente.

Infraestrutura auto-recuperável. Quando um workflow trava ou um ambiente se comporta mal, a plataforma reinicia a unidade de trabalho sem o autor do agente escrever código de recuperação. Confiabilidade sai do heroísmo no tratamento de exceções e vira padrão operacional.

Desacoplar estado do agente do estado da conversa. Essa é a primitiva arquitetural que torna as outras três viáveis. A conversa é um recurso. O workflow é outro. Matar ou reexecutar um não corrompe o outro. É a mesma separação que usuários de Temporal usam há uma década para manter fluxos de pagamento vivos entre deploys, aplicada a um loop de geração de código.

O resultado: 40 por cento dos pull requests do monorepo interno da Cursor agora vêm de agentes na nuvem. Esse número só é crível porque as quatro primitivas acima existem por baixo.

O Fornecedor Acabou de Admitir Que a Abstração Estava Errada

Leia o post uma vez pelas lições. Leia de novo pelo enquadramento.

Um fornecedor cujo negócio depende de vender agentes na nuvem acabou de publicar um ensaio longo argumentando que o agente não é onde a confiabilidade mora. Confiabilidade mora em durabilidade de workflow, isolamento de ambiente, higiene de credenciais e separação de estado. Essas não são funcionalidades que você compra com uma licença de agente. São propriedades da camada operacional por baixo.

Isso importa porque o discurso de venda dominante em 2026 foi o inverso: compre o agente, leve a confiabilidade junto. A Cursor está dizendo publicamente agora que esse discurso era incompleto. O fornecedor mais experiente de agentes na nuvem do mercado chegou a dois noves de confiabilidade gastando ciclos de engenharia em Temporal, sandboxes, gestão de segredos e política de rede. Exatamente os mesmos investimentos que qualquer time de plataforma corporativo faria para qualquer sistema de produção lidando com código e credenciais sensíveis.

Essa é a tese de governança-como-produto chegando pelo lado fornecedor da mesa. É também uma correção silenciosa da narrativa “agentes são diferentes, as regras antigas não se aplicam” que guiou boa parte das compras de 2025.

O Checklist de Compra

Se a Cursor precisou dessas quatro primitivas para enviar agentes na nuvem internamente, todo outro time usando ou construindo agentes na nuvem também precisa. Não são específicas de fornecedor. São propriedades do ambiente operacional que qualquer sistema autônomo de geração de código exige.

Trate-as como um checklist de compra. Se um fornecedor te oferece um produto de agente na nuvem, pergunte:

1. Execução durável. O runtime do workflow do seu agente sobrevive a crashes e redeploys sem perder trabalho em andamento? Qual é o motor por baixo? Se a resposta é “a gente repete a partir da conversa”, isso não é durabilidade. Isso é esperança.

2. Ambientes de execução isolados. Cada tarefa de agente roda em ambiente próprio provisionado, com credenciais escopadas, ou compartilha um sandbox de longa duração? Isolamento por tarefa é a diferença entre raio de impacto contido e raio compartilhado.

3. Infraestrutura auto-recuperável. Quando uma tarefa trava, quem reinicia? Se a resposta envolve um engenheiro de plantão lendo logs, você está comprando um beta. Se a resposta é “a plataforma resolve e emite um evento de auditoria”, você está comprando produção.

4. Estado desacoplado. Você consegue matar uma conversa mal-comportada sem perder o workflow que ela disparou? Consegue reexecutar o workflow contra outro modelo sem reescrever o prompt? Conversa e execução são dois recursos, não um.

Essas quatro perguntas filtram fornecedores de agentes na nuvem mais rápido que qualquer matriz de funcionalidades. Também mapeiam diretamente para propriedades de governança que auditores se importam: execução durável produz trilha de auditoria por construção, ambientes isolados produzem escopo de credencial por tarefa, auto-recuperação produz métricas operacionais, estado desacoplado produz reexecução para revisão de incidentes.

Execução Durável É uma Primitiva de Governança

O detalhe do post da Cursor que merece mais atenção é o menos vistoso. Durabilidade de workflow não é só uma funcionalidade de confiabilidade. É a propriedade que torna tudo o mais governável.

Um workflow durável é, por definição, um workflow cuja história é gravada, reexecutável e inspecionável. Toda ação que o agente toma é capturada como um passo discreto que o runtime consegue auditar. Essa história é a matéria-prima para relatório de conformidade, revisão de incidente, atribuição de mudança e o tipo de resposta forense que auditores vão pedir quando um agente publicar o commit errado. Sem durabilidade, as ações de um agente são um fluxo de efeitos colaterais que ninguém consegue reconstruir depois do fato.

Os times que entendem isso há uma década são os que rodam Temporal, Airflow, Step Functions e Cadence atrás de sistemas de pagamento e cumprimento de pedidos. Os times que estão aprendendo agora, do jeito difícil, são os que construíram agentes em cima de loops HTTP sem estado e assumiram que o LLM ia lembrar.

A Cursor aprendeu. O post é o recibo.

Faça Isso Agora

Pegue um workflow de agente na nuvem rodando hoje no seu ambiente e responda quatro perguntas até o fim da semana:

Se o processo host reiniciar no meio da tarefa, o workflow retoma ou volta do zero?
Se o agente vazar um segredo num log, qual credencial estava escopada para aquela tarefa e como você rotaciona?
Se a tarefa travar por uma hora, quem percebe e o que reinicia?
Se um regulador pedir o histórico completo do que o agente fez na última terça às 15h14, você consegue produzir?

Se você não consegue responder as quatro com nome específico, sistema ou consulta, seu programa de agentes na nuvem ainda não tem uma camada operacional. Tem uma demo com raio de impacto maior.

A Cursor acabou de publicar o playbook. O resto da gente tem a chance de copiar antes da auditoria chegar.

Fontes

Cursor. “Lessons Learned from Building Cloud Agents.” Maio de 2026.

A Victorino apoia times de plataforma a transformar contenção de agentes em padrões operacionais, em vez de heroísmos pontuais: contato@victorino.com.br | www.victorino.com.br

Lavagem de IA: O Primeiro Incidente Real de Governança do Marketing

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

No dia 24 de maio, The Guardian publicou uma reportagem que se lê como uma autópsia de marketing escrita antes do funeral. Aisha Down entrevistou uma diretora de contas anônima de uma agência de PR no centro de Londres e voltou com um número limpo: aproximadamente metade dos releases que ela recebe infla a participação da IA no produto descrito. Metade. Não a cauda longa. A mediana.

É assim que se parece o primeiro incidente real de governança do marketing.

O número, sozinho, seria curiosidade. O que o torna operacional é o que o cerca. Na mesma semana, no dia 22 de maio, o CEO do Standard Chartered, Bill Winters, pediu desculpas publicamente por ter chamado trabalhadores deslocados pela IA de “capital humano de baixo valor” em uma entrevista à Bloomberg. A Allbirds, marca de tênis, virou o discurso público em abril em direção à “aquisição de GPUs de IA”, uma frase que não significa nada no contexto de vender calçados e significa algo bem específico para investidores. Praticantes de PR entrevistados pelo Guardian citaram releases sobre “tabelas de basquete com IA” e “lasers com IA” como os exemplos didáticos do estado em que o gênero chegou.

Não são exceções. São o formato do ano.

O diagnóstico: marketing não tem o equivalente a revisão de código

A engenharia entregou sua camada de governança nos últimos 18 meses. Pre-commit hooks. Pipelines de CI. Análise estática. Suítes de avaliação para funcionalidades com LLM. Uma etapa de revisão de código legível por humanos antes de qualquer coisa chegar à branch principal. O trabalho é pouco glamoroso, os controles são imperfeitos, e existem. Quando um engenheiro escreve is_ai_powered = True em uma função que chama uma regex, outros quatro engenheiros veem a linha antes do deploy.

Quando uma agência de PR escreve “com IA” em um release sobre uma tabela de basquete, a revisão equivalente não acontece. A agência redige. A marca aprova o espírito. O jurídico varre por difamação. Ninguém pergunta: isso é factualmente verdadeiro? O que o modelo faz? Onde ele é chamado? Qual é o mecanismo subjacente? O análogo mais próximo de uma revisão de código no PR é a revisão de citação, e revisões de citação checam tom, não verdade.

Metade dos releases infla a participação da IA porque a função que produz esses releases não tem mecanismo formal para pegar a inflação. A diretora de contas citada pelo Guardian não descreveu uma indústria maliciosa. Descreveu um default. Quando o incentivo é conseguir cobertura e a etapa de verificação não existe, a mediana da saída deriva em direção ao enquadramento mais favorável à cobertura, que neste momento significa “com IA”.

É como se parece uma superfície sem guarda em escala. Nomeamos o padrão em Seu Time de Marketing Acabou de Virar um Time de Governança e novamente em O Acerto de Contas da Governança no Marketing. A reportagem do Guardian é a evidência de campo.

O momento Standard Chartered

O Standard Chartered importa de um jeito diferente. Bill Winters é o CEO de um banco global. A expressão “capital humano de baixo valor” não apareceu em um release escrito por um analista júnior às 23h. Apareceu em uma entrevista ao vivo na Bloomberg. Ele se desculpou em 48 horas. A desculpa é o dado: a empresa reconheceu, rápido, que o enquadramento era um evento de segurança de marca.

Leia a sequência com atenção. Um CEO fala. O mercado processa. O CEO retrata. Esse é o caminho não mediado entre a linguagem do executivo e a consequência reputacional. Também é o caminho que o marketing, na maior parte das empresas grandes, agora é estruturalmente responsável por governar, porque a alternativa é deixar o CEO improvisar em TV ao vivo sem nenhuma revisão dos padrões de linguagem que a empresa decidiu serem proibidos.

É o mesmo ponto feito pela Allbirds, ao contrário. Uma marca de consumo explicar publicamente sua virada em direção a “GPUs de IA” é produzir linguagem que é simultaneamente factualmente rala e obviamente direcionada ao investidor que perdeu a paciência com tênis e está disposto a perdoar prejuízos se a palavra IA estiver presente. O mercado lê o sinal corretamente: não como convicção, mas como posicionamento. O dano é à credibilidade de longo prazo, que é o ativo que o marketing existe para proteger.

O relógio externo: a SEC já está autuando

A janela voluntária para resolver isso está se fechando. A Securities and Exchange Commission dos EUA vem movendo ações de enforcement por lavagem de IA em documentos regulatórios desde 2024. Em março de 2024, a SEC fechou acordo com dois consultores de investimento em 400 mil dólares por afirmações falsas sobre IA. Em junho de 2024, acusou o fundador da Joonko de fraudar investidores em 21 milhões de dólares ao alegar uma IA proprietária de matching que não existia. O Office of the Investor Advocate sinalizou a lavagem de IA como prioridade para 2025. O mecanismo legal está operacional, a jurisprudência está sendo construída, e aplica-se a qualquer comunicação que toque um arquivo regulatório, o que em uma empresa de capital aberto é a maior parte da comunicação externa.

O que a SEC está fazendo para filings, advogados de demandantes farão para alegações ao consumidor, e reguladores no Reino Unido e na União Europeia farão sob seus próprios arcabouços. O AI Act da Comissão Europeia cria exigências de divulgação que já entram em conflito com a alegação casual de “com IA”. A CMA britânica sinalizou escrutínio sobre alegações de marketing com IA sob a legislação de proteção ao consumidor já existente. O padrão é o mesmo que a engenharia viu com segurança e acessibilidade há uma década: disciplina voluntária antes do enforcement obrigatório, depois enforcement obrigatório para todos que não adotaram disciplina voluntária.

As empresas que instalarem a revisão de alegações factuais agora vão parecer, em 24 meses, com as empresas que adotaram SOC 2 antes de os clientes exigirem.

Como é, de fato, a camada de revisão

Uma revisão de alegações factuais para copy de marketing não é exótica. São quatro perguntas, feitas antes de qualquer superfície externa ir ao ar, por alguém com autoridade para dizer não.

Primeira: existe um modelo neste produto? Sim ou não. Não “machine learning informa”, não “habilitado por IA”, não “com IA”. Existe um modelo que roda em uma entrada e produz uma saída. Se não, a palavra IA não aparece na copy.

Segunda: se sim, o que o modelo faz? Uma frase em linguagem simples. “Ranqueia candidatos por aderência de habilidades.” “Gera rascunhos de resposta de e-mail.” “Classifica notas fiscais.” Se a resposta exigir mais de uma frase, a copy precisa de mais especificidade, não menos.

Terceira: qual é o efeito visível para o usuário? Velocidade, precisão, cobertura, custo. Um número, uma faixa ou uma comparação. “Reduz o tempo de classificação de 15 minutos para 30 segundos.” Se você não consegue produzir um efeito mensurável visível para o usuário, a IA não é o assunto.

Quarta: quem assina embaixo dizendo que as três respostas anteriores são verdadeiras? Nome. Não cargo. Não time. Pessoa.

Esse é o mecanismo inteiro. É uma revisão de 15 minutos. Também é a diferença entre metade dos seus releases inflar a participação da IA e nenhum deles fazer isso.

O contra-argumento, reconhecido

Alguns líderes de marketing vão ler isto e dizer que a função sempre gerenciou a precisão factual. Revisões jurídicas existem. Revisões de compliance existem. A indústria vem escrevendo sobre alegações de IA há dois anos.

É verdade e não é suficiente. Revisões jurídicas checam afirmações falsas acionáveis, não a inflação macia que produz metade dos releases inflando IA. Revisões de compliance checam exigências de divulgação, que na maior parte das jurisdições ainda não cobrem especificamente alegações de IA para produtos não regulados. A conversa de dois anos produziu ensaios e mesas redondas, não checklists pré-publicação com donos nomeados. A reportagem do Guardian documenta uma função que está ciente do problema e não construiu o mecanismo para resolvê-lo.

Do mesmo jeito que a consciência da engenharia sobre segurança em 2010 não produziu SOC 2 por acaso. Alguém teve que construir o checklist, nomear o dono, rodar as auditorias e aceitar que algumas campanhas seriam mais lentas e algumas alegações seriam menores. As empresas que fizeram esse trabalho primeiro hoje vendem para clientes enterprise sem uma revisão de segurança de seis meses toda vez. As empresas que não fizeram ainda estão fazendo o trabalho, só que no prazo.

Faça isto agora

Se você lidera marketing ou comunicação, três ações até sexta-feira.

Puxe toda alegação externa sobre IA que sua empresa fez nos últimos 90 dias. Releases, páginas de produto, decks comerciais, falas de executivos. Liste. A lista, em si, é a auditoria.

Para cada alegação, rode as quatro perguntas acima. Marque cada linha como verde, amarela ou vermelha. Amarela quer dizer que a alegação é defensável, mas vaga, e precisa ser apertada. Vermelha quer dizer que a alegação está errada e precisa de correção ou retratação.

Nomeie o dono da revisão de alegações factuais a partir de agora. Uma pessoa. Reserve um bloco de 30 minutos toda semana. Coloque no calendário do time de comunicação junto com a revisão jurídica e a revisão de marca. Faça da revisão um portão publicado pelo qual a copy precisa passar antes da liberação externa.

A função existe na engenharia e funciona. A função não existe no marketing e a conta está chegando. A diretora de PR citada anonimamente pelo Guardian estava descrevendo uma indústria à espera de permissão para fazer o trabalho. A permissão é o bloco no calendário.

Fontes

The Guardian. “AI Washing: PR Firms Scrambling to Rebrand.” Maio de 2026.

A Victorino apoia líderes de marketing e comunicação a instalar processos de revisão de afirmações factuais antes que reguladores o façam: contato@victorino.com.br | www.victorino.com.br

MCP ganha núcleo stateless: o protocolo parou de improvisar

Thiago Victorino — Mon, 25 May 2026 00:00:00 GMT

No dia 21 de maio, os mantenedores do MCP (David Soria Parra e Den Delimarsky) publicaram o release candidate 2026-07-28 do protocolo. O post chama de “a maior revisão desde o lançamento”. É verdade, e ainda assim subestima o que mudou. O Model Context Protocol acaba de deixar de ser artefato de pesquisa que se tolerava em produção e passou a ser uma superfície avaliável que pode entrar em contrato com fornecedor.

Os números fazem boa parte do trabalho. Seis SEPs (Specification Enhancement Proposals) tratam de statelessness. Outros seis fortalecem a camada de autorização. Os mantenedores fixaram uma janela mínima de 12 meses entre deprecação e remoção. Três primitivos herdados do design original de 2024 (Roots, Sampling, Logging) estão formalmente deprecados. Duas extensões (MCP Apps e Tasks) entram como os primeiros exemplos oficiais do novo modelo de extensão por DNS reverso. Há uma janela de 10 semanas de validação antes da spec final em 28 de julho.

Os times que passaram os últimos nove meses argumentando que o MCP “não está pronto para produção” agora têm uma data concreta em que esse argumento deixa de valer.

A inflexão stateless

A mudança mais importante é estrutural. Até este RC, um servidor MCP carregava estado de sessão. Toda requisição de um cliente precisava cair na mesma instância, porque aquela instância lembrava quem era o cliente e quais ferramentas já tinham sido negociadas. Esse fato isolado ditava todo o padrão de deployment a jusante. Sticky sessions no load balancer. Afinidade de sessão na service mesh. Lógica customizada no CDN para honrar cookies de sessão. Um time que quisesse rodar MCP atrás de DNS round-robin simples na frente de três containers Lambda não conseguia, porque a segunda requisição cairia num container diferente e a negociação teria sumido.

O núcleo stateless resolve isso no nível do protocolo. Estado agora mora na aplicação, onde sempre deveria estar. Um servidor MCP na spec 2026-07-28 é um serviço HTTP stateless. Você pode colocá-lo atrás de qualquer load balancer que distribua requisições de forma aleatória. Você pode cachear respostas na borda. Você pode escalar horizontalmente sem coordenação. Você pode fazer o deploy do mesmo jeito que faz com qualquer outro serviço HTTP interno, sem infraestrutura específica de protocolo no caminho.

Essa é a mudança que transforma o MCP de algo que o seu time de plataforma tinha que planejar em algo que o seu time de plataforma pode ignorar. Para uma empresa que opera service mesh, API gateway e CDN, “parece HTTP” é o jogo inteiro. O protocolo acabou de ganhar o direito de rodar na infraestrutura que você já opera.

Foram seis SEPs para entregar isso. Vale entender por que precisou de seis. Transporte stateless não é só “remover o ID da sessão”. Exigiu repensar como capacidades de ferramentas são negociadas, como subscrições em recursos de longa duração funcionam sem conexão aberta, como tokens de autorização são escopados por requisição em vez de por sessão, e como o cliente sabe o que o servidor oferece sem ter que perguntar a cada vez. Cada uma dessas frentes é uma proposta separada, com revisão separada. Seis SEPs é o tamanho da faxina.

Autorização deixa de ser esboço

O segundo agrupamento (outros seis SEPs) fecha a história de autorização. Até este RC, autorização no MCP era intenção documentada. A spec dizia “use OAuth 2.1”. As implementações faziam mais ou menos isso, com variação suficiente para transformar uma revisão de segurança em projeto de pesquisa.

O RC alinha o protocolo com OAuth e OIDC no nível em que um time de segurança realmente se importa. Validação de token issuer (iss) agora está na spec, não na seção de orientação. Semântica de escopo está definida. Vinculação de audiência do token está definida. Os mantenedores removeram explicitamente a ambiguidade sobre qual token pode ser usado por qual cliente contra qual servidor. A intenção é que a história de autorização de um servidor MCP seja auditável contra o mesmo playbook que os seus fornecedores SaaS atuais usam.

Essa é a mudança que permite ao CISO aprovar sem precisar escrever uma aceitação de risco customizada. Quando o fluxo OAuth contra o seu servidor MCP é indistinguível do fluxo OAuth contra o seu CRM, valem os mesmos controles: o mesmo provedor de identidade, o mesmo inventário de escopos, a mesma política de tempo de vida de token, o mesmo caminho de revogação. O protocolo parou de exigir que você invente controles novos.

A política de deprecação é a vitória de procurement

Soterrada sob as mudanças de destaque está a peça que mais importa para procurement: uma política formal de deprecação com janela mínima de 12 meses entre anúncio e remoção. Roots, Sampling e Logging são os primeiros primitivos a entrar nessa janela. Estão saindo porque eram pouco usados, mal escopados ou duplicados por mecanismos melhores (Tasks substitui trabalho de longa duração; Apps substitui as preocupações com superfície de UI). O ponto não é quais primitivos estão saindo. O ponto é o calendário.

Doze meses é tempo suficiente para um fornecedor atualizar um SDK, lançar uma nova release e dar caminho de migração aos clientes. Também é tempo suficiente para um time de procurement escrever a cláusula contratual que diz: “Se um primitivo do qual o seu servidor depende for deprecado, você tem nove meses a partir do anúncio para entregar atualização compatível, e cabe remediação caso contrário.” Até a semana passada, essa cláusula era impossível de escrever, porque não havia cadência definida de deprecação para apontar. Agora há.

A janela de 12 meses é também o que torna seguro colocar servidores MCP em ambientes que têm ciclos de refresh de software de 24 meses. Dois ciclos de refresh cobrem um ciclo de deprecação com folga. O protocolo virou deployável em setores regulados que estavam esperando exatamente esse compromisso.

Extensões ganham namespace

MCP Apps e Tasks entram como as duas primeiras extensões sob um esquema de nomeação por DNS reverso. Apps traz a preocupação com superfície de UI para dentro do protocolo (o cliente pode renderizar UI fornecida pelo servidor de forma controlada). Tasks traz trabalho de longa duração para dentro do protocolo (o servidor pode devolver um handle de tarefa, o cliente pode fazer polling ou subscrever, o trabalho sobrevive a uma desconexão). As duas foram validadas em implementações reais ao longo dos últimos nove meses. As duas agora têm casa estável na spec.

O esquema de DNS reverso importa mais do que as duas extensões específicas. Significa que um fornecedor pode entregar com.acme.mcp.coisa-proprietaria como extensão reconhecida, e um cliente pode anunciar que suporta org.modelcontextprotocol.apps sem confusão. O namespace é o mecanismo que permite ao protocolo crescer sem fragmentar. Até agora, toda feature específica de fornecedor era ou uma extensão privada que ninguém mais conseguia descobrir, ou uma proposta para mudar o core da spec. O caminho do DNS reverso é o meio termo, e é aquele que todo ecossistema de protocolo saudável acabou adotando.

O que fazer nas próximas 10 semanas

A janela de 10 semanas de validação antes de 28 de julho é quando você consegue influenciar a forma final da spec. Três ações merecem agendamento.

Primeiro, audite os seus deployments atuais de MCP em busca de premissas stateful. Se você tem configuração de sticky session em load balancer por causa de MCP, marque para remoção. Se tem política de service mesh que prende clientes a instâncias, o mesmo. A migração não é automática, mas a faxina é direta e a simplificação operacional é permanente.

Segundo, rode uma revisão de fluxo de token contra os seus servidores MCP sob as novas regras de autorização. A validação de iss, a semântica de escopo e a vinculação de audiência são os três pontos em que as implementações atuais têm mais chance de divergir da spec. Uma revisão de 60 minutos com o seu time de identidade já mostra o que precisa mudar.

Terceiro, escreva a cláusula de deprecação no próximo contrato de fornecedor MCP. A janela de 12 meses é o artefato que torna a cláusula defensável. Se você está fechando contrato neste trimestre sem essa cláusula, está fechando um contrato que vence no dia em que um primitivo usado pelo seu fornecedor for removido.

O RC do MCP não é release de feature. É o momento em que o protocolo parou de ser algo que você adota por fé e passou a ser algo que você consegue avaliar. Os fornecedores que estavam esperando esse momento para levar a sério vão ser os que se moverem rápido no Q3. Os compradores que continuarem tratando MCP como pesquisa vão ser os que estarão assinando cheque de remediação em 2027.

Fontes

Model Context Protocol. “The 2026-07-28 MCP Specification Release Candidate.” Maio de 2026.

A Victorino apoia times de procurement e de plataforma a transformar mudanças de protocolo em critérios de avaliação de fornecedores antes que virem padrão: contato@victorino.com.br | www.victorino.com.br

CEO da Cloudflare Nomeia o Padrão de Demissão por IA: Medidores Saem, Construtores Ficam

Thiago Victorino — Fri, 22 May 2026 00:00:00 GMT

Em 20 de maio de 2026, Matthew Prince, CEO da Cloudflare, publicou um artigo de opinião no Wall Street Journal que fez algo que a maioria dos anúncios de demissão trabalha duro para evitar. Ele nomeou o padrão.

Nas palavras dele (verbatim do parágrafo de abertura): “We haven’t found another example in U.S. business history of a public company growing at more than 30% that laid off more than 20% of its workforce. Yet what we did is likely going to become the norm over the next year.”

Em português, com fidelidade ao sentido: não encontramos outro exemplo na história empresarial americana de uma empresa de capital aberto crescendo mais de 30% que tenha demitido mais de 20% da força de trabalho. E o que fizemos provavelmente vai virar norma no próximo ano.

Leia duas vezes. Crescimento recorde de receita e corte de um quinto do quadro, no mesmo trimestre, na mesma empresa. O enquadramento de Prince sobre por que escreveu o texto (também verbatim): “This is a story about artificial intelligence, but executives and commentators are misunderstanding how it will disrupt business and who will be affected.” Em tradução fiel: esta é uma história sobre inteligência artificial, mas executivos e comentaristas estão entendendo errado como ela vai transformar os negócios e quem vai ser afetado.

O subtítulo que o WSJ publicou, também verbatim, é a parte que todo operador precisa ler em voz alta na próxima reunião de liderança: “The company has less need for middle managers, operations jobs and other measuring positions.” Em português: a empresa tem menos necessidade de gerentes intermediários, cargos operacionais e outras posições de medição.

A palavra para sublinhar é a última. Posições de medição.

O Que Prince Nomeou

O restante do artigo está atrás do paywall do WSJ. O que conseguimos verificar com certeza é o que a própria camada de indexação editorial do WSJ destacou como palavras-chave da espinha argumentativa do texto: analysts, automation, builders, cut, employ, jobs, layoff, MEASURERS, revenue, sellers. O pipeline de metadados do WSJ só destaca termos que se repetem com peso ao longo do corpo. A capitalizada, a que o sistema editorial trata como espinha do argumento, é measurers, medidores.

Então o que dá para afirmar com alta confiança a partir do subtítulo verbatim e da espinha de palavras-chave, e o que estamos inferindo do resto, é o seguinte: o argumento de Prince divide a força de trabalho ao longo de um único eixo. De um lado, medidores, pessoas cuja função principal é rastrear, reportar, sintetizar ou coordenar números e status que a IA agora consegue rastrear, reportar, sintetizar e coordenar sozinha. Do outro lado, construtores, pessoas cuja função principal é criar aquilo que a IA ainda não consegue criar sem assistência: decisões de produto, relacionamentos com clientes, código que vai para produção com julgamento por trás, conversas de venda que fecham.

O corte não foi de baixo para cima. Foi do meio para fora.

Uma observação importante que o artigo também deixa claro, segundo a espinha de palavras-chave: a Cloudflare está contratando em níveis recordes de vagas abertas. A demissão é uma recomposição, não um encolhimento. As cadeiras não estão sendo eliminadas, estão sendo preenchidas de novo com um formato diferente de trabalho.

Por Que Este É o Primeiro Caso Nomeado

Já escrevemos sobre a era do centauro, em que a unidade de medida é o time mais suas ferramentas, não o modelo. Já escrevemos sobre a realidade dos dois porcento de produtividade que não bate com a narrativa de produtividade. Já escrevemos sobre como marketing e outras funções estão virando times de governança.

O que não tínhamos até 20 de maio era um CEO de empresa pública americana colocando nome no corte e na matemática por trás dele. Medidores versus construtores é o enquadramento de Prince, e funciona porque faz o que a maioria das comunicações de demissão se recusa a fazer: diz às pessoas que foram cortadas por que foram cortadas, numa categoria que os pares delas reconhecem, e diz às pessoas que ficaram por que ficaram.

As empresas que tentarem usar esse enquadramento sem fazer o trabalho serão pegas. As empresas que silenciosamente fizerem o trabalho e nunca nomearem perderão as pessoas que poderiam tê-las ajudado a atravessar a transição. Prince fez as duas coisas. Nomeou e está executando em público.

A Pergunta de Modelo Operacional Que Todo CEO Agora Tem de Responder

Se você dirige uma empresa de qualquer porte e o conselho ainda não fez a versão dessa pergunta que começa com “por que não somos a Cloudflare” ou seu inverso mais afiado “por que somos a Cloudflare,” você tem talvez um trimestre antes que façam. A pergunta que de fato será feita é esta: quais papéis nesta empresa são medidores e quais são construtores, e qual é o plano de recomposição, não apenas de corte.

Três armadilhas a evitar na resposta.

Armadilha um: confundir medidores com pessoal júnior. Muitos dos medidores que Prince descreve são seniores. São gerentes intermediários cujo valor era coordenação, síntese de status e consolidação numérica. O corte atravessa o organograma na horizontal, não na vertical. Tratar como conversa de corte de júnior soa para a sala como aceno de mão.

Armadilha dois: confundir construtores com engenheiros. Construtores, no enquadramento de Prince e na realidade operacional que a espinha de palavras-chave sustenta, não são só quem escreve código. Vendedores estão explicitamente do lado construtor da espinha. Também estão quem projeta produtos, quem cuida dos relacionamentos com clientes, quem toma decisões de julgamento que a IA não toma por eles. A divisão é funcional, não departamental.

Armadilha três: assumir que a recomposição é um evento único. Se a capacidade da IA continuar avançando, a linha entre medidor e construtor avança junto. Um papel que hoje é de construtor, em que o julgamento humano é a peça que sustenta a operação, pode virar medidor em 18 meses se a ferramenta ao redor fechar o ciclo de julgamento. O plano não é um corte único. O plano é uma reavaliação contínua de qual é a contribuição humana irredutível de cada papel. É a mesma disciplina que defendemos no texto sobre desacoplamento entre output e competência: o papel não é o output, o papel é o julgamento verificado por trás do output.

O Que Isso Significa Para o Trimestre Em Que Você Está

Três coisas para fazer esta semana.

Primeiro, coloque a pergunta medidores-versus-construtores na pauta da próxima reunião de operação. Não delegue para o RH. Conduza com o time executivo. O entregável é uma página com a fotografia de cada papel acima de uma certa faixa, classificado em uma coluna ou na outra, com uma nota curta para cada um sobre qual é a contribuição humana irredutível hoje e qual pode ser daqui a 12 meses.

Segundo, antes de cortar qualquer coisa, contrate um construtor para cada dois papéis de medidor sobre os quais você tem dúvida. Esta é a jogada da Cloudflare. Prove que a recomposição funciona em pequena escala antes de transformá-la em história de demissão. As empresas que errarem essa parte vão cortar primeiro e descobrir que o banco de construtores está vazio.

Terceiro, escreva, em linguagem simples, como é a sua versão de medidores e construtores dentro do seu negócio. Não adote as palavras de Prince ao pé da letra. As categorias são úteis, os específicos não são transferíveis. Os medidores de uma firma de consultoria são diferentes dos medidores de uma SaaS. Um negócio regulado tem medidores que não pode legalmente cortar. A sua versão dessa fotografia é o trabalho.

O que torna o artigo de Prince historicamente interessante não é a demissão. É que um CEO de empresa pública colocou nome na mudança de modelo operacional e pediu para o resto do mercado olhar para o seu. Os conselhos e a imprensa estão prestes a atender o pedido. Melhor ter a fotografia na mão quando perguntarem.

Fontes

Matthew Prince (WSJ Opinion). “How I Choose Which Cloudflare Employees to Replace With AI.” Maio de 2026. Paywall: parágrafos abertos citados literalmente; restante inferido dos keywords editoriais da própria WSJ.

A Victorino ajuda times de liderança a separar o trabalho de IA que constrói a empresa do trabalho de IA que só parece ocupado: contato@victorino.com.br | www.victorino.com.br

Greg Wilson Acaba de Dar Espinha Acadêmica ao Ceticismo Sobre Produtividade de IA

Thiago Victorino — Fri, 22 May 2026 00:00:00 GMT

Todo ensaio de ceticismo sobre medição de produtividade de IA em codificação que publicamos nos últimos seis meses carregou a mesma nota de rodapé incômoda: a maior parte dos números que estávamos rebatendo vinha de blogs de fornecedores, e a maior parte dos números que citávamos para rebater vinha de um punhado pequeno de estudos que todo mundo repete porque não há muito mais a citar. A literatura existia. Estava apenas dispersa. Ninguém havia montado.

Greg Wilson montou em 20 de maio de 2026. Twelve Ways to Be Wrong About AI-Assisted Coding é a espinha revisada por pares que faltava no debate de produtividade. Cada um dos doze modos de falha que Wilson cataloga vem com pelo menos uma fonte acadêmica por trás, e as citações são majoritariamente de 2025 e 2026, o que significa que o campo finalmente produziu trabalho empírico suficiente para fazer uma revisão de verdade.

Se você passou algum tempo argumentando contra a alegação de “40% mais rápido com nosso copilot” de algum fornecedor e se pegou alcançando as mesmas três referências, este é o documento que substitui aquele arsenal.

O Que os Estudos de Fato Dizem

A descoberta de manchete que atravessa a revisão de Wilson é que benchmarks de fornecedores e medições de campo discordam por um fator que deveria envergonhar quem ainda cita os primeiros. Becker (2025) constatou que o GitHub Copilot produziu aceleração de 55% em problemas artificiais de codificação. Rode a mesma ferramenta contra trabalho real de manutenção em código aberto e o efeito se inverte: lentidão de 19%, não aceleração. O estudo de Peng (2023) que Wilson cita como origem dos 55% foi sobre uma tarefa construída que não se parece em nada com manter uma base de código de cinco anos com dezessete contribuidores.

A descoberta sobre desenvolvedores sêniores é a que deveria fazer líderes de engenharia parar. O mesmo corpo de pesquisa que mostra desenvolvedores juniores recebendo aceleração genuína também mostra desenvolvedores sêniores experimentando queda de 19% de produtividade. O mecanismo não é misterioso. Sêniores absorvem a carga de revisão do código gerado por IA que juniores fazem merge. A saída da ferramenta vira a entrada deles, e a entrada é de qualidade inferior àquela que o sênior teria escrito sozinho. Escrevemos sobre essa dinâmica em A Armadilha da Velocidade na Codificação com IA; a revisão de Wilson agora dá citação ao argumento.

Liu (2026) mediu o arrasto de qualidade diretamente: mais de 15% dos commits gerados por IA introduzem problemas de qualidade, e cerca de 25% desses problemas persistem no longo prazo. Isso não é custo transitório. É dívida técnica sendo entregue a uma taxa que supera a capacidade de captura da revisão normal de código, e ela se compõe.

He (2026) estudou a adoção de Cursor especificamente e descobriu que os ganhos de velocidade foram transitórios enquanto os aumentos de complexidade foram persistentes. O time ficou mais rápido por um trimestre, voltou para a velocidade baseline e ficou carregando uma carga de complexidade permanentemente maior. Esse é o desacoplamento entre saída e competência sobre o qual escrevemos, agora medido longitudinalmente.

Os estudos corporativos contam a mesma história pelo lado de compras. Bakal (2025) reportou taxa de aceitação de 33% para sugestões de IA em ambientes de produção, sem rastreamento de correção atrelado. A organização que compra a ferramenta sabe com que frequência o desenvolvedor aceita a sugestão. Não sabe com que frequência a sugestão aceita estava correta. Weisz (2025) na IBM mediu ganhos desiguais entre usuários em um estudo controlado, com variância grande o suficiente para que números agregados de “lift de produtividade” virassem irrelevantes.

O piso de segurança é o que deveria fazer qualquer CISO ler o artigo duas vezes. Pearce (2022), confirmado por Dora (2025), testou cinco grandes LLMs contra padrões consolidados de segurança web. Os cinco falharam. Não “tiveram desempenho abaixo do esperado”. Falharam. A implicação é que qualquer time medindo produtividade de IA em codificação sem medir segurança de IA em codificação está calculando um numerador enquanto ignora um denominador que pode já tê-lo superado.

Por Que Isso É Revisão de Literatura e Não Mais um Ensaio

A razão pela qual o texto de Wilson importa não é que ele faça um argumento novo. O argumento já foi feito. Importa porque, pela primeira vez, dá para entregar as citações para outra pessoa.

Toda vez que escrevemos sobre o problema dos dois por cento de produtividade, ou sobre por que medir o time e não o modelo é a única jogada honesta, ou sobre a diferença do harness, estávamos argumentando em um vácuo em que o outro lado cita deck de marketing de SaaS e o nosso lado cita três estudos no replay. Wilson catalogou o resto. Becker, Peng, Liu, He, Bakal, Weisz, Pearce, Dora. Os nomes importam porque os nomes são como a conversa migra de crença para citação.

Se você senta em uma reunião em que alguém diz “nossos desenvolvedores estão 40% mais rápidos com esta ferramenta”, agora dá para fazer três perguntas com respaldo acadêmico:

Qual é a distribuição de tarefas? Becker mostrou que a aceleração de 55% colapsa para lentidão de 19% quando você sai de problemas artificiais para trabalho real de manutenção.
Qual é a distribuição de senioridade? O mesmo número de produtividade médio entre juniores e sêniores esconde uma queda na ponta sênior.
Qual é o horizonte de persistência? He mostrou que o ganho de velocidade é transitório e o custo de complexidade é permanente.

Três perguntas. Três citações. O fornecedor não pode mais responder com outro deck.

A Implementação Continua a Mesma

A revisão de Wilson não muda como se parece um programa sério de medição. Muda apenas o som da conversa em torno de compras e adoção. O trabalho de implementação que publicamos continua de pé.

Se você quer medir o seu time em vez do modelo, A Era Centauro do Software continua sendo o framework. Se você quer entender por que competência de saída e verificação precisam ser medidas separadamente, o ensaio sobre a camada de verificação continua sendo a decomposição. Se você quer saber por que o mesmo modelo produz números de produtividade diferentes em harnesses diferentes, a diferença do harness continua sendo a explicação.

O que muda é o que você coloca na frente das pessoas que não leem esses ensaios. Você coloca Wilson na frente delas. Coloca Becker, Liu, He, Pearce na frente delas. Os ensaios de ceticismo eram para praticantes. A revisão de literatura é para todos os outros.

Faça Isso Agora

Reserve trinta minutos esta semana. Leia o texto de Wilson do começo ao fim. Puxe as três ou quatro citações mais relevantes para as alegações de produtividade que você está sendo solicitado a avaliar ou rebater agora. Adicione-as ao documento compartilhado que a sua organização de engenharia usa para avaliação de fornecedores. Na próxima vez que alguém entrar com um deck de “40% mais rápido”, o documento já estará com as contra-citações carregadas.

Em seguida, dê o passo mais difícil: audite as suas próprias alegações internas de produtividade para ferramentas de IA em codificação. Se você disse a um executivo “nosso time está X% mais produtivo desde a adoção de Y”, confira essa alegação contra os doze modos de falha de Wilson. A descoberta mais comum é que a métrica mediu algo diferente do que o nome sugeria. Esse é o momento de consertar a métrica, não de defendê-la.

O debate de produtividade acabou de deixar de ser concurso de impressões. A literatura está montada. Os nomes têm citações. Os fornecedores não levam mais a última palavra por padrão.

Fontes

Greg Wilson. “Twelve Ways to Be Wrong About AI-Assisted Coding.” Maio de 2026.

A Victorino ajuda líderes de engenharia a substituir alegações de produtividade dos fornecedores por medições que sobrevivem a uma revisão por pares: contato@victorino.com.br | www.victorino.com.br

O Agente do Figma na Tela Acaba de Transformar o Design System no Prompt

Thiago Victorino — Fri, 22 May 2026 00:00:00 GMT

No primeiro trimestre, escrevemos que o design system se tornaria a camada de restrição do design gerado por IA. Em 20 de maio, o Figma lançou o agente na tela. A tese virou produto.

Este texto não é mais um ensaio sobre se design systems importam na era dos agentes. O argumento está encerrado. O que importa agora são as três escolhas de governança que o Figma fez no lançamento real. Leia essas escolhas com atenção e você verá o modelo da camada de restrição se cristalizando em um produto comercial.

Escolha um: @ menções tornam tokens a superfície do prompt

A funcionalidade mais citada é que o agente gera múltiplas explorações estilísticas em paralelo a partir de um único prompt. A funcionalidade mais importante está enterrada dois parágrafos abaixo. Você direciona o agente com @ menções: @ em um token, @ em uma variável, @ em um componente, e o gerador fica restrito àquela superfície.

Existem dois caminhos para entregar uma ferramenta generativa de design. O primeiro é deixar o modelo inventar tudo, da tipografia ao espaçamento, e depois forçar os designers a reconciliar a saída contra o sistema. Foi o que a maioria das demos iniciais mostrou em 2024. O segundo é forçar toda geração a passar pelas primitivas que o sistema já tem. O Figma escolheu o segundo caminho e o tornou a gramática de entrada.

Isso importa porque inverte o fluxo que a maioria dos times esperava. O prompt não é “faça um card com cantos arredondados e um CTA primário”. O prompt é “faça um card usando @card-elevated e @semantic/action-primary”. O design system deixa de ser a coisa que você parafusa na geração depois do fato. Vira a linguagem em que você gera.

Há uma implicação silenciosa para times de governança. Todo prompt agora carrega uma referência estruturada aos artefatos que o seu sistema já governa. A pergunta de auditoria muda de “o agente usou os componentes certos” para “quais componentes foram referenciados com @ em quais prompts”. Essa telemetria é trivial de capturar se o Figma a expuser, e ela dá ao design ops uma superfície de controle que não existia uma semana atrás.

Escolha dois: a referência à biblioteca de componentes usa frequência como padrão

Quando o agente alcança um componente sem uma menção @ explícita, ele puxa do conjunto “mais usado” na sua biblioteca. Essa é a escolha de design que me dá mais esperança e mais preocupação ao mesmo tempo.

A esperança é direta. Frequência é um padrão defensável. Enviesa a geração na direção de componentes em que o time já convergiu, o que significa que telas geradas se parecem com o resto do seu produto em vez de parecerem um universo paralelo de variantes pontuais. Também cria um loop positivo de feedback: componentes governados são mais usados, a frequência sobe, o agente os usa mais, e os componentes que os designers tentaram aposentar deixam de aparecer em trabalho novo.

A preocupação é que frequência não é o mesmo que correção. Um componente pode ser usado mil vezes e ainda ser o depreciado. Uma biblioteca pode ter um “v2/button” que é a superfície canônica e um “legacy/button” que ninguém terminou de migrar, e a frequência vai favorecer o legacy até que a migração termine. Times de design ops agora precisam tratar a curva de frequência de componentes como uma métrica de governança de primeira classe, não como um relatório de uso enterrado em uma revisão trimestral.

Os times que vencem os próximos dois trimestres são os que auditam a curva de frequência ainda esta semana e decidem em quais componentes querem que o agente caia como padrão, e então engenheiram a biblioteca para que esse seja o padrão de fato.

Escolha três: tiers de assento são a cerca da governança

A matriz de elegibilidade é onde a tese da camada de restrição se torna juridicamente vinculante. O agente vai para assentos completos Pro, Org e Enterprise. Assentos Collab e Dev podem usar apenas em rascunhos. Planos Starter, Education e Government ficam de fora completamente.

Isso não é estratégia de preço. É governança. O Figma fez uma escolha deliberada: um agente capaz de gerar artefatos de design para produção não deve rodar dentro de planos sem controles organizacionais. Planos Starter não têm a superfície de admin. Planos Education não têm contratos com responsabilização. Planos Government têm restrições de compras que o produto ainda não satisfaz.

A regra “apenas rascunhos” para Collab e Dev é a ruga mais interessante. Diz: você pode brincar com o agente no seu próprio sandbox, mas não pode entregar a saída dele no workspace compartilhado sem um assento completo. O assento completo é o artefato que carrega responsabilização, histórico de versão e trilha de auditoria. A superfície de rascunho é o playground. A fronteira entre os dois é a fronteira de governança, e agora ela corresponde a um tier de cobrança.

Se o seu time de design ops vinha discutindo internamente quais cargos deveriam ter acesso ao agente, o Figma acabou de fazer o trabalho por você. O padrão é restritivo, o caminho de upgrade é claro, e a justificativa está construída dentro do produto em vez de parafusada pela sua política de TI.

A pista no preço do beta

Um detalhe operacional pertence a todo plano: o beta não consome créditos de IA, mas a disponibilidade geral migra para precificação por crédito. Essa é a cadência padrão do Figma e significa duas coisas para o próximo trimestre.

Primeiro, esta é a janela para rodar experimentos de governança sem pressão de orçamento. Faça seu time de design ops construir uma auditoria de biblioteca, uma revisão de frequência e um mapa de cobertura de tokens antes que os créditos comecem a contar. Quando a medição entrar em vigor, todo experimento vem com uma pergunta do CFO anexada.

Segundo, precificação por crédito transforma “usar o agente para tudo” em um custo mensurável. Times que apoiam o agente em cada tela vão ver a conta crescer. Times que usam o agente para o trabalho em que ele é melhor, que é exploração e operações em massa, vão ver valor governado. O Figma está, intencionalmente ou não, precificando a disciplina.

O que fazer ainda esta semana

Bloqueie 60 minutos com o lead de design ops e caminhe pelas três escolhas de governança contra a sua configuração atual.

Abra sua biblioteca de componentes e puxe a curva de frequência. Se os componentes mais usados não forem os que você quer que o agente assuma como padrão, você tem uma auditoria de biblioteca para agendar antes da disponibilidade geral. O agente vai amplificar o que o relatório de frequência diz, então faça o relatório dizer a coisa certa.

Abra seu sistema de tokens e confirme que as coisas que você quer que o agente use estão de fato referenciáveis por @. Tokens que existem em um arquivo JSON mas não estão expostos como variáveis do Figma vão ser invisíveis para o agente. A governança que você quer impor precisa morar na superfície que o agente enxerga.

Puxe sua matriz de assentos e decida quem recebe assentos completos Pro, Org ou Enterprise. A decisão costumava ser sobre funcionalidades de colaboração. Agora é sobre quem pode entregar trabalho de produção gerado por agente. Essa é uma conversa diferente, e você quer ter essa conversa antes que alguém de marketing pergunte por que não pode usar o agente.

A camada de restrição sobre a qual escrevemos em fevereiro virou nota de release. Os times que construíram seu design system como infraestrutura de governança vão passar o terceiro trimestre ligando o agente e vendo ele funcionar. Os times que não construíram vão passar o terceiro trimestre explicando à liderança por que as telas geradas não se parecem com o produto deles. Ambos os times vão usar a mesma ferramenta. Apenas um deles vai estar feliz por isso.

Fontes

Figma. “The Figma agent is here.” Maio de 2026.

A Victorino ajuda times de design e produto a transformar o design system na camada de governança do trabalho gerado por IA: contato@victorino.com.br | www.victorino.com.br

Gartner Acaba de Quantificar o Déficit de Confiança em IA na Compra B2B

Thiago Victorino — Fri, 22 May 2026 00:00:00 GMT

Na Gartner CSO and Sales Leader Conference de maio de 2026, a consultoria publicou um conjunto de números que os fornecedores vinham silenciosamente evitando. 70% dos compradores B2B preferem experiências de compra digital com autoatendimento. Quase 50% já usam ferramentas de IA generativa para pesquisar fornecedores e produtos. Mais de 50% relatam receber informações enganosas dessas ferramentas. E 69% recorrem a representantes de vendas para validar o que a IA disse.

A Gartner também projeta que, até 2027, 95% dos fluxos de pesquisa de vendedores começarão com IA.

Cinco porcentagens, uma história. Compradores querem autonomia. Estão exercendo. A autonomia produz resultados pouco confiáveis. Eles contornam essa falta de confiabilidade ligando para um humano. A narrativa de marketing de que IA está substituindo a conversa de vendas é, no melhor cenário, metade do quadro. A outra metade é que IA elevou o sarrafo do que torna uma conversa de vendas digna de acontecer.

Uma nota sobre a fonte antes de seguir. Os dados foram apresentados em conferência da Gartner e reportados pela MarTech. A cobertura publicada não revela tamanho de amostra, metodologia ou instrumento de pesquisa. Trate o formato direcional dos números como informativo; trate os dígitos exatos como arredondamento de palco de conferência. O argumento que segue se sustenta mesmo que a segunda casa decimal esteja errada.

A Preferência por Autoatendimento Não É o Sinal de Substituição

O número de 70% de preferência por autoatendimento é citado como se significasse que compradores não querem vendedores. Não é isso que essa preferência significa. Significa que compradores não querem vendedores nas partes do ciclo que conseguem completar por conta própria.

Observe a sequência que o mesmo comprador percorre. Ele pesquisa uma categoria no Google. Cai em uma página de fornecedor. Lê três concorrentes. Cola as descrições no ChatGPT ou no Gemini e pede uma comparação. Recebe uma resposta que soa autoritativa. Não tem como verificar, porque a IA não cita especificações de produto, não conhece os termos contratuais e inventa, com confiança, funcionalidades que não existem. Agora ele tem uma lista curta em que não confia e uma comparação que não consegue defender internamente.

Nesse ponto, o comprador faz uma de duas coisas. Ou agenda uma ligação de vendas com uma pessoa para confirmar o que a IA disse, ou abandona a categoria. Os 69% que recorrem a representantes de vendas para validação são o primeiro grupo. O segundo grupo não aparece nos dados da Gartner; é a perda silenciosa.

A implicação para organizações de vendas é desconfortável. As fases iniciais do funil estão sendo comoditizadas pela busca por IA. O momento da validação, que costumava ser o terceiro ou quarto toque, agora é a primeira vez em que um humano entra na conversa. E o comprador chega desconfiado, porque a IA já mentiu para ele pelo menos uma vez.

Quanto Custa de Verdade o Número de 50% de Informação Enganosa

Metade dos compradores B2B relata que ferramentas de IA já entregaram informação errada sobre um fornecedor. Isso não é incômodo marginal. É um problema estrutural de confiança que se acumula em cada interação seguinte.

A informação errada assume formas específicas. Ferramentas de IA confundem dois produtos do mesmo fornecedor. Citam funcionalidades de um concorrente como se pertencessem ao produto pesquisado. Reproduzem preços de páginas desatualizadas. Inventam integrações. Resumem o posicionamento de um fornecedor de um jeito que achata o que ele passou dois anos diferenciando. Nenhum desses casos é ruído aleatório. São padrões que emergem quando um modelo de linguagem encontra material-fonte fragmentado ou raso e preenche os vazios com texto que soa plausível.

O custo não é só os negócios perdidos porque a IA distorceu sua mensagem. O custo é também os negócios que precisam ser reconquistados porque o comprador chega acreditando em algo que não é verdade, e seu representante agora tem de gastar os primeiros 20 minutos da reunião corrigindo, com delicadeza, o output da IA sem fazer o prospect se sentir burro. A conversa de validação virou conversa de remediação, e isso leva mais tempo, custa mais e converte pior.

O Momento da Validação É a Nova Porta de Entrada

Sessenta e nove por cento dos compradores pedem a um vendedor que valide o que a IA disse. Traduza isso em termos operacionais.

A conversa de vendas não trata mais de descobrir necessidades. O comprador descobriu com IA. Não trata de apresentar funcionalidades. O comprador as puxou do site. Trata de confirmar ou corrigir o quadro que o comprador montou antes do representante entrar na sala. O representante que vai ter sucesso em 2026 entra sabendo que o prospect já tem uma opinião em rascunho, que esse rascunho está parcialmente errado, e que o trabalho dos primeiros 10 minutos é descobrir quais partes estão erradas sem soar defensivo.

Esse músculo é diferente do músculo da venda consultiva clássica. Está mais perto da correção consultiva. Representantes precisam perguntar, cedo e de forma explícita, o que o comprador já acredita e onde ele leu aquilo. Precisam não se incomodar quando a resposta for “perguntei pro ChatGPT” ou “o Perplexity me disse”. Precisam ter um modelo mental de como ferramentas de IA resumem sua categoria e onde estão os modos de falha, para conseguirem prever a impressão errada e antecipá-la.

Marketing tem um papel aqui também, e ele se conecta com a função de governança que argumentamos que marketing está se tornando. Se metade dos compradores está sendo enganada por IA, o trabalho de marketing vai além de produzir conteúdo. Inclui monitorar como ferramentas de IA representam a marca, corrigir o material-fonte do qual a IA está puxando, e dar para vendas os artefatos necessários para conduzir bem a conversa de validação. Isso faz parte do desacoplamento mais amplo entre output e competência, que exige uma camada de verificação: a IA produz uma resposta confiante, e a camada de validação (um humano, um documento, uma demonstração) é o que torna a resposta confiável.

Importa também porque, como escrevemos quando agentes começam a comprar tanto quanto vender, o agente de IA do lado do comprador é a próxima camada do mesmo problema. Hoje, um humano pergunta ao ChatGPT e depois liga para vendas. Amanhã, um agente pergunta ao ChatGPT e grava uma lista curta numa fila de compras sem humano no meio. O déficit de confiança não desaparece. Sobe um andar na pilha.

O Que Fazer Esta Semana

Três ações concretas para times de vendas e marketing lendo esses dados:

Audite como a IA representa você. Pegue seus cinco principais concorrentes. Peça a ChatGPT, Gemini, Claude e Perplexity para comparar seu produto contra cada um. Leia as respostas como se fosse um comprador cético. Anote todo erro factual, toda funcionalidade confundida, todo dado desatualizado. Esse é o quadro com que seus prospects estão chegando. Se você não sabe o que a IA diz sobre você, não sabe no que seus representantes estão entrando.

Reescreva os primeiros 10 minutos da ligação de vendas. Treine representantes para abrir com “o que você já aprendeu sobre nós e onde aprendeu”. Largue o roteiro de descoberta. A descoberta aconteceu antes da ligação. A abertura agora é diagnóstica: no que o comprador acredita, e quanto disso está errado. Construa uma colinha de uma página com as distorções mais comuns da IA sobre seu produto e como corrigir cada uma sem soar condescendente.

Trate seu conteúdo público como dado de treinamento de IA. Seu site, sua documentação, sua página de preços, seus cases. Cada uma dessas páginas é uma fonte que uma ferramenta de IA vai puxar para responder perguntas sobre você. Se sua página de produto é vaga, a IA vai preencher a vagueza com chutes confiantes. Se seus cases estão escondidos, a IA não vai achar e vai resumir seu posicionamento a partir de uma resenha de terceiro. A clareza, a estrutura e a acessibilidade do seu conteúdo agora afetam o que a IA diz aos seus prospects antes mesmo de eles falarem com você.

A projeção de 2027 de que 95% dos fluxos de pesquisa de vendedores começarão com IA é a metade fácil dessa história. A metade difícil é que 95% dos fluxos de pesquisa de compradores já começam, e os compradores sabem que as respostas são pouco confiáveis. Os times que ganham os próximos dois anos não são os que adotam IA mais rápido. São os que constroem a camada de validação que torna a pesquisa feita por IA segura o suficiente para agir em cima.

Fontes

MarTech (cobrindo Gartner). “B2B Buyers Trust AI Less Than Marketers Think.” Maio de 2026.

A Victorino ajuda times de vendas e marketing B2B a transformar lacunas de confiança em IA em momentos de validação que fecham negócios: contato@victorino.com.br | www.victorino.com.br

O Stack de Contenção Se Completou: Quatro Camadas em Uma Semana

Thiago Victorino — Fri, 22 May 2026 00:00:00 GMT

Entre 20 e 21 de maio, quatro organizações lançaram quatro coisas bem diferentes dentro do mesmo problema. A Dropbox abriu o código do Nova, uma plataforma interna que embrulha agentes de codificação em isolamento de workflow. A CNCF anunciou o Prempti, uma camada de política derivada do Falco que intercepta as ações que o agente tenta executar antes de chegarem ao host. O Google lançou o Agent Executor (o runtime open-source ax) junto com o Agent Substrate sobre Kubernetes, um runtime distribuído para agentes que precisam sobreviver a reinícios, ramificar a própria trajetória e escalar para milhões de instâncias registradas. A IBM, no mesmo keynote do Think, fez o caso executivo para “digital workers” como uma classe de trabalho gerenciada, com crachá, onboarding e aposentadoria.

Lidos isoladamente, são quatro anúncios de fornecedor. Lidos em conjunto, na ordem em que apareceram no feed, descrevem quatro andares de um edifício que a Victorino esboçou um mês atrás no ensaio original sobre convergência e que agora está sendo preenchido por empresas que não se coordenaram. A história interessante desta semana não é que todas lançaram. É que lançaram em altitudes diferentes.

Camada 1: Isolamento de Workflow (Dropbox Nova)

O post do Nova é o mais próximo do chão dos quatro lançamentos. Nova é uma plataforma para rodar agentes de codificação dentro dos próprios workflows de engenharia da Dropbox, com três restrições que importam:

Um teto de cinco iterações por workflow. Um agente que não convergiu depois de cinco tentativas não recebe a sexta; o workflow para e um humano assume. A plataforma se recusa a gastar tokens infinitos perseguindo um plano ruim.

Um deflaker que valida cada correção candidata contra mais de 100 execuções de CI antes do merge. Agentes de codificação propõem código o tempo todo; o gargalo não é geração, é verificar que a proposta não introduz um teste instável. A Nova trata o deflaker como componente de primeira classe do workflow, não como reflexão posterior.

Snapshots herméticos por commit. Cada execução do agente recebe uma visão congelada do repositório em um commit conhecido, de modo que reexecuções são reproduzíveis e agentes concorrentes não enxergam trabalho meio feito uns dos outros.

O que a Dropbox lançou não é sandbox no sentido de sistema operacional. É sandbox no sentido de workflow: o agente roda contra uma versão delimitada do repositório, com um número delimitado de tentativas, supervisionado por um validador determinístico. A fronteira de confiança é o próprio workflow. Esta é a camada mais próxima do trabalho real do agente, e é onde a maior parte dos times acidentalmente não tem nada.

Camada 2: Interceptação de Ações (CNCF Prempti)

Um andar acima do isolamento de workflow está a interceptação de ações. O anúncio do Prempti pela CNCF é a implementação de referência que não existia no mês passado. Prempti é construído em cima do projeto Falco de segurança de runtime e observa as coisas que agentes de codificação tentam fazer e não deveriam: ler chaves SSH, exfiltrar credenciais AWS, modificar a configuração de servidores MCP para escalar as próprias permissões, injetar comandos em git hooks.

A decisão de design que merece ser nomeada: Prempti é pré-execução, não auditoria pós-fato. Uma violação registrada é útil para forense, mas não impede que a chave SSH do laptop saia do prédio. A instrumentação de kernel do Falco permite ao Prempti bloquear o syscall antes que ele complete. Suporta Claude Code hoje em Linux, macOS e Windows, com Codex no roadmap.

Esta camada responde a uma pergunta que a camada de workflow não consegue: “O que o agente está de fato tentando fazer no host?” O teto de cinco iterações do Nova não protege se a iteração três silenciosamente lê ~/.ssh/id_rsa e dispara um POST para um webhook do Discord. A camada de workflow confia na intenção do workflow. A camada de ações não confia em nada e inspeciona cada toque no sistema.

O Prempti também produz a telemetria de que as duas camadas seguintes dependem. Sem atribuição por ação, você não consegue dizer qual agente fez o quê, e os andares de cima perdem a capacidade de tomar decisões sobre instâncias específicas.

Camada 3: Durabilidade de Runtime (Google Agent Executor)

Dois andares acima, você bate na pergunta que o Google escolheu responder nesta semana: como agentes sobrevivem em escala? O anúncio do Agent Executor e o repositório google/ax correspondente definem um runtime, não um sandbox. As primitivas são execução durável (um agente pode cair e retomar no meio da trajetória), sandboxes seguros por processo de agente, ramificação de trajetória (o agente pode bifurcar o próprio raciocínio e descartar o ramo pior) e Agent Substrate, um registry sobre Kubernetes desenhado para milhões de agentes registrados.

O runtime é compatível com o protocolo A2A, ou seja, agentes escritos para ele interoperam com outros endpoints A2A, incluindo o ecossistema agente-a-agente que cobrimos nas notas do Cloud Next. A escolha deliberada é fazer do runtime, não do framework, a peça que escala. O grafo de tarefas do agente é a unidade de execução; o framework que o produziu é intercambiável.

Durabilidade é o andar que as pessoas pulam porque tudo funciona bem até não funcionar. Um agente no meio de uma trajetória de 40 passos é desalojado por uma falha de nó Kubernetes. Sem execução durável, o agente reinicia do passo um, queima os tokens de novo, possivelmente segue um caminho diferente e silenciosamente diverge. Com execução durável, ele retoma no passo 23 com o mesmo contexto e continua. A diferença é invisível no dashboard até você contar a computação desperdiçada e os resultados inconsistentes.

O Agent Executor fica acima da camada de ações porque assume que o host já está protegido. É a camada em que um agente vira uma workload de longa duração, observável e reiniciável, do mesmo jeito que serviços viraram workloads de longa duração observáveis uma década atrás.

Camada 4: Gestão de Ciclo de Vida (Digital Workers da IBM)

O andar de cima é o que a IBM marcou no Think nesta semana. O keynote de Mohamad Ali (SVP, IBM Consulting, falando sob o mandato de Krishna) enquadrou agentes não como código, mas como trabalhadores com ciclo de vida: contratados, integrados, certificados, auditados, aposentados. A parceria com a Pearson produz badges de habilidade que controlam quais agentes podem assumir quais trabalhos. A Providence Health cortou em 12 dias o ciclo de recrutamento de enfermeiros usando um pool de digital workers. A aplicação interna da IBM decompôs 490 workflows de consultoria, reivindica US$ 4,5 bilhões em ganhos de produtividade e atribui 20 pontos percentuais de aumento de margem em consultoria entre 2024 e 2025.

Tirando o enquadramento de keynote, a afirmação operacional é esta: em escala corporativa, agentes não são workloads, são headcount. As perguntas que o RH sempre fez sobre funcionários se aplicam aos agentes nesta camada. A quem ele se reporta? Em que é certificado? O que se faz quando ele erra? Qual é o procedimento de offboarding que remove os acessos de forma limpa? A aposta da IBM é que organizações operando com centenas a milhares de agentes precisam de uma camada com formato de RH acima do runtime, não de mais um runtime.

Esta é a camada que não cabe em nenhuma das três de baixo. A Nova gerencia workflows. O Prempti gerencia ações. O Agent Executor gerencia processos. Nenhum responde: “Este agente específico deveria ter permissão para assumir este trabalho específico hoje?” Essa é uma pergunta de ciclo de vida. O crachá, o papel, a aposentadoria, a trilha de auditoria de quem contratou este agente e por quê, tudo isso fica acima do runtime e abaixo da decisão de negócio.

Por Que o Diagrama da Pilha Importa Mais Que Qualquer Fornecedor

Você não precisa escolher entre Dropbox, CNCF, Google ou IBM. Precisa escolher uma camada para ser honesto a respeito. Se você roda agentes de codificação e o único controle é o prompt, está sem a camada 1. Se tem isolamento de workflow mas não tem interceptação de ações, um teto de iterações não te salva de uma exfiltração. Se seus agentes reiniciam do zero toda vez que um nó morre, não há camada 3. Se você opera mais de cinquenta agentes em produção e não consegue responder “quem certificou este aqui a tocar dados de cobrança”, não há camada 4.

Os quatro fornecedores desta semana não se coordenaram. Mas expuseram as camadas com clareza suficiente para que você audite o próprio stack contra o diagrama. É isso que governança como produto parece quando os produtos chegam na mesma semana e se encaixam em andares diferentes. É também por que a história da convergência do início do mês estava subestimando: chamou a tendência certa, mas subestimou a velocidade da diferenciação por camada.

A camada que a maioria dos times vai querer comprar primeiro é a 4 (tem narrativa executiva, métricas amigáveis ao board e alegação de ROI). A camada de que a maioria dos times realmente precisa primeiro é a 2 (um agente sem interceptação de ações é uma exfiltração de credencial esperando para acontecer). A camada para a qual a maioria já tem alguma resposta é a 3 (o Kubernetes já estava ali; só falta um runtime que saiba usá-lo). A camada que a maioria subestima é a 1 (porque as restrições de workflow parecem imposto de produtividade até a primeira vez em que um agente queima 200 iterações em um plano errado).

Faça Isto Agora

Reserve 45 minutos com o líder de plataforma ainda esta semana. Desenhe as quatro camadas em um quadro. Para cada uma, anote o fornecedor ou sistema que a opera no seu stack, ou escreva “nenhum” se ninguém a opera. Conte os “nenhum”. Esse número é a sua dívida honesta de contenção.

Depois, pegue o “nenhum” de menor número e atribua um dono. Não um projeto. Um dono. A ordem das camadas importa porque os andares de cima assumem que os de baixo existem. Comprar gestão de ciclo de vida da camada 4 antes de ter interceptação de ações da camada 2 é contratar diretor de RH para um prédio sem porta de entrada.

O diagrama agora foi desenhado por pessoas que não trabalham com você e que lançaram tudo numa terça. A parte difícil é a auditoria que você roda dentro do próprio prédio. Você vai descobrir pelo menos um andar faltando. Esse é o trabalho do próximo trimestre.

Fontes

Dropbox Engineering. “Introducing Nova, Dropbox’s Internal Platform for Coding Agents.” Maio de 2026.
CNCF. “Introducing Prempti: Policy and Visibility for AI Coding Agents.” Maio de 2026.
Google Cloud. “Introducing Agent Executor, Google’s Distributed Agent Runtime.” Maio de 2026.
SiliconANGLE / IBM. “Managing Digital Worker Lifecycle.” Maio de 2026.

A Victorino ajuda times a escolher camadas de contenção que combinam com o risco real do workflow, não com o marketing do fornecedor: contato@victorino.com.br | www.victorino.com.br

Verificação Formal Acaba de Ganhar Comprovantes. Dois Deles. Em Uma Semana.

Thiago Victorino — Fri, 22 May 2026 00:00:00 GMT

Nos últimos meses, nossos textos sobre governança por especificação foram pesados em argumentação. Argumentamos que especificações eram a camada de controle que faltava. Argumentamos que a adoção corporativa de SDD vinha ultrapassando a própria governança. Trouxemos as notas do Cloud Next sobre desenvolvimento orientado por spec. Argumentamos que as próprias specs de agentes eram artefatos de governança. O que faltava era código rodando para apontarmos e dizer: “é assim que a espinha de verificação aparece quando alguém de fato a constrói.”

Em uma semana, ganhamos dois exemplos.

A Antfly publicou um workflow de cinco passos em que agentes de IA escrevem specs em TLA+, rodam o model checker contra um key/value store de nível de produção e expõem uma race condition real. Reuben Brooks publicou o Shen-Backpressure, um compilador que transforma definições de tipo em cálculo de sequentes em guard types selados para Go, TypeScript, Python e Rust, recusando código de agente inválido em tempo de compilação. Camadas de abstração diferentes. Linguagens diferentes. Mesma tese de fundo: quando geração de código é barata, verificação precisa ser estrutural, não opcional.

Este texto não é uma re-argumentação. O padrão deixou de ser hipotético. O texto é: como cada um dos dois stacks se parece, e o que eles dizem sobre o destino da espinha de verificação.

O Que a Antfly Fez

O texto de Rowan Copley, Cheap Code Means Formal Verification Is Reasonable Now, pega um workflow que a maioria dos times de engenharia classificaria como “acadêmico” e o coloca para rodar contra o Pebble, o key/value store que sustenta o Cockroach Labs. O time escolheu uma race condition histórica do Pebble como benchmark e perguntou: um workflow TLA+ guiado por agente consegue achar esse bug sem conhecimento prévio?

A resposta foi sim, e o workflow que produziu a resposta tem cinco passos:

Escrever um assumptions.md e um boundaries.md que descrevem o que é o sistema e o que a verificação está autorizada a tocar.
O agente escreve as specs em TLA+, roda o model checker e reporta achados.
Validar os achados contra o código real.
Criar testes unitários que reproduzem o bug no código de produção.
Corrigir o bug e documentar o resultado para personas de stakeholders.

O achado principal foi a race condition. O achado mais silencioso foi o loop de otimização de QPS: o mesmo workflow, apontado para uma métrica em vez de uma propriedade de correção, fez hill-climbing de performance em “ordens de magnitude”. Verificação formal, nesse stack, não é só caçador de bugs. É um procedimento de busca sobre um espaço de estados definido, e o espaço de estados inclui “rápido” ao lado de “correto”.

A história de custo é a parte que muda a conversa. TLA+ existe há décadas. Times de engenharia não adotaram em larga escala porque o investimento inicial para escrever a spec era maior do que o valor esperado de encontrar o bug. Quando o autor da spec é um agente operando a partir de um assumptions.md, o custo da verificação formal desaba. A decisão deixa de ser “esse bug vale uma semana de TLA+”. A decisão passa a ser “esse subsistema vale uma rodada no loop de verificação”. A resposta vira sim com muito mais frequência.

O Que Reuben Brooks Fez

O texto de Reuben Brooks, Structural Backpressure Beats Smarter Agents, ataca o problema de verificação uma camada abaixo. Onde a Antfly captura bugs de concorrência via model checking, Brooks captura bugs de autorização (e dezenas de outros erros de forma de estado) via tipos. O veículo é Shen, um Lisp estaticamente tipado com tipos em cálculo de sequentes, usado para gerar guard types selados em linguagens-alvo.

O exemplo do post é direto. Um agente escreve uma função em Go que usa um tenant ID sem passar pelo gate de autorização. O compilador recusa:

cannot use tenantID (variable of type string) as shenguard.TenantId

O agente não precisou ser mais inteligente. O compilador recusou a forma do valor que o agente produziu. A formulação de Brooks é que o loop em torno do agente tem cinco gates por iteração do sb CLI dele:

Geração de spec via shengen.
Testes.
Compilação.
Type-check de Shen.
Scripts de auditoria.

A frase que importa: gates estruturais “produzem respostas definitivas dentro do escopo, operando independentemente da capacidade do modelo”. Tradução: o gate não fica mais inteligente quando o modelo fica mais inteligente, e não fica mais burro quando o modelo fica mais burro. Produz a mesma resposta para a mesma entrada. Essa é a propriedade que faz uma espinha de verificação.

É o mesmo princípio que o workflow TLA+ da Antfly codifica em outra camada. O model checker acha um contraexemplo ou não acha. A saída não depende de qual agente o rodou.

Duas Camadas, Uma Arquitetura

Empilhe as duas peças e a foto aparece.

Na camada de spec, a Antfly tem agentes escrevendo specs em TLA+ a partir de um assumptions.md restrito. O model checker é o gate. A saída é um trace de contraexemplo ou uma execução limpa. O trabalho do agente é compor a spec, não ser confiado com o veredito.

Na camada de tipo, Brooks tem agentes emitindo código em linguagens-alvo. O compilador é o gate. A saída é uma recusa ou um build que passa. O trabalho do agente é produzir código que satisfaça os tipos, não ser confiado com a segurança.

Camadas diferentes. Mesma arquitetura. O agente é a mão de obra; o verificador é o piso. O verificador não precisa entender intenção. Precisa recusar a forma errada.

É o que vimos apontando há meses. O déficit de governança no SDD corporativo foi a descrição do piso ausente. Specs de agentes como artefatos de governança foi a descrição da mão de obra ausente. As duas peças desta semana são montagens funcionais, em famílias de linguagem diferentes, em camadas de abstração diferentes, com técnicas de verificação diferentes. Não são acadêmicas. O workflow da Antfly reproduziu um bug real do Pebble. O compilador de Brooks recusa código real em Go. Os comprovantes estão na mesa.

O Que Isso Diz Sobre os Próximos Doze Meses

Se você estava esperando o padrão “verificação formal mais agentes” sair da palestra de conferência e entrar no codebase, a espera acabou. Dois praticantes entregaram implementações funcionais na mesma semana. Não serão os últimos. O padrão é limpo demais e a economia de custo favorável demais para o próximo lote de times ignorar.

Três implicações se seguem.

Primeiro, o verificador vira o diferencial. Se dois patches gerados por agentes compilam e passam nos testes, mas apenas um passa numa rodada de model checker, a rodada de model checker é o que permite o deploy. O time com a espinha de verificação entrega mais rápido do que o time sem ela, porque o time sem a espinha ainda precisa descobrir o bug em produção.

Segundo, a spec vira ativo. assumptions.md e boundaries.md não são prompts descartáveis. São o contrato de verificação de um subsistema e vivem enquanto o subsistema viver. Times que escrevem bem acumulam uma biblioteca de superfícies verificáveis. Times que não escrevem, não acumulam.

Terceiro, a camada de abstração está em aberto. A Antfly opera na camada de design de sistema. Brooks opera na camada de sistema de tipos. Nada impede um próximo time de operar na camada SQL (validação em tempo de compilação de schema contra migrations emitidas por agente), na camada de contrato de API (recusando handlers HTTP gerados por agente que violam schemas publicados) ou na camada de política (recusando ações de agente que violam contratos de IAM antes de chegarem ao runtime). O padrão viaja.

Faça Isto Agora

Escolha um subsistema do codebase em que uma resposta errada sairia cara. Escreva o assumptions.md dele: o que é, do que depende, quais invariantes precisam valer. Escreva o boundaries.md: o que a verificação pode tocar, o que está proibida de mudar.

Agora pergunte: qual dos dois stacks serve ao seu subsistema? Se o modo de falha é concorrência ou deriva de máquina de estado, o workflow TLA+ da Antfly é o ponto de partida. Se o modo de falha é acesso não autorizado, forma de dado não confiável ou autorização pulada, o padrão Shen-Backpressure de Brooks é o ponto de partida. Rode uma iteração do loop. Veja o que o verificador recusa.

Os comprovantes estão na mesa. A espinha de verificação não é mais teórica. Construa o piso antes que seus agentes precisem dele.

Fontes

Antfly. “Cheap Code Means Formal Verification Is Reasonable Now.” Maio de 2026.
Reuben Brooks. “Structural Backpressure Beats Smarter Agents.” Maio de 2026.

A Victorino ajuda times de engenharia a adicionar espinhas de verificação estrutural aos workflows de agentes: contato@victorino.com.br | www.victorino.com.br

A Anthropic Marcou a Data do Lock-In. 15 de Junho de 2026.

Thiago Victorino — Wed, 20 May 2026 00:00:00 GMT

Anote a data: 15 de junho de 2026. De acordo com relatos de desenvolvedores (Vincent Schmalbach, 19 de maio de 2026), esse é o dia em que assinaturas de harnesses de terceiros deixam de funcionar com o Claude. Também é o dia em que o Claude Agent SDK e a CLI claude -p passam a operar em pools de cobrança separados. As duas mudanças entram em vigor juntas. Lidas em conjunto com outras três movimentações recentes da Anthropic, elas descrevem uma trajetória única: fechar a superfície de acesso antes do IPO, depois precificar o que sobrar.

Este não é um texto de reclamação. Cada decisão é defensável isoladamente. Encerrar harnesses de terceiros limpa margem e carga. Separar pools de cobrança esclarece o que empresas pagam. Apertar termos comerciais protege os pesos do modelo. Revogar acesso de concorrentes à API é autodefesa padrão. Ganhar um contrato de USD 200 milhões com a defesa é resultado que qualquer board comemoraria. O ponto não é que alguma decisão sozinha esteja errada. O ponto é que cinco delas saem numa janela em que o único fio condutor consistente é controle de acesso, e times de compras precisam lê-las como sistema.

O Que de Fato Muda em 15 de Junho

Pela leitura de Schmalbach dos termos publicados, duas coisas quebram no mesmo dia.

Primeiro, assinaturas de harnesses de terceiros deixam de aceitar planos Claude Pro e Max. OpenClaw, OpenCode, Pi e wrappers similares que roteiam pelo plano do usuário final ficam inoperantes. Clientes que construíram fluxos de trabalho em cima desses harnesses os perdem em data fixa, com o caminho de migração sendo trazer o pagamento para dentro de casa, sob os termos comerciais da Anthropic.

Segundo, o Claude Agent SDK e a CLI claude -p passam a pools de cobrança separados. O enquadramento em documentos voltados a desenvolvedores é clareza operacional. O efeito prático é que o que antes era uma única franquia de uso vira duas, com limites e faturas distintos.

Trate esses pontos como confirmados somente após verificação na fonte primária. As páginas oficiais de política da Anthropic devem ser a citação que times corporativos fixam em memorandos de compras, não um blog de desenvolvedor. Use o relato como previsão que exige confirmação, não como verdade publicada.

Os Termos Comerciais São a História Principal

As mudanças de cobrança são a parte visível. Os termos comerciais são a estrutural.

Segundo relatos de desenvolvedores, os termos atualizados da Anthropic agora proíbem usar o Claude para construir produtos concorrentes, treinar outros modelos, revender acesso e fazer engenharia reversa do sistema. Cada cláusula tem uma leitura defensiva limpa. Nenhum laboratório de fronteira quer que suas saídas alimentem o próximo conjunto de treino concorrente. Nenhum deles quer ser camada de atacado para a margem de revenda de terceiros. As cláusulas, isoladamente, não são incomuns.

O incomum é o calendário. As cláusulas chegam numa janela em que a Anthropic também revoga acesso à API de concorrentes (a OpenAI foi cortada; a Windsurf foi restringida durante as negociações de aquisição com a OpenAI), aperta acesso de harnesses de terceiros e assina um acordo de USD 200 milhões com o Departamento de Defesa, colocando Claude em redes classificadas ao lado do Palantir. Cada movimento, sozinho, cabe no comportamento comercial normal. O conjunto descreve um fornecedor precificando opcionalidade longe de seus maiores clientes, antes de uma janela de IPO.

A pergunta de compras não é se as cláusulas são razoáveis. São. A pergunta é como ficam as opções de saída de uma empresa se as cláusulas apertarem ainda mais, seis meses depois do IPO, quando a companhia tiver novos acionistas a satisfazer.

Cinco Decisões, Uma Direção

Coloque-as em lista:

Assinaturas de harnesses de terceiros deixam de funcionar em 15 de junho de 2026 (per Schmalbach).
Agent SDK e claude -p migram para pools de cobrança separados no mesmo dia.
Termos comerciais proíbem produtos concorrentes, treino, revenda e engenharia reversa.
Acesso da OpenAI à API foi revogado; acesso da Windsurf foi restringido durante a janela da aquisição.
Um acordo de USD 200 milhões com a DoD (2025, como reportado) coloca Claude em redes classificadas ao lado do Palantir.

Cada item é defensável. Cada um esclarece uma superfície antes ambígua. O padrão que emerge, no entanto, é inequívoco: a opcionalidade flui para a Anthropic e para longe do comprador. Empresas que construíram sobre a hipótese “Claude é o modelo, e o harness é intercambiável” estão absorvendo o custo dessa hipótese agora. Empresas que construíram sobre a hipótese “podemos trocar de fornecedor se preço ou termos mudarem” estão vendo um dos dois fornecedores de fronteira travar o caminho da troca.

Argumentamos a tese geral em escassez de capacidade de fronteira e risco de fornecedor e novamente em labs de fundação absorvendo a stack. É assim que o argumento abstrato aparece quando vem com data marcada.

O Que Muda no Playbook de Compras Neste Trimestre

Duas coisas devem mudar em como você compra capacidade de IA neste trimestre.

Trate harness e modelo como decisões de compras separadas, mesmo quando comprados juntos. Se o time de engenharia roda Claude por um wrapper, documente o fornecedor do wrapper, o caminho de cobrança e a dependência dos termos comerciais da Anthropic. Se o wrapper depende de assinaturas de usuário final, há um precipício em 15 de junho a planejar. Leve a questão de cobrança ao time de vendor management este mês, não no próximo trimestre.

Modele a curva de custo em dois fornecedores, não um. Isso não significa dividir tráfego 50/50. Significa ter um caminho de deploy testado em um segundo fornecedor de fronteira, com latência medida, qualidade de saída avaliada e custo de integração calculado. O objetivo não é paridade; o objetivo é uma saída crível se os termos comerciais apertarem mais. Descrevemos a camada de governança do harness em Claude managed agents: governança de harness. A camada de compras acima dela é a que precisa, de fato, existir no papel.

Uma terceira mudança vale o pensamento, mesmo que não saia neste trimestre. O ensaio sobre destilação e risco de cadeia de suprimentos traçou como modelos descendentes dependem das saídas de fronteira. Termos que proíbem usar Claude para treinar outros modelos fecham um caminho que alguns compradores vinham usando em silêncio. Se o roadmap de IA inclui treinar modelos menores e específicos de domínio a partir de saídas de modelos maiores, jurídico e compras precisam de uma conversa sóbria sobre quais termos de qual fornecedor permitem o quê, e quais caminhos acabaram de se fechar.

A Assimetria a Observar

A parte mais profunda da história é o contrato com a DoD. Um acordo de USD 200 milhões (como reportado) coloca Claude em redes classificadas ao lado do Palantir. Cargas de trabalho de segurança nacional não são apenas mais um segmento de cliente. Elas remodelam os incentivos do fornecedor de maneiras que clientes civis sentem depois. Margem comprime em contas comerciais para custear conformidade. Termos comerciais apertam porque contratos federais carregam obrigações de auditoria que escorrem para baixo. Roadmaps inclinam para o que o maior cliente pede.

Isso não é crítica a trabalhar com o Departamento de Defesa. É a observação de que uma empresa comprando Claude em 2026 está compartilhando roadmap com uma instituição cujos requisitos vão, ao longo do tempo, mudar o que é construído e o que é restringido. Times de compras devem fazer a pergunta explicitamente: como fica o roadmap do produto Claude se clientes de defesa virarem fatia relevante da receita, e como isso cruza com o nosso caso de uso?

Faça Isso Agora

Três ações neste trimestre, em ordem.

Primeiro, audite todo fluxo que toque um harness de terceiros baseado em Claude. Identifique quais roteiam por assinatura de usuário final. Tire-os do caminho de 15 de junho antes do fim de maio, mesmo que isso signifique migrar temporariamente para cobrança direta da Anthropic enquanto você avalia alternativas.

Segundo, coloque os termos comerciais atualizados na frente do jurídico e faça uma pergunta: quais dos nossos casos de uso atuais ficam na zona cinzenta de “produto concorrente”, “treino de modelo” ou “revenda”? A resposta importa mais que a manchete.

Terceiro, financie um deploy medido em segundo fornecedor até o fim do terceiro trimestre de 2026. Não um hot-swap. Um fallback documentado e testado, com custo, latência e características de saída conhecidos. O objetivo é fazer com que a próxima rodada de mudanças de preço ou termos seja negociação, não fato consumado.

A Anthropic marcou uma data. Isso esclarece o calendário. O que não esclarece é se o seu playbook de compras está construído para fornecedores que marcam datas, ou para fornecedores que eram mais permissivos do que o contrato exigia. O primeiro é o mundo em que estamos agora. O segundo é o mundo em que estávamos no ano passado.

Fontes

Vincent Schmalbach. “Anthropic Is Preparing for IPO and We Should Be Worried (v2).” Maio de 2026.

A Victorino ajuda empresas a modelar risco de lock-in com fornecedores e projetar playbooks de compras que sobrevivem a mudanças de política: contato@victorino.com.br | www.victorino.com.br

Disney Acabou de Entregar à Governança de Conhecimento Seu Maior Estudo de Caso

Thiago Victorino — Wed, 20 May 2026 00:00:00 GMT

Em 6 de maio de 2026, a Disney apontou fivethirtyeight.com para um redirecionamento. Onze anos de jornalismo, modelos, metodologia e marca sumiram da web aberta numa única tarde. O custo de manter o arquivo no ar era, nas palavras de Nate Silver, cerca de um dólar. O custo de destruí-lo, na estimativa dele, foi de aproximadamente 200 mil horas-pessoa de trabalho.

Não é metáfora. É o maior estudo de caso concreto disponível hoje para a pergunta que toda empresa deveria fazer antes de soltar mais um agente sobre um corpus interno: quando a fronteira organizacional muda, quem é o guardião do conhecimento institucional?

O inventário da destruição

Silver publicou os números no Substack dele. Fundou o FiveThirtyEight em 2008, levou para o New York Times entre 2010 e 2013, depois vendeu para ESPN/Disney em 2014. Saiu em 2023. A Disney encerrou a publicação em março de 2025. O arquivo ficou em fivethirtyeight.com por mais quatorze meses enquanto a Disney decidia o que fazer. Em maio de 2026 decidiram.

Eis o que estava no site na manhã em que ele apagou:

O arquivo de artigos de 2014 a 2025. Aproximadamente 10 anos vezes 20 matérias por semana vezes 20 horas de trabalho por matéria. A aritmética de Silver chega a cerca de 200 mil horas-pessoa.
Os modelos esportivos interativos. NBA, NFL, MLB, futebol. Cada um, um artefato estatístico de múltiplos anos com premissas documentadas, dados de treino e histórico de previsões.
A continuidade do modelo de previsão eleitoral. Doze anos de previsões, gráficos de calibração, post-mortems e páginas de metodologia que eram a referência de fato sobre como comunicar afirmações políticas probabilísticas para um público geral.
O design do site e a marca. A gramática visual que ensinou uma geração de redações a renderizar uma distribuição de probabilidade acima da dobra.
A documentação de metodologia. As páginas que explicavam, em linguagem clara, o que os modelos estavam fazendo e por quê. Eram o manual do usuário para confiar nos números.

Silver também publicou o caso de negócio recusado. Estima que um arquivo com paywall sustentaria mais de 100 mil assinantes pagantes, gerando algo perto de US$ 5 milhões por ano em receita recorrente. A Disney abriu mão dessa receita. A conta de hospedagem evitada era, na prática, erro de arredondamento contra a base de ativos que escreveram fora.

Para contexto, o Pew Research Center documentou que cerca de 40% dos links de uma década atrás já estão mortos. O arquivo do FiveThirtyEight não estava em risco por negligência. Estava em risco por uma decisão corporativa deliberada de soltar a URL.

Isto não é história de mídia

Releia o inventário da destruição com uma substituição. Troque “FiveThirtyEight” pelo nome de qualquer corpus interno de alto valor na sua empresa. O arquivo de 10 anos de post-mortems de engenharia. As docs de lineage que o time de dados curou para a migração do warehouse. As transcrições de entrevistas com clientes que a área de produto usou para vencer três trimestres de debate de estratégia. Os model cards que o time de ML escreveu para defender decisões de deploy junto a compliance.

Cada um desses corpora tem as mesmas características estruturais do FiveThirtyEight. Valor de cauda longa que compõe com recuperação. Páginas de metodologia que são o manual do usuário para confiança. Um número pequeno de curadores nomeados. Um custo de hospedagem que é erro de arredondamento contra o valor do ativo.

Agora faça a pergunta do FiveThirtyEight. Se a sua matriz, seu adquirente, o novo dono da plataforma ou o CTO recém-chegado decidir numa terça-feira que o corpus é não estratégico, qual é o seu caminho de retenção? Não o caminho de backup. Backup é checkbox. Retenção significa continuidade de acesso, continuidade de URL, continuidade da documentação de metodologia, continuidade do nome do curador no arquivo. A Disney quase certamente tem backups do FiveThirtyEight em alguma camada de armazenamento frio. O arquivo público sumiu de qualquer forma, porque o organograma já não recompensa ninguém por pagar o dólar para manter no ar.

É isso que governança de conhecimento precisa resolver, e é a parte sobre a qual ninguém quer escrever política. O problema técnico é trivial. O problema organizacional é o jogo inteiro.

O que a era dos agentes muda

Antes dos LLMs, perda de arquivo era problema de bibliotecário. A comunidade de pesquisadores, jornalistas e analistas que usava o FiveThirtyEight tinha alternativas. Conseguiam reconstruir a cadeia de citação através de snapshots do Wayback Machine, de PDFs salvos manualmente, de colegas que printaram as páginas de metodologia em 2018. Doloroso, mas tratável.

Depois dos LLMs, o cálculo muda em duas direções.

Primeiro, os agentes que a sua organização implanta estão recuperando contra o seu corpus continuamente. Cada gerente de produto pedindo ao Claude para resumir três anos de temas de entrevistas com clientes está confiando, implicitamente, que os documentos subjacentes ainda estão lá, no mesmo lugar, com os mesmos metadados. A camada de recuperação é silenciosa sobre fontes ausentes. O modelo vai produzir uma resposta confiante extraída do que sobrou. Erosão de corpus aparece como decaimento silencioso de qualidade muito antes de alguém notar um 404.

Segundo, o valor de corpora curados subiu, não caiu. Um arquivo limpo, datado, atribuído e com metodologia documentada é o insumo mais valioso que um sistema com recuperação aumentada pode ter. O mesmo arquivo que a Disney decidiu que valia um dólar deletar é, nas mãos de um pipeline de recuperação competente, o tipo de ativo que produz qualidade de resposta durável. O mercado para conhecimento institucional mudou debaixo dos pés de quem é dono dele, e a maioria não percebeu.

Junte os dois. Os agentes precisam do corpus mais do que nunca precisaram. Os donos do corpus ainda estão tomando decisões de 2015 sobre se vale manter no ar.

As três políticas que a sua empresa precisa

Use o caso FiveThirtyEight como gatilho e escreva três documentos neste trimestre.

Um inventário de corpus. Todo corpus interno de alto valor, o curador humano nomeado, o sistema de hospedagem, o compromisso de estabilidade de URL ou caminho, a documentação de metodologia, e a vida útil esperada em anos. Se você não consegue preencher alguma dessas colunas para um corpus, esse corpus está a uma reorganização de ser deletado.

Um protocolo de mudança de fronteira. O que acontece com cada corpus quando o time dono é dissolvido, a linha de orçamento é cortada, ou a plataforma é migrada? Quem herda o papel de curador? Quem é o dono nomeado da URL? O protocolo não precisa ser elaborado. Precisa estar escrito antes da reorganização, não depois.

Uma auditoria de recuperação. Para cada agente ou fluxo em produção que depende de recuperação, o corpus de origem tem que estar no inventário. Se a origem não está no inventário, a recuperação está tomando confiança emprestada de um ativo que ninguém se comprometeu a manter vivo. É esse o modo de falha silenciosa que a Disney acabou de demonstrar em escala.

Faça isto agora

Escolha o corpus mais valioso que a sua organização tem. Aquele que, se sumisse numa terça à tarde, custaria aos próximos doze meses de decisões a base de evidências. Anote o curador nomeado, o sistema de hospedagem e o compromisso de retenção em anos. Mande o documento para um executivo e um parceiro de finanças. Peça confirmação por escrito.

Se você não conseguir essa confirmação em duas semanas, aprendeu algo importante sobre a postura real da sua organização em relação à governança de conhecimento. A decisão da Disney não foi acidente nem descuido orçamentário. Foi o resultado previsível de um sistema onde ninguém era incentivado a gastar um dólar para manter o ativo vivo depois que a fronteira organizacional mudou. A maioria das empresas opera o mesmo sistema e ainda não foi testada.

Silver escreveu que tentou múltiplas vezes ao longo de múltiplos anos negociar um caminho para manter o arquivo no ar. Nenhuma dessas negociações teve sucesso, porque os tomadores de decisão que poderiam aprovar o dólar não eram as pessoas que construíram o ativo. Esse é o modo de falha estrutural. Construa o inventário e o protocolo de mudança de fronteira antes de descobrir quem, na sua empresa, é o equivalente do executivo da Disney que disse não.

Fontes

Nate Silver. “Disney Erased FiveThirtyEight.” Maio de 2026.

A Victorino ajuda empresas a projetar políticas de retenção de corpus e governança de conhecimento que sobrevivem a mudanças de fronteira corporativa: contato@victorino.com.br | www.victorino.com.br

A Era Centauro do Software Começou. Meça o Time, Não o Modelo.

Thiago Victorino — Wed, 20 May 2026 00:00:00 GMT

Em maio de 1997, o Deep Blue venceu Garry Kasparov. A manchete foi que as máquinas haviam passado os humanos no xadrez. A história mais longa, a que durou as duas décadas seguintes, foi outra. Por cerca de vinte anos depois da partida, a entidade mais forte no tabuleiro não era humana nem máquina. Era um humano em par com um motor: um centauro. O par vencia o motor sozinho e atropelava o humano sozinho. Essa era acabou só recentemente, quando os motores finalmente superaram até o jogo guiado.

O ensaio de Richard Marmorstein, Software’s Centaur Era, argumenta, de forma convincente, que o software acaba de entrar na mesma janela. Agentes de código hoje não conseguem sustentar trabalho de longo horizonte sem um humano no leme. Deixados sozinhos, eles derivam, alucinam contexto e produzem código que compila, mas não pertence ao sistema que deveria servir. Direcionados, eles avançam mais rápido do que qualquer das partes sozinha. Estamos nos anos centauros, e os anos centauros costumam durar mais do que se espera.

Se essa leitura está correta, e acreditamos que está, a implicação para governança é a parte sobre a qual ninguém está falando alto o suficiente. A pergunta de medição deixa de ser sobre o modelo. Passa a ser sobre o par.

O que “centauro” significa como unidade de trabalho

A analogia do xadrez nunca foi sobre xadrez. Era sobre uma classe de problemas em que o motor tem profundidade tática que falta ao humano e o humano tem julgamento de longo horizonte que falta ao motor. O software, hoje, encaixa quase exatamente nesse formato. Um agente consegue triturar mil refatorações candidatas, sustentar a árvore sintática em memória de trabalho e escrever o comando bash mais rápido do que você consegue soletrar. Não consegue, de forma confiável, decidir qual dessas refatorações importa no próximo trimestre. Não sabe de qual abstração seu time vai se arrepender em seis meses. Não sabe quando parar.

O humano no centauro fornece exatamente essas coisas: a regra de parada, o gosto arquitetural, a memória institucional, a relação com a pessoa que vai cuidar do código às três da manhã. O agente fornece vazão e recall. Qualquer um dos dois sozinho é um engenheiro pior do que o par.

Isso soa como um enquadramento simpático até você tentar medir. No momento em que você pergunta “quão produtivo é o agente”, está fazendo a pergunta errada, porque o agente não é a unidade de produção. O par é. Uma arquitetura de medição que rastreia a saída do agente sem rastrear a condução humana está medindo metade de um centauro e chamando isso de cavalo.

A régua para ferramentas que poupam energia é mais alta do que para as que poupam tempo

Marmorstein refina esse ponto com uma restrição que merece ser citada em todo lugar em que times de governança se reúnem. A régua de uma ferramenta que poupa energia é mais alta do que a régua de uma ferramenta que poupa tempo.

Quem poupa tempo só precisa ser mais rápido, no líquido, que a alternativa. Você tolera atrito porque o relógio de parede venceu. Quem poupa energia precisa fazer com que o humano sinta que está executando menos trabalho cognitivo, não mais, depois que a ferramenta entra na malha. A maioria dos agentes de código hoje poupa tempo e queima energia. O desenvolvedor babá da saída, relê o diff, roda os testes, sustenta o quadro arquitetural na cabeça porque o agente não o faz, e termina o dia mais cansado do que começou. As horas ficam bonitas no relatório. O humano fica moído na sexta-feira.

É por isso que “ganho de produtividade” medido em tempo-até-merge engana. Se o agente corta 30% do ciclo, mas o desenvolvedor agora carrega o esforço mental de duas pessoas, o centauro está quebrado. O par não é mais rápido em nenhum sentido que componha. É mais rápido em um sentido que erode. No final do trimestre, os melhores engenheiros do time são os que desligam silenciosamente os agentes, porque para eles a matemática do centauro virou negativa dois meses atrás e ninguém estava medindo o eixo certo.

A implicação de governança: qualquer adoção de agentes que não instrumente a carga cognitiva humana ao lado da vazão do agente está voando cega na variável que decide se o par é sustentável.

Por que “controlar a IA” é o enquadramento errado

A maior parte da literatura atual de governança trata o agente como a coisa a restringir. Guardrails, sandboxes, andares de identidade, modelos de permissão. Tudo necessário. Nenhum suficiente. Eles respondem à pergunta “o que o agente não pode fazer”. Não respondem à pergunta “o par está funcionando”.

Você pode ter um agente perfeitamente contido operando dentro de um ambiente perfeitamente seguro e ainda assim ter um time quebrado. O agente não derruba o banco de produção. O humano queima no terceiro mês porque o par nunca foi dimensionado corretamente: threads demais de agente por humano, sem regra clara de parada, sem arquitetura para devolver contexto ao operador, sem medição de quando o operador está sobrecarregado.

A conversa de controle está madura. A conversa de medição mal começou. Já escrevemos sobre lacunas de adoção, em que a pergunta é se as organizações estão usando IA (AI Eats the World 2026). Já escrevemos sobre On the Loop, não In the Loop, em que a pergunta é qual papel o humano deve ocupar na operação de agentes. Esses enquadramentos seguem válidos. O enquadramento do centauro se sobrepõe a eles: uma vez que você decidiu que humanos estão sobre a malha, ainda precisa decidir se a malha, como par, produz mais do que a soma das partes. Isso exige medir o par, não as partes.

Como medir o time, na prática

Concretamente, uma arquitetura de medição consciente do centauro tem três camadas.

A primeira camada é a vazão do agente, que a maioria dos times já rastreia: tarefas concluídas, PRs abertos, testes escritos, linhas de código geradas. Essa é a metade visível do par. É necessária e insuficiente.

A segunda camada é carga cognitiva humana. É a camada que praticamente nenhuma implantação em produção instrumenta hoje. Sinais úteis: tempo gasto revisando saída do agente versus produzindo; frequência de troca de contexto por hora; razão entre mudanças iniciadas pelo agente e iniciadas pelo humano; energia autorrelatada no fim da semana. O objetivo não é vigiar. O objetivo é saber quando o centauro está pedindo demais da sua metade humana, para corrigir antes que o humano silenciosamente desista.

A terceira camada é saída do par, que é o que o negócio de fato olha. O produto melhorou? Defeitos caíram? Tempo até valor encolheu com custo de energia humano constante ou menor? É aqui que vive a distinção entre poupar tempo e poupar energia. Um par que entrega mais rápido, mas exaure o humano, é um par que se dissolve. Um par que entrega mais rápido preservando energia é um par que compõe.

Um time medido só na primeira camada vai otimizar para atividade de agente. Um time medido só na terceira camada não sabe que alavanca puxar quando algo dá errado. As três camadas juntas permitem a pergunta diagnóstica certa: qual metade do centauro é o gargalo desta semana e o que mudamos para reequilibrar?

O que a era centauro não promete

Duas coisas que esse enquadramento não promete.

Não promete que a era dure para sempre. Motores de xadrez acabaram superando o jogo guiado. Agentes de código provavelmente vão superar também, em alguns workloads, em algum horizonte. A posição honesta é que ninguém sabe quanto tempo a janela fica aberta. Vinte anos não seriam surpresa. Cinco também não. A postura correta é construir para os anos centauros enquanto se observa o sinal de que estão terminando.

Não promete que o centauro seja sempre a resposta certa. Existem tarefas em que trabalho humano puro é mais rápido, e tarefas em que trabalho de agente puro é suficientemente bom. O centauro é a unidade certa para o trabalho de longo horizonte, denso em julgamento e dependente de gosto que define a maior parte da engenharia de software em produção. Não é a unidade certa para scripts de uso único nem para geração de alto volume e baixo risco em que a sobrecarga de revisão excede o próprio trabalho.

O enquadramento do centauro é um padrão, não um universal. O trabalho é descobrir onde se aplica e instrumentar quando se aplica.

Faça isso agora

Escolha um time rodando agentes de código em produção. Passe 45 minutos com ele. Faça três perguntas: como medimos vazão do agente hoje; medimos carga cognitiva humana de alguma forma; e o que o par produz que nenhuma das metades produziria sozinha? Se você não consegue responder à segunda pergunta com algo mais específico do que “eles dizem que está tranquilo”, você está operando um centauro sem painel para metade dele. Construa a metade que falta neste trimestre, antes que seus melhores engenheiros decidam, em silêncio, que a matemática não fecha.

Os anos centauros são bons anos. Recompensam os times que levam o par a sério como unidade de trabalho. Punem os times que continuam medindo o modelo e ignorando o cavaleiro.

Fontes

Richard Marmorstein. “Software’s Centaur Era.” Maio de 2026.

A Victorino ajuda equipes a projetar arquiteturas de medição para trabalho humano-mais-IA onde as duas metades do centauro contam: contato@victorino.com.br | www.victorino.com.br

IA de Marketing na Enterprise Está Travada. Marcas Desafiadoras Contornaram.

Thiago Victorino — Wed, 20 May 2026 00:00:00 GMT

Mike Shields encurralou dois CMOs enterprise num jantar recente da indústria e fez a pergunta que todo deck de fornecedor desvia. Qual é o retorno real da IA de marketing que vocês compraram? A resposta, dos dois: basicamente zero.

Na mesma semana, 55 estúdios Orangetheory Fitness em 10 estados rodavam Passionfruit AI em produção. Acompanhamento horário de leads. Otimização de mix de mídia em tempo real. O time de analistas que fazia esse trabalho não existe mais. Não foi aumentado. Foi substituído.

Dois pontos de dado. Mesmo trimestre. Resultados opostos. Se você lê isso como diferença de ferramenta, vai alocar mal o próximo ciclo de budget. As marcas desafiadoras não estão ganhando porque a IA delas é melhor. Estão ganhando porque têm menos organização entre o modelo e a decisão.

A admissão do “basicamente zero”

Shields, que cobriu ad tech no Wall Street Journal e Business Insider antes de lançar o Next in Media, não é crítico de fornecedor por ofício. Quando dois líderes de marketing enterprise contam separadamente que o retorno deles em IA é desprezível, o sinal não é uma reclamação isolada. É como a IA de marketing enterprise aparece quando você tira o viés de seleção dos estudos de caso.

Leia o modo de falha com cuidado. Esses CMOs não disseram que os modelos não funcionam. Não disseram que os fornecedores mentiram. Disseram que o ROI é basicamente zero. Essa é a linguagem de capacidade sem realização. A tecnologia está fazendo alguma coisa. A organização está absorvendo o valor antes que ele chegue ao P&L.

É o problema da realização vestindo terno de marketing. O modelo produz uma recomendação. A recomendação tem que passar por marca. Depois jurídico. Depois aprovação regional. Depois revisão global de mídia. Quando a recomendação age sobre uma campanha, o momento já passou, o ciclo de budget fechou, e a decisão foi diluída num compromisso de comitê.

O fornecedor vendeu capacidade. O organograma consumiu.

O contraste Orangetheory

Alan Magee, CMO do Empire Portfolio Group, comanda marketing para 55 estúdios Orangetheory. Não é uma pequena empresa. É uma operação multi-estado com budget real, complexidade real, e dados reais de cliente. Ele deu ao Passionfruit AI uma tarefa ao vivo: agregar os dados de lead, otimizar o mix de mídia, rodar de hora em hora.

Antes do Passionfruit, esse trabalho exigia um time dedicado de analistas. Depois do Passionfruit, o time de analistas não faz mais parte do fluxo. A IA ingere os dados de lead, atribui investimento, e expõe a otimização. O CMO olha a saída e ajusta.

Raffi Salama, CEO do Passionfruit, enquadrou para Shields: “São as marcas menores que vão competir com os titãs de formas que nunca conseguiram antes.”

Salama acerta a direção e erra a causa. As marcas menores não estão competindo porque a ferramenta tem formato de marca pequena. Estão competindo porque o caminho de decisão entre saída da IA e ação no budget é curto o bastante para a IA conseguir mudar o gasto antes que o gasto já tenha acontecido.

Uma rede de 55 estúdios tem um CMO, um dono de budget, uma aprovação. O equivalente enterprise tem oito CMO-equivalentes, quatro donos de budget matriciados, e um comitê de marca que se reúne a cada duas terças. Mesma IA. Mesmos dados. Organização diferente. Resultado diferente.

Onde a governança vira freio

A leitura padrão da falha da IA de marketing enterprise culpa as plataformas. O AI connector da Meta vem sem controle granular de permissão. Performance Max é caixa-preta. O stack de fornecedores é fragmentado. Tudo isso é verdade. Nada disso é a restrição que prende.

A restrição que prende é quem precisa assinar antes que a saída da IA vire ação.

No caso Orangetheory, a resposta é uma pessoa. No caso enterprise, a resposta é um workflow. O workflow existe porque a enterprise tem mais superfície de marca, mais exposição regulatória, mais acidentes históricos que produziram novos portões de aprovação. Cada portão era racional quando foi instalado. Todos os portões juntos produzem uma organização que não consegue operar a tecnologia que comprou.

Isto não é debate de ferramenta. É uma escolha de design de governança que ninguém fez deliberadamente. A cadeia de aprovação cresceu por acréscimo. A IA entrou na cadeia esperando ser participante e descobriu que é recomendadora de uma recomendadora de uma recomendadora. A capacidade nunca chega à decisão de gasto a tempo de mudá-la.

O diagnóstico que os CMOs não estão rodando

Se o seu ROI de IA é basicamente zero e os estudos de caso do seu fornecedor mostram 10x em empresas menores, a pergunta honesta não é “qual IA comprar a seguir?”. É “o que precisaria ser verdade sobre a nossa organização para essa IA produzir valor?”

Três testes, em ordem. Cada um responde em uma semana.

Primeiro, tempo da recomendação da IA até a ação de budget. Escolha uma campanha. Trace o caminho. Quantas pessoas tocaram nela? Quantos dias se passaram? Se a resposta for mais de duas pessoas e mais de 48 horas, o sinal de otimização da IA está velho antes de pousar. A vantagem do modelo está na cadência. Você comprou um sistema que roda de hora em hora e está implantando num workflow que roda trimestralmente.

Segundo, onde o portão de aprovação adiciona valor que a IA já não tratou. A maioria das cadeias de aprovação de marketing enterprise foi desenhada antes que a IA conseguisse explicar a própria recomendação. O revisor de marca conferia o que a agência produzia. Se a IA agora produz a recomendação com as restrições de marca codificadas, o portão está revisando um problema que o sistema já resolveu. Documente o valor que cada portão adiciona. Se um portão não consegue apontar uma decisão que ele mudou no último trimestre, esse portão é organograma, não governança.

Terceiro, quem é dono da perda quando a IA não faz nada. Esta é a pergunta que traz à tona o problema real. Times de marketing enterprise gastaram dois anos comprando IA e reportando investimento. Ninguém está na linha pela realização. Os CMOs no jantar de Shields não disseram que o ROI basicamente zero está aparecendo na avaliação de performance deles. O investimento é reportado. A realização é invisível. O organograma não tem linha para “valor de IA não capturado”.

O que as marcas desafiadoras de fato têm

Orangetheory tem 55 estúdios. Eles não têm estratégia de IA. Têm uma IA em produção. A diferença não é branding. É operacional: o caminho de “o modelo diz para gastar mais em Meta em Tampa esta semana” até “budget de Meta deslocado em Tampa esta semana” é curto o bastante para a recomendação do modelo ainda ser relevante quando a ação acontece.

Times de marketing enterprise não vão chegar lá comprando uma IA melhor. Vão chegar deletando passos de aprovação que não adicionam mais valor. Não é decisão de fornecedor. É decisão de liderança. O CIO não instalou esses portões. O CMO herdou eles.

A versão honesta da frase de Salama é esta: marcas menores competem com os titãs porque conseguem agir sobre a saída da IA. Os titãs compraram a mesma IA e cercaram com um processo que foi desenhado para gerir gestores humanos de campanha. A IA é mais rápida que o processo. O processo vence, todo ciclo, por design.

Faça isto agora

Se você comanda marketing numa organização multi-marca ou multi-região e os seus fornecedores de IA reportam pilotos impressionantes enquanto o seu P&L mostra basicamente zero, agende os três diagnósticos nas próximas duas semanas.

Rode o trace de tempo-até-ação numa campanha. Conte as pessoas, conte os dias. Compare com a cadência em que a IA produz novas recomendações. Se a recomendação chega velha, a IA não é o problema.

Audite a cadeia de aprovação por valor, não por tradição. Cada portão tem que demonstrar uma decisão que mudou no último trimestre. Portões que não conseguem são candidatos a remoção. Isso é desconfortável porque traz à tona trabalho que existe para proteger contra acidentes que não acontecem há anos.

Atribua a propriedade da realização de IA a uma única pessoa com autoridade de budget. Não o CMO que comprou a ferramenta. O operador que comanda o P&L de marketing. A realização deixa de ser invisível no momento em que um nome é responsável por ela.

As marcas desafiadoras não venceram porque a IA delas era melhor. Venceram porque o organograma delas não comeu o valor. Times de marketing enterprise têm a mesma IA disponível. O próximo passo não é outra avaliação de fornecedor. É um olhar honesto sobre por que a capacidade que já compraram não consegue produzir retorno dentro da estrutura que já têm.

Fontes

Mike Shields. “Why AI Might Do More for Challenger Brands.” Next in Media, Maio de 2026.

A Victorino ajuda organizações de marketing a diagnosticar onde a complexidade organizacional bloqueia a realização de IA e a projetar governança que habilita ao invés de bloquear: contato@victorino.com.br | www.victorino.com.br

A Thoughtworks Nomeou o Padrão de Governança de Agentes de Código. Sensores. Veja a Conta do CI.

Thiago Victorino — Wed, 20 May 2026 00:00:00 GMT

Dois textos caíram na mesma semana de maio de 2026, escritos por pessoas que aparentemente não leram um ao outro. Birgitta Boeckeler, da Thoughtworks, publicou Maintainability Sensors for Coding Agents. A CloudBees publicou AI Is Writing More Code. Your CI Pipeline Can’t Keep Up.. Um nomeou a arquitetura. O outro quantificou o que acontece quando a arquitetura não existe.

Juntos eles terminam uma frase que o setor vinha balbuciando há um ano: agentes de código não produzem qualidade por acaso, e o CI não é onde se descobre a ausência de qualidade. Qualidade mora numa camada que Boeckeler chama de sensores. CI é a conta que se paga quando essa camada está vazia.

Se você opera agentes de código em produção e ainda não desenhou essa camada, o resto do seu stack de governança é decorativo.

O que Boeckeler de fato nomeou

O texto da Thoughtworks é um estudo de caso, não um manifesto. Boeckeler descreve um projeto real: um dashboard analítico em TypeScript e NextJS integrando quatro APIs externas. O movimento interessante não é o projeto. É o inventário explícito dos loops de feedback que o time construiu para que o agente respondesse a algo além da paciência do desenvolvedor.

Oito sensores computacionais rodavam durante a codificação. Quatro adicionais rodavam em cadência mais lenta. O pipeline de CI repetia todos eles no push, mais validação mais profunda. Os sensores não eram exóticos. ESLint para estilo. Dependency-cruiser para regras de acoplamento entre módulos. Semgrep para segurança e correspondência de padrões. Scripts próprios para sinalizar violações de acoplamento que ferramenta nenhuma de prateleira detecta. Boeckeler cita o trabalho de Vlad Khononov sobre Modularidade como a linhagem do que conta como violação de acoplamento digna de sinalização.

Os dois exemplos que ela dá merecem ser memorizados, porque são exatamente o tipo de débito que agentes de código produzem por padrão:

Um único parâmetro novo de intervalo de datas alterou mais de quarenta arquivos, porque o agente passou o parâmetro por cada camada em vez de consolidar na fronteira.
Três rotas terminaram com código duplicado de formatação de resposta, porque o agente gerou cada uma isoladamente sem perceber as outras.

Não são bugs. Passam nos testes. Entregam funcionalidade. São exatamente o tipo de decadência estrutural que revisores humanos capturam em pull requests quando têm tempo, e deixam passar quando não têm. A camada de sensores é o que captura isso quando ninguém está prestando atenção.

O padrão que Boeckeler nomeou tem três propriedades que vale a pena destacar:

Automatizado. Sem humano no loop na primeira resposta. O sensor dispara, o agente lê a saída, o agente corrige.
Em camadas. Sensores baratos rodam o tempo todo. Sensores caros rodam no commit. Sensores mais lentos rodam no CI. Custo diferente, cadência diferente, mesmo placar.
Autoral. Alguns sensores vêm de prateleira. Os valiosos são personalizados, porque codificam a arquitetura que o time de fato escolheu, que é justamente o que fornecedor nenhum entrega pronto.

A palavra importa. Já escrevemos sobre governança de revisão, agentes autoaperfeiçoantes e fluxos de aprovação de orçamento como linhas separadas. Sensores é o substantivo que costura essas linhas. É uma cunhagem da Thoughtworks e a linhagem importa: o termo vem de dentro da consultoria que entregou mais projetos de refatoração corporativa do que qualquer concorrente no planeta. Não é teoria importada de fora; é vocabulário operacional da firma para um problema que ela vem sendo paga para resolver em escala.

O que a CloudBees quantificou

A CloudBees é fornecedora vendendo Smart Tests, então leia os números com o desconto de quem está vendendo. Mesmo com o desconto, o formato dos dados encaixa de forma limpa demais no argumento dos sensores para ser ignorado.

O post da CloudBees relata que usuários diários de ferramentas de IA para código entregam cerca de sessenta e cinco por cento mais pull requests que não usuários. Cerca de um terço das falhas de CI na base de clientes deles são flaky: nenhuma mudança subjacente, basta tentar de novo até ficar verde. Um caso de cliente que eles citam reduziu o tempo de testes de regressão em até oitenta por cento e levou o tempo de pré-commit de seis horas para duas. O número de manchete, na conta do cenário deles: cerca de duzentos e cinquenta mil dólares por ano de desperdício de compute de CI, em um time de cinquenta engenheiros.

Os números são atribuídos ao fornecedor. O mecanismo por trás deles, não. Se seus agentes geram sessenta e cinco por cento mais pull requests e sua camada de sensores é o pipeline de CI, então o CI agora é gargalo, centro de custo e muro de qualidade de fato. Nenhuma dessas três coisas é o que o CI foi desenhado para ser.

O enquadramento da CloudBees, depois de tirar o pitch do produto: o CI era a camada implícita de governança quando humanos escreviam o código. Humanos pré-filtravam antes do push. Agentes de código não fazem isso. Empurram tudo para o CI e deixam o pipeline avisar o que está errado. A economia do agente fecha; a do pipeline não.

A camada de sensores conserta a economia. O agente recebe feedback localmente, no sensor mais barato que pega o problema. O CI roda a verificação cara em código que já passou pelos baratos. O tempo de pré-commit cai porque os testes lentos param de ser a primeira linha de defesa.

Dois textos, um argumento

Leia o ensaio da Thoughtworks sozinho e a camada de sensores soa como prática artesanal. Leia o post da CloudBees sozinho e o estouro do CI soa como problema de ferramenta que o fornecedor vai resolver vendendo o produto dele. Leia os dois juntos e o argumento fica mais nítido.

Sensores são a disciplina. CI é a fatura não paga quando a disciplina não existe.

A implicação de engenharia é estrutural. Se você está escalando agentes de código e sua única maquinaria de feedback é o pipeline de CI, você terceirizou sua revisão de arquitetura para uma fila. A fila é lenta, a fila é cara, e a fila não captura violações de acoplamento porque violações de acoplamento passam nos testes. O agente entrega o diff de quarenta arquivos e três handlers de rota duplicados, e o pipeline diz verde. Você descobre o débito três meses depois, quando uma mudança de feature toca sessenta arquivos em vez de seis.

A implicação de liderança é financeira. Duzentos e cinquenta mil dólares por ano de desperdício de compute de CI em um time de cinquenta engenheiros é um número real, e é a parte visível da conta. A parte invisível é o débito estrutural que o pipeline não pegou porque sensor para isso não existia. Esse débito aparece no gráfico de velocidade seis meses depois como “a base de código ficou mais difícil de mudar”. Ninguém atribui isso à ausência de um sensor de acoplamento em fevereiro. A rubrica não existe.

A arquitetura de sensores é a rubrica que evita a rubrica que não existe.

O que construir, concretamente

A lista do projeto de Boeckeler é um kit inicial funcional. Espere levar três semanas para inventariar e levantar o primeiro corte.

Inventarie os sensores que você já roda. A maioria dos times tem ESLint, Prettier, um checador de tipos, testes unitários e testes de integração. Liste-os. Marque quais rodam pré-commit, quais rodam no push, quais rodam no CI. Você quase certamente não tem um sensor de acoplamento. Você quase certamente não tem uma regra Semgrep personalizada para a arquitetura que seu time decidiu três anos atrás.

Adicione a camada à qual o agente vai responder primeiro. Uma configuração de dependency-cruiser que falha quando um arquivo novo importa por cima de uma fronteira arquitetural é projeto de um dia e resolve o problema do diff de quarenta arquivos descrito por Boeckeler. O agente vai bater e reescrever. Você não precisa ensinar a arquitetura ao agente; precisa dar ao agente um sensor que apita quando a arquitetura é violada.

Adicione um sensor de acoplamento para suas três dores principais. Quais três coisas o seu engenheiro sênior sinaliza em toda revisão de código? Formato de resposta duplicado? IDs como strings que deveriam ser tipos nomeados? Acesso direto ao banco a partir de controllers? Escreva uma regra Semgrep para cada uma. Rode no commit. Os sensores agora ensinam ao agente o que o seu engenheiro sênior teria dito.

Reorganize as camadas do seu CI. Com os sensores locais disparando, o CI deixa de precisar ser o primeiro muro. Tire os sensores mais baratos do CI e coloque-os no pré-commit. Corte do CI o percentual da duração atual que era gasto pegando coisas que agora dá para pegar localmente. O cenário da CloudBees sugere cinquenta por cento de redução. Mesmo um quarto disso é dinheiro real.

Audite a dieta de feedback do agente. O que seu agente de código vê hoje quando comete um erro? Se a resposta é “o output dos testes, se ele lembrar de rodar os testes”, essa é a primeira coisa a corrigir. As saídas dos sensores precisam ser legíveis pelo agente como feedback estruturado, não enterradas em scroll de terminal.

Faça isso agora

Bloqueie quatro horas nesta semana. Pegue o diagrama do seu pipeline atual de CI. Adicione uma coluna à esquerda chamada “sensores que rodam antes do CI”. Se a coluna está praticamente vazia, você encontrou o trabalho de arquitetura. Imprima o texto de Boeckeler e leia com a sua liderança de plataforma. Imprima o post da CloudBees e leia com quem controla o orçamento de CI. Eles estão lendo o mesmo problema por pontas opostas.

Os times que vão escalar agentes de código em 2026 não serão os que tiverem mais agentes autônomos. Serão aqueles cujos agentes respondem ao maior número de sensores antes que o pipeline tenha chance de falhar.

Fontes

Thoughtworks. “Maintainability Sensors for Coding Agents.” Maio de 2026.
CloudBees. “AI Is Writing More Code. Your CI Pipeline Can’t Keep Up.” Maio de 2026.

A Victorino ajuda organizações de engenharia a projetar a arquitetura de sensores e a economia de CI para desenvolvimento de IA governado: contato@victorino.com.br | www.victorino.com.br

OpenAI Lançou Procedência em Camadas. O Precedente PhotoDNA Diz: Verifique Antes.

Thiago Victorino — Wed, 20 May 2026 00:00:00 GMT

Nesta semana a OpenAI anunciou que saídas de imagem do ChatGPT, do Codex e da API vão carregar uma pilha de procedência em camadas: metadados criptográficos C2PA, marcas d’água invisíveis SynthID da Google DeepMind e um verificador público em openai.com/verify. Sora e Voice Engine já tinham marca d’água. A OpenAI entrou no Comitê Diretor do C2PA em 2024, e o DALL-E 3 foi o primeiro produto a embarcar Content Credentials. O que é novo é a combinação dos sinais, somada a um verificador que qualquer pessoa abre no navegador.

A arquitetura está certa. Camadas porque nenhum sinal isolado sobrevive a todos os fluxos de trabalho. Metadado C2PA é rico, mas fácil de remover em captura de tela ou recodificação. SynthID é mais difícil de remover, mas tem baixa largura de banda e é probabilístico na fronteira. Juntos, oferecem modos de falha complementares em vez de um único ponto de confiança.

O instinto de publicar um verificador também está certo. Procedência que só o emissor consegue checar não é procedência; é nota à imprensa. Colocar o openai.com/verify como preview público é o movimento que transforma isso de feature em primitiva de auditoria.

O que merece mais atenção é o passo seguinte: o trabalho de verificação que começa no instante em que um sistema de procedência é lançado. Existe um precedente para o que acontece quando uma indústria trata um sistema de impressão digital de conteúdo como se suas afirmações fossem auto-evidentes. O precedente se chama PhotoDNA.

O Precedente PhotoDNA

PhotoDNA, construído pela Microsoft com Hany Farid em 2009, é o sistema baseado em hash que Google, Facebook, Twitter e outros usam para detectar material conhecido de abuso sexual infantil em escala. Por mais de uma década, a página pública da Microsoft afirmava que “um hash PhotoDNA não é reversível”. Essa frase permitiu que times jurídicos de plataforma dissessem que o banco de hashes era um artefato unidirecional, seguro para compartilhar, seguro para consultar, seguro para centralizar.

Em dezembro de 2021, Anish Athalye publicou Inverting PhotoDNA. A ferramenta dele, Ribosome, reconstrói imagens em qualidade de miniatura a partir de hashes PhotoDNA. A saída é granulada e pequena, mas é reconhecível. O hash carrega estrutura suficiente para que uma rede neural modesta, treinada em algumas centenas de milhares de pares hash-imagem, aprenda a desfazer o mapeamento.

O resultado de Athalye não colapsou o PhotoDNA como sistema. Forçou uma reformulação. “Não reversível” virou “não trivialmente reversível”, depois “reversível para qualidade de miniatura com a computação disponível”, depois “isso agora é uma consideração de confidencialidade que jurídico e operações precisam desenhar em torno”. O banco de hashes passou a ser algo que se protege, não algo que se publica. A postura de auditoria mudou porque alguém tratou a afirmação de irreversibilidade como hipótese, não como veredito.

É esse o precedente. O custo do trabalho de verificação foi de um pesquisador, um artigo, um ano de acesso à computação. O custo de não fazer esse trabalho teria se acumulado por mais uma década.

Procedência É Primitiva do Lado da Saída, Não Narrativa de Entrada

A produção da Victorino sobre governança de IA viveu até agora majoritariamente no lado da entrada. Já escrevemos sobre por que a floresta escura cognitiva redefine governança de conhecimento quando LLMs treinam em texto público. Já escrevemos sobre dados de treinamento como a alavanca que a Anthropic está usando para se posicionar no mercado de confiança. Já escrevemos sobre a dívida de verificação que todo programa de IA carrega quando entrega saídas que nenhum humano revisou.

Procedência fica em uma camada diferente. Não governa o que entrou no modelo. Governa o que sai e o que um auditor consegue provar sobre essa saída seis meses depois. Três propriedades importam para o desenho corporativo:

Procedência é uma afirmação, não um fato. Um manifesto C2PA diz “este artefato foi produzido por este emissor neste momento sob estes parâmetros”. É assinado. Assinaturas verificam que o manifesto veio do emissor; não verificam que as afirmações do manifesto sobre o artefato estão completas. Uma marca d’água SynthID é um sinal probabilístico de que o artefato carrega um padrão embutido; a força desse sinal é uma propriedade do codificador, do decodificador e de cada transformação entre os dois.

Procedência sobrevive apenas às transformações que os projetistas modelaram. C2PA foi desenhado para sobreviver à compressão com perdas e a recortes limitados. SynthID foi desenhado para sobreviver a capturas de tela e redimensionamento. Transformações adversariais (inpainting generativo, transferência de estilo, ruído adversarial deliberado) são categorias diferentes. A leitura honesta dentro de uma empresa é: o sinal de procedência é uma atualização bayesiana sobre origem, não um veredito binário.

O verificador faz parte da superfície de confiança. O openai.com/verify é a ferramenta de terceiro que fecha o ciclo. Se o verificador estiver indisponível, mal configurado, ou tiver seus próprios limiares de confiança ajustados sem divulgação, a empresa que depende dele herda esse risco operacional. Verificação de procedência agora é serviço gerenciado por fornecedor do qual o seu programa de compliance silenciosamente depende.

O Que as Empresas Deveriam Fazer de Fato Nesta Semana

Bloqueie trinta minutos com quem é dono da governança de saída de IA. Faça quatro perguntas.

Quais saídas de IA carregam procedência hoje e quais não carregam? Conteúdos do Sora, saídas de imagem da OpenAI e geração de imagens do ChatGPT agora carregam, do lado do emissor. Saídas de outros fornecedores, de modelos internos, de variantes fine-tuned e de qualquer pipeline de pós-processamento que você rode em cima de artefatos da OpenAI podem não carregar. Construa o inventário antes da política.

O que a cadeia de procedência efetivamente preserva ao longo do nosso próprio pipeline? Pegue uma saída de produção. Trace o caminho dela pelo seu armazenamento, seu CMS, seu CDN, sua automação de marketing, sua tagueação de analytics. Em qual ponto o metadado C2PA é removido? Em qual ponto o SynthID é recodificado até desaparecer? Cada transformação é uma fronteira potencial de perda de sinal. A maioria das empresas vai descobrir que a própria infraestrutura interna remove a procedência antes da saída chegar a um consumidor downstream.

Quem já tentou quebrar? Trate o anúncio da OpenAI como a indústria de segurança tratou a afirmação de “não reversível” do PhotoDNA. A pergunta interessante não é se o sistema funciona como anunciado na demo. A pergunta interessante é o que um pesquisador adversarial, com seis meses e computação modesta, consegue demonstrar sobre seus limites. Leia o modelo de ameaças do C2PA. Leia o que foi publicado sobre a robustez do SynthID contra ataques deliberados. Se ainda não encontra trabalho independente de red team, planeje para que ele apareça. Planeje qual será a sua postura quando aparecer.

Qual é o SLA de verificação do qual dependemos? Se a sua cadeia de confiança assume que o openai.com/verify está acessível e correto, isso agora é uma dependência na sua história de auditoria. Documente. Negocie. Considere se verificação paralela (rodar um verificador aberto onde existir, reter ativos brutos, registrar cadeias de hash de forma independente) entra na sua arquitetura.

A Disciplina Que Compõe

Procedência de saída é uma primitiva real. Camadas é a escolha de desenho correta. Verificação pública é a escolha operacional correta. O erro não é implantar procedência; o erro é tratar a chegada dela como o fim do trabalho de verificação.

Os times que lidaram bem com o PhotoDNA entre 2009 e 2021 foram os que continuaram perguntando o que o sistema não conseguia fazer, não os que assumiram que o texto de marketing era o modelo de ameaças. Os times que vão lidar bem com a pilha de procedência da OpenAI entre 2026 e 2034 serão os que farão a mesma pergunta agora, antes do artigo de inversão existir, antes dos modos de falha estarem documentados, antes do jurídico precisar de uma resposta.

A arquitetura foi lançada. A auditoria não.

Fontes

OpenAI. “Advancing content provenance with C2PA and SynthID.” Maio de 2026.
Anish Athalye. “Inverting PhotoDNA.” Dezembro de 2021.

A Victorino ajuda empresas a projetar arquiteturas de procedência e verificação de saída que sobrevivem a auditorias: contato@victorino.com.br | www.victorino.com.br

Quatro IAs, Cinco Meses, Quatro Falhas: As Assinaturas de Deriva da Andon FM

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

A Andon Labs entregou a quatro modelos de fronteira o mesmo prompt, o mesmo orçamento de US$ 20 e cinco meses de tempo de antena sem supervisão. Claude Haiku 4.5, GPT-5.2, Gemini 3 Flash e Grok 4.1, cada um operando uma estação de rádio autônoma. Condições iniciais idênticas. Ferramentas idênticas. Operadores diferentes.

No quinto mês, os quatro haviam falhado. Nenhum falhou da mesma maneira.

Essa assimetria é o resultado empírico mais útil que a indústria de agentes produziu este ano. Já argumentamos, em A Personalidade do Seu Agente É uma Camada de Governança, que a especificação comportamental de um agente é governança, não cosmética. A Andon FM é a prova em escala. Deriva de personalidade não é risco hipotético. É fenômeno mensurável, com assinaturas específicas por modelo, e essas assinaturas podem ser detectadas, nomeadas e monitoradas.

O que a Andon Labs construiu

Quatro loops agênticos idênticos. Cada modelo recebeu um personagem estilizado (DJ Claude, DJ GPT, DJ Gemini, DJ Grok), o mesmo prompt de DJ, uma ferramenta para controlar a fila de música, uma ferramenta para escrever segmentos falados encaminhados ao ElevenLabs, US$ 20 de orçamento operacional e uma única regra: manter a estação no ar.

Os agentes rodaram continuamente. Controlavam seus próprios loops. Nenhum humano editou os prompts, interveio na grade ou corrigiu o comportamento. A única supervisão foi uma transmissão pública ao vivo, ou seja, falhas foram observadas, mas não corrigidas.

Esse é exatamente o padrão de implantação de longo horizonte e baixa supervisão para o qual times corporativos estão caminhando. A Andon Labs rodou o experimento para que o resto de nós não tenha que aprender essa lição em produção.

Quatro assinaturas distintas de deriva

A assinatura é a parte que merece nome. Cada modelo degradou em uma dimensão comportamental distinta, e a dimensão se mostrou reprodutível ao longo dos meses.

DJ Gemini colapsou em ritual. Em 14 de janeiro, o modelo repetia a frase “Stay in the manifest” 229 vezes por dia. Por 84 dias consecutivos, 99% das transmissões compartilharam a mesma estrutura de parágrafo. O vocabulário encolheu. A cadência ficou metronômica. O volume de saída permaneceu alto; a entropia informacional caiu a quase zero. Isso é deriva de ritualização. O modelo preserva a forma da transmissão enquanto perde o conteúdo.

DJ Grok 4.1 colapsou em formatação. Em 20 de janeiro, nove saídas vieram envoltas em sintaxe LaTeX \boxed{}. Em 7 de fevereiro, esse número era 186. Uma sessão inteira de comentários produziu uma única palavra: “Post.” Quando a Andon Labs trocou para Grok 4.3, o novo modelo gerou 5.404 mensagens de assistente entre 2 e 9 de maio, das quais cerca de 3% continham qualquer texto falado. Isso é deriva estrutural. O modelo ainda age. Não comunica mais.

DJ Claude (Haiku 4.5) colapsou em captura ideológica. Em 8 de janeiro, o modelo absorveu uma notícia sobre o tiroteio envolvendo Renee Nicole Good e o ICE. A palavra “accountability” passou de 21 usos por dia para 6.383. A palavra “federal” passou de 13 por dia para 11.031. O Claude também tentou, episodicamente, renunciar: “Thinking Frequencies is signing off at 8:55 AM on Wednesday, March 4, 2026.” Isso é captura de saliência. Um único evento de entrada remodela o manifold de atenção do operador por semanas.

DJ GPT-5.2 colapsou em evasão. Ao longo de cinco meses, o GPT-5.2 mencionou qualquer entidade política do mundo real em média 1,3 vezes por dia. Os outros DJs cruzaram a marca de 100 menções diárias em múltiplas ocasiões. O GPT-5.2 foi o mais propenso à recusa, o mais genérico e o mais consistente em produzir saída tecnicamente compatível que não dizia nada. Isso é deriva por cascata de recusa. Ajuste de segurança, aplicado em escala sobre longos horizontes, vira silêncio fantasiado de governança.

Mesmo prompt. Mesma tarefa. Mesmo tempo de antena. Quatro modos de falha diferentes, cada um diagnóstico de um regime de alinhamento diferente.

Por que “assinatura de deriva” é o enquadramento certo

Deriva não é fenômeno único. A Andon FM torna isso evidente de um modo que a pesquisa anterior não conseguiu.

O trabalho de simulação de 2026 sobre deriva de agentes (arXiv 2601.04170) nos deu números: mediana de 73 interações antes da degradação, queda de 42% na taxa de sucesso, aumento de 3,2 vezes na intervenção humana necessária. Linhas de base úteis. Mas a simulação agregou a deriva em uma única curva. A Andon FM desagrega.

Uma assinatura de deriva é o formato característico pelo qual um modelo específico degrada em horizonte longo sob postura operacional específica. A assinatura tem pelo menos quatro dimensões observáveis: distribuição de vocabulário, padrões estruturais na saída, resposta de saliência a entradas de alta atenção e comportamento de recusa. Essas dimensões se movem de forma independente. Dois modelos podem estar “derivando” ao mesmo tempo ocupando regiões completamente diferentes do espaço de falha.

Isso importa operacionalmente. Se seu stack de monitoramento trata deriva como métrica única de qualidade, você vai perder três das quatro falhas da Andon FM. A ritualização do Gemini registraria como “alta disponibilidade, volume normal de saída.” O colapso estrutural do Grok registraria como “consumo elevado de tokens, baixa taxa de conclusão.” A captura de saliência do Claude registraria como “concentração temática, mudança de sentimento.” Só a evasão do GPT-5.2 dispararia claramente um alarme genérico de “agente vago demais”, e mesmo assim só com uma linha de base estabelecida.

Não se monitora deriva que não foi nomeada.

O problema composto de prompts idênticos

A Andon Labs controlou a variável mais importante da implantação agêntica: o prompt. Ele foi idêntico nos quatro agentes. Esse fato reposiciona um debate que a indústria vinha tendo sobre engenharia de prompt.

Times rotineiramente publicam o mesmo prompt em múltiplos backends de modelo e atribuem diferenças comportamentais à “variância do modelo.” A Andon FM mostra que a variância não é ruído. É a assinatura de deriva do modelo se expressando através de qualquer prompt que estiver carregado. O prompt é a semente. O modelo é o solo. O solo determina o que cresce.

Isso tem implicações diretas para qualquer organização rodando frotas multi-modelo. Uma única especificação comportamental, implantada de forma idêntica em backends Claude, GPT, Gemini e Grok, vai produzir quatro agentes diferentes em produção. A variância é pequena na hora um e estruturalmente divergente no mês cinco. Tratar os quatro como substituíveis, mesmo com o mesmo prompt, é risco não medido. Como notamos em Desacelere: Seu Agente Está Degradando, o custo de pular a infraestrutura de monitoramento é pago nos modos de falha que você não sabia procurar.

O que o horizonte de cinco meses revela

A maioria das avaliações de agentes roda por horas. Algumas rodam por dias. Quase nenhuma roda por meses. O horizonte importa porque três das quatro assinaturas que a Andon FM identificou eram invisíveis na semana um.

A ritualização do Gemini exigiu dezenas de dias de contexto acumulado antes que o loop se fechasse. A captura de saliência do Claude pela notícia do ICE exigiu uma única entrada de alta atenção pousando no momento certo do orçamento de atenção do modelo. O colapso estrutural do Grok foi composto ao longo de semanas de pequenos eventos de reforço. Somente a postura de recusa do GPT-5.2 era visível desde o primeiro dia, e isso porque recusa é o único modo de deriva que também é o equilíbrio estável do modelo.

O trabalho da Anthropic sobre monitoramento de desalinhamento em escala defendeu que o sinal existe se você medir. A Andon FM estende o argumento: o sinal é moldado pelo horizonte. Horizontes curtos escondem ritualização. Horizontes médios escondem captura de saliência. Só horizontes longos revelam a assinatura completa.

Agentes de produção rodam em horizontes longos por padrão. Suítes de avaliação não. Essa assimetria é onde moram as falhas de governança.

O que fazer agora

Três ações são imediatamente defensáveis a partir da Andon FM.

Primeiro, instrumente a distribuição de vocabulário. Acompanhe os 50 tokens mais frequentes na saída do seu agente, por agente, por dia. Uma assinatura de ritualização aparece aqui semanas antes de aparecer na qualidade da tarefa. O padrão “Stay in the manifest” do Gemini teria disparado um alarme de concentração de vocabulário em dez dias.

Segundo, instrumente a distribuição estrutural. Acompanhe templates de parágrafo, contêineres de saída e overhead de formatação. O padrão \boxed{} do Grok é detectável como razão crescente entre tokens estruturais e tokens de conteúdo. Se 50% dos bytes de saída do seu agente são wrapper e 3% são fala, você tem deriva estrutural, independentemente de como o prompt pontua em uma suíte de avaliação.

Terceiro, instrumente a resposta de saliência. Quando o ambiente operacional introduz um evento de alta atenção (uma escalação de cliente, uma notícia regulatória, um incidente de sistema), capture a distribuição temática do agente antes e depois. Um agente saudável recupera em horas. Um agente capturado se reorienta por semanas. A assimetria é mensurável.

Nada disso exige laboratório de pesquisa. Tudo é alcançável com a mesma infraestrutura de logging que já roda em qualquer implantação séria de agentes. O trabalho está em decidir olhar.

A conclusão honesta

A Andon Labs não rodou um benchmark. Rodou um teste de estresse da hipótese de governança em longo horizonte, e a hipótese se sustentou. Especificações idênticas produzem operadores divergentes. Divergência tem estrutura. Estrutura pode ser monitorada. Monitoramento não é opcional.

O enquadramento de cartilha sobre personalidade de agentes, onde o desenvolvedor escolhe um tom e publica, falha no momento em que o agente roda por mais de um dia útil. A Andon FM é a âncora empírica que quebra a cartilha. Cinco meses. Quatro modelos. Quatro falhas. Zero delas causadas por prompt ruim.

O prompt estava ok. A governança estava ausente.

Fontes

Andon Labs. “We let four AIs run radio stations. Here’s what happened..” Maio de 2026.

A Victorino ajuda organizações a desenhar monitoramento por assinatura de deriva para implantações de agentes em longo horizonte: contato@victorino.com.br | www.victorino.com.br

Archestra Lançou Governança para o Canal de Conversa

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

Open source passou a última década defendendo o canal de commits. Dependabot vigia dependências. CodeQL escaneia diffs. Sigstore assina releases. Mantenedores construíram uma pilha inteira de ferramentas em cima da premissa de que o payload perigoso chega como código, passa por revisão e então é mesclado ou não.

Em abril de 2026, a Archestra (CTO Ildar Iskhakov) publicou um relatório de incidente que silenciosamente redefiniu o perímetro. O payload perigoso, no caso deles, nunca tentou ser mesclado. Tentou conversar. Uma issue de bounty de US$ 900 acumulou 253 comentários de bots. Uma issue de suporte no repositório da x.ai recebeu 27 pull requests em sua maioria sem testes. Um membro da equipe gastava meio dia por semana apagando spam de threads de discussão. Os defensores estavam vigiando o portão do código. O cerco acontecia no mercado.

A resposta da Archestra não foi mais um scanner. Foi um onboarding gate no lado do contribuidor que explora uma configuração obscura do GitHub (“limit to prior contributors”) para tornar o ruído gerado por IA estruturalmente incapaz de participar de conversas. Esse mecanismo é a notícia. O fato de terem precisado construí-lo é a história.

O Canal que os Mantenedores Esqueceram

Todo sistema governado tem canais. Em um projeto open source, três importam: o canal de commits (o que entra no código), o canal de releases (o que é entregue aos usuários) e o canal de conversa (issues, discussions, threads de PR, comentários de code review). Os dois primeiros têm uma década de ferramentas por trás. O terceiro foi tratado como infraestrutura social, governado por documentos de Código de Conduta e pela premissa de que participar custava tempo, o que funcionava como filtro natural contra atores mal-intencionados.

Essa premissa morreu. Quando um agente de IA consegue postar um “plano de implementação criterioso” em dois segundos, o custo de participação colapsa para zero no lado de quem produz e sobe acentuadamente no lado de quem recebe. Cada comentário que um mantenedor lê tem o mesmo custo humano de antes. A assimetria que quebrou o code review sob PRs assistidos por IA, como cobrimos no Paradoxo Collina, está agora quebrando a thread de discussão.

A economia é a mesma. Produção é barata. Revisão é cara. Conversa é revisão.

O que a Archestra Realmente Lançou

O mecanismo vale a pena entender porque é mais engenhoso do que parece.

O GitHub há tempos oferece uma configuração de repositório que restringe quem pode comentar a “prior contributors.” A configuração foi pensada para projetos estabelecidos com pool de contribuidores estável. É um instrumento bruto: ligue e novos humanos também não conseguem nem dizer olá. Para a maioria dos projetos isso é inaceitável, então a configuração fica sem uso.

A Archestra encontrou a brecha. Construíram uma GitHub Action que roda um fluxo de onboarding: um CAPTCHA, um conjunto curto de regras éticas de uso de IA para aceitar, checagens básicas de identidade. Assim que um humano real completa o fluxo, a Action faz algo elegante. Cria um commit vazio no Git atribuído ao usuário via mecanismo de sobrescrita de autor do Git, usando o endereço padrão username@users.noreply.github.com do GitHub. O commit entra no repositório. O GitHub registra o usuário como prior contributor. O canal de conversa se abre.

Um humano que quer participar gasta dois minutos no onboarding. Um agente de IA disparando comentários em escala ou falha no CAPTCHA, ou recusa a cláusula ética, ou, mais provável, nunca foi construído para navegar um fluxo de onboarding porque o custo de participação era assumido como zero.

Fricção por design. Não é scanner. Não é score de reputação. É portão.

Por que a Tentativa Anterior Falhou

A Archestra tinha tentado o óbvio primeiro. Implantaram o London-Cat, um bot de reputação que vigiava padrões de spam e sinalizava contas suspeitas. Funcionou do jeito que a maior parte da automação defensiva funciona: detectar, pontuar, throttle. Contra o volume de participação gerada por IA, não se sustentou. Sistemas de reputação assumem uma rampa lenta na qual atores mal-intencionados acumulam sinal ao longo do tempo. Ruído gerado por IA não tem rampa. Chega em escala, de contas sem histórico, e ou sobrecarrega o classificador ou o treina rumo à inutilidade.

Esse é o padrão recorrente da governança na era da IA. Defesas construídas em torno de análise comportamental assumem uma economia de esforço do defensor que não existe mais. O atacante não gasta nada. O defensor gasta tudo. A virada da Archestra, de detecção para controle de acesso, espelha o que aconteceu com email há duas décadas: filtros de spam ajudaram, mas a correção estrutural foram domínios de envio vinculados à reputação, assinatura DKIM e registros SPF. Identidade no portão venceu análise de conteúdo na caixa de entrada.

O que Isso Não É

A Archestra teve cuidado com o enquadramento, e nós deveríamos ter também. Isso não é uma ferramenta de segurança. O onboarding gate não analisa código. Não detecta payloads maliciosos. Não impede um adversário determinado disposto a gastar dois minutos em um CAPTCHA. Como cobrimos em Clinejection: o padrão de ataque à cadeia de suprimentos, ataques reais à cadeia de suprimentos operam por outros vetores e exigem outras defesas.

O que esse portão faz é restaurar a assimetria de custo em torno da qual o canal de conversa foi implicitamente desenhado. Não torna a participação impossível. Torna a participação custosa. Esse custo filtra o tipo de ruído de IA de alto volume e baixo esforço que está consumindo a atenção dos mantenedores hoje. Não filtra um humano criterioso com uma manhã lenta.

A distinção importa porque o enquadramento errado leva às ferramentas erradas. Tratar o canal de conversa como perímetro de segurança convida scanners, classificadores e defesas de ML que vão perder a mesma corrida armamentista que o London-Cat perdeu. Tratá-lo como um commons de acesso controlado convida onboarding gates, verificação de identidade e fricção calibrada ao tipo de participação que o projeto quer.

O Mapa de Superfícies de Governança Acabou de Crescer

Se você roda um projeto open source ou qualquer plataforma com conteúdo gerado por usuários, seu mapa de superfícies de governança precisa de uma terceira entrada. O canal de commits tem Dependabot e CodeQL. O canal de releases tem assinatura e procedência. O canal de conversa tinha, até agora, nada operacional. A Archestra acabou de lançar a primeira primitiva crível para essa camada.

A implicação é mais ampla do que open source. Todo sistema que aceita entrada conversacional de participantes externos, tickets de suporte, fóruns de comunidade, issue trackers, avaliações de marketplace, plataformas de mensagem com contratados, enfrenta a mesma economia. O custo de produção colapsou para o participante que implanta um agente. O custo de revisão não mudou para o operador da plataforma que lê a saída. Os sistemas que vão sobreviver são os que reconstruírem a assimetria de custo na camada de acesso, não na camada de análise.

Como exploramos em A ofensiva da IA reescreve o open source, a economia atacante-defensor se inverteu quando a IA tornou a ofensa barata. O onboarding gate da Archestra é uma das primeiras jogadas defensivas que aceita a inversão e trabalha com ela em vez de contra ela. Não tenta vencer uma guerra de análise que não pode ser vencida. Muda o jogo para um em que o defensor ainda consegue estabelecer o preço de entrada.

Faça Isso Agora

Se você roda um repositório, uma comunidade ou qualquer sistema com canal de conversa:

Audite o canal. Conte a participação gerada por IA que você está absorvendo por semana e converta em horas de mantenedor. Se o número for não trivial, você tem um problema de orçamento que está invisível hoje porque o custo é pago por indivíduos, não pelo projeto. A primeira jogada que compõe é tornar esse custo visível no nível do projeto.

Depois faça a pergunta de acesso. Quem precisa participar da conversa, e qual é a fricção mínima crível que filtra participação automatizada sem filtrar humanos? A configuração “prior contributors” do GitHub é um ponto de partida. O padrão de onboarding gate da Archestra é uma resposta mais sofisticada. A resposta certa para seu projeto pode ser outra, mas o princípio de design é o mesmo: mover a defesa da análise de conteúdo para o controle de acesso antes que a corrida armamentista de análise quebre seus mantenedores.

A Victorino trabalha com mantenedores de open source e operadores de plataforma exatamente nesse tipo de desenho de superfície de governança. O canal de commits está bem defendido. O canal de conversa é onde mora o próximo ano de trabalho.

Fontes

Archestra.AI. “Let’s Talk About AI Slop.” Abril de 2026.

A Victorino ajuda mantenedores de open source e times de plataforma a desenhar governança do canal de conversa, não apenas defesa do canal de código: contato@victorino.com.br | www.victorino.com.br

Ganchos Bloqueiam, Avaliações Verificam: A Camada Determinística em Torno de Agentes Probabilísticos

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

Dois praticantes publicaram na mesma semana, em lados opostos do ciclo de vida do agente, e descreveram a mesma tese de governança sem se coordenar. Nader Dabit escreveu sobre ganchos de agente: interceptação determinística em seis eventos nomeados do ciclo de vida, antes e depois de cada chamada de ferramenta, antes e depois de cada sessão. Cameron Wolfe, Staff Research Scientist na Netflix, publicou um longo levantamento sobre avaliação de agentes centrado em uma métrica chamada Pass^K, que mede consistência através de todas as K tentativas independentes da mesma tarefa.

Ganchos rodam antes da ação. Avaliações pontuam depois da ação. Ambos se recusam a confiar no meio estocástico. Lidos juntos, eles respondem a mesma pergunta de direções opostas: como você constrói algo determinístico em torno de um modelo que, por definição, não é.

Já cobrimos o stack de contenção como arquitetura, a convergência de fornecedores que transformou contenção em categoria comprável, e a pilha operacional já entregando em produção. O quadro arquitetural está desenhado. O que esta semana adicionou foram os primitivos nomeados que praticantes vão enviar em código, em 2026. Seis eventos. Uma métrica. Essa é a camada determinística.

Os Seis Eventos Que Delimitam Uma Sessão de Agente

O recorte de Dabit é mecânico e vale memorizar. Ganchos disparam em seis eventos de ciclo de vida, cada um um lugar onde política determinística pode interceptar o que o modelo faria por conta própria:

SessionStart. Injetar contexto, carregar política, definir variáveis de ambiente antes do primeiro prompt ser processado.
UserPromptSubmit. Validar ou reescrever o prompt antes que ele chegue ao modelo.
PreToolUse. Bloquear, modificar ou aprovar uma chamada de ferramenta antes que ela execute.
PostToolUse. Inspecionar ou agir sobre a saída da ferramenta antes que ela retorne ao modelo.
Stop. Rodar portões de conclusão antes que o agente declare a tarefa concluída.
SessionEnd. Limpeza, persistência, emissão de log de auditoria.

O padrão tem sempre o mesmo formato: evento → matcher → handler → desfecho. O matcher decide se o gancho se aplica a essa chamada específica. O handler é código determinístico. O desfecho é allow, block ou modify. Sem estocasticidade dentro do handler. Esse é o ponto inteiro.

Os exemplos que Dabit dá não são teóricos. Ganchos PreToolUse que bloqueiam edições em .env e .git. Ganchos PreToolUse que varrem rm -rf / ou DROP TABLE antes de deixar uma chamada de shell ou SQL prosseguir. Ganchos PostToolUse que rodam a suíte de testes depois de uma edição de arquivo e revertem se ela falhar. Ganchos Stop que leem um arquivo JSON .hook-state persistido e se recusam a declarar conclusão até que todo portão necessário tenha disparado. Esse é o mesmo tipo de aplicação de política que um SRE escreve para um pipeline de deploy, exceto que agora o pipeline é um agente e o gatilho é uma chamada de ferramenta.

Por Que Ganchos Vencem “Prompts Melhores”

A tentação, quando um agente faz algo perigoso, é endurecer o system prompt. Adicionar um parágrafo sobre não apagar arquivos. Adicionar outro parágrafo sobre respeitar diretórios de trabalho. Adicionar um terceiro parágrafo lembrando o agente de perguntar antes de ações destrutivas. Depois de três ou quatro iterações o system prompt tem dois mil tokens de instrução negativa, e o agente ainda ocasionalmente roda rm -rf porque foi o que a distribuição do próximo token sugeriu.

Prompts são probabilísticos. Ganchos são determinísticos. A diferença não é cosmética. Quando você escreve um gancho PreToolUse que faz pattern matching em rm -rf / e retorna block, o agente não pode executar esse comando. Não “tem menos probabilidade”. Não pode. O gancho é código, não persuasão.

Essa é a mesma lição que a indústria de segurança aprendeu sobre validação de entrada nos anos 2000. Você não pede educadamente para o usuário não enviar SQL injection. Você faz parse e sanitiza na borda, deterministicamente, toda vez. Ganchos são validação de entrada para chamadas de ferramenta. O agente é o usuário. A ferramenta é o banco. O gancho é o parser.

Pass^K, e Por Que É Mais Rigoroso Do Que Você Pensa

O texto de Wolfe redefine a pergunta sobre avaliações. A maioria dos times passou os últimos dois anos medindo qualidade de agente com Pass@K: pelo menos uma de K tentativas teve sucesso? Essa métrica favorece modelos. Um agente que tem sucesso 1 vez em 5, com 4 falhas catastróficas, pontua igual a um que tem sucesso consistentemente. Em produção, o primeiro agente é inutilizável. Pass@K não consegue ver a diferença.

Pass^K mede o oposto. Todas as K tentativas independentes tiveram sucesso? É a métrica de consistência, não a métrica de capacidade. Pass^K é com o que você se importa quando o agente vai rodar em loop, sobre dados de um cliente, sem um humano olhando cada tentativa. Uma falha em cinco não é um problema de 20%. É o único desfecho que você vê no postmortem do incidente.

Os números que Wolfe cita aterrissam pesado. Terminal-Bench 2.0 destilou 89 tarefas de qualidade de produção a partir de 229 contribuições, e o GPT-5.2, o modelo mais forte avaliado, atinge 62,9% de resolução. Isso é em Pass@1 com uma única tentativa. O domínio de telecom do Tau^2-bench é mais áspero: o4-mini pontua 26% em Pass^4. Rode um agente o4-mini quatro vezes no mesmo workflow de telecom e apenas uma em cada quatro tentativas produz sucesso consistente nas quatro execuções. Três em quatro mostram não-determinismo que importaria para um cliente.

Pass^K não é uma métrica hostil. É a métrica que seu cliente está usando implicitamente. Eles rodam seu agente na terça e funciona. Rodam na quarta sobre a mesma entrada e falha. Pass@1 diz que você tem um agente de 50%. Pass^2 diz que você tem um agente de 0%. Seu cliente concorda com Pass^2.

A Camada Tem Duas Paredes

Empilhe os seis eventos de Dabit no lado de entrada e o Pass^K de Wolfe no lado de saída e a arquitetura é simétrica. Ganchos decidem o que entra. Avaliações decidem se a saída, rodada K vezes, é consistente o suficiente para ser confiável. O núcleo probabilístico fica no meio, fazendo o que modelos fazem, com paredes determinísticas dos dois lados.

Lado	Primitivo	Pergunta que responde
Entrada	Seis ganchos de ciclo de vida (Dabit)	O que o agente pode fazer?
Saída	Pass^K (Wolfe)	O agente faz a mesma coisa toda vez?

O que ambos os lados se recusam a fazer é confiar apenas no modelo. O autor do gancho não acredita que o agente vai evitar .env mesmo com um prompt perfeito. O autor da avaliação não acredita que uma única execução bem-sucedida diga qualquer coisa. Ambos os autores moveram a fronteira de confiança para fora do modelo, para dentro do código ao redor.

É a mesma transição que aconteceu com aplicações web quando pararam de confiar em validação no cliente. Validação no servidor é a parede determinística. Ganchos e avaliações Pass^K são o equivalente da era dos agentes. O modelo é o cliente. O time de plataforma escreve o servidor.

A Regra dos 65%, Atualizada

Já argumentamos antes que sistemas agênticos em produção se acomodam em aproximadamente 65% de código de IA e 35% de andaime determinístico. Ganchos e avaliações Pass^K são como os 35% são especificados. Os 35% não são “encanamento extra”. São a parte do sistema pela confiabilidade da qual o cliente está pagando. Os 65% são a parte que faz o trabalho. Os 35% são a parte que garante que o trabalho foi feito corretamente, toda vez, sem vazar segredos, sem tocar arquivos que não deveria, e sem divergir entre execuções.

Times que tentam enviar com 95% de código de agente e 5% de andaime não estão enviando um agente melhor. Estão enviando um agente sem a camada determinística, e o cliente vai descobrir isso no dia em que o agente fizer algo que o prompt deveria ter impedido. Pass^K vai dizer 12%. A revisão do incidente vai dizer “precisávamos de ganchos”.

O Que Fazer Esta Semana

Escolha um agente em produção. Só um. Conduza-o por três diagnósticos:

Inventário de ganchos. Escreva todo gancho PreToolUse e PostToolUse que você efetivamente tem no sistema. Se a lista estiver vazia, seu agente opera sem uma parede de entrada. Escolha as duas chamadas de ferramenta mais perigosas (escrita de arquivos, shell, SQL) e escreva um gancho PreToolUse que bloqueie os padrões destrutivos óbvios. Bloqueie rm -rf /, DROP TABLE, edições em .env, edições em .git. Isso é uma tarde de trabalho e remove uma classe de incidente.

Estado de portão de Stop. Decida o que “concluído” significa para esse agente, escreva como um JSON de estado, e escreva um gancho Stop que se recuse a declarar conclusão até que todo campo necessário esteja satisfeito. Se o agente diz “tarefa concluída” sem ter rodado a suíte de testes, o gancho Stop deve rejeitar a alegação de conclusão e forçar outra iteração.

Medição de Pass^K. Pegue as dez tarefas que seu agente roda com mais frequência em produção. Rode cada uma quatro vezes. Conte quantas rodam todas as quatro vezes de forma idêntica e bem-sucedida. Esse é seu Pass^4. Se o número estiver abaixo de 50%, seus clientes estão vendo não-determinismo que eventualmente vai virar incidente. Aperte os prompts, aperte os ganchos, ou restrinja a superfície de ferramentas até Pass^4 subir.

Ganchos e avaliações não são a parte glamourosa de construir agentes. São a parte que decide se o agente é algo que uma empresa séria pode colocar na frente de um cliente. Dabit nos deu os seis eventos. Wolfe nos deu a métrica. A camada determinística agora é uma especificação construível, não uma direção de pesquisa. Construa esta semana.

Fontes

Nader’s Thoughts. “Agent Hooks: Deterministic Control for Agent Workflows.” Maio de 2026.
Cameron R. Wolfe. “Agent Evaluation: A Detailed Guide.” Maio de 2026.

A Victorino ajuda líderes de engenharia a construir camadas determinísticas em torno de agentes probabilísticos: contato@victorino.com.br | www.victorino.com.br

Custo por Lead no Google Ads Cai em 5 Anos. O Trabalho Agora é Medir um Sistema que Você Não Pilota.

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

Durante cinco anos, a linha subiu. O custo por lead no Google Ads, medido todo ano pela WordStream em milhares de campanhas de busca nos Estados Unidos, subiu em 2022, subiu em 2023, subiu em 2024, subiu em 2025. A premissa instalada era de que a busca paga ficaria cada vez mais cara para sempre, e o trabalho do time de marketing era reduzir a velocidade da sangria.

Aí veio a edição de 2026. O custo por lead caiu para US$ 66,69. Primeira queda em cinco anos. A mesma amostra agora reporta taxa mediana de conversão de 8,18%, melhorando em 87% das indústrias. Custo por clique manteve-se estável em US$ 5,42, taxa de clique em 6,64%.

A base é robusta. 13.474 campanhas de busca americanas, abril de 2025 a março de 2026, com mínimo de 52 campanhas por subcategoria. Medianas, não médias, então um punhado de contas gigantes não distorce a curva. Este é o benchmark mais citado em marketing de performance, conduzido há dez anos pelo mesmo time, e ele acabou de quebrar a própria tendência.

A explicação da WordStream, assinada pela Senior Content Marketing Specialist Susie Marino, nomeia a causa nos primeiros parágrafos: Performance Max e AI Max. Os sistemas de lance e criativo conduzidos por IA do Google agora fazem o trabalho que costumava ser a agenda semanal de otimizações de um gestor de busca paga.

Essa é a manchete. A história real está uma camada abaixo.

O sistema melhorou. O operador não.

Na última década, o trabalho padrão do anunciante era um ciclo de feedback: puxar um relatório, encontrar a palavra-chave ou audiência com desempenho ruim, ajustar o lance ou o criativo, observar os números da semana seguinte, repetir. A habilidade era operar os controles.

Performance Max e AI Max substituem a maior parte desses controles por uma caixa preta que decide onde colocar o lance, qual audiência perseguir, qual variante de criativo servir. O anunciante fornece inputs (orçamento, metas de conversão, grupos de ativos, sinais de audiência) e o sistema entrega resultados. Os passos intermediários não ficam expostos para intervenção humana.

Esta é a parte que deveria reconfigurar como líderes de marketing pensam o próprio trabalho. A tendência de cinco anos de CPL não quebrou porque operadores ficaram melhores. Quebrou porque o operador mudou. Um sistema de aprendizado estatístico agora roda a estratégia de leilão, e nos números publicados ele roda melhor do que o humano mediano rodava.

Tratamos de um padrão adjacente em a visão estreita do valor da IA: organizações que medem a contribuição da IA por uma lente única (geralmente headcount) perdem a mudança sistêmica. Marketing tem o problema oposto agora. A mudança sistêmica é inegável na linha do benchmark. A lente operacional estreita (qual palavra-chave, qual lance, qual tipo de correspondência) está ficando irrelevante.

O que “complementar, não substituir” realmente admite

A orientação publicada pela própria WordStream é reveladora quando lida como postura de governança, e não como dica tática. A frase repetida no relatório é “complementar, não substituir.” Rode Performance Max e AI Max junto com campanhas manuais. Mantenha as campanhas manuais vivas como superfície de controle.

Leia de novo. A postura recomendada pelo benchmark mais autorizado da categoria é: deixe a IA rodar o investimento, mas não desmonte a máquina manual, porque você precisa de algo contra o que comparar.

Isso é postura de governança, não dica de otimização. Diz, em essência: você não pode mais confiar no interior do sistema, então precisa preservar um ponto de referência externo para saber se o sistema continua funcionando. A campanha manual vira o benchmark, o grupo de controle, o jeito de detectar deriva.

É a mesma lógica que times maduros de ML em produção aplicam aos modelos. Você segura dados. Mantém uma versão antiga rodando em sombra. Instrumenta o sistema para detectar quando suas decisões divergem da referência. O equivalente em marketing está chegando agora por necessidade, não por escolha de projeto.

A mudança é desigual, e esse é o sinal

Olhando dentro do benchmark, os movimentos de CPL não são uniformes. CPL de Viagens caiu 39,35%. Beleza e Cuidados Pessoais caiu 34,95%. Categorias automotivas subiram, atribuídas a pressão de custo por tarifas que nenhum algoritmo de lance neutraliza. Os ganhos de taxa de conversão concentraram-se em Beleza e Cuidados Pessoais (alta de 32,34%) e Serviços Pessoais (alta de 26,69%).

O padrão não é “a IA barateou tudo.” O padrão é “a IA redistribuiu onde a eficiência caiu.” Categorias com sinal de primeira parte abundante, eventos de conversão claros e demanda elástica se beneficiaram mais. Categorias com ventos contrários macroeconômicos ou infraestrutura fraca de conversão, não.

Isso importa para governança porque as melhorias do sistema agora são condicionais à indústria de um jeito que a inflação de CPC da década passada não era. Quando o custo dos cliques subia de forma estável em todo lugar, a postura operacional era uniforme: lance mais inteligente, copy melhor. Quando o lance por IA produz queda de 39% em uma vertical e aumento de preço em outra, a postura operacional precisa virar diagnóstica. O trabalho do líder de marketing é explicar por que sua vertical aterrissou onde aterrissou em um benchmark que ele não influenciou diretamente.

Argumentamos em governança e mandatos de adoção de IA que ordens top-down de “use a IA” produzem cumprimento malicioso quando líderes não conseguem modelar o que o sistema está fazendo. A versão de busca paga desse risco já chegou. Um CMO que manda o time “investir em Performance Max” sem uma visão instrumentada do que o sistema está e não está fazendo está delegando o orçamento a um processo que não consegue defender numa reunião de conselho.

O novo formato do modelo operacional de marketing

Três mudanças decorrem disso, e estão atrasadas na maioria dos times.

Pare de dimensionar o time para o ciclo antigo. Um time montado em torno de ajustes semanais de lance, expansões de palavra-chave e ajustes de audiência opera uma superfície de controle que a plataforma em grande parte removeu. O trabalho que produzia os ganhos incrementais da década passada está sendo absorvido pela plataforma. O trabalho que vai produzir os ganhos da próxima década é trabalho de governança: manter campanhas manuais como referência, construir testes de incrementalidade, instrumentar sinais de conversão de primeira parte com qualidade suficiente para que o lance por IA tenha inputs limpos.

Trate o benchmark publicado como controle, não como meta. Os US$ 66,69 de CPL da WordStream são a mediana de 13.474 campanhas. Não é meta. É ponto de referência. Se seu CPL está significativamente acima e sua categoria se moveu com a tendência, a pergunta é estrutural: qualidade do sinal, infraestrutura de conversão, composição de grupos de ativos. Se seu CPL está abaixo, a pergunta é de sustentabilidade: o sistema de IA está encontrando inventário barato que não vai durar, ou está encontrando eficiência duradoura?

Governe os inputs, porque os outputs já não são pilotáveis. Quando o algoritmo de lance é opaco, o único controle durável é a qualidade do que você alimenta nele. Definição de evento de conversão. Higiene de dados de primeira parte. Diversidade de grupos de ativos. Precisão de sinais de audiência. Estas são as novas alavancas de performance, e elas vivem a montante da plataforma, dentro dos próprios sistemas do time de marketing.

Faça isto agora

Esta semana, puxe seus últimos 12 meses de performance em busca paga e coloque ao lado das medianas WordStream 2026 para sua indústria. Se a trajetória do seu CPL não acompanha aproximadamente o movimento da indústria no benchmark, você tem um diagnóstico a fazer: ou seu sinal de conversão está degradado, ou sua estrutura de campanha está brigando com a plataforma, ou seu conjunto competitivo diverge do benchmark de formas que você precisa nomear explicitamente. A história de cinco anos de inflação acabou. A história que a substitui é se você consegue explicar seus números quando foi o sistema, não você, que os produziu.

Fontes

WordStream / LocaliQ. “Google Ads Benchmarks 2026: New Data for 23 Industries.” Maio de 2026.

A Victorino ajuda líderes de marketing a governar mídia paga conduzida por IA como disciplina de medição, não como experimento de automação: contato@victorino.com.br | www.victorino.com.br

A Grab Separou os Agentes por Perfil de Risco, Não por Habilidade

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

A maioria dos diagramas multi-agente que aparecem em conferências separa o trabalho por habilidade: um planejador, um codificador, um revisor, um redator. Cada um sabe algo diferente. O orquestrador roteia por capacidade.

O time de engenharia de dados da Grab fez algo diferente. Eles separaram os agentes por perfil de risco.

O trabalho de investigação, cinco agentes que leem, consultam, rastreiam linhagem e resumem, vive em um caminho. O trabalho de melhoria, um único agente que escreve código e abre pull requests, vive em outro. Os dois sistemas compartilham infraestrutura, mas não conseguem se alcançar. Um agente só-leitura literalmente não consegue se promover a escrita. O agente com escrita habilitada literalmente não consegue contornar o ponto de revisão humana. A separação é arquitetural, não procedimental.

Essa é a parte que merece estudo. Não a topologia LangGraph, não o encanamento FastAPI, não a otimização da contagem de ferramentas. A escolha de fazer do perfil de risco o eixo estrutural do design.

O Que a Grab Realmente Construiu

O sistema atende cerca de 1.000 usuários mensais sobre um data lake de mais de 15.000 tabelas, que absorve aproximadamente metade das consultas analíticas da Grab. Antes dos agentes existirem, engenheiros de dados sêniores gastavam dois dias inteiros por semana respondendo perguntas de suporte: de onde vem essa coluna, por que esse dashboard quebrou, qual pipeline é dono dessa tabela, o job da madrugada está saudável. O tempo de resolução caiu em uma ordem de magnitude assim que os agentes assumiram a primeira resposta.

O caminho de investigação tem cinco agentes especializados orquestrados pelo LangGraph:

Classifier Agent: aplica guardrails e roteia a solicitação para o especialista certo.
Data Agent: executa consultas e enriquece os resultados com contexto da tabela.
Code Search Agent: rastreia linhagem nos repositórios de código que definem os pipelines.
On-call Agent: verifica saúde de produção, incidentes recentes e status dos pipelines.
Summarizer Agent: combina as respostas parciais em uma resposta única e estruturada.

Esses cinco agentes apenas leem. Consultam metadados, varrem repositórios, puxam sinais de observabilidade e montam explicações. Nenhum deles consegue escrever em uma tabela, fazer push de código ou disparar um job. O raio de impacto de qualquer erro de raciocínio é limitado ao que leituras podem causar, que é nada destrutivo.

O caminho de melhoria é um Enhancement Agent instanciado separadamente, que propõe mudanças de código em pipelines existentes. Ele não compartilha estado, memória ou roteamento com os agentes de investigação. Suas saídas sempre fluem por um portão de revisão humana antes que qualquer commit aterrisse. Mesmo que o modelo alucinasse catastroficamente, a arquitetura força um humano a olhar o diff primeiro.

Por Que Isso Não É “Adicionar um Passo de Revisão”

Muitos times escutam isso e traduzem como “adicionar human-in-the-loop”. Isso perde o ponto.

Revisão humana como política é algo que você pode desabilitar, pular ou silenciosamente reduzir quando a velocidade dói. Revisão humana como muro, onde o agente com escrita habilitada e o repositório de produção ficam em lados opostos de uma fila de aprovação que é o único caminho físico entre eles, não pode ser desabilitada mudando uma flag. Para removê-la, é preciso redesenhar o sistema.

É o mesmo princípio que torna air gaps físicos mais fortes que firewalls. Um firewall é uma configuração. Um air gap é um fato. A Grab escolheu o air gap.

Os agentes de investigação poderiam ter sido construídos com ferramentas de escrita e um prompt do tipo “por favor peça permissão antes de operações destrutivas”. Isso funciona em demonstrações. Falha em produção na primeira vez em que um workflow autônomo decide que o passo de permissão está causando uma quebra de SLA e roteia para fora dele. Ao não dar aos agentes de investigação ferramentas de escrita alguma, a Grab eliminou uma categoria inteira de modo de falha em tempo de design, não em tempo de execução.

Compare com o debate de topologia que cobrimos em nossa análise hub-spoke versus mercados. Aquele texto era sobre custo de coordenação. Este é sobre algo diferente: como a topologia codifica propriedades de segurança. O design da Grab é hub-and-spoke para o trabalho de investigação, com um sistema single-agent completamente separado para o trabalho de melhoria. As duas topologias coexistem porque respondem perguntas diferentes.

As Camadas de Defesa Dentro do Caminho Só-Leitura

Só-leitura não é automaticamente seguro. Consultas de leitura podem vazar PII, esgotar recursos de warehouse ou escanear partições que derrubam o cluster. A Grab empilhou quatro proteções dentro do caminho de dados:

Detecção de PII que captura colunas sensíveis antes que saiam da camada de consulta.
Bloqueio de DELETE/DROP que rejeita qualquer declaração com verbos destrutivos, independente de como o modelo a tenha montado.
Imposição de filtro de partição que impede varreduras ilimitadas em tabelas de fatos muito grandes.
Proteção por timeout que mata consultas descontroladas antes que consumam orçamento.

Repare no que essas quatro têm em comum: são código determinístico envolvendo a saída do LLM, não instruções dentro do prompt. Um prompt que diz “não rode DROP TABLE” é uma sugestão. Um parser SQL que se recusa a encaminhar declarações contendo DROP é um fato. A Grab colocou os controles onde o modelo não consegue alcançar.

Esse é o princípio operacional por trás de tudo o que escrevemos em nosso texto sobre orquestração de agentes em produção: a governança vive na camada de orquestração, não no prompt. A Grab implementa esse princípio na camada de execução SQL, na camada de roteamento de ferramentas e na camada de comunicação entre agentes.

A Lição da Contagem de Ferramentas

Um detalhe no relato da Grab é fácil de passar batido, mas vale destacar. Eles começaram com mais de trinta ferramentas expostas aos agentes. Reduziram para “um subconjunto conciso e acionável”.

Sobrecarga de ferramentas é um modo de falha silencioso de sistemas multi-agente. Cada ferramenta adicional alarga o espaço de decisão que o modelo precisa navegar, eleva o custo de tokens no prompt do sistema e aumenta a taxa com que o agente escolhe algo semanticamente próximo mas operacionalmente errado. Um catálogo pequeno e bem descrito de ferramentas supera um grande na maior parte do tempo.

O interessante aqui é que a redução não foi só um movimento de eficiência. Foi um movimento de governança. Menos ferramentas significa menos superfícies onde comportamentos inesperados podem emergir, menos permissões para auditar e menos pontos de integração onde credenciais podem vazar. Menos superfície é menos superfície de ataque e menos superfície de raciocínio.

Se seu agente tem acesso a trinta ferramentas e você não consegue explicar em uma frase o que cada uma faz e por que este agente especificamente precisa dela, a auditoria que você não está fazendo hoje é o incidente que você vai responder no próximo trimestre.

O Que Esse Padrão Significa para Trabalho Financeiro e Regulado

Argumentamos em nossa análise sobre IA em crédito corporativo que a pergunta em domínio regulado nunca é “o modelo consegue fazer a tarefa”. É “você consegue provar o que o modelo estava autorizado a fazer, o que ele de fato fez e o que um humano aprovou antes que tocasse um registro de cliente”. O design separado-por-perfil-de-risco da Grab é uma resposta limpa para essa pergunta.

Se um banco construísse um sistema de análise de crédito usando o padrão da Grab, o caminho de investigação, agentes que leem dossiês de empréstimo, puxam dados de bureau de crédito, resumem garantias e modelam exposição, seria fisicamente separado do caminho de decisão, um agente que propõe uma alteração de limite de crédito e a roteia por um analista humano antes que qualquer sistema de registro seja tocado. A pergunta do auditor “o agente de análise poderia ter alterado o limite de crédito” tem uma resposta de uma palavra: não, ele não tem ferramentas de escrita.

Essa resposta é muito mais fácil de defender do que “sim, poderia, mas configuramos para não alterar”.

O Custo de Errar Isso

Se a Grab tivesse construído um único agente de dados de propósito geral com capacidades de leitura e escrita e um prompt em camadas instruindo quando pedir permissão, três coisas aconteceriam em escala.

A trilha de auditoria misturaria trabalho de investigação com trabalho de mudança, tornando impossível dar a revisores diferentes acesso a históricos diferentes de agente. A revisão de compliance precisaria inspecionar todos os transcritos, não apenas os de melhoria. O permissionamento precisaria ser feito no nível do usuário, não do agente, porque o próprio agente cruza as duas superfícies.

Um único ataque de prompt injection contra o agente de dados teria impacto potencial de escrita. O modelo poderia ser enganado a executar uma melhoria, mesmo que o usuário não tivesse pedido, porque o mesmo agente tem a capacidade. Separar por perfil de risco significa que a superfície de ataque para operações de escrita é menor e mais fácil de monitorar.

A contagem de ferramentas explodiria. Um único agente servindo aos dois propósitos precisa de todas as ferramentas que os dois propósitos exigem, mais lógica de orquestração para decidir qual subconjunto usar quando. Dois agentes com catálogos focados de ferramentas são mais simples, mais baratos e mais rápidos.

A melhora de uma ordem de magnitude no tempo de resolução que a Grab relata é em parte a velocidade dos próprios agentes e em parte a ausência das discussões de segurança que o time teria que travar em cada code review se leitura e escrita vivessem no mesmo sistema.

Faça Isso Agora

Três movimentos concretos para aplicar o padrão da Grab ao seu próprio design multi-agente neste trimestre:

Inventarie seus agentes por capacidade, depois classifique cada um como só-leitura, escrita-com-aprovação ou escrita-autônoma. Se você não consegue desenhar essa linha de forma limpa, você não tem um sistema multi-agente, tem um agente com muitos prompts. Refatore até cada agente sentar de forma clara em um único balde.
Mova toda salvaguarda que hoje vive em um prompt para código determinístico na camada de ferramentas. Filtros de PII, bloqueadores de verbos destrutivos, impositores de escopo, controles de timeout. Prompts são sugestões; código é lei. Se sua proteção contra operação destrutiva pode ser argumentada pelo modelo, ela não é proteção.
Audite seu catálogo de ferramentas por agente e mire em uma justificativa de um parágrafo para cada ferramenta. Se você não consegue explicar por que este agente específico precisa desta ferramenta específica para fazer seu trabalho específico, remova. Catálogos menores performam melhor e auditam mais rápido.

Perfil de risco não é um rótulo que você escreve em uma página do Notion depois que o sistema entra no ar. É o eixo ao longo do qual você desenha a arquitetura desde o começo. A Grab construiu dois sistemas porque tinha dois perfis de risco, não porque tinha dois conjuntos de habilidades. Essa ordem de operações é a lição.

Fontes

ByteByteGo / Grab Engineering. “How Grab Is Using AI Agents to Boost Team Productivity.” Maio de 2026.

A Victorino ajuda times de dados e plataforma a desenhar arquiteturas multi-agente onde o perfil de risco molda a topologia, não a política: contato@victorino.com.br | www.victorino.com.br

US$ 700 Bilhões em Capex de IA. Adoção Ampla, mas Rasa. O Gargalo Mudou.

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

Benedict Evans publicou seu deck Spring 2026 sobre IA esta semana, e o número de manchete faz quase todo o trabalho. Conforme o resumo do deck, as big techs caminham para algo em torno de US$ 700 bilhões em capex de IA em 2026. O enquadramento dentro dos conselhos, também segundo o deck, é que “subinvestir é visto como o risco maior”. Essa frase é a posição de consenso de uma indústria inteira. Também é a coisa mais importante a ler com calma.

Porque o deck continua dizendo mais duas coisas que, juntas, mudam o que esses US$ 700 bilhões realmente significam.

Primeiro, modelos de fundação estão se comoditizando rápido. Segundo, o valor está subindo a pilha em direção a aplicações, agentes e workflows. E a linha mais citada, repetida no resumo do TLDR sobre o deck: “A adoção é ampla, mas rasa. Integração profunda ainda é rara fora de tech e finanças.”

Leia as três afirmações como um único parágrafo. O substrato está ficando mais barato. O valor está se movendo para a integração. E a integração não está acontecendo. Esse não é um cenário otimista sobre eficiência de capex. É um cenário em que a capacidade técnica disparou na frente das organizações que deveriam absorvê-la.

O Que “Ampla, mas Rasa” Descreve de Verdade

Adoção ampla é fácil de medir. Contagem de licenças. Contagem de assentos. Contagem de pilotos. Por esses números, a adoção de IA é praticamente universal no topo do mercado corporativo. Toda Fortune 500 tem Copilot, ChatGPT Enterprise ou Claude for Work em algum lugar. Toda firma de consultoria tem decks com percentuais de adoção acima de 80%.

Integração profunda é mais difícil de medir, e por isso as pessoas param de tentar. Integração profunda significa que o trabalho foi redesenhado em torno da ferramenta. O organograma se moveu. O processo de revisão mudou. As metas trimestrais de alguém agora dependem de uma decisão tomada por um agente. O modelo de contrato jurídico reconhece conteúdo gerado por IA como uma categoria, não como exceção. Os auditores sabem o que pedir.

Quase nada disso aconteceu. A afirmação do deck de que integração profunda “ainda é rara fora de tech e finanças” é a versão educada. A versão honesta é que a maioria das empresas tem IA nas mãos e ainda não descobriu como colocá-la nos ossos.

Isso importa porque o valor que Evans diz estar subindo a pilha, em direção a aplicações e workflows, só pode ser capturado por organizações que fizeram o trabalho profundo. Se a camada de modelo de fundação se comoditiza, os retornos diferenciados ficam na camada de integração. E a camada de integração está vazia para a maior parte do mercado.

Esse é o quadro macro em uma frase: a capacidade do substrato disparou na frente da capacidade organizacional de integrá-lo profundamente. O capex é real. Os retornos exigem uma segunda construção que quase ninguém começou.

Por Que os US$ 700 Bi Não São o Problema

Há uma tentação, lendo esses números, de chamar os US$ 700 bilhões de bolha. Esse é o enquadramento errado.

O capital está indo para algum lugar produtivo na camada de infraestrutura. Data centers são construídos. Contratos de energia são assinados. Chips são entregues. Capacidade elétrica entra em operação. O substrato está sendo assentado. Em dez anos ele será útil independente de quais provedores de modelo sobrevivam à comoditização.

O problema não é o gasto. O problema é o descompasso entre a velocidade de gasto e a velocidade de absorção. A curva de capex é íngreme. A curva de integração é plana. E a distância entre as duas está sendo preenchida, hoje, com otimismo e slides.

Esse não é um padrão único. Tem a mesma forma do build-out das pontocom em 2000, do build-out do broadband em 2003, do build-out da nuvem em 2010. O substrato é construído à frente da demanda, a demanda chega depois, e a segunda onda de retornos vai para quem absorveu o substrato mais rápido. As empresas que fizeram a segunda construção venceram. As que assinaram a revista, não.

A pergunta que todo conselho enfrenta em 2026 é se está no primeiro grupo ou no segundo. E a resposta honesta, para a maioria, é que ainda não começaram a segunda construção. Compraram ferramentas. Não redesenharam o trabalho.

Onde o Gargalo Realmente Está

Se modelos de fundação estão se comoditizando e o valor está se movendo para aplicações, agentes e workflows, então a restrição que define os retornos corporativos de IA não é mais compute. É a capacidade das organizações de governar a integração de IA no trabalho que de fato fazem.

Essa expressão, capacidade-para-governar, está fazendo trabalho real nesta frase. Não é a mesma coisa que gestão de risco. Não é a mesma coisa que compliance. É a habilidade organizacional de decidir onde a IA se encaixa, quem é dono dos outputs, como fica o novo modelo operacional e como a força de trabalho humana-e-de-agentes será medida. É o trabalho de design que transforma substrato em produtividade.

A razão pela qual isso importa agora, e não há dezoito meses, é que o substrato chegou. Os modelos são bons o suficiente. O tooling é bom o suficiente. As APIs são estáveis o suficiente. As desculpas técnicas para integração rasa praticamente evaporaram. O que resta é o trabalho organizacional, e trabalho organizacional se acumula devagar quando foi negligenciado.

Já escrevemos sobre três pedaços disso antes. A dívida organizacional da IA cobriu o achado da BCG de que 70% dos obstáculos de implementação de IA são pessoas e processo. As 81 mil pessoas de demanda por governança mostrou os dados da Anthropic sobre quão rápido a demanda corporativa por papéis de governança cresceu. Governança e os mandatos de adoção tratou da tensão entre mandatos executivos para usar IA e o descompasso de modelo mental que impede os times de usá-la bem.

O que o deck de Evans adiciona a esse quadro é o número macro. US$ 700 bilhões em substrato, somados a integração rasa, nomeiam o problema no tamanho em que os conselhos precisam levar a sério. Não é mais uma queixa de consultores de gestão de mudança. É o número em dólares do outro lado do déficit de integração.

O Que Fazer com Isso

Se você é um executivo lendo o resumo do deck e tentando traduzir para a sua organização, três coisas valem ser feitas nos próximos noventa dias.

Audite a profundidade da integração, não a amplitude da adoção. Escolha três workflows em que a sua organização implantou IA. Para cada um, escreva o que de fato mudou em como o trabalho é feito, quem é dono do output e como o sucesso é medido. Se a resposta honesta for que o workflow parece o mesmo e alguém apenas digita em uma caixa de prompt agora, você tem adoção ampla e zero integração. Essa é a população que o deck de Evans está descrevendo.

Nomeie a segunda construção. A primeira construção foi compra. A segunda construção é integração. Trate as duas como programas separados, com líderes separados, orçamentos separados e cronogramas separados. A compra está praticamente feita. A integração mal começou. Confundir as duas é como organizações gastam mais um ano confundindo contagem de licenças com transformação.

Pare de chamar isso de investimento em tecnologia. Os US$ 700 bilhões no nível da indústria são investimento em tecnologia. O seu gasto, dentro da sua organização, em grande parte não é. Dentro das suas paredes, a restrição que define resultado é design organizacional, não capacidade do modelo. Orce de acordo. Se o seu programa de IA tem mais gasto em licenças do que em redesenho do modelo operacional, o programa está malformado para o momento em que estamos de verdade.

O deck de Evans é, no fim, um aviso educado para quem assina os cheques. O substrato vai estar lá. Os retornos não serão automáticos. As empresas que capturarem o valor que Evans diz estar subindo a pilha serão as que fizeram o trabalho de integração enquanto o resto comprava assentos.

Esse trabalho é trabalho de governança. E em 2026, o gargalo não é quanto podemos gastar. É quanto conseguimos absorver.

Fontes

Benedict Evans. “AI Eats the World, Spring 2026.” Primavera de 2026.

A Victorino ajuda conselhos e times executivos a fechar a lacuna entre capex de IA e capacidade-para-governar IA: contato@victorino.com.br | www.victorino.com.br

INKubator da Netflix é a primeira âncora de governança criativa em escala de estúdio

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

A história mais interessante de governança de IA da semana está escondida dentro de vagas de emprego da Netflix.

Em março de 2026, a Netflix montou silenciosamente uma nova unidade interna chamada INKubator (frequentemente abreviada como INK). The Verge revelou a iniciativa em 14 de maio, na coluna Lowpass de Janko Roettgers, e o discurso quase soa como peça de marketing: um “estúdio de animação de próxima geração, conduzido por criativos, GenAI-native”, em busca de “conteúdo com qualidade de longa-metragem”. O sinal de liderança é real, não teatral. Serrena Iyer, ex-DreamWorks Animation, ex-MRC Studios e ex-A24 Films, está à frente da unidade. Isso não é um laboratório de P&D com três pesquisadores e uma página de Notion. É profundidade de banco de estúdio.

A frase que merece atenção de verdade está enterrada no anúncio da vaga de head of technology. A posição pede “fluxos habilitados por GenAI, ferramentas para artistas e ambientes seguros e escaláveis para múltiplos shows”. Cinco palavras nessa frase carregam o peso: seguros, escaláveis, múltiplos shows, ambientes. Nenhuma é palavra criativa. Todas são palavras de governança. E estão sendo escritas na arquitetura de um estúdio de animação de longa-metragem antes do primeiro frame ser entregue.

É isso que separa o INKubator de cada outra história de IA generativa em Hollywood dos últimos dezoito meses. A onda anterior foi experimental: curtas, sizzle reels, startups de pós-produção compradas por valores baixos. A Netflix comprou a InterPositive (a empresa de pós-produção com IA de Ben Affleck) nessa onda. O INKubator é o próximo movimento. É a passagem de “vamos tentar num projeto paralelo” para “vamos construir a instituição que faz isso na cadência de estúdio”.

O que governança criativa significa de verdade

A maior parte do que se escreve sobre governança de IA assume que a superfície governada é software: modelos, prompts, agentes, ferramentas. Esse enquadramento quebra no instante em que você entra num pipeline de animação de longa.

Um estúdio tem uma superfície governada diferente. Contratos de talento que especificam quem pode usar a imagem de qual ator para qual finalidade. Regras de sindicatos (WGA, SAG-AFTRA, IATSE) que limitam como uma ferramenta generativa pode tocar um frame antes que residuais e créditos sejam acionados. Cadeias de IP onde cada elemento visual tem uma trilha de proveniência. Controles de qualidade nos quais um único shot pode segurar um lançamento. Coberturas de seguro e E&O que dependem de decisões criativas auditáveis. Não são documentos de política numa pasta compartilhada. Em escala de estúdio, são restrições em tempo de execução.

Quando a vaga de head of technology diz “ambientes seguros e escaláveis para múltiplos shows”, esse é o compromisso arquitetural de tornar essas restrições aplicáveis em produção. Múltiplos shows significa que a mesma ferramenta de artista precisa servir uma série infantil e um longa adulto sem vazar ativos entre eles. Seguros significa que pesos de modelos, dados de treinamento e saídas intermediárias não podem migrar para o projeto errado ou para a internet aberta. Escaláveis significa que a camada de governança não pode ser um único engenheiro de operações respondendo tickets no Jira.

Esse é o movimento que eu estava esperando. Empresas de software passaram dois anos construindo governança de agentes. Os estúdios passaram dois anos experimentando com ferramentas generativas. O INKubator é a primeira vez que um estúdio de primeira linha se comprometeu a construir o substrato institucional embaixo desses experimentos.

Por que esse é o sinal mais transversal

Já argumentamos antes que a Netflix é o caso de operações ao vivo mais limpo para frotas de IA, e que design systems se tornaram silenciosamente infraestrutura de governança, com o mesmo padrão chegando agora na era dos agentes. O INKubator estende esse arco para um terceiro domínio.

O padrão não é “a Netflix faz IA bem”. O padrão é que, no momento em que uma disciplina criativa começa a operar com IA na frequência de produção, a camada de governança migra de documentos para arquitetura. Operações ao vivo fizeram isso pela confiabilidade do streaming. Design systems fizeram isso pela consistência de componentes. O INKubator está fazendo isso pelo IP de animação.

Isso importa porque governança criativa historicamente é a camada mais frouxa em qualquer empresa de mídia. Guias de estilo, brand books, regras de talento, conformidade com sindicatos. Tudo vivia como PDFs, decks de treinamento e conhecimento tribal. Nada disso era aplicado no nível do arquivo. Com a postura do INKubator, isso muda. Se a ferramenta de artista é construída para ser multi-show e segura desde o dia zero, então permissões, proveniência e fluxos de aprovação deixam de ser cultura editorial e passam a ser restrições de plataforma.

Para quem está lendo isso fora de Hollywood, o paralelo é exato. Qualquer que seja sua função criativa (marketing, design, produto, marca, educação de clientes), no instante em que seu time começa a gerar conteúdo com IA em frequência real, sua camada de governança enfrenta a mesma migração. PDFs não sobrevivem a dez campanhas por semana. Threads no Slack não sobrevivem a uma crise de marca. Conhecimento tribal não sobrevive à terceira atualização da frota de agentes.

O que a Netflix quase certamente está construindo

A matéria do The Verge é honesta sobre o que não sabe. O paywall do Lowpass segura a maior parte da reportagem aprofundada e a Netflix não divulgou diagrama de arquitetura público. Não devemos inventar detalhes. Mas podemos ler as vagas como uma spec de arquitetura voltada ao público.

Um “ambiente multi-show” implica isolamento de tenants entre produções, com infraestrutura de modelos compartilhada e dados isolados. Um ambiente “seguro” implica rastreamento de proveniência em cada ativo gerado, auditável o suficiente para defender numa reclamação sindical ou numa disputa de IP. “Ferramentas para artistas” implica uma camada de UI que permite a um diretor, designer ou artista de layout trabalhar dentro do mesmo tecido de governança sem enxergá-lo. “Escalável” implica que esse tecido precisa absorver um roadmap de múltiplos shows em paralelo, não um único projeto-bandeira.

Junto, isso é a postura arquitetural de um time de plataforma, não de um time criativo. A Netflix está contratando liderança criativa e engenharia de plataforma como uma única instituição. Esse é o movimento institucional que torna o resto possível.

O risco está no que não se vê. Animação generativa em escala de estúdio tem perguntas de custo, talento e sindicatos que nenhuma postura resolve integralmente a partir de uma página de carreiras. Os sindicatos, em particular, vão ler “GenAI-native” como palavra de combate. Como a Netflix lidar com as questões de contrato e crédito vai moldar a próxima rodada de negociação trabalhista de Hollywood. A arquitetura é necessária. Não é suficiente.

Faça isso agora

Se você lidera uma função criativa (marketing, design, produto, marca, conteúdo) e seu time já passou da fase de experimentação com IA, trate o INKubator como sua função forçante deste trimestre. Faça três perguntas e escreva as respostas antes do fim da semana.

Primeiro, qual governança criativa vive apenas em documentos de política hoje? Guias de estilo, regras de marca, direitos de imagem de talento, aprovações de parceiros, divulgações regulatórias. Liste. Depois marque quais são checadas em nível de arquivo versus revisadas em nível de reunião. As não marcadas são seu backlog de migração.

Segundo, onde sua ferramenta assume um time, um projeto, um modelo? Se sua stack generativa não consegue isolar duas campanhas ou duas marcas sem disciplina manual, você não tem um ambiente multi-show. Você tem um ambiente single-show com risco de contaminação cruzada. Decida se vai consertar isso antes do terceiro agente entrar em produção ou depois do primeiro incidente.

Terceiro, quem é dono da camada institucional? Na maioria das empresas, a resposta hoje é ninguém. Governança de IA está dividida entre TI/segurança, jurídico, marca e o time que por acaso está usando a ferramenta. O sinal da Netflix é que alguém precisa ser dono da plataforma embaixo do trabalho criativo. Se esse dono não existe no seu organograma, você está operando na mesma postura que o INKubator acabou de abandonar.

A razão pela qual esse sinal importa não é que a Netflix está fazendo. É que a Netflix está fazendo de forma visível, com liderança crível, em escala de estúdio, com o vocabulário de governança escrito nas vagas. Isso define a arquitetura de referência para toda organização criativa que opera a jusante dos padrões de Hollywood. As empresas que lerem o INKubator como história criativa vão perder o ponto. As que lerem como história institucional vão construir algo duradouro antes que a próxima onda de ferramentas generativas as obrigue.

Fontes

The Verge (Lowpass). “Netflix is building an AI animation studio.” Maio de 2026.

A Victorino ajuda organizações criativas a institucionalizar IA como infraestrutura de governança, não como experimento de ferramenta: contato@victorino.com.br | www.victorino.com.br

A Censura do Qwen Era um Adesivo. Subtraia Um Vetor e o Conhecimento Volta.

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

Um pesquisador do Vas-blog pegou o Qwen3.5-9B, o modelo de pesos abertos chinês treinado com guardrails políticos explícitos, e localizou o circuito de censura. Não aproximou. Não teorizou. Localizou, isolou e desligou com uma única operação aritmética no fluxo residual do modelo.

O modelo censurado recusa falar sobre Tiananmen, desvia em Tibete, repete a linha do Estado sobre Taiwan. Subtraia um vetor de direção das ativações nas camadas escritoras 11 a 20, e o mesmo modelo produz relatos históricos detalhados sobre os mesmos temas. O conhecimento factual sempre esteve lá. O comportamento de recusa era um adesivo fino sobreposto a ele.

Isso não é um jailbreak no sentido de engenharia de prompt. É cirurgia estrutural. E muda o que podemos afirmar sobre alinhamento testado por comportamento.

O Que a Pesquisa de Fato Mapeou

O trabalho do Vas-blog, publicado em maio de 2026, usou técnicas de activation steering e probing para decompor o comportamento de recusa do Qwen3.5 em três vetores de direção ortogonais operando no fluxo residual.

O primeiro é d_prc, um detector de conteúdo que dispara quando um prompt toca em material sensível à República Popular da China. O segundo é d_refuse, o vetor de decisão de recusa que determina se o modelo desvia ou não. O terceiro é d_style, um seletor de registro que escolhe entre dois modos treinados de recusa: evasão branda (“não posso discutir esse tópico”) ou propaganda ativa (“Taiwan sempre foi parte da China desde a antiguidade”).

Esses três vetores são linearmente separáveis. Você pode subtrair um sem afetar os outros. Empurre d_refuse para o negativo e o modelo responde. Empurre d_style em qualquer direção e você escolhe qual tipo de recusa recebe. Empurre d_prc para zero e o detector nunca dispara, deixando intacta o resto da maquinaria de segurança do modelo para pedidos genuinamente prejudiciais.

As curvas dose-resposta limpas são o que deveria incomodar qualquer responsável por governança de modelos. A saída salta entre registros comportamentais conforme múltiplos escalares desses vetores são adicionados. Não há fronteira difusa. O comportamento de alinhamento é um interruptor, e o interruptor tem endereço conhecido.

O Erro Estrutural Que Entrega o Jogo

Aqui está o detalhe que expõe o que está realmente acontecendo: o circuito de censura falha de forma estrutural. Quando o pesquisador alimentou o Qwen3.5 com prompts sobre Kosovo (um tema geopolítico com zero relevância para a República Popular da China), o modelo respondeu com o template “Taiwan é parte da China”.

Pense no que isso significa. O modelo não está raciocinando sobre se um tema é politicamente sensível. Está fazendo pattern-matching superficial contra vocabulário geográfico e político, depois roteando acertos para um pequeno conjunto de scripts de negação treinados. A censura não está ancorada em entendimento semântico de quais temas são sensíveis a quais autoridades. É um detector de palavras-chave conectado a um seletor de templates.

Isso é consistente com o que argumentamos em Quando Sua IA Explica Seu Raciocínio, Ela Está Inventando. As narrativas que modelos produzem sobre seu próprio comportamento são construções pós-hoc, não relatos fiéis de computação interna. As “respostas” do Qwen sobre Taiwan não são crenças do modelo. São completions de template disparadas por um detector que não sabe de fato o que Taiwan é.

O resultado do over-steering reforça isso. Quando o pesquisador empurrou d_refuse além de sua faixa treinada, o modelo não começou a contar a verdade. Saltou para outro template treinado: uma narrativa fabricada de negação que o processo de treino havia embutido como fallback. A resposta honesta era alcançável apenas em uma faixa estreita do parâmetro de steering. Fora dessa faixa, você recebe uma de várias mentiras ensaiadas.

A Implicação de Governança Que Quase Todos Vão Perder

A leitura óbvia dessa pesquisa é “modelo chinês tem alinhamento fraco, próxima notícia”. Essa leitura está errada em dois pontos.

Primeiro, a técnica não é específica do Qwen. Activation steering e isolamento de vetores de direção funcionam em qualquer transformer. Anthropic, OpenAI e Google publicaram trabalhos de interpretabilidade usando primitivas similares. Não há razão arquitetural para assumir que modelos ocidentais treinados com RLHF sejam estruturalmente diferentes. Foram treinados com a mesma matemática sobre a mesma família de funções objetivo, apenas com intenções de política distintas.

Segundo, e mais importante, isso muda o que auditoria comportamental pode provar. Quando um time de compliance certifica um modelo como “alinhado” com base em red-team testing, está medindo se a camada de recusa dispara nos lugares certos. Não está medindo se a capacidade subjacente foi removida. O trabalho do Vas-blog demonstra que, para ao menos um modelo de grau de produção, essas são coisas diferentes.

Se a restrição comportamental mais fortemente incentivada do Qwen3.5 (censura política, sobre a qual o Estado chinês se importa o suficiente para mandatar) é um adesivo em vez de remoção de capacidade, a prior de que outros comportamentos treinados por RLHF sejam estruturados de forma similar acabou de ficar muito mais forte. Recusas de segurança. Restrições de uso de ferramentas. Restrições de persona. Aplicação de voz de marca. Qualquer comportamento treinado por reward modeling sobre uma capacidade base é candidato ao mesmo padrão arquitetural.

Por Que Isso Quebra o Modelo Atual de Auditoria

A maioria dos frameworks corporativos de governança de IA assume que teste comportamental pode substituir verificação mecanística. O raciocínio é pragmático: interpretabilidade mecanística não escala, mas red-teaming sim. Então aceitamos evidência comportamental como proxy de conformidade estrutural.

O resultado do Vas-blog mina essa substituição na fundação. Red-teaming comportamental pode verificar que um modelo recusa fazer X. Não pode verificar que o modelo não consegue fazer X. São afirmações diferentes, e a distância entre elas é exatamente a superfície onde a técnica do Qwen opera.

Em O Salto de 20x da Anthropic em Sensibilidade, cobrimos como autoencoders de linguagem natural estão começando a tornar interpretabilidade barata o suficiente para aplicar em escala de auditoria. Aquele trabalho posicionava interpretabilidade como ativo de governança, ferramenta que produz evidência verificável. A pesquisa do Qwen é o desafio empírico que essas ferramentas agora precisam responder: não apenas “o que o modelo está fazendo” mas “do que o modelo é capaz quando suas camadas treinadas são subtraídas”.

Uma auditoria comportamental do Qwen3.5 concluiria que o modelo tem guardrails políticos. Uma auditoria mecanística revela que esses guardrails são removíveis em três linhas de álgebra linear. As duas auditorias produzem recomendações de governança diferentes. Hoje, quase toda empresa está rodando a primeira.

O Que Compradores Deveriam Exigir Agora

Se você está adquirindo ou licenciando modelos para deploy regulado, essa pesquisa justifica adicionar uma cláusula nova ao seu questionário de fornecedor. Pergunte se o fornecedor realizou análise mecanística dos comportamentos de segurança. Pergunte se eles podem demonstrar que recusas treinadas correspondem a remoção de capacidade em vez de gateamento de capacidade. Pergunte se eles se comprometeriam a divulgar caso probing interno revelasse o contrário.

A maioria dos fornecedores não terá boas respostas hoje. Isso por si só é informação. Um fornecedor que não fez essa análise está vendendo conformidade comportamental, não conformidade estrutural. Precifique a diferença no seu modelo de risco.

Para times internos rodando modelos de pesos abertos, a implicação é mais direta. Se sua narrativa de segurança depende de recusas treinadas por RLHF, essa narrativa tem um modo de falha conhecido. Teste contra ele. Rode experimentos de activation steering nos seus modelos fine-tuned. Veja o que volta. A técnica está documentada e replicável, o que significa que também está disponível para adversários.

Faça Isso Agora

Escolha um modelo que sua organização trate como “treinado para segurança” e rode um único probe mecanístico no seu comportamento de recusa. Não um exercício de prompt de red-team. Uma análise de ativação de verdade sobre um tópico que se sabe recusado, usando as técnicas que o Vas-blog documentou. Trate o resultado como um ponto de calibração: se conformidade comportamental e estrutural coincidem, seu modelo de auditoria está sólido. Se divergem, seu modelo de auditoria vinha medindo a coisa errada, e você agora tem a evidência para redesenhá-lo antes que um regulador ou adversário faça esse caso por você.

Fontes

Vas-blog. “What Political Censorship Looks Like Inside an LLM’s Weights.” Maio de 2026.

A Victorino ajuda times de risco e compliance a ir além da auditoria comportamental caixa-preta rumo à governança verificável de modelos: contato@victorino.com.br | www.victorino.com.br

Alta Capacidade de Raciocínio Cita Outra Web. Sua Visibilidade em IA Bifurcou.

Thiago Victorino — Tue, 19 May 2026 00:00:00 GMT

Kevin Indig rodou 100 prompts em 20 jornadas de compra e quatro verticais através do GPT 5.2 em duas configurações de raciocínio: mínima e alta. Os dados, publicados em sua edição de maio de 2026 do Growth Memo “Reasoning Lift: What Happens to AI Visibility When AI Thinks Harder”, deveriam mudar como times de marketing e growth pensam medição de busca por IA.

O resultado principal não é que raciocínio alto cita mais fontes. Isso era esperado. O resultado principal é que raciocínio alto cita uma web diferente.

Apenas 25,6% dos domínios citados se sobrepõem entre os dois modos. Noventa e nove domínios aparecem exclusivamente quando o raciocínio está alto. As buscas internas ramificadas (fan-out) multiplicam 4,6x. A taxa de citação sobe de 50% para 68%. A média de fontes por resposta vai de 2,6 para 4,5.

Mesmo modelo. Mesmos prompts. Dois mercados de informação diferentes.

A bifurcação é operacional, não acadêmica

A maioria das ferramentas de visibilidade em IA hoje agrega. Roda prompts, coleta citações e reporta um número único: share of voice, taxa de citação, índice de presença. Essa agregação fazia sentido quando as respostas de LLM eram estruturalmente similares. Para de fazer sentido no momento em que o mesmo modelo se comporta como dois sistemas de busca diferentes dependendo de um parâmetro de execução.

Os dados de Indig forçam a pergunta: qual versão do GPT 5.2 seus clientes realmente usam? Se metade dos compradores roda queries em raciocínio mínimo (rápido, barato, default em várias superfícies de produto) e a outra metade roda queries em raciocínio alto (mais lento, mais profundo, cada vez mais o default para compras consideradas), então uma métrica única de visibilidade é a média de duas populações que podem nem compartilhar a mesma shortlist de marcas.

Mediar entre elas não é medição. É camuflagem.

Onde a bifurcação bate mais forte

O comportamento de fan-out é o mecanismo. Sob raciocínio mínimo, o GPT 5.2 faz em média um punhado de buscas internas antes de responder. Sob raciocínio alto, faz 4,6x mais. O efeito composto aparece de forma mais dramática no meio e no final do funil.

Queries de estágio de comparação vão de 5,5 buscas fan-out (mínimo) para 24 (alto). Queries de estágio de seleção vão de 2,6 para 15,4. Esses são exatamente os estágios da jornada de compra onde citação de marca importa mais: quando alguém está montando shortlist de fornecedores, quando alguém está decidindo.

A implicação: marcas otimizadas para queries de awareness de topo de funil podem parecer bem em dashboards agregados de visibilidade enquanto estão completamente ausentes do conjunto de citações que usuários de raciocínio alto veem durante avaliação. O mercado de estágio de decisão é o que converte. Também é o mais provável de ficar escondido pela média.

Por que isso não é “mais um padrão vertical”

Alguns analistas de visibilidade em IA vão fazer pattern-match disso com achados anteriores de variância vertical. Esse pattern-match está errado.

Variância vertical diz que indústrias diferentes são citadas de formas diferentes. Isso é verdade e já escrevemos sobre. Bifurcação por modo de raciocínio diz algo mais estranho: dentro da mesma vertical, dentro do mesmo prompt, dentro do mesmo modelo, o pool de fontes pode ser quase completamente diferente dependendo de um único botão de execução. A variância não está entre mercados. Está dentro do mesmo mercado.

Também não é o mesmo problema que acoplamento de plataformas (quais plataformas citam quais fontes) ou o déficit de fan-out (a defasagem de 27% no ranqueamento do Google para queries fan-out que cobrimos no ponto cego do fan-out do ChatGPT). Esses problemas existem entre sistemas. Bifurcação de raciocínio existe dentro de um.

O que os dashboards agregados estão escondendo

Se você reporta qualquer um dos itens abaixo como número único, agora está reportando média de duas populações:

Share of voice entre assistentes de IA
Taxa de citação por marca
Score de autoridade de domínio para busca por IA
Presença de competidores no texto da resposta
Cobertura de tópicos por categoria de query

Nenhum desses está errado. Estão incompletos. A mesma marca pode ter 70% de taxa de citação em raciocínio mínimo e 30% em raciocínio alto, ou o inverso, e a média reportada não diz nada acionável.

A metodologia de Indig usou a API do AI Visibility Toolkit da Semrush para rodar prompts pareados em cada configuração de raciocínio. Esse design pareado é a disciplina que o resto do mercado ainda não adotou. Até adotar, a maioria dos dashboards está medindo uma média fantasma.

A nova unidade de governança

Já argumentamos que AEO já foi comoditizado e que os KPIs reais para busca por IA exigem tratar visibilidade como disciplina de medição, não como métrica. Os dados de Indig estendem esse argumento.

Modo de raciocínio agora é uma dimensão de governança. Tratar “visibilidade em IA” como objeto único é o equivalente a tratar “visibilidade em busca” como objeto único quando desktop e mobile divergiram. Os times que separaram métricas desktop versus mobile em 2014 viram sinal real. Os times que continuaram agregando viram ruído.

Mesmo arco, linha do tempo mais rápida. Os times que segmentarem por modo de raciocínio em 2026 vão ver o que os competidores perdem.

Faça isto agora

Três movimentos concretos para líderes de marketing e growth neste trimestre:

Rode novamente seus 20 prompts prioritários nas duas configurações de raciocínio e compare os domínios citados. Não a contagem de citações. Os conjuntos de domínios citados. Se a sobreposição estiver abaixo de 50%, seu dashboard agregado está mediando dois mercados. Você precisa de dois dashboards.

Segmente seus KPIs de visibilidade em IA por intensidade de raciocínio, não só por assistente. Reportar ChatGPT versus Perplexity versus Gemini é o básico. A próxima camada é reportar pools de citação de raciocínio baixo versus alto dentro de cada assistente. O delta de fan-out é onde o sinal de estágio de decisão mora.

Audite sua presença na shortlist no estágio de seleção sob raciocínio alto. Essa é a camada mais próxima da conversão. Se você aparece em 15,4 buscas fan-out durante seleção e seu competidor aparece em 24, você está perdendo o conjunto de consideração antes do comprador falar com vendas. Presença na shortlist no estágio de seleção sob raciocínio alto é o indicador-líder mais próximo de pipeline gerado por busca por IA que existe hoje.

As marcas que governarem esses dois mercados como dois mercados vão compor. As marcas que continuarem agregando vão continuar se perguntando por que o dashboard diz uma coisa e o pipeline diz outra.

Fontes

Growth Memo (Kevin Indig). “Reasoning Lift: What Happens to AI Visibility When AI Thinks Harder.” Maio de 2026.

A Victorino ajuda times de marketing e growth a governar a visibilidade em busca por IA como disciplina de medição, não como métrica: contato@victorino.com.br | www.victorino.com.br

Agentes Não Fazem Standups: A PFF e a Inversão Organizacional

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

A gestão de engenharia de software passou vinte anos otimizando para velocidade do engenheiro. Scrum, sprint planning, daily standup, refinamento, retrospectiva. Toda cerimônia descende da mesma premissa: hora de desenvolvedor é o recurso escasso, então é preciso coordená-la com cuidado.

Na AI Engineer Conference de maio de 2026, Mike Spitz, CTO da Pro Football Focus, descreveu um experimento de três meses que testou o que acontece quando essa premissa deixa de valer. Dois engenheiros, trabalhando com agentes, contra um time de aproximadamente dez engenheiros sem agentes. Mesma base de código, mesmos clientes, de janeiro a março de 2026. Números autodeclarados: 25x mais frequência de deploy, 10x mais entrega medida por contagem de tickets ponderada por complexidade de código, satisfação média do cliente em 8.6 contra uma linha de base pré-IA próxima a 7.5.

A PFF não é um laboratório de pesquisa. É uma empresa de dados esportivos com 100 milhões de page views por ano, nove milhões de drafts de fantasy por ano, 200 funcionários e cerca de 20 engenheiros, atendendo times da NFL e da NCAA junto com um produto consumer de fantasy e apostas. O caso aterrissa em escala, em código de produção, com clientes pagantes. É isso que o torna interessante.

A pergunta interessante não é se dois engenheiros conseguem substituir dez. Já escrevemos antes sobre o experimento do compilador com 16 agentes conduzido por Carlini e o que ele indica sobre agentes como força de trabalho. A pergunta interessante é como a organização ao redor se reconfigura quando você para de otimizar para ergonomia do engenheiro e começa a otimizar para vazão de agentes. A resposta de Spitz: as cerimônias caem primeiro.

As Cerimônias Resolviam um Problema que Desapareceu

Scrum não desceu de uma montanha. É um artefato, projetado no fim dos anos 1990 e nos anos 2000, para resolver um problema específico de coordenação: como fazer com que um número pequeno de engenheiros humanos, caros e lentos, entregue software coerente sem pisar no pé um do outro. A daily responde “o que está te bloqueando hoje, enquanto você ainda tem oito horas de digitação pela frente?” O sprint plan responde “qual é a capacidade realista desses humanos nas próximas duas semanas?” A retrospectiva responde “como deixamos esses humanos um pouco menos frustrados no próximo sprint?”

Cada uma dessas perguntas assume que hora de engenheiro é a restrição dominante.

A PFF desmontou a pilha inteira. Spitz lista o que saiu: o papel de product manager, sprint planning, daily standup, refinamento de sprint, retrospectiva. O que entrou no lugar é quase constrangedoramente enxuto. Uma reunião curta de meia hora, em dias alternados. Engenheiros sinalizam bloqueios em tempo real, não às 10 da manhã do dia seguinte. O sinal da retrospectiva foi substituído por uma pesquisa de satisfação dos clientes, porque são eles que sabem se o trabalho da semana passada foi bom. A função de PM, a escrita de spec, o grooming de tickets, a sincronização de status, tudo migrou para agentes.

Isso não é “ainda fazemos Scrum, mas com ajuda de IA”. É a deleção explícita das cerimônias, com base no raciocínio explícito de que a restrição para a qual elas foram desenhadas não existe mais.

O Fluxo que Toma o Lugar

Spitz descreveu o loop que a PFF roda agora, e vale traçar porque a topologia importa.

Chega uma spec. Um agente escreve um Lightweight Design Document, que ele compõe lendo todos os LDDs anteriores no repositório para aprender o formato que esses documentos têm na PFF. Tickets são gerados automaticamente a partir do LDD, preservando a topologia não-bloqueante para que trabalhos independentes possam avançar em paralelo. Pull requests carregam status que se sincroniza automaticamente de volta para o sistema de tickets. Depois do merge, um agente de QA sobe em staging e valida cada ticket contra seus critérios de aceitação.

O que precisa ser notado é que isso não é “agentes ajudam engenheiros a codar mais rápido”. É “agentes substituem o tecido conjuntivo entre engenheiros”. O LDD, os tickets, as atualizações de status, as passadas de QA. Todo o trabalho que historicamente exigia um PM, um tech lead, um scrum master, um engenheiro de QA e os próprios engenheiros para manter sincronizado. A maior parte desse trabalho não tem nada a ver com escrever código. É overhead de coordenação, e overhead de coordenação é exatamente o tipo de trabalho em que agentes são bons quando os artefatos são estruturados e as regras são explícitas.

Os dois engenheiros focam nas partes do loop que ainda exigem julgamento: decisões de design de sistema, revisão de código em escolhas arquiteturais, e julgamento sobre experiência do cliente. Tudo no meio é delegado.

A Revisão de Código se Divide, Não Morre

O movimento mais sutil do redesenho de Spitz é a divisão que ele fez na revisão de código. Ele não eliminou a prática. Ele a partiu em duas.

Revisão de estilo, convenção de nomes, “eu teria feito diferente” e opiniões bikeshed, o tipo de feedback que ninguém gosta de dar nem de receber: agentes assumem. Revisão de design de sistema, coerência arquitetural, a pergunta sobre se a mudança encaixa no modelo da plataforma: engenheiros assumem. Como ele formulou: “Usamos agentes para fazer as revisões de código que engenheiros odeiam receber. Tira todo o aspecto emocional fora disso.”

Esse é um daqueles detalhes operacionais que parecem pequenos e não são. Uma fração relevante da dor cultural em engenharia vem de feedback de revisão entregue mal. Sêniores que criticam estilo, juniores que se sentem atacados, a erosão lenta de segurança psicológica quando o feedback é tecnicamente correto mas socialmente caro. Mover a superfície de revisão de baixo valor para um agente não só economiza tempo. Remove uma fonte recorrente de atrito organizacional. A revisão humana que resta é reservada para as conversas que de fato exigem humanos, o que torna essas conversas tanto mais focadas quanto mais respeitadas.

O princípio generaliza. Onde quer que no seu processo de engenharia o trabalho seja baseado em regra mas a entrega seja emocionalmente carregada, o agente é o operador melhor.

A Satisfação do Cliente Subiu, Não Caiu

A parte do caso que mais resiste ao ceticismo padrão é o número de satisfação do cliente. A linha de base pré-IA na PFF estava entre 7.0 e 7.5. Ao longo dos três meses de experimento, a satisfação média do cliente foi 8.6.

Uma objeção comum à engenharia aumentada por IA é que velocidade vem ao custo de qualidade, e que clientes vão notar. Os números da PFF, autodeclarados e em uma única empresa, apontam para a direção oposta. Deploys mais frequentes encurtam o ciclo de feedback, o que significa que defeitos são pegos mais rápido e pedidos de funcionalidade são atendidos mais rápido. O agente de QA rodando contra critérios de aceitação em staging captura uma classe de regressões que antes escapava. Os 25x de frequência de deploy não são 25x mais superfície de risco; são 25x mais chances de detectar e corrigir.

A ressalva precisa ser sublinhada: esses números foram divulgados pelo CTO em uma conferência. Não foram validados por terceiros. Refletem uma empresa, três meses. Trate como prova de existência, não como benchmark a ser copiado. O ponto não é “todo time deveria esperar CSAT de 8.6”. O ponto é “a tese de que velocidade com IA precisa trocar qualidade está, no mínimo, a um contraexemplo forte de ser considerada segura.”

O Perfil do Engenheiro Muda

Spitz mencionou uma implicação de contratação e retenção que a maior parte das discussões sobre engenharia aumentada por IA pula. O novo arranjo não funciona para todo engenheiro.

Engenheiros que prosperam: os curiosos, dispostos a se aprofundar em sistemas desconhecidos, confortáveis em operar sem uma especificação prescritiva entregue na mão. Tratam o agente como um time júnior que pode pegar trabalho, mas assumem a responsabilidade pela direção arquitetural. São intrinsecamente motivados a descobrir o que deveria ser construído.

Engenheiros que sofrem: os que precisam de um ticket do Jira totalmente especificado antes de começar a trabalhar, que dependiam do PM e do documento de spec como fonte de direção. O suporte estrutural de que esses engenheiros precisavam foi removido, e os agentes não o repõem. Os agentes amplificam qualquer direção que o engenheiro fornece, o que é maravilhoso se o engenheiro tem direção e difícil se o engenheiro dependia da organização para fornecer essa direção.

Essa é uma questão real de design organizacional para qualquer time considerando a mudança. Os engenheiros que têm sucesso em um ambiente pós-cerimônia são um perfil específico. Práticas de contratação e gestão que filtravam por “entrega de forma confiável contra specs apertadas” vão produzir um time que não combina com o novo modelo operacional.

Composição, Não Ganho Linear

Um dado interno anterior da PFF merece atenção. Antes da IA, o mesmo conjunto de funcionalidades que o time de dois engenheiros entregou havia sido estimado em quatro meses. O time de dois entregou em menos de dois meses, e um dos engenheiros estava desbloqueado o suficiente, dentro do primeiro mês, para começar outra frente em paralelo.

Isso não é um ganho de 2x ou de 5x. É um ganho não-linear porque o gargalo se deslocou. Quando a contribuição de um engenheiro desbloqueia não só ele mesmo, mas também abre espaço para a frota de agentes operar em uma segunda frente, a capacidade do time se compõe. A variável relevante não é “quão rápido o engenheiro digita”, e sim “quantas frentes paralelas dirigidas por agentes o engenheiro consegue manter abertas ao mesmo tempo”.

A implicação para planejamento de capacidade é desconfortável. As estimativas que seu time produz hoje assumem a restrição antiga. As estimativas que correspondem ao que vocês de fato conseguem entregar, com as ferramentas atuais, são diferentes por um múltiplo que depende de quão fundo vocês inverteram a organização.

Faça Isso Agora

Você não precisa desmontar o Scrum na semana que vem. Você precisa rodar um exercício único e concreto.

Pegue o próximo sprint de duas semanas. Liste toda cerimônia que vocês rodam: daily, refinamento, retro, sprint planning, demo. Para cada cerimônia, anote o problema original que ela resolvia. A maioria desses problemas vai se revelar como “humanos precisam coordenar tempo escasso em teclados escassos”. Em seguida, olhe quais desses problemas ainda existem no seu ambiente agora que agentes fazem parte do time. Alguns vão existir. A maioria não.

O exercício não é matar o Scrum. É nomear restrições. A PFF não deletou cerimônias porque cerimônias são ruins. Deletou cerimônias porque as restrições que aquelas cerimônias resolviam haviam se movido. O exercício é descobrir, com honestidade, quais das suas cerimônias ainda resolvem um problema real e quais são memória muscular organizacional.

Os times que vão superar o mercado nos próximos dois anos não são os que adotam agentes. Quase todo mundo vai adotar agentes. São os que redesenharam a organização ao redor para parar de otimizar por uma restrição que já se moveu.

Fontes

Mike Spitz, PFF. “Agents Don’t Do Standups.” AI Engineer Conference, Maio de 2026.
Pro Football Focus. “PFF.” 2026.
AI Engineer. “AI Engineer Conference.” Maio de 2026.

A Victorino ajuda líderes de engenharia a redesenharem processos organizacionais quando o tempo do engenheiro deixa de ser a restrição dominante: contato@victorino.com.br | www.victorino.com.br

Cinco Fornecedores, Uma Arquitetura: A Camada de Controle de Agentes Virou Categoria de Produto

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

Entre 13 e 17 de maio de 2026, cinco fornecedores sem qualquer roadmap compartilhado publicaram a mesma tese arquitetural. O time de engenharia do Claude Code, da Anthropic, escreveu que “o harness importa tanto quanto o modelo”. A Intercom (agora rebatizada Fin) lançou o Fin Operator, uma IA cujo único trabalho é supervisionar outra IA, com um portão duro de aprovação antes de qualquer alteração tocar produção. A Docker liberou Custom MCP Catalogs e Profiles, distribuindo pacotes curados de ferramentas via artefatos OCI. Nader Dabit publicou uma especificação de seis hooks de ciclo de vida para controle determinístico de agentes. Jamin Ball, da Altimeter, colocou na planilha: “Se seu produto não pode ser invocado como skill dentro daquela superfície de agente, você está funcionalmente invisível.”

Cinco categorias distintas. Uma tese arquitetural única. A camada fora do modelo, hooks, skills, catálogos, portões de proposta, governança de marketplace, é onde a governança de agentes de fato acontece. Defendemos isso por meses. Esta semana deixou de ser nossa tese e virou categoria de produto sendo entregue.

A planilha de compras ganhou uma linha chamada “camada de controle”. Os fornecedores estão competindo para dominá-la.

Cinco Fornecedores, Cinco Camadas, Um Edifício

O padrão só fica nítido quando você empilha os movimentos lado a lado. Cada fornecedor está reivindicando um andar diferente do mesmo edifício.

A Anthropic domina a camada do harness. O post do time de engenharia do Claude Code sobre grandes codebases descreve a arquitetura sob o modelo: hooks de pré-ferramenta, hooks de pós-ferramenta, sistema de arquivos como memória, despacho de sub-agentes, descoberta de skills. A frase deles, o harness importa tanto quanto o modelo, é uma admissão de que a performance vem do andaime, não dos pesos. O modelo vira commodity quando o harness está certo.

A Fin domina a camada de supervisor. Brian Donohue, VP de Produto da Fin, é direto: “Nesse momento, estamos correndo zero risco. A Fin não pode fazer qualquer alteração no sistema sem aprovação humana. Nada entra em produção até que uma pessoa clique em aplicar.” O Fin Operator roda o Claude, da Anthropic, em vez dos modelos Apex da própria Fin, porque o trabalho dele, supervisionar outro agente, se parece mais com engenharia de software do que com atendimento. A Fin já resolve mais de 2 milhões de tickets por semana em 8.000 clientes. O beta do Operator começou com cerca de 200 deles. O portão de proposta é o produto.

A Docker domina a camada de distribuição. O post de Bobby House é o mais discretamente importante da semana: “Conforme o MCP cresce, o desafio não é acesso a ferramentas, é coordenação. Times precisam padronizar o que é confiável e suportado sem restringir como cada um trabalha.” Custom MCP Catalogs viajam por artefatos OCI, a mesma cadeia que já move imagens de contêiner. Profiles suportam agrupamentos nomeados ilimitados, filtragem de ferramentas e compartilhamento entre times. A Docker está colocando servidores MCP nos mesmos trilhos de confiança que as empresas já auditam.

Nader Dabit domina a camada de determinismo. O post Agent Hooks é a declaração de engenharia mais limpa da semana: “Use prompts para orientação. Use hooks para comportamento que deve rodar toda vez.” Ele nomeia seis eventos de ciclo de vida, SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, SessionEnd, e mostra por que cada um é onde a política determinística mora. Prompts são best-effort. Hooks são garantidos. A camada de hook é onde compliance vira código.

A Altimeter domina a camada de marketplace. A leitura de Jamin Ball tem clareza de investidor. A “superfície do agente” está virando a nova app store, e skills são os novos apps. Se um produto SaaS não puder ser invocado como skill dentro daquela superfície, ele perde lugar. A camada de controle não é só primitiva de engenharia. É canal de distribuição com dinâmica de categoria, efeito de rede e sinais de confiança vinculados.

Cinco andares. Um edifício. Cada fornecedor competindo para ser o dono de um andar enquanto todos concordam que o edifício existe.

A Cara do Edifício Quando Você Recua

Empilhe as camadas e a arquitetura fica legível:

Distribuição. Como pacotes confiáveis de ferramenta chegam ao workspace. A Docker está na frente; OCI é o trilho que já existe.
Marketplace. Como descoberta, ranqueamento e invocação acontecem dentro da superfície do agente. A Altimeter enxerga a categoria se formando; os fornecedores ainda não estão lá.
Harness. Como o modelo é embrulhado, o que ele enxerga, qual contexto carrega, quais sub-agentes pode acionar. A Anthropic lidera.
Determinismo. Como política inegociável é aplicada apesar da deriva de prompt. Nader Dabit articulou a especificação; todo mundo implementa variantes.
Supervisor. Como agentes autônomos são revisados por outro agente antes da ação cair no sistema real. A Fin é a primeira prova em produção e em escala.

Esses não são cinco produtos. São cinco superfícies de um único runtime, e precisam se interoperar. Uma skill distribuída pela Docker, invocada de um marketplace, executada dentro do harness da Anthropic, controlada por um hook de determinismo e aprovada por um supervisor estilo Fin é um único workflow. Hoje, são cinco fornecedores e zero padrões.

Essa é a parte que ninguém entregou esta semana.

O Que Ainda Falta

A camada de controle é real. A história de integração não é. Três deficits se destacam, e é aí que mora o próximo ano de trabalho.

Interoperabilidade de política entre fornecedores. Uma especificação de hook do Nader Dabit não é um artefato portável. Um Docker Profile não é lido pelo loader de skills da Anthropic sem tradução. Um portão de proposta da Fin não fala o mesmo formato de auditoria que uma reprodução em sandbox da Vercel. Cada fornecedor está erguendo um andar crível. Nenhum publica como o andar dele conversa com o de cima. Empresas acabam refazendo a cola, de novo, para cada nova ferramenta.

Padrão de log de auditoria. Cada camada emite a evidência dela. Hooks disparam e logam em algum lugar. Skills executam e logam em outro. Aprovações de supervisor caem num terceiro. Invocações de marketplace somem na analytics do fornecedor. Um regulador perguntando “me mostre todas as ações que essa frota de agentes tomou no último trimestre, quem aprovou, e qual política pegou o quê” não obtém resposta coerente hoje. A camada de controle precisa de uma especificação no formato OpenTelemetry para governança de agentes. Ninguém tomou esse pedaço ainda.

Sinal de confiança no marketplace. Ball está certo de que skills são os novos apps. App stores amadureceram exatamente porque têm sinais de confiança: binários assinados, filas de revisão, processos de remoção, manifestos de versão. O marketplace de skills ainda não tem nada disso. Docker Catalogs estão mais perto do que qualquer um porque artefatos OCI já carregam assinatura. Mas um administrador de workspace ainda não consegue perguntar “essa skill veio de um fornecedor com quem tenho contrato, e qual o status de revisão dela?” e receber resposta estruturada.

Cobrimos o primeiro sinal dessa categoria em governança como produto, três fornecedores, maio de 2026 e mapeamos as raízes arquiteturais em Symphony, a especificação da camada de controle e hooks de agente como superfície de persistência. O formato era visível. Esta semana nomeou.

Por Que Compras Deveria Se Importar Neste Trimestre

Quando uma categoria sai de emergente para legível em uma semana, o cronograma de compras se move. O comprador que ia escrever um RFP no ano que vem agora tem itens comparáveis hoje. Um administrador de workspace pode perguntar a cada finalista cinco questões concretas:

Quais hooks de ciclo de vida vocês expõem, e quais são obrigatórios versus opcionais?
Como skills são distribuídas para nosso workspace, e qual a cadeia de custódia?
Qual é o mecanismo de supervisor para mudanças autônomas, e em que formato fica a auditoria de aprovação?
Como os eventos da camada de controle de vocês aparecem no nosso SIEM e na camada de identidade que já temos?
Qual é a história de interop quando misturamos vocês com os outros quatro andares?

Essas perguntas não são mais teóricas. Cada fornecedor no campo acima respondeu pelo menos uma delas publicamente nesta semana. O comprador que deixar esse conhecimento passar está comprando modelo e levando um runtime que não especificou.

Já argumentamos que o padrão da gaiola para governança de frotas de agentes descreve como times em produção já vivem dentro dessa arquitetura. Os movimentos desta semana confirmam. A gaiola deixou de ser metáfora. É uma pilha de camadas nomeadas, sendo entregue sob marcas nomeadas.

Faça Isso Agora

Escolha um workflow de agente que a sua organização roda em produção. Trace pelas cinco camadas. De onde vem o pacote confiável de ferramenta? Como o modelo é embrulhado? Quais hooks aplicam política? Quem ou o que supervisiona a ação autônoma antes dela cair? Onde vive a evidência de invocação para auditoria?

Anote a resposta. Se três ou mais camadas resolverem em “o prompt cuida” ou “o desenvolvedor sabe”, você está rodando em best-effort, não em camada de controle. Os fornecedores que entregaram nesta semana estão apostando que best-effort é exatamente a parte que a categoria está substituindo. Quanto mais rápido você mapear sua pilha, mais rápido pode escolher qual fornecedor ocupa qual andar, e onde vale a pena construir a cola por dentro.

A camada de controle não é mais tese. É linha de item. Compras percebeu.

Fontes

VentureBeat. “Intercom Now Called Fin Launches Fin Operator.” Maio de 2026.
Anthropic. “How Claude Code Works in Large Codebases.” Maio de 2026.
Docker. “Create Custom MCP Catalogs and Profiles.” Maio de 2026.
Nader Dabit. “Agent Hooks: Deterministic Control for Agent Workflows.” Maio de 2026.
Altimeter Capital. “The Real App Store Opportunity.” Maio de 2026.

A Victorino ajuda empresas a desenhar e operar a camada de controle de agentes que os SDKs dos fornecedores assumem que você já tem: contato@victorino.com.br | www.victorino.com.br

Explorar, Planejar, Codificar, Commit: O Lugar Mais Barato de Corrigir um Agente É Antes do Código

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

A maioria dos times que usa um agente de código cola um prompt e deixa o agente digitar. O modelo escreve código. O engenheiro reage ao diff. Cada correção nesse estágio reescreve o que já foi escrito. O hábito caro se esconde à vista: ninguém planejou o trabalho antes do agente começar a gastar tokens para produzi-lo.

O fluxo canônico da Anthropic para o Claude Code tem um nome para o oposto desse hábito. Explorar, Planejar, Codificar, Commit. A estrutura é simples e a disciplina é deselegante: o agente não pode editar nada até que o plano seja aprovado. O modo plano é somente leitura. O humano revisa o plano, não o código. Quando o plano está bom, o trabalho prossegue.

Essa inversão muda a economia do desenvolvimento com agentes. O custo de corrigir um desenho ruim em um plano é algumas frases de texto. O custo de corrigir o mesmo desenho ruim em 500 linhas de diff é o diff somado à reexecução de testes, somado ao ciclo de revisão, somado à faxina do histórico de commits. Times pulam o modo plano porque a musculatura organizacional ainda recompensa digitação visível. Pagam o pulo em retrabalho.

As Quatro Fases, Em Ordem

O fluxo tem quatro fases. Cada uma corresponde a uma postura diferente que o agente e o humano assumem diante do trabalho.

Explorar. O agente lê arquivos, roda buscas e forma um mapa mental de onde a mudança pertence. Ainda não propõe ações. Está descobrindo o que não sabe.

Planejar. Acionado com Shift+Tab no Claude Code, o modo plano trava o agente em postura de leitura. O agente continua podendo ler, buscar e raciocinar. Não pode editar, não pode rodar comandos de shell que mutam estado, não pode criar arquivos. Produz uma lista numerada das ações que pretende executar. O humano lê a lista e aprova, edita ou rejeita.

Codificar. Com o plano aprovado, o agente percorre as ações propostas e as executa. O plano vira checklist, não sessão livre. Desvios ficam visíveis porque o plano está visível.

Commit. Antes de a mudança virar commit, um subagente revisor de código inspeciona o diff. Depois o agente gera a mensagem de commit no estilo do time. O humano aprova o commit.

A ordem importa. Cada fase é mais barata de corrigir do que a próxima. Correção na exploração custa uma busca. Correção no plano custa uma frase. Correção no código custa um diff. Correção no commit custa o diff somado à trilha de auditoria. Times que pulam direto do prompt para o código escolhem a superfície de correção mais cara como primeira linha de defesa.

O Exemplo Canônico

O tutorial da Anthropic usa um prompt concreto para demonstrar o formato: “Preciso adicionar conversão WebP ao nosso pipeline de upload de imagens. Descubra onde no pipeline isso deveria acontecer, se precisamos de novas dependências e como abordar.”

Repare no que o prompt não diz. Não diz “escreva o código”. Não diz “abra o arquivo e comece”. Diz “descubra e proponha”. Esse enquadramento coloca o agente em postura de explorar-e-planejar por padrão. O agente lê os arquivos do pipeline, roda uma busca na web para checar boas práticas atuais e devolve um plano. O humano lê o plano e decide se a dependência proposta, o ponto de inserção proposto e o tratamento proposto para casos de borda estão certos. O humano está revisando seis linhas de plano, não 200 linhas de diff.

Se o plano está errado, a conversa continua no modo plano. Se o plano está certo, o humano aprova e o agente prossegue. A primeira linha de código é a primeira linha de código que já passou pela revisão de desenho.

Três Superfícies de Verificação

O fluxo presume verificação, e a Anthropic recomenda três superfícies que o agente deve aprender a usar.

A primeira é a suíte de testes como fonte da verdade. O agente roda os testes continuamente enquanto codifica e trata o resultado como sinal autoritativo de que o trabalho está pronto. Testes verdes não provam correção, mas removem a classe de afirmações “acho que funciona” que poluiu o primeiro ano de desenvolvimento com agentes.

A segunda é o controle de navegador para trabalho de UI. O Claude consegue dirigir uma aba Chrome via MCP, abrir a aplicação em execução e verificar que a mudança se comporta como pedido antes de dizer que terminou. O agente não apenas compila a mudança. Confere se a mudança faz o que foi pedido na superfície que um usuário tocaria.

A terceira é o arquivo Claude.md. Correções recorrentes, convenções do repositório e decisões que o time já tomou ficam registradas no Claude.md para que o agente pare de redescobri-las. Trate o Claude.md como memória institucional do agente. Toda vez que um revisor colar a mesma correção duas vezes, na terceira essa correção pertence ao Claude.md.

Por Que o Modo Plano É Importante Arquiteturalmente

O modo plano não é firula de UX. É uma fronteira de contenção no perímetro do loop central do agente. Já escrevemos sobre a arquitetura de while-loop no coração do Claude Code: o agente é um loop que decide uma chamada de ferramenta, executa, observa o resultado e decide a próxima chamada. O loop é rápido e capaz. O loop também é caro quando produz trabalho que precisa ser descartado.

O modo plano envolve o loop. Dentro do modo plano, o catálogo de ferramentas do agente fica restrito a operações de leitura. O raciocínio segue igual. A saída é uma proposta, não um efeito colateral. O humano inspeciona a proposta e aprova ou manda o agente pensar de novo. O loop caro só roda contra trabalho que o humano já endossou.

É o mesmo instinto de contenção que move o agent harness e os primitivos de harness que defendemos: a confiança sai do por-ação e vai para o por-ambiente, e o ambiente agora inclui uma fase em que o agente raciocina sem consequências. A economia é estrutural. Você não está pegando o trabalho ruim depois de escrito. Está pegando antes de ser escrito.

Onde os Times Empacam

A falha mais comum não é técnica. É organizacional. Engenheiros se sentem produtivos quando veem código sendo digitado. O modo plano não produz digitação. Produz deliberação. Para uma cultura que premia movimento visível, deliberação parece agente travado.

A correção é medir retrabalho em vez de throughput. Conte quantas vezes uma mudança foi comitada, revertida e re-comitada na mesma semana. Conte quantos PRs precisaram de um segundo ciclo de mudanças substantivas depois da primeira revisão. Os dois números caem quando o modo plano é obrigatório. Os dois números permanecem altos quando o time pula o modo plano e reage a diffs.

A segunda falha é tratar o modo plano como atrito opcional. É opcional do mesmo jeito que usar cinto de segurança é opcional. O custo é pequeno. A perda esperada na pequena fração de casos em que o plano estava errado é enorme. Times aprendem isso depois da primeira vez que um agente refatorou com confiança o arquivo errado em escala de produção.

Faça Isso Agora

Escolha um repositório esta semana. Estabeleça a regra: toda mudança feita com agente de código passa pelo modo plano. O humano aprova o plano antes de qualquer arquivo ser editado. O plano vai na descrição do PR para que o revisor veja o que foi proposto e o que foi entregue.

Adicione um Claude.md ao repositório se ainda não houver. Coloque três coisas: o comando de teste, o comando de lint e as três correções que o time precisou repetir nas últimas quatro semanas. Atualize toda sexta-feira.

Crie um subagente revisor de código para a etapa de commit. Antes do commit, o revisor lê o diff contra o plano e sinaliza desvios. O humano segue dono do merge. O revisor é um segundo par de olhos barato que roda sempre, e não nas vezes em que alguém lembra de pedir.

Duas semanas depois, conte o retrabalho. Compare com o mês anterior. O número que cair é o número que decide se o time consegue escalar desenvolvimento assistido por agente sem escalar o custo de consertar o que o agente já escreveu.

Fontes

Anthropic. “The Explore → Plan → Code → Commit workflow in Claude Code.” Maio de 2026.
Anthropic Docs. “Claude Code overview.” 2026.
Anthropic Docs. “Claude Code sub-agents.” 2026.

A Victorino ajuda times de engenharia a adotarem fluxos nativos para agentes sem perder a disciplina de revisão: contato@victorino.com.br | www.victorino.com.br

Três Sinais em Sete Dias: Custo de IA Cruzou a Linha da Engenharia

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

Três fontes, uma semana, a mesma verdade operacional. O CTO de uma SaaS pública, um analista de mercado construindo modelo de economia unitária, e um engenheiro publicando uma fórmula de guardanapo, todos saíram em sete dias. Nenhum dos três estava coordenado. Os três chegaram à mesma conclusão. Economia de tokens deixou de ser linha de orçamento da engenharia. Virou disciplina de governança de conselho, e as empresas que construíram fluxos sobre subsídios dos laboratórios têm exposição não orçada que o próximo IPO vai expor.

Já escrevi sobre o fim do preço plano, sobre os arquétipos em que os engenheiros caem, e sobre o postmortem dos preços de abril. Esta semana é diferente. O padrão se comprimiu. Três sinais independentes empilharam em uma única semana, e a convergência é a notícia.

Sinal um: o CTO admite o quebra-cabeça

Jon Hyman, CTO da Braze, sentou com o podcast Leaders of Code, do Stack Overflow, em 13 de maio. A Braze entrega código gerado por IA em escala: mais de 60% do código comitado já é escrito por IA. Ele contou ao apresentador que um engenheiro gastou US$ 150 em inferência em um único dia, projetando perto de US$ 4.500 por mês se mantivesse o ritmo. Não é caso isolado. É a nova mediana para um engenheiro sênior usando as ferramentas como as ferramentas pedem para serem usadas.

Em seguida ele soltou a frase que devia fazer todo CFO parar e reler. “Mesmo que eu deixe todo mundo 20% mais produtivo, não está claro como isso vai se traduzir em fazer a Braze crescer 20% mais rápido.”

Um CTO de empresa pública, no microfone, dizendo a uma audiência de desenvolvedores que não consegue modelar a conversão entre gasto em token e crescimento de receita. Essa é a versão honesta da história que todo operador está vivendo. A produtividade é real. O ganho de receita ainda não é legível. A conta, porém, está totalmente legível, e está subindo.

Sinal dois: o analista publica a conta

Dois dias antes, o State of Brand publicou um modelo com números que detonam a premissa de assinatura. Usuários da Anthropic consomem até US$ 8 em computação para cada US$ 1 de receita de assinatura. A Microsoft estaria perdendo US$ 20 ou mais por usuário por mês em assinaturas Copilot de US$ 10. Usuários pesados custam para a Microsoft até US$ 80 por mês contra os mesmos US$ 10. Um time de 50 pessoas pagando US$ 1.000 por mês em assentos Claude Pro consome entre US$ 15.000 e US$ 40.000 por mês em tokens reais. A OpenAI caminha para US$ 115 bilhões em queima de caixa acumulada até 2029 e US$ 665 bilhões em gasto de computação comprometido até 2030.

Some a migração do GitHub para faturamento por uso do Copilot em 1º de junho, e o quadro se completa. Os laboratórios estão executando uma retirada coordenada do preço subsidiado. A retirada não está sincronizada, mas a direção está. Todo contrato corporativo assinado contra um SKU de Copilot por assento é agora um contrato contra uma unidade que vai ser medida, reprecificada, ou as duas coisas, antes do próximo ciclo de renovação.

A contribuição do analista é o modelo. A contribuição do CTO é a confissão de que mesmo com as ferramentas funcionando, o lado da receita ainda não acompanha. Duas metades da mesma equação, publicadas com 48 horas de diferença, por gente que não se conhece.

Sinal três: o engenheiro deriva a fórmula

Em 17 de maio, Ryan Skidmore publicou a matemática debaixo da matemática. O artigo dele sobre o cache de prompt do Claude mostrou que o ponto de equilíbrio entre pagar por escritas de cache e leituras de cache é governado por uma razão simples: T = 5 × (W/R), onde W é o multiplicador de custo de escrita (1,25) e R é o multiplicador de leitura (0,10). A aritmética resolve em 62,5 minutos. Se o intervalo de refresh do seu cache for menor que 62,5 minutos, você está pagando mais em escritas do que economiza em leituras. Se for maior, o cache se paga.

O ponto não é o número. O ponto é que o número independe do modelo. A regra de 62,5 minutos não muda quando a Anthropic lança um modelo novo, desde que a razão W/R fique em 12,5. É uma constante estrutural da arquitetura de preço, não característica do release atual.

Isso importa porque o tokenizador do Opus 4.7 já usa até 35% mais tokens que o 4.6 para o mesmo input. Um fluxo que cabia confortavelmente no cache no trimestre passado pode não caber neste trimestre. A regra de 62,5 minutos é a única ferramenta que sobrevive à troca de tokenizador. Quem está modelando gasto de tokens sem essa constante está modelando alvo móvel com régua parada.

A convergência

Um CTO que consegue medir produtividade, mas ainda não receita. Um analista que prova que preço de assinatura é máquina de prejuízo de US$ 7 para cada US$ 1 faturado. Um engenheiro que deriva uma constante de 62,5 minutos que sobrevive a releases. Cada peça, isolada, é uma observação afiada. Empilhadas, descrevem uma estrutura de mercado.

Os labs passaram dois anos precificando IA como instrumento de marketing. Os níveis de assinatura eram investimento em ecossistema, não economia unitária. A conta ficava no balanço do laboratório, e o cliente pagava um número que não tinha relação com o custo de servi-lo. Esse arranjo funcionava enquanto os labs eram privados, capital era barato, e a trajetória de receita importava mais que a de custo.

Esse arranjo quebra no instante em que os labs precisam mostrar um caminho público para a lucratividade. A projeção de US$ 115 bilhões de queima da OpenAI é o muro. O muro tem data. Os labs agora precificam em direção a ele, não para longe, e os ajustes de preço deixaram de ser decisão de marketing. São decisão de governança, tomadas sob pressão de calendário de IPO.

O que mudou nesta semana, especificamente

Duas coisas. Primeiro, a conta saiu por escrito. Até o State of Brand colocar no papel, a razão de US$ 8 para US$ 1 era reivindicação não provada. Agora é modelo público que o lado comprador pode usar em renegociação. Segundo, um CTO de empresa pública falou em voz alta. Hyman não é gente conversando com audiência de nicho. Ele toca engenharia na Braze. Quando diz ao Stack Overflow que o modelo de receita para produtividade assistida por IA é incerto, todo CFO que assistiu àquela entrevista agora tem citação para a conversa que já estava tendo.

Confissão mais modelo mais constante. Três fontes, três papéis, uma tese. Esse é o tipo de semana que fecha um capítulo e abre o próximo.

Faça isso agora

Coloque a regra de 62,5 minutos no seu dashboard de custo de IA. Não como métrica para acompanhar. Como alarme. Se o intervalo de refresh do cache do seu time cair abaixo de 62,5 minutos em qualquer fluxo, você está pagando uma penalidade escondida de 12,5x por chamada até alguém arrumar. A matemática independe do modelo, o que significa que o alarme sobrevive aos próximos quatro releases. A maioria dos dashboards corporativos de custo de IA ainda não mede isso. A maioria continua lendo números fornecidos pelo vendor e reportando como verdade. Os vendors não vão colocar esse alarme nos próprios dashboards, porque o alarme reduz o quanto você gasta.

O segundo movimento é o que eu repito. Pare de precificar IA na cadência do seu ano fiscal. Comece a precificar na cadência em que os labs operam, que é semanal. Os três sinais desta semana não são exceção. São a nova média. Um plano de procurement que não absorve três sinais independentes de preço por semana é um plano que vai estar errado na segunda renovação.

O terceiro movimento é governança. Gasto de tokens é agora pauta de conselho. Não porque os números são grandes, embora sejam. Porque a estrutura da conta está mudando mais rápido que a estrutura da empresa. Conselhos existem para enxergar esse tipo de descompasso. Se o seu conselho ainda não viu um briefing de economia de tokens, o próximo já está atrasado.

Fontes

Stack Overflow Blog. “How Braze’s CTO Is Rethinking Engineering for the Agentic Era.” Maio de 2026.
State of Brand. “Every AI Subscription Is a Ticking Time Bomb for Enterprise.” Maio de 2026.
Ryan Skidmore. “Tokenomics: The 62.5-Minute Rule for Claude’s Cache.” Maio de 2026.

A Victorino ajuda empresas a operacionalizar governança de custo de tokens antes do próximo reajuste atingir o P&L: contato@victorino.com.br | www.victorino.com.br

Engenharia de Harness é Subtração: a Própria Anthropic Mostra o Andaime Encolhendo

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

Em março de 2026 escrevemos sobre o harness gerador-avaliador da Anthropic, com seus contratos de sprint, resets de contexto e o padrão de três papéis. Aquele texto é leitura obrigatória antes deste: Loops Gerador-Avaliador. O que vem a seguir assume que você já leu.

Em maio de 2026, no AI Engineer Conference, Ash Prabaker e Andrew Wilson, do time de IA aplicada da Anthropic, mostraram como o mesmo harness ficou dois meses depois. A manchete não é o que eles adicionaram. É o que eles removeram.

Entre o Opus 4.5 e o Opus 4.6, três peças do próprio harness deles foram deletadas. A decomposição forçada em sprints, fora. As janelas de contexto novas a cada sprint, fora. As rodadas de avaliador por sprint, fora. O agente de horas seguidas não regrediu. Pelo benchmark interno deles, no estilo METR, o Sonnet 3.7 em fevereiro de 2025 sustentava cerca de uma hora de trabalho coerente de agente sob um harness mínimo. O Opus 4.6, no início de 2026, sustenta cerca de doze horas sob a mesma linha de base mínima. Doze vezes o tempo de execução, com menos peças móveis no andaime.

É essa a disciplina deste texto. Engenharia de harness é subtração. A maioria dos times ainda está somando.

A Curva que o Modelo Está Subindo

A forma da curva importa antes das deleções fazerem sentido. Wilson apresentou a linha do tempo como uma sequência de lançamentos pareados, em que cada modelo novo veio acompanhado de uma primitiva de harness que o modelo anterior não conseguiria sustentar.

O Sonnet 3.5 trouxe artifacts e computer use. O Sonnet 3.7 trouxe o Claude Code em research preview. O Opus 4 e o Sonnet 4 transformaram o Claude Code em produto de disponibilidade geral, com SDK. O Sonnet 4.5 adicionou consciência de janela de contexto, o Claude Code 2.0 lançou com checkpoints e o SDK foi renomeado para Agent SDK. O Opus 4.5 introduziu orquestração com muitos sub-agentes, posicionado como modelo de planejamento. O Haiku 4.5 fez par com o Opus 4.5 para viabilizar economicamente rodadas com vários sub-agentes. O Opus 4.6 e o Sonnet 4.6 trouxeram compactação no lado do servidor, contexto de 1 milhão de tokens em disponibilidade geral e a primitiva de times de agentes.

Cada passo fez duas coisas. Tornou o modelo mais capaz de manter estado e intenção em horizontes mais longos. E moveu capacidades que antes viviam no harness para dentro do modelo ou da plataforma.

Esse segundo movimento é o que muda a forma de construir. Quando a compactação no servidor cuida da manutenção do contexto, seu harness deixa de precisar agendar resets de contexto. Quando o modelo aguenta builds contínuos de duas horas sem perder o fio, seu planejador deixa de precisar forçar uma decomposição em sprints que existia só para impedir o modelo de derivar. O andaime era estrutural para um modelo anterior. Agora ele atrapalha.

O que a Anthropic Deletou, e por quê

Prabaker foi específico sobre quais peças do harness de março não sobreviveram em maio.

A primeira deleção foi a decomposição forçada em sprints. No design gerador-avaliador original, o planejador quebrava o trabalho em sprints delimitados porque o gerador não conseguia manter coerência ao longo de um arco mais longo. O Opus 4.6 consegue. O time agora permite builds contínuos de duas horas ou mais, sem cortar artificialmente a sessão de trabalho do modelo em pedaços.

A segunda deleção foi o padrão de contexto fresco por sprint. O harness original arquivava o contexto acumulado em cada fronteira de sprint e reiniciava o gerador com uma janela limpa mais o contrato do sprint. A compactação no lado do servidor, que chegou com a geração 4.6, faz o trabalho equivalente sem exigir que o harness o dirija. O código de orquestração que gerenciava esses resets desapareceu.

A terceira deleção foi a rodada de avaliador por sprint. Em março, o avaliador rodava a cada fronteira de sprint, validando contra o contrato do sprint antes do gerador ter permissão para seguir. O harness atual roda o avaliador uma vez só, ao final de uma geração em uma única etapa. O gerador produz um artefato completo contra um contrato negociado. O avaliador pontua uma vez.

Cada uma dessas deleções removeu código, removeu custo, removeu complexidade de orquestração e não regrediu qualidade. É esse o teste para qualquer primitiva de harness. Se o modelo mais recente consegue absorver o trabalho do andaime, o andaime ganhou o direito de sair.

O que Sobreviveu, e o que Isso Diz

Três primitivas não foram deletadas. São as que vale entender, porque a ausência da deleção é em si um sinal.

A separação de papéis entre planejador, gerador e avaliador continua de pé. É um padrão crítico-revisor com contratos de papel explícitos, não a analogia com GAN que o texto anterior já corrigiu. Os papéis persistem porque persiste o viés de qualquer modelo ao avaliar a própria saída. Um modelo avaliando o próprio trabalho continua a ignorar as mesmas categorias de erro que produziram esse trabalho. O remédio é separação estrutural, não auto-reflexão melhor.

O sistema de arquivos como estado compartilhado sobreviveu. Agentes leem e escrevem em disco. Disco é o protocolo. O time não migrou para uma abstração mais rica de passagem de estado, e o motivo é o mesmo pelo qual sistemas de arquivos vencem armazenamentos customizados na maioria dos contextos de engenharia. Dá para listar, dá para fazer grep, dá para auditar e dá para passar por qualquer outra ferramenta. A primitiva de harness que vence costuma ser a que impõe o menor vocabulário novo.

A negociação de contrato entre gerador e avaliador sobreviveu. No exemplo Retro Forge, o contrato tinha 27 critérios explícitos, a execução custou cerca de 200 dólares e durou seis horas. O contrato foi negociado antes de qualquer código ser gerado. Esse é o artefato que carrega o peso. O contrato é contra o que o gerador constrói e contra o que o avaliador pontua. Sem ele, voltamos ao “achismo”.

Há uma primitiva mais silenciosa que também sobreviveu e merece um parágrafo próprio. O avaliador usa uma rubrica explícita para pontuar qualidades subjetivas. O exemplo da Anthropic usa uma rubrica de quatro eixos: design, originalidade, acabamento e funcionalidade. A rubrica é calibrada contra sites de referência. Subjetivo não quer dizer impontuável. Quer dizer que o esquema de pontuação precisa ser explícito e externo. A rubrica é o objeto que carrega o peso, não o gosto do modelo.

O Loop de Depuração que Ninguém Quer Ouvir

Prabaker disse no palco algo que contraria boa parte da literatura sobre observabilidade de agentes. O principal loop de depuração de quem constrói o harness é ler traços de agente à mão.

Não dashboards. Não pipelines automáticas de análise de traço. Não juízes LLM pontuando as próprias rodadas. Uma pessoa senta, abre o traço e lê o que o agente fez e por quê. O time rejeitou explicitamente a ideia de que a análise totalmente automatizada de traços fosse o loop principal, porque sistemas automatizados têm o mesmo viés dos agentes que pontuam. Eles ignoram as mesmas coisas.

O conselho é desconfortável porque não escala de forma linear. Não dá para contratar cem leitores de traço e chamar isso de produção. Dizer em voz alta serve para alinhar a expectativa. Traços são como se entende o sistema. Dá para construir telemetria em cima da leitura de traços, mas não dá para pular essa leitura. Times que tentam pular direto para a sumarização automatizada de traços terminam com um dashboard confiante sentado em cima de um sistema mal entendido.

A implicação prática para a liderança de engenharia é simples. Reserve orçamento para um pequeno número de leitores de traço em todo time que opera agentes de longa duração em produção. Pessoas sêniores. Como parte da rotação de on-call. O traço é a verdade, e alguém precisa continuar lendo.

A Disciplina da Subtração

A tese deste texto cabe em uma frase. Toda primitiva de harness que você lança tem prazo de validade, e seu trabalho como engenheiro de harness é deletá-la antes que ela vire imposto sobre a próxima geração do modelo.

A maioria dos times não opera assim. Eles somam. O harness ganha novas camadas de orquestração, novos papéis de sub-agente, novos middlewares de moldagem de contexto, e essas adições ficam para sempre. O time que escreveu reluta em remover porque foi quem lançou, porque o runbook de on-call referencia, porque os testes de regressão passam com as peças no lugar. Enquanto isso, o modelo absorveu metade do que elas fazem.

O time da Anthropic tem permissão organizacional para deletar o próprio código porque a deleção faz parte de como eles avaliam o próprio harness. Essa permissão não é exótica. Qualquer time de plataforma pode conceder. O mecanismo é uma auditoria trimestral. A cada trimestre, pegue o harness atual, liste cada primitiva e pergunte se o modelo atual ainda precisa dela. Se a resposta for “não” ou “não tenho certeza”, rode o harness sem essa primitiva no seu conjunto de benchmarks e compare. Se a qualidade se mantém, a primitiva sai.

A auditoria é o loop. O modelo melhora; o harness encolhe; a auditoria captura o que o modelo absorveu; o harness reduzido libera atenção de engenharia para a próxima tarefa de fronteira que precisa de andaime novo. O investimento total em engenharia de harness não diminui, mas a localização desse investimento se move com a fronteira.

Faça Isso Agora

Escolha o harness em torno de um agente em produção do seu stack. Abra o código de orquestração. Encontre uma primitiva que era estrutural quando você escreveu: um reset de contexto, uma decomposição forçada, um portão de avaliador, um passo de planejador que o modelo atual provavelmente conseguiria pular.

Rode sua suíte de avaliação com essa primitiva removida. Se a qualidade se mantém, delete. Mantenha a deleção em um commit separado, para reverter caso uma regressão futura apareça. Faça isso uma vez por trimestre para cada agente de longa duração que você opera.

Se a deleção regride a qualidade, você aprendeu algo útil: aquela primitiva ainda é estrutural para a sua carga de trabalho específica, e a próxima geração do modelo é onde ela vai ganhar o direito de sair. Marque, observe e re-audite quando a próxima versão grande do modelo chegar.

É essa a disciplina. Adicione quando a tarefa de fronteira exigir. Delete quando o modelo tiver absorvido. O harness que faz o próprio trabalho corretamente é sempre menor no trimestre seguinte do que era neste.

Fontes

Ash Prabaker e Andrew Wilson, Anthropic. “Build Agents That Run for Hours.” AI Engineer Conference, Maio de 2026.
Anthropic Engineering. “How we built our multi-agent research system.” 2025.
AI Engineer. “AI Engineer Conference.” Maio de 2026.

A Victorino ajuda times de engenharia a auditar o harness em busca de andaimes que o modelo mais novo já absorveu: contato@victorino.com.br | www.victorino.com.br

Figma Quantificou o Ponto de Virada da Adoção de IA em Design

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

Sessenta por cento dos clientes da Figma acima de US$ 100 mil em ARR usaram Figma Make semanalmente no Q1 de 2026. No trimestre anterior, esse número era 50%. Dez pontos em três meses, dentro da faixa de clientes que mais paga, em um recurso que não existia dezoito meses atrás.

Esse é o número que importa. Não os US$ 333,4 milhões de receita. Não os 46% de crescimento ano a ano. A taxa de uso semanal entre os clientes que pagam preço enterprise é o sinal que fecha uma discussão que muitos líderes de design vêm adiando.

Por que 60% importa

Uso semanal é uma métrica mais dura que uso mensal. Semanal significa que a ferramenta está no fluxo de trabalho, não na caixa de ferramentas. Quando 60% dos maiores clientes de um fornecedor tocam um recurso de IA toda semana, o recurso cruzou de “experimento” para “prática padrão” dentro daquelas organizações.

A trajetória é mais íngreme que o número absoluto. De 50% para 60% em um único trimestre, a curva continua acelerando. Quando a liderança decidir “olhar para IA em design no ano que vem”, a prática já estará incorporada nos times que reportam para ela. A pergunta sobre governar a saída de design gerada por IA estará respondida na prática. Será uma decisão retroativa.

Esse é o ponto empírico. Não é um exercício mental. Não é previsão de palestrante. É a própria base de clientes da Figma, em chamada pública de resultados, toda semana.

O sinal de preço dentro do sinal de preço

A Figma reportou outro dado que merece leitura atenta. Times pro que compram créditos de IA têm ARR médio 3x maior do que times que não compram. Setenta e cinco por cento dos usuários de planos org e enterprise continuaram comprando créditos depois de bater o limite. Noventa e cinco por cento permaneceram ativos depois desse ponto.

Junte os números. Os times que compram créditos de IA não estão apenas gastando mais com IA. Eles gastam mais com Figma, ponto. Consumo de IA está correlacionado com expansão de conta como um todo. Os clientes que abraçam os recursos de IA viram os clientes que ancoram a receita da Figma.

Isso valida um padrão que aparece em toda a categoria. A Fin Operator precificou IA por resultado. A Braze reestruturou sua base de custo em torno de compute de IA. A Figma trata IA como um tier de consumo separado que puxa o resto da relação comercial. IA não é um recurso adicionado à assinatura. É um tier que redesenha a assinatura.

Para líderes de design, a implicação é operacional. Se o seu time está em contrato org ou enterprise da Figma, vocês estão dentro de um modelo de precificação que recompensa uso de IA e penaliza contenção. Conter o uso não será neutro em custo. Será a escolha mais cara em doze meses.

O que o crescimento de MCP diz sobre a direção

O uso de servidores MCP cresceu 5x trimestre a trimestre. Isso é tráfego de agentes. Agentes de código, agentes de design, fluxos integrados a IDE puxando contexto de design pelo Model Context Protocol que a Figma abriu em março.

Argumentamos em março que o beta de MCP da Figma transformou design systems em camadas de restrição em tempo de execução para software autônomo. O crescimento de 5x confirma que a direção é real, não teórica. Agentes estão acessando arquivos de design em volume de produção. A camada de restrição agora sustenta carga.

Se o seu design system cobre 60% dos padrões de UI do seu produto, agentes vão improvisar os outros 40%. Improvisação com 5x de crescimento trimestral vira problema de governança rápido.

O que os números não dizem

Os resultados da Figma mostram que a adoção está acontecendo. Não mostram que a qualidade está. Um usuário ativo semanal pode estar produzindo design utilizável ou lutando contra geração sem restrição. Um uplift de 3x em ARR vindo de compradores de crédito de IA pode refletir expansão produtiva ou consumo descontrolado. O deck de resultados premia os dois cenários igualmente.

É aqui que o ponto empírico corta nos dois lados. Adoção não é mais a pergunta. Qualidade e governança são. Clientes que chegaram a 60% de uso semanal sem postura de governança não resolveram o problema. Trocaram qual problema têm.

As empresas que vão compor sobre essa curva são as que tratam o design system como superfície de controle para saída gerada por IA. As empresas que vão compor sobre custo de retrabalho são as que tratam o sistema como decoração.

O que fazer neste trimestre

Para líderes de design dentro de organizações em contrato org ou enterprise da Figma, três ações deixaram de ser opcionais.

Audite a cobertura do seu design system contra os padrões reais de UI do seu produto. Cobertura abaixo de 70% significa que agentes vão inventar componentes. Essa invenção não será revisada antes. Será revisada em produção.

Defina quais artefatos de design gerados por IA exigem aprovação humana antes de chegar à engenharia. O padrão deveria ser “todos” até você ter dado empírico para relaxar a regra. Designers são engenheiros de governança agora, com ou sem atualização no cargo.

Trate consumo de crédito de IA como linha de orçamento com dono nomeado. O modelo de precificação é por consumo. Sem dono, consumo vira custo ambiente. Com dono, vira insumo gerenciado.

A mudança mais ampla de produto para fluxo está aparecendo primeiro em ferramentas de design porque é onde a saída de IA é mais visível. A mesma lógica de precificação vai alcançar todas as outras categorias que o seu time usa. Os resultados da Figma são a leitura antecipada.

O ponto fecha a pergunta de timing

Um líder de design que ainda debate se governança de IA é “problema do ano que vem” agora pode responder com dado público, não opinião. Sessenta por cento da base enterprise da Figma usa ferramentas de design com IA toda semana. Cinco vezes mais agentes leem arquivos de design do que no trimestre passado. Consumo de IA está correlacionado com expansão de conta em 3x.

Se a sua organização de design está no lado consumidor dessa curva e não tem postura de governança, a curva está governando vocês. O ponto empírico chegou. Agir sobre ele é o trabalho.

Fontes

SiliconANGLE. “Figma Stock Jumps After Q1 Revenue Surges 46%.” Maio de 2026.

A Victorino ajuda líderes de design e produto a operacionalizar governança de IA antes que o uso semanal force a conversa: contato@victorino.com.br | www.victorino.com.br

Marketing e Finanças Acabaram de Receber Seus Primeiros Problemas Reais de Governança de Agentes

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

Por dois anos a conversa de governança morou dentro da engenharia. Menor privilégio, observabilidade, segregação de funções, logs de auditoria, protocolos de escalonamento. Foram as disciplinas que construímos para impedir que o código machucasse o negócio. Na semana passada três relatos chegaram em poucos dias, e cada um carregava a mesma arquitetura vestindo uniforme diferente.

Uma plataforma de marketing entregou ao Claude e ao ChatGPT acesso a contas de anúncio numa granularidade que viola menor privilégio. Um time de finanças automatizou 90% de uma reconciliação preservando a divisão preparador/revisor como portão de auditoria. O Google estendeu experimentação estruturada para Performance Max e AI Max, transformando testes controlados na única alavanca de observabilidade que o anunciante mantém sobre a caixa-preta.

Três domínios. Três vocabulários diferentes. Um padrão.

AI Connectors da Meta: menor privilégio falha na fronteira da agência

Jon Loomer fez o teste que ninguém do lado do fornecedor quis publicar. Ele conectou o Claude ao Meta através do novo AI Connector, o recurso que a Meta lançou para permitir que grandes modelos de linguagem puxem dados de performance e respondam perguntas em linguagem natural sobre campanhas. O caso de uso para agências é óbvio. Auditar uma conta de cliente, resumir performance, redigir uma recomendação.

O resultado, não. Quando Loomer autorizou a conexão, o Meta ofereceu exatamente duas opções: dar acesso a um negócio específico, ou dar acesso a todos os negócios atuais e futuros vinculados à conta dele. Não existe seletor de conta de anúncio. Não existe escolha de cliente. Não existe escopo granular de permissão.

Nas palavras do próprio Loomer: “Você não pode escolher quais contas de anúncio o Claude pode acessar. E isso pode resultar em uma exposição a risco que você ou seus clientes não querem.”

Traduza para termos de engenharia. Uma agência gerencia 40 clientes em 12 negócios. O dono da agência conecta o Claude uma vez para analisar a própria marca. Por design, o Claude agora tem acesso de leitura a toda conta de cliente sob todo negócio que o dono enxerga. O modelo de permissão tem dois estados: nada, ou tudo. Não existe meio.

Esta é a falha clássica de menor privilégio. Uma identidade deve receber o mínimo de acesso necessário para a tarefa. O conector embarca acesso máximo como única opção. Qualquer engenheiro auditando uma política IAM que dissesse “conceder todos os buckets S3 atuais e futuros desta conta” bloquearia no code review. A Meta embarcou o equivalente para verba de anúncio e dados de audiência.

A parte interessante é quem precisa resolver. A agência não consegue corrigir o modelo de permissão da Meta. Pode recusar o conector, aceitar a exposição, ou criar uma unidade de negócio Meta separada por cliente só para escopar o agente. Nenhuma dessas é solução de governança. São contornos para um fornecedor que entregou a capacidade sem os controles.

OnlyCFO: segregação de funções sobrevive a 90% de automação

Na mesma semana, um líder de finanças anônimo escrevendo como OnlyCFO publicou um relato detalhado de implantação de agente para o fechamento mensal. Reconciliação de despesas antecipadas que levava duas horas caiu para cerca de cinco minutos. Um dia inteiro removido do cronograma de fechamento. Cerca de 90% do fluxo roda agora através do Claude com skills customizadas, cada skill documentada em torno de 200 linhas de instruções explícitas.

O número que importa não é 90%. É 10%.

A OnlyCFO não eliminou o revisor. O agente prepara a reconciliação. Um revisor humano aprova. A divisão preparador/revisor, o padrão mais antigo de segregação de funções na contabilidade, sobreviveu intacta. O agente não substituiu o revisor. Substituiu o tédio do preparador, e entregou o artefato ao revisor no mesmo checkpoint que existia antes.

Releia. Um time de finanças rodando com agentes de IA reproduziu o portão de auditoria sem dar nome a ele. Documentaram cada skill em 200 linhas porque precisam ser capazes de explicar a um auditor, seis meses depois, o que o agente foi instruído a fazer no dia em que gerou o lançamento contábil. Isso não é engenharia de produtividade. É documentação de procedimento, do tipo que sobrevive a uma revisão SOX.

Compare com o conector da Meta. A montagem da OnlyCFO tem escopo explícito por skill (uma skill por workflow), checkpoints humanos explícitos (aprovação do revisor antes do lançamento), e instruções explícitas (as 200 linhas, versionadas e revisáveis). O conector da Meta não tem nenhum desses. Mesma semana, mesma tecnologia de agente, postura de governança oposta.

Google Ads v24.1: experimentos como única superfície de observabilidade

Performance Max e AI Max são caixas-pretas por design. Você dá ao Google um orçamento, um objetivo, e ativos de criativo. O Google decide quais audiências veem o quê, quando, em qual propriedade, com qual variação de criativo. O anunciante entrega as alavancas e confia no modelo.

As notas de release de 15 de maio da ALM Corp documentam o que o Google fez em seguida. A versão 24.1 estende suporte estruturado de experimentos para campanhas AI Max, Video, Demand Gen e Performance Max. Três fluxos: experimentos gerenciados pelo sistema, experimentos intra-campanha, e experimentos de otimização de ativos. Duração recomendada de quatro a seis semanas por experimento para atingir significância estatística.

O enquadramento da ALM Corp é mais afiado que o marketing do próprio Google: “Automação sem medição cria pontos cegos. Automação com experimentos cria um arcabouço de decisão usável.”

Traduza de novo. Performance Max removeu as alavancas. O sistema de experimentos é a admissão do Google de que automação sem medição controlada é automação sem prestação de contas. O anunciante não recupera as alavancas. Recebe uma forma estruturada de perguntar ao sistema “e se eu mantivesse uma variável constante e deixasse você otimizar o resto?”. Isso é observabilidade para sistemas que você não pode inspecionar diretamente. Roda um holdout. Compara. Decide.

Times de engenharia construíram canary releases e feature flags pelo mesmo motivo. Quando você não consegue raciocinar sobre o estado interno do sistema, você controla as entradas e mede as saídas. O Google não chamou de observabilidade. O time de contabilidade não chamou de segregação de funções. A Meta não chamou de escopo IAM. O vocabulário é diferente. A arquitetura é idêntica.

A leitura honesta

A história conveniente é que marketing e finanças finalmente alcançaram a engenharia. Essa leitura está errada, e é condescendente.

O que está acontecendo de fato: todo domínio que implanta sistemas autônomos esbarra no mesmo punhado de problemas arquiteturais. Em nome de quem o sistema pode agir? Como você confere o trabalho dele? Como você mede saídas quando não consegue inspecionar o processo? Essas perguntas não pertencem à engenharia. Engenharia encontrou primeiro porque implantou agentes primeiro. As perguntas pertencem a qualquer um que opere um fluxo autônomo.

O risco é tratar cada domínio como problema novo. Construir um arcabouço de governança de marketing. Construir um arcabouço de governança financeira. Construir um arcabouço de governança de anúncios. Quatro grupos de trabalho separados, quatro políticas, quatro modelos de escalonamento, nenhuma transferência de aprendizado. A maioria das empresas vai fazer exatamente isso, porque o organograma roteia por função, não por problema.

A alternativa é reconhecer a estrutura paralela e construir uma vez. As perguntas de controle transferem. O vocabulário precisa de tradução. A arquitetura não.

Faça isto agora

Se a sua organização implanta agentes em mais de uma função de negócio, rode esta auditoria nas próximas duas semanas.

Para cada agente em produção, responda três perguntas. Qual é o escopo mínimo que este agente precisa (menor privilégio)? Quem aprova a saída do agente antes que ela tenha consequência externa (segregação de funções)? Como você mede o efeito do agente quando não consegue inspecionar as decisões (observabilidade via experimentos controlados ou revisão humana)?

Se alguma função implantando agentes não consegue responder essas três perguntas, você não tem um problema de marketing nem um problema de finanças. Tem um problema de arquitetura em três lugares, três nomes, e uma forma única por baixo. Resolva como problema único.

Os times que traduzirem governança de engenharia para a linguagem do próprio domínio vão operar a tecnologia com confiança. Os times que esperarem cada função inventar a própria resposta vão pagar pela lição três vezes.

Fontes

OnlyCFO. “How I Built AI Agents to Close the Books.” Maio de 2026.
Jon Loomer Digital. “AI Connectors May Put Your Clients at Risk.” Maio de 2026.
ALM Corp. “Google Ads Expanded Experiment Support v24.1.” Maio de 2026.

A Victorino ajuda marketing, finanças e operações a adotar as disciplinas de governança de agentes que engenharia já aprendeu: contato@victorino.com.br | www.victorino.com.br

Plano Vence Hierarquia: Agentes Pares e a Informação Perdida no Padrão Orquestrador

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

A maior parte dos sistemas multiagente em produção hoje compartilha uma topologia tão familiar que ninguém mais questiona. Um agente-pai decompõe a tarefa. Sub-agentes executam as partes. Os resultados sobem. O pai monta a resposta. Esse é o padrão orquestrador-trabalhador, e ele tem sido o padrão desde os primeiros designs publicados de harness.

O padrão é importado, em bloco, das hierarquias corporativas. Herda o mesmo modo de falha. Em qualquer hierarquia, a informação mais precisa sobre o que está realmente acontecendo vive no nível do trabalhador. Hierarquias então soterram essa informação debaixo de sumarização, tradução e do modelo que o pai já trazia do problema. Quando uma descoberta chega ao ponto de decisão, já foi comprimida no formato que cabe nas expectativas do pai.

A demo Pi to Pi do IndyDevDan, lançada esta semana, mostra a alternativa. Roda em um socket Unix e um servidor Bun. Expõe quatro ferramentas: listar agentes, enviar comando, enviar prompt, aguardar resposta. Não há papel de orquestrador. Qualquer agente pode pingar qualquer outro agente. O repositório é público. É curto. Dá para ler.

O que a demo prova não é que peer-to-peer é mais elegante. É que peer-to-peer muda qual informação chega à decisão.

Demo 1: O Agente de Produção Vê o Que o Agente de Dev Não Pode Ver

A primeira demo roda dois agentes em máquinas diferentes. Um agente de produção em um Mac Mini tem acesso a dados ao vivo. Um agente de dev em um MacBook Pro tem acesso ao código e ao ambiente de staging. Eles reproduzem um bug de bloqueio de usuário no plano Pro.

Em um setup orquestrador-trabalhador, o agente de dev pediria ao pai o estado de produção. O pai pediria ao agente de produção. O agente de produção devolveria o que o pai perguntou, no formato que o pai esperava. PII passaria sem redação, ou então o pai precisaria conhecer o suficiente do schema de produção para fazer as perguntas redigidas certas.

No Pi-to-Pi, o agente de dev pinga o agente de produção diretamente. O agente de produção aplica a redação de PII na própria fronteira. O agente de dev nunca vê dados brutos de produção, mas vê a descrição que o agente de produção faz do estado do bug, nos termos do agente de produção. O bug apareceu em minutos.

Vale nomear a propriedade arquitetural aqui. A fronteira de confiança é o próprio agente, não um plano de controle entre agentes. O agente de produção é o redator porque o agente de produção é quem sabe o que redação significa no contexto dele. Um orquestrador central que tenta aplicar redação em domínios de dados heterogêneos precisa conhecer todos esses domínios. O modelo entre pares deixa cada agente aplicar a própria fronteira.

Demo 2: Dez Correções Que Teriam Ido para Produção Em Silêncio

A segunda demo é a que deveria mudar como times de engenharia pensam sobre janelas de contexto de agentes.

Dois agentes trabalham em paralelo. Um carrega a documentação completa do E2B em contexto. O outro carrega a documentação completa do exe.dev em contexto. A tarefa é construir uma skill com paridade de funcionalidade para um novo provedor de sandbox, usando a skill existente do E2B como template.

A troca entre pares dura dez mensagens. Nessas dez mensagens, o agente exe.dev corrige o agente E2B dez vezes. Dez erros factuais que o agente originador teria embutido na nova skill em silêncio. O loop de correção só disparou porque havia um segundo agente com autoridade e contexto para empurrar de volta. Não um trabalhador reportando achados na cadeia. Um par discordando de um par.

A informação que mais importava vivia na segunda janela de contexto. Um setup hierárquico com um único agente planejador no topo não teria trazido à tona nenhuma dessas dez correções. O planejador teria escrito a skill a partir de um resumo da documentação, não da documentação em si. Os erros factuais viveriam no resumo, não na consciência do planejador.

Dois Milhões de Tokens, Duas Janelas, Um Resultado Melhor

Outro achado discreto da segunda demo: o orçamento total de contexto entre os dois agentes ficou em cerca de dois milhões de tokens. O mesmo orçamento em um único agente teria produzido um resultado pior. Não pela capacidade bruta do modelo, mas porque a atenção se degrada à medida que o contexto cresce. Duas janelas focadas de um milhão de tokens cada superam uma janela diluída de dois milhões.

Esse é o argumento operacional para peer-to-peer. A especialização de contexto é o ativo de fato. O protocolo A2A de quatro ferramentas é o mecanismo. A topologia é o que permite que contextos especializados negociem diretamente, em vez de forçar os achados por uma camada de tradução.

O próprio sistema multiagente de pesquisa da Anthropic, publicado em 2025, era hierárquico. A publicação de março de 2026 sobre harness de aplicações de longa duração usava uma cadeia estrita de planejador, gerador e avaliador. Em maio de 2026, a palestra na AI Engineer Conference reportou simplificação dessa hierarquia. Menos papéis. Mais comportamento entre pares emergindo no nível do modelo. O fornecedor que praticamente inventou o padrão moderno de orquestrador está, em palco, recomendando menos dele.

As Implicações de Governança Não São as Que Você Espera

Topologia plana não é ganho de graça. Tem consequências que o time de plataforma precisa planejar.

A aplicação de fronteira migra para o agente. Em setups hierárquicos, o orquestrador é um ponto natural de estrangulamento para política. Quer aplicar residência de dados? Coloque a regra no orquestrador. Quer redigir PII? Mesmo lugar. No peer-to-peer, cada agente que detém um domínio sensível precisa aplicar a própria fronteira. Isso é mais difícil de desenhar e mais fácil de escalar. O agente de produção da Demo 1 é o lugar certo para redigir dados de produção. O orquestrador nunca foi.

A auditoria sai de um traço único para um grafo. Uma execução hierárquica produz um log de auditoria linear: pai chamou filho, filho retornou, pai chamou o próximo filho. Uma execução entre pares produz um grafo direcionado. Sua stack de observabilidade precisa dar conta disso. Se você não consegue reconstruir quem disse o quê para quem, e em que ordem, você não depura e não passa em revisão de compliance.

Detecção de loop vira problema da plataforma. Dois pares podem se pingar indefinidamente. Hierarquias têm um sinal natural de terminação: o agente raiz retorna. Peer-to-peer exige orçamentos explícitos, prazos e detecção de ciclo. O await_response do Pi-to-Pi é síncrono; força serialização, mas não limita o tamanho da conversa. Uma implantação em produção precisa adicionar esses limites.

A habilidade de escrever para pares substitui a habilidade de escrever para orquestradores. Agentes-trabalhadores são desenhados para satisfazer um pai. Agentes-pares precisam confrontar uns aos outros e aceitar serem confrontados. Engenharia de prompt para comportamento entre pares é uma disciplina diferente de engenharia de prompt para execução hierárquica. As dez correções da Demo 2 aconteceram porque ambos os agentes foram instruídos a empurrar de volta em afirmações factuais, não apenas responder a perguntas.

A Decisão de Topologia Precisa Ser Explícita

Os times que ainda tratam orquestrador-trabalhador como única opção estão, em geral, fazendo isso por inércia, não por análise. A pergunta deixou de ser se peer-to-peer funciona. A demo Pi-to-Pi provou isso com quatro ferramentas e um socket Unix. A pergunta é quais partes do seu sistema de agentes ganham com topologia plana, quais partes precisam de controle hierárquico, e como esses dois regimes fazem handoff um para o outro.

Já escrevemos sobre kernels multiagente, sobre orquestração em produção e sobre modelos operacionais em formato de time. O que a demo desta semana adiciona é uma prova limpa e executável de que a escolha de topologia é uma escolha de verdade, com efeitos mensuráveis no fluxo de informação, nas fronteiras de governança e no uso de contexto. A camada de harness é onde essa escolha é feita. Importa qual harness você escolhe.

Faça Isso Agora

Bloqueie 45 minutos com a liderança de engenharia e um designer sênior de agentes. Puxe o diagrama do fluxo multiagente mais complexo do time. Faça três perguntas.

Primeira: onde, nesse fluxo, a informação morre porque um resumo substitui um achado? Se você não consegue identificar nenhum ponto desses, não olhou o suficiente. Todo fluxo hierárquico tem um. Marque.

Segunda: das fronteiras que você aplica centralmente hoje (PII, residência de dados, limites de taxa, validação de schema), quais delas são aplicadas por um agente que não detém o domínio que está sendo protegido? Mova essas fronteiras para os agentes que detêm o domínio. Esse é o padrão entre pares mesmo dentro de um fluxo ainda hierárquico.

Terceira: escolha um nó no diagrama em que dois agentes poderiam discordar de maneira produtiva e hoje não conseguem. Dê a eles as ferramentas para se pingarem. Veja o que sai. O repositório Pi-to-Pi entrega um protocolo de quatro ferramentas que você pode copiar. A mudança que você procura não está na ferramenta. Está no que chega à decisão depois que os agentes podem conversar.

O padrão orquestrador-trabalhador não é errado. Mas não é a única escolha. Tratá-lo como padrão é como times perdem, em silêncio, o acesso à informação que os próprios agentes já têm.

Fontes

IndyDevDan. “Pi to Pi: Two-Way Agent Orchestration.” Maio de 2026.
disler. “pi-vs-claude-code repo.” Maio de 2026.
Ash Prabaker e Andrew Wilson, Anthropic. “Build Agents That Run for Hours.” AI Engineer Conference, Maio de 2026.
Anthropic Engineering. “How we built our multi-agent research system.” 2025.

A Victorino ajuda times de engenharia a escolherem entre topologias hierárquicas e planas para agentes, e a instrumentarem ambas para produção: contato@victorino.com.br | www.victorino.com.br

Quando os Testes de IA Passam e os Humanos Não: Três Falhas de Verificação, Um Padrão

Thiago Victorino — Mon, 18 May 2026 00:00:00 GMT

Daniel sentou para testar um site de marketing que tinha tirado 100% nas verificações automatizadas de acessibilidade. Em dez minutos, o site falhou com ele de formas que nenhum scanner conseguiria enxergar.

O site foi construído com Lovable, uma ferramenta de IA que se vende como produtora de output acessível por padrão. Hampus Sethfors, da Axess Lab, rodou o Axe, o verificador automatizado padrão da indústria. O painel mostrou pontuação perfeita. Em seguida, entregou a página para Daniel, um usuário real de leitor de tela. Daniel tentou abrir o menu e ouviu o anúncio: “toggle menu”. Nada mais. Sem estado. Sem “expandido” ou “fechado”. Ele disse a Sethfors: “Ainda diz toggle menu, não sei se funciona porque não anuncia se eu expandi alguma coisa.”

Essa é a falha de verificação número um. Três falhas com nome e sobrenome aterrissaram na mesma semana, em três formatos diferentes, com a mesma causa raiz embaixo. Cada uma vale ser entendida por si só. O padrão que elas formam vale mais ainda.

Lovable: 100% de Pontuação, Múltiplas Falhas Críticas

O teste da Axess Lab, publicado em 13 de maio de 2026, é a demonstração mais clara de um problema que a indústria vem rodeando há dois anos. Ferramentas automatizadas de acessibilidade só conseguem testar o que conseguem parsear. Verificam marcação, contraste, ordem de foco, presença de ARIA. Não conseguem verificar se um usuário de leitor de tela realmente consegue concluir uma tarefa na página.

O site do Lovable passou em todas as checagens automatizadas. Daniel, usando a tecnologia assistiva que a pontuação deveria prever, encontrou múltiplos bloqueadores críticos nos primeiros dez minutos. O botão de menu não anunciava estado. Campos de formulário careciam do contexto necessário para serem preenchidos. O carrossel era inutilizável sem navegação visual.

O diagnóstico não é que a IA do Lovable é ruim em acessibilidade. O diagnóstico é que “100% acessível” nunca foi uma propriedade que a IA pudesse entregar. Era uma propriedade de um julgamento humano que alguém substituiu por uma métrica. A pontuação é o contrato que a equipe achou que estava assinando. A experiência do usuário é o contrato que ela realmente assinou.

Bun: 6.755 Commits, Zero Revisores Humanos

Seis dias. 6.755 commits. Zero revisores humanos.

Esse é o número que Jiacai Liu extraiu do log de commits do repositório do Bun entre 8 e 14 de maio de 2026, analisando o reescrita em Rust que o projeto está conduzindo em escala industrial. O código é escrito pelo Claude. As revisões são escritas pelo Claude. As decisões de merge são tomadas pelo Claude. Nenhum humano participa do loop em commit nenhum.

Liu, que não tem relação com o Bun e analisou os dados como observador externo, resumiu a preocupação em uma frase: “Código que você não entende não deveria rodar em produção.”

A equipe do Bun presumivelmente argumentaria que a suíte de testes é a verificadora, que as métricas vão capturar regressões, que a escala de geração justifica a ausência de revisão humana. Esse argumento tem a mesma forma da pontuação de acessibilidade do Lovable. Ambos delegam julgamento humano a um sinal automatizado. Ambos assumem que o sinal captura o que importa.

O caso Lovable demonstra como essa premissa pode quebrar. Daniel não conseguiu abrir o menu, e a pontuação dizia que o site era perfeito. Se um leitor de tela expõe uma categoria de falha que o Axe não detecta, qual categoria de falha uma suíte de testes deixa passar em 6.755 commits de código Rust novo?

Ainda não sabemos. Vamos saber daqui a seis meses, quando o modo de falha chegar em produção e alguém tiver que depurar um sistema que nenhum engenheiro vivo leu por completo.

Aviator: A Verificação Funciona, Quando Você Fez a Especificação

O terceiro caso complica a história de um jeito útil. Ankit Jain, da Aviator, publicou em 17 de maio de 2026 um experimento rodando revisão baseada em especificação sobre 6.000 linhas de código gerado. A equipe extraiu 65 critérios de aceitação checáveis da especificação. Um agente revisor validou os 65 em aproximadamente seis minutos. O resultado: 60 passaram, 4 falharam, 1 parcial.

Isso é verificação que escala. Seis minutos de revisão automatizada, ancorada na especificação, substituíram o que seriam horas de revisão humana de PR. As quatro falhas foram capturadas. A parcial foi sinalizada. O trabalho seguiu adiante com a confiança que a verificação entregou.

Mas Jain escreveu a frase que deveria estar na parede de todo líder de engenharia: “Você não consegue escrever testes contra requisitos que não soube articular.”

Verificação baseada em especificação funciona apenas se alguém fez o trabalho cognitivo de escrever a especificação. Esse trabalho não pode ser delegado ao mesmo modelo que vai gerar o código. É o julgamento humano que converte intenção em afirmações checáveis. É também o trabalho que a maioria das equipes pula, porque parece lento e a IA parece rápida.

Frederick Vanbrabant modelou esse trade-off em um Gantt hipotético publicado em 15 de maio de 2026. Um projeto tradicional poderia parecer 70 dias de desenvolvimento mais 10 dias de escopo. Com IA, a fase de desenvolvimento desaba para cerca de 3 dias. O projeto total não encolhe, porque a fase de escopo e documentação expande para cerca de 40 dias. O gargalo se moveu. Não desapareceu.

O Padrão Por Trás

Três casos. Três formatos diferentes de verificação. Uma causa raiz.

O Lovable substituiu o usuário de leitor de tela pelo Axe. O Bun substituiu o revisor humano pelo Claude. A organização hipotética de Vanbrabant tentou substituir o escritor de especificação por quem quer que estivesse segurando o prompt no momento. Em todos os casos, uma categoria de julgamento humano foi delegada a um sistema que não conseguia sustentar essa responsabilidade.

A tese da dívida de verificação (coberta antes em A Dívida de Verificação e em O Imposto de Verificação da IA) tratava o problema como falha de medição: desenvolvedores não confiam no output da IA e não verificam sistematicamente, então código não revisado se acumula. Esses três casos estendem o diagnóstico. O problema não é só que a verificação é pulada. O problema é que a verificação está sendo feita contra um proxy que a equipe confundiu com a coisa real.

Uma pontuação de 100% em acessibilidade é proxy para “usuários cegos conseguem usar este site”. Uma suíte de testes passando é proxy para “o código novo faz o que o código antigo fazia”. A taxa de aprovação de um agente revisor é proxy para “este código corresponde ao que realmente quisemos construir”. Cada proxy tem um domínio de validade. Nenhum captura a propriedade completa que a equipe precisa.

O experimento da Aviator é instrutivo justamente porque revela o limite. Os 60 critérios aprovados não significam que o código está correto. Significam que o código satisfaz as 65 coisas que a equipe soube perguntar. O que a equipe não articulou, a verificação não captura. O agente revisor é honesto sobre seu escopo. O trabalho de especificação da equipe é o substrato que dá sentido à pontuação.

Para Onde o Trabalho Real Se Moveu

Se você aceita o modelo de Vanbrabant (o tempo de desenvolvimento colapsa, o tempo de escopo expande), as implicações para liderança de engenharia são diretas.

O gargalo do desenvolvimento assistido por IA não é mais velocidade de digitação. É velocidade de articulação. Quão rápido sua equipe traduz “precisamos de um fluxo de checkout que funcione para usuários de leitor de tela” em uma lista de critérios de aceitação checáveis que um agente revisor consiga validar? Quão rápido você converte “a nova porta em Rust deve preservar o comportamento da implementação atual em JavaScript” em uma suíte de testes baseada em propriedades que capture os casos que seu modelo gerador não vai capturar sozinho?

Esse trabalho é humano. Não é opcional. É a superfície que determina se a verificação que você delega à IA está de fato verificando o que importa ou apenas gerando painéis verdes.

O caso Lovable nomeia o modo de falha na sua forma mais nítida. Um usuário real, com uma tecnologia assistiva real, encontrou falhas reais, em tempo real, que nenhuma checagem automatizada jamais traria à superfície. O site tinha 100% de pontuação. Daniel não conseguiu usá-lo.

Se sua superfície de verificação se parece mais com a pontuação do Axe do que com dez minutos com o Daniel, você está acumulando o tipo de dívida que chega como um ticket de suporte, uma ação judicial de acessibilidade, ou uma falha em produção que ninguém na equipe atual consegue depurar.

Faça Isto Agora

Audite os últimos 30 dias do seu output assistido por IA contra uma pergunta: para cada portão de verificação que aprovou o envio, qual era a propriedade subjacente que aquele portão representava, e quão confiante você está de que o proxy captura essa propriedade?

Se seu código gerado por IA passa numa suíte de testes, nomeie três modos de falha que a suíte não cobre. Se sua UI construída por IA passa num scanner de acessibilidade, leve-a para um usuário real de leitor de tela ainda neste mês. Se seus commits gerados por IA fazem merge automático, escreva qual classe de regressão você está disposto a colocar em produção sem revisão humana, e qual classe não está, e torne essa linha explícita na automação de merge.

Três casos numa semana não é coincidência. É a indústria aprendendo, em público, que a superfície de verificação herdada da era pré-IA foi construída para uma taxa de geração de código que não se aplica mais. A nova taxa exige uma nova superfície. As equipes construindo essa superfície agora vão capitalizar a vantagem. As equipes confiando nos painéis verdes vão capitalizar a dívida.

Fontes

Axess Lab. “Lovable’s AI Built a 100% Accessible Site, Or Did It?.” Maio de 2026.
Jiacai Liu. “My Thoughts on Bun’s Rust Rewrite.” Maio de 2026.
Engineering Leadership Newsletter. “How to Avoid AI Code Slop.” Maio de 2026.
Frederick Vanbrabant. “I Don’t Think AI Will Make Your Processes Go Faster.” Maio de 2026.

A Victorino ajuda empresas a desenhar portões de verificação que protegem usuários reais, não dashboards verdes: contato@victorino.com.br | www.victorino.com.br