A Cursor Vende Revisar Menos Como Recurso. Escreva o Que Traz um Humano de Volta.

“No início, você revisa cada PR de perto. À medida que as correções se sustentam, você revisa menos, e o coordenador segue tocando a migração sozinho.” A frase é da Cursor, em tradução livre do anúncio do produto Projects.

Programas de governança tratam exatamente esse comportamento como desvio a ser detectado. A Cursor imprime a frase no material do próprio produto como a forma esperada de um fluxo saudável. Vale lembrar a origem: é um post de fornecedor anunciando um produto que a Cursor vende.

A mesma página afirma que o Project “está a caminho de tocar de 20 a 100 PRs por dia”.

O Que a Página Descreve

Reduza o anúncio à mecânica e quatro coisas aparecem.

O coordenador não escreve código. Nas palavras da Cursor, ele “não escreve código, mas direciona outros agentes que escrevem. Como delega em vez de executar, nunca fica bloqueado e está sempre responsivo à direção.” Delegar é o motivo pelo qual ele consegue manter uma migração aberta ao longo de muitos PRs.

As subscriptions o conectam a eventos. Um coordenador “pode observar um canal do Slack, rodar em um cronograma ou acompanhar todos os seus PRs, consertando CI e agindo quando eles abrem ou dão merge.” Leia a parte do CI isolada. A mesma parte automatizada que produz as mudanças também conserta o portão que as julga. Em qualquer outro ambiente de controle isso é uma questão de segregação de funções, e a página não responde a ela.

Os arquivos de contexto compartilhado “sincronizam entre todas as máquinas na nuvem e locais que seus agentes usam”. Agentes escrevem nesses arquivos. Esses arquivos passam a governar todo agente futuro dentro do Project. A página descreve nenhuma etapa de revisão desse contexto, nenhuma procedência sobre quem escreveu cada linha e nenhum prazo de validade.

A regra de composição é a mais afiada das quatro. O coordenador “varre cada PR novo, extrai componentes que pertencem ao design system e adiciona uma regra de lint sempre que vê o mesmo erro duas vezes.” Uma regra de lint é política. A Cursor descreve nenhuma etapa de aprovação humana antes de essa política entrar.

Controles podem existir por trás dos quatro pontos. A afirmação aqui é mais estreita: a página declara nenhum deles, enquanto descreve um fluxo cuja condição de sucesso declarada é um humano lendo menos com o tempo. A Cursor também posiciona o Project para trabalho que “vai sobreviver a um único chat, seja uma feature com vários PRs, uma migração ou um trabalho que você quer resolvido enquanto está fora.” Longa duração e ausência humana são exatamente as condições em que um limiar não declarado pesa mais.

Onde o Reflexo de Governança Erra o Alvo

O reflexo de um programa de governança é tratar a queda de revisão como falha a detectar: painéis de latência de aprovação, alertas quando o tamanho do diff por aprovação sobe, auditoria trimestral de merges carimbados.

A PostHog mira em outro lugar e explica por quê. “Se você está gerando 20 PRs por dia, ler cada linha e rodar tudo na mão é irrealista.” A newsletter de engenharia deles nomeia o gargalo: “Com o volume de mudanças vindo de agentes, isso rapidamente vira um gargalo”, falando do trabalho de avaliar o que os agentes produzem. A PostHog reporta a própria telemetria aqui, não uma medição de indústria. Em quatro meses, os PRs abertos por agentes foram “de cerca de 20% dos PRs do nosso monorepo abertos por agentes para 70%”.

Nesse volume, ler linha a linha deixa de ser controle e vira ritual. Já argumentamos que compreensão é o gargalo, acima da verificação. Os números de volume dos dois posts mostram como esse argumento chega a um time real.

A atenuação vai acontecer, então. A pergunta interessante é o que substitui aquilo que ela remove.

O Artefato Que Vale Copiar

A resposta da PostHog é uma frase:

“Não foi aprovado automaticamente porque a revisão encontrou 2 problemas ‘must fix’.”

Essa frase é uma condição de gatilho escrita e auditável. Ela declara por que um humano entrou no circuito para aquela mudança e, por implicação, por que não entrou nas outras. Dá para consultar. Dá para contestar. Dá para apertar no próximo trimestre e comparar a versão antiga com a nova.

Leia também os limites dela. A PostHog publica essa linha, não o limiar completo, então achados “must fix” podem ser uma rota entre várias. O que a linha estabelece é que existe um limiar na forma de artefato nomeado, no lugar de um sentimento semanal sobre quanto os agentes mereceram confiança.

A PostHog tem cuidado com o que permanece humano por outro motivo também. Sobre escopar o trabalho pessoalmente: “Na melhor das hipóteses, meus agentes teriam gasto muito mais tokens para chegar à mesma solução. Na pior, teriam introduzido bugs e vetores de ataque.” E sobre para onde o esforço migra: “A consequência disso é engenheiros trabalhando mais no sistema que constrói o produto do que no produto em si. Eles constroem a fábrica de software em vez do software.”

A condição de gatilho é trabalho de fábrica. Pertence ao sistema que constrói o produto, e alguém precisa ser dono dela ali.

Escrito Vence Implícito

Um gatilho escrito é um controle. Um gatilho implícito é um hábito com boa intenção, e hábito não sobrevive a auditoria, comitê ou questionário de cliente.

A diferença aparece no minuto em que algo dá errado. Com uma condição escrita, a pergunta pós-incidente tem resposta: a mudança não atingiu o critério de escalação, aqui está o critério, aqui está por que ele não disparou, aqui está a emenda. Com atenuação por intuição, a única resposta disponível é que o time tinha parado de ler com atenção, o que vale para todo time e explica nada.

Já argumentamos que uma alegação de revisão precisa ser testada e que o tipo de bug que um agente consegue achar depende de o oráculo ser binário ou arquitetural. Os dois tratam da qualidade da revisão automatizada. Este texto trata da outra metade: a regra que decide quando a revisão automatizada é insuficiente, e quem a escreveu.

Faça Isto Agora

Pegue os últimos 30 merges de autoria de agentes no seu repositório mais movimentado. Para cada um, responda em um documento compartilhado: o que teria puxado um humano para dentro dessa mudança? Se a resposta honesta na maioria for “nada específico, alguém teria percebido”, você tem atenuação sem gatilho, e tem isso hoje, com qualquer fornecedor que você use.

Depois escreva quatro linhas e coloque-as no repositório, não em um wiki que ninguém abre:

A condição de escalação. Nomeie a classe de achado, o caminho tocado ou o raio de impacto que obriga um humano. A versão da PostHog é uma contagem de “must fix”. A sua pode ser mais simples, desde que uma máquina consiga avaliá-la e uma pessoa consiga ler o resultado.
A regra de segregação do portão. Se um agente pode consertar CI, declare quais falhas ele pode consertar e quais ele só pode reportar. Um agente capaz de deixar o próprio build verde removeu o único juiz independente do pipeline.
O ciclo de vida do contexto compartilhado. Quem pode escrever nos arquivos que guiam todo agente futuro, quem revisa essas escritas e quando elas expiram. Contexto compartilhado sem revisão é mudança de política sem changelog.
O gatilho de reversão. A condição que eleva a revisão de volta: um incidente em produção, um rollback, uma taxa de falha acima de uma linha declarada. Atenuação sem caminho de volta é porta de mão única com uma placa simpática.

A Cursor vende um coordenador que trabalha enquanto você dorme, e o discurso é honesto sobre o que isso custa em atenção. A PostHog vive o mesmo problema de atenção e publicou a frase que o administra. Pegue a frase.

Fontes

Cursor. “Introducing Projects.” 2026.
PostHog. “What happens to engineers when AI writes all the code?.” Setembro de 2026.

A Victorino ajuda times de engenharia a escrever e fazer valer as condições de escalação que mantêm julgamento humano na entrega conduzida por agentes: contato@victorino.com.br | www.victorino.com.br