Precisão Antes de Recall: A Figma Publicou a Ordem Que Ninguém Adivinha

TV
Thiago Victorino
8 min de leitura
Precisão Antes de Recall: A Figma Publicou a Ordem Que Ninguém Adivinha

A primeira semana do agente de revisão de segurança da Figma produziu 27 achados. Quatro eram reais. “Only about 15% of findings (4 of 27) were valid”, escreve o time de segurança, e essa frase contém todo o problema de rollout. Um revisor com 15% de precisão tem um problema de confiança, e cada comentário ruim que ele publica gasta a atenção de outra pessoa.

O impulso nesse momento é recorrer ao histórico de bugs. Toda organização de engenharia madura tem um: relatórios de bug bounty, post-mortems de incidente, achados de auditoria, o corpus que diz se o agente pega o que os últimos três anos de atacantes encontraram. A Figma construiu exatamente esse corpus, 66 tarefas no total, e então disse a frase que vale citar: “the historical bugs you already have can only measure recall; they barely help with the precision you must fix first.”

Isso é aritmética. Um corpus de bugs conhecidamente reais não consegue produzir um falso positivo, porque todo item dentro dele é verdadeiro. Rode o agente contra ele e você aprende qual fração ele encontra. Sobre qual fração da saída é ruído, o corpus é silencioso, e o ruído é o que determina se os desenvolvedores continuam lendo.

Precisão Só Se Mede em Produção

A ordem adotada pela Figma decorre disso. Primeiro modo sombra, com achados visíveis apenas para o time de segurança. Depois rotular os falsos positivos à mão, a etapa que nenhum benchmark faz por você, porque um falso positivo é definido contra a sua base de código e o seu modelo de ameaças, e não contra uma noção geral de vulnerabilidade. Depois escrever a política. Só então liberar comentários visíveis no pull request, com portão: “We held back developer-facing PR comments until precision stayed above 70% over a two-week lookback, with no embarrassingly bad false positives.” A precisão chegou a 80% dentro de um mês. Somente depois disso a revisão virou requisito de merge.

Quatro elementos desse portão merecem cópia literal. Ele nomeia um número. Nomeia uma janela, o que impede uma semana de sorte de passar a barra. Adiciona um veto qualitativo para o achado tecnicamente defensável e socialmente catastrófico. E prende o portão a uma superfície específica, os comentários visíveis ao desenvolvedor, em vez de ao agente inteiro.

Essa última parte é a que a maioria dos rollouts achata. A Figma opera barras assimétricas por superfície: os hooks que guiam o agente “don’t carry a high precision bar, because they’re mostly invisible to the human author.” Um hook errado custa computação. Um comentário errado no PR custa credibilidade. Mesmo modelo, mesmos achados, limiares diferentes, porque a moeda gasta é outra. Um único hook de orientação derrubou uma classe de bug de segurança em logging em cerca de 50%.

A Política São Noventa e Nove Linhas de Precedente

O artefato que moveu a precisão é um documento, sem troca de modelo. “Ninety-nine lines, 2,560 words, and 68 precedents.” A palavra que trabalha ali é precedentes.

O formato tentador são regras. Não sinalize SQL injection em dbops. Uma linha assim faz o achado desaparecer e não ensina nada ao revisor, então a próxima variante do mesmo padrão volta. A Figma escreve a razão: “dbops is only run by highly privileged operators who already have direct database access.” Um revisor que sabe o porquê generaliza para o caso adjacente. Um revisor que só conhece a exceção fica parado nela.

E a contribuição da política é falsificável, o que é mais raro do que deveria ser em relatos desse tipo. Com a política zerada por ablação, o mesmo revisor limpou 44,4% do corpus em peso de payout. Com a política restaurada, 64,2%. É um delta medido sobre um documento que a maioria dos times classificaria como overhead. “The policy is the threat model”, escreve a Figma, e a ablação é o recibo.

Dois modelos rodam em paralelo por decisão de projeto, Claude Code com Opus 4.8 em esforço xhigh e Codex com GPT-5.6 Sol em esforço high, “because they miss different bugs. If either model surfaces a finding, we bubble it up.” União em vez de interseção, a escolha correta quando recall é a quantidade escassa e uma política já está suprimindo o ruído. O custo permanece sem drama: “a pull request review runs about $0.50 median spend, rarely more, since most PRs have nothing to flag.” A primeira varredura completa do monorepo trouxe “more than a hundred latent vulnerabilities, including two criticals missed by traditional SAST tools, which we patched immediately.”

A Figma também é honesta sobre o que o corpus prova. A taxa de captura em união é de 75,8%, e eles se recusam a arredondar isso para cobertura: “a 75.8% union catch rate is 75.8% of the bugs that got all the way past our existing controls.” O corpus é “a floor for the agent to clear rather than proof of coverage.” Das 66 tarefas, 46 vieram do programa HackerOne, 24 delas de um único pesquisador de topo, e 20 de incidentes e auditorias internas. Um benchmark moldado pelo gosto de um pesquisador mede esse gosto tanto quanto mede o agente.

A Vercel Pesa Recall em Dobro, e Está Certa

Publicado no mesmo mês, o DeepsecBench da Vercel pontua modelos com Score = 100 x 5PR/(4P+R), pesando recall duas vezes mais que precisão “because missed vulnerabilities will go unfixed, while false positives don’t make your codebase less secure.”

Lido ao lado da Figma, parece contradição direta. As duas posições são corretas, e o motivo que as reconcilia é o mesmo. O falso positivo de um benchmark é pago em computação e no tempo de um avaliador. O falso positivo de um comentário no PR é pago na confiança de um desenvolvedor, e confiança não se recarrega na próxima execução. A Vercel mede capacidade de modelo, onde subdetecção é a falha que importa. A Figma implanta dentro de um fluxo humano, onde sobredetecção é a falha que encerra o programa. A variável que decide a ordem é se a atenção de uma pessoa está sendo gasta em cada achado.

Os próprios números do benchmark sustentam a ponderação. O escopo é de 50 arquivos de entrada contra “a golden set of 231 human-judged findings”, rodado três vezes com a mediana publicada. O piso de dificuldade é brutal: “the best run finds 30.7%, and 20 of the 25 runs come in under 20%.” Quando o teto fica abaixo de um terço dos achados conhecidos, a restrição dominante do lado do modelo está em outro lugar. Contaminação é tratada retendo tudo: “We don’t disclose the repository, the commit, the files, or the findings, so there is nothing for models to train against.” Uma passada completa em produção extrapola para “roughly $1,200 for a Kimi K3 sweep, or over $5,000 for the top-scoring frontier model from OpenAI.”

Um detalhe de oferta pertence a qualquer conversa de compra: “Anthropic’s most capable model, Fable 5, is absent because it declines security work, including defensive tasks.” Disponibilidade de modelo para segurança defensiva é uma variável de política do fornecedor, e isso restringe arquitetura. A assimetria com que a Vercel fecha o texto é a razão para se importar: “a model that can read the source finds what an attacker can only probe for. The advantage is real, but it only counts if you use it first.”

Faça Isso Antes de Publicar o Primeiro Comentário

Se você vai subir um agente de revisão de segurança neste trimestre, rode em modo sombra e instrumente uma métrica: a fração de achados que os engenheiros de segurança rotulam como reais, em janela móvel de duas semanas. Publique esse número internamente antes de publicar um único comentário para um desenvolvedor. Depois escreva a política como precedentes com a razão anexada, e prove o valor dela por ablação, como a Figma fez com 44,4% contra 64,2%.

Defina a barra de precisão por superfície, não por agente. Superfícies invisíveis recebem barra baixa e iteração rápida. Superfícies visíveis ao humano recebem limiar nomeado, janela de lookback e veto para o achado embaraçoso. Deixe o bloqueio de merge como última etapa, pela razão que a Figma declara sem rodeio: “Making review a merge requirement turned it from a nice-to-have into infrastructure, and infrastructure has to be boring to be trusted.”

Seu histórico de bugs continua importando. Ele estabelece o piso. O que ele não consegue dizer é quando você ganhou o direito de interromper um desenvolvedor.

Já escrevemos sobre o déficit de governança na revisão de código com IA, sobre o que o Bugbot revelou da experiência do desenvolvedor, sobre detecção correndo à frente da remediação e sobre governança empacotada como produto em modelos cyber restritos. Este é o primeiro texto em que alguém publicou o limiar.


Fontes

A Victorino ajuda organizações de engenharia a desenhar a escada de rollout de agentes de revisão de segurança, do modo sombra ao bloqueio de merge, com portões de precisão nomeados por superfície: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa