Como avaliar agentes além dos testes aprovados

Um agente de programação que passa nos testes visíveis de uma tarefa ainda pode ser arriscado demais para integrar. Ele pode apagar um comportamento antigo que ninguém incluiu no fixture, editar um arquivo gerado no lugar da fonte, passar quarenta minutos explorando o subsistema errado ou produzir um patch que só faz sentido no repositório conhecido por seus criadores. Uma avaliação séria precisa detectar esses resultados, em vez de parabenizar o agente por deixar os testes verdes.

A unidade útil não é uma execução de testes. É uma tentativa de tarefa com um estado inicial do repositório, uma instrução, um orçamento, uma trajetória observável, um patch e vários julgamentos independentes. Tratar a tentativa inteira como evidência muda o que a equipe mede e quais falhas ela corrige.

Como definir uma tarefa para um agente de programação

Uma tarefa para um agente de programação precisa de um commit inicial congelado, uma solicitação realista, um ambiente de execução explícito e verificações ocultas de aceitação. Sem os quatro elementos, duas execuções que parecem tratar do mesmo problema podem resolver problemas diferentes.

Comece com um trabalho parecido com o que chega à sua fila real. Uma tarefa pode ser um relato de bug, uma funcionalidade pequena, uma migração de dependência ou uma mudança operacional. Preserve a ambiguidade que uma pessoa competente resolveria lendo o repositório, mas remova aquela que apenas um ex-funcionário conseguiria esclarecer. "Corrigir o arredondamento da fatura quando uma linha de crédito vem depois de uma linha tributável" é justo se o código e o comportamento existente contêm a resposta. "Deixar o financeiro satisfeito" não é.

Fixe mais do que o commit. Registre a cadeia de ferramentas, a política de cache de dependências, as variáveis de ambiente disponíveis para o agente, a política de rede, os pontos de entrada dos testes e os limites de recursos. Se o ambiente variar, a pontuação mistura a qualidade do agente com a sorte do runner. As imagens de build devem ter identificadores imutáveis, e os fixtures devem ser versionados junto do avaliador.

Cada registro de tarefa deve poder ser inspecionado. Uma especificação compacta pode ser assim:

{
  "task_id": "billing-credit-rounding-014",
  "repo_commit": "4f93c2a",
  "request": "Preserve tax rounding when a credit line follows a taxable line.",
  "visible_checks": ["test_billing_unit"],
  "hidden_checks": ["credit_after_tax", "mixed_currency_unchanged"],
  "budget": {"wall_seconds": 900, "model_cost_usd": 8.00},
  "allowed_paths": ["src/billing", "tests/billing"]
}

As verificações ocultas não são uma armadilha. Elas impedem que o agente se otimize diretamente pela folha completa de respostas. Mantenha algumas verificações de comportamento fora do repositório e alterne uma parte delas, pois os agentes conseguem deduzir muita coisa dos nomes dos testes e dos fixtures próximos.

Execute cada tarefa várias vezes. O comportamento do agente varia mesmo quando o modelo e o prompt permanecem iguais. Uma aprovação por sorte mostra que a tarefa é possível. Tentativas repetidas mostram se o sistema é confiável. Armazene a semente ou as configurações de amostragem quando o fornecedor as expuser, mas não finja que elas eliminam toda variação.

Por que testes aprovados oferecem apenas um julgamento

Os testes respondem se certas observações corresponderam às expectativas. Eles não comprovam que o patch tem o escopo certo, é sustentável e seguro, ou mantém comportamentos que a suíte nunca codificou.

Avalie a conclusão da tarefa em camadas. Primeiro, execute as verificações visíveis que o agente podia usar. Segundo, execute testes ocultos que cubram entradas próximas e o caso extremo relatado. Terceiro, rode verificações do repositório inteiro, incluindo lint, tipos, builds e testes dos pacotes dependentes. Quarto, examine propriedades que os frameworks de teste raramente percebem: mudanças em arquivos proibidos, novas dependências, alterações em APIs públicas, migrações, artefatos gerados e exclusões suspeitas de testes.

Mantenha esses julgamentos separados em vez de reduzi-los imediatamente a uma porcentagem. Um patch que corrige o alvo e quebra um pacote sem relação é diferente de um patch que nunca corrigiu o alvo. Ambos impedem a entrega, mas apontam para soluções distintas. O primeiro sugere análise de impacto fraca ou exploração insuficiente do repositório. O segundo indica implementação ruim ou entendimento incorreto da tarefa.

A inspeção do patch pode ser parcialmente mecânica. Rejeite edições fora de uma lista permitida quando a tarefa tiver um limite estreito. Sinalize reduções na quantidade de asserções, novos skips, tratadores de exceção amplos e mudanças em snapshots. Esses sinais pedem revisão, mas não provam trapaça automaticamente. Uma correção legítima pode atualizar um snapshot ou remover uma asserção obsoleta. Portanto, preserve o diff e a explicação do agente para a revisão humana.

Adicione uma rubrica pequena para qualidades que as máquinas ainda não julgam de modo consistente. Os revisores podem avaliar se o patch segue abstrações locais, valida no limite certo, deixa código morto ou acrescenta trabalho de manutenção. Use opções ancoradas como "segue um padrão existente no repositório" e "cria um mecanismo paralelo". Notas vagas de um a cinco variam entre revisores e ensinam muito pouco.

A decisão de aprovação deve continuar rígida: o comportamento exigido, as verificações de regressão e a saúde do repositório precisam passar. O registro de diagnóstico deve continuar rico. Muitas equipes estragam uma avaliação guardando apenas o resultado verde ou vermelho. Depois, não têm evidência quando uma nova versão do agente altera a pontuação.

Comportamentos já corrigidos pertencem à suíte

Uma avaliação de agentes de programação deve repetir bugs que sua equipe já pagou para entender. Esses casos expõem o risco de regressão muito melhor do que uma coleção formada apenas por tarefas novas e bem delimitadas.

Quando um bug de produção for corrigido, preserve três elementos: o estado do repositório antes da correção, o sintoma visível para o usuário e um oráculo que diferencie o comportamento correto. O oráculo pode ser um teste focado, uma solicitação e resposta gravadas, uma transição de estado do banco de dados ou um comando com saída normalizada. Remova segredos e carimbos de data instáveis antes de armazenar tráfego.

Existem duas perguntas de regressão diferentes. "O agente consegue resolver um bug antigo a partir do estado quebrado?" mede a capacidade de reparo. "Um novo patch para outra tarefa reintroduz esse bug antigo?" mede a preservação de comportamento. As equipes misturam as duas e acabam com um benchmark que recompensa a correção de bugs sem dizer nada sobre danos colaterais.

Monte um banco cumulativo de comportamentos usando incidentes encerrados e descobertas difíceis de revisão. Marque cada caso por subsistema, mecanismo da falha e consequência. Depois, selecione casos relevantes para cada tarefa e uma amostra menor do repositório inteiro. O conjunto relevante encontra quebras próximas. A amostra encontra acoplamentos inesperados, como um formatador de cobrança que muda uma exportação de relatório porque ambos usam o mesmo auxiliar de arredondamento.

Não execute apenas a branch padrão atual contra o banco. Rode o patch exato do agente sobre sua base congelada, pois mudanças humanas posteriores podem esconder ou criar falhas. Quando um teste falha tanto na base quanto no patch, classifique-o como ruído preexistente. Quando passa na base e falha depois do patch, a tentativa causou uma regressão.

Verificações instáveis precisam de quarentena com responsável e evidência, não de repetições silenciosas até ficarem verdes. Registre cada execução individual. Uma política de repetição pode dizer se o patch pode ser publicado segundo as regras atuais de CI, mas os resultados brutos mostram que o ambiente de avaliação ou o produto tem comportamento não determinista. Misturar os dois faz o agente parecer melhor sem tornar seu patch mais seguro.

Um banco de comportamentos fica caro à medida que cresce, então divida-o em níveis. Rode os casos rápidos e próximos em toda tentativa, uma reprodução mais ampla antes de aceitar uma versão candidata do agente e os casos de sistema mais lentos em um cronograma. A cobertura deve crescer: um caso só sai quando o comportamento deixa de existir ou um oráculo melhor o substitui.

O custo precisa de denominador e registro de falhas

O custo por tarefa concluída com sucesso é mais útil do que o gasto de tokens por execução. Tentativas baratas que falham ou obrigam uma pessoa a reparar o patch não são trabalho barato.

Registre cobranças de entrada e saída do modelo, tokens em cache, computação das ferramentas, tempo de sandbox e qualquer serviço externo pago chamado pela execução. Mantenha o tempo de revisão técnica em um campo separado, em vez de inventar um valor em dinheiro. Ainda será possível comparar a mediana de minutos de revisão entre versões do agente e classes de tarefa.

Observe o custo por pelo menos quatro perspectivas:

• custo por tentativa, que expõe exploração descontrolada;
• custo por tarefa aceita, que inclui tentativas malsucedidas;
• custo por classe de tarefa e repositório, que impede trabalho fácil de esconder trabalho caro;
• custo de execuções desperdiçadas por categoria de falha, que aponta defeitos corrigíveis de orquestração.

Mostre distribuições, não apenas médias. A mediana descreve uma execução comum, enquanto o percentil 90 ou 95 identifica agentes que passam repetidamente pelos mesmos arquivos, recompilam sem parar ou despejam o repositório inteiro no contexto. Um orçamento rígido deve interromper essas execuções e marcá-las como orçamento esgotado, não como falha comum da tarefa.

O cache dificulta comparações. Um cache de dependências aquecido pode ser realista para um worker interno de CI, mas um cache aquecido de prompts pode tornar tarefas repetidas artificialmente baratas. Escolha a condição que representa a produção, identifique-a e inclua uma amostra com cache frio. Nunca compare uma versão em tarefas aquecidas com outra em tarefas recém-criadas.

O registro de falhas importa porque as economias vêm de mudanças diferentes. Se a maior parte do gasto desperdiçado vem de falhas na preparação do ambiente, trocar o modelo não ajudará. Se o agente lê repetidamente código de terceiros incluído no repositório, melhore a orientação do repositório ou os filtros de ferramentas. Se ele chega a um patch correto depois de ciclos longos de testes, melhore a seleção dos testes e os builds incrementais.

Os limites de custo também mudam o comportamento. Com um teto apertado, o agente pode implementar a primeira correção plausível e pular uma verificação ampla. Avalie a qualidade em vários orçamentos antes de declarar que uma configuração é eficiente. O ponto operacional útil aparece quando uma unidade adicional de gasto deixa de aumentar de forma relevante as tarefas aceitas ou reduzir regressões graves.

A latência deve seguir o caminho crítico

Meça o tempo decorrido como o usuário o vivencia e depois divida esse período em fases nas quais a equipe pode agir. Uma única duração não revela se o atraso veio do raciocínio do modelo, da inicialização de uma ferramenta, da instalação de dependências, dos testes ou de um runner congestionado.

Registre horários da entrada na fila, disponibilidade da sandbox, primeira resposta do modelo, cada chamada de ferramenta, primeiro patch, início da verificação e resultado final. A partir desses eventos, derive tempo de fila, preparação, tempo até a primeira edição, atividade do agente, verificação e total. Mantenha separadas a latência do modelo e a duração dos comandos.

O tempo até a primeira edição é especialmente revelador. Um período muito curto pode indicar que o agente adivinhou antes de ler as convenções locais. Um período muito longo pode mostrar que ele vagou por diretórios irrelevantes. Nenhum é ruim automaticamente, então relacione a medida à aceitação do patch e aos arquivos examinados.

CI também deve medir a latência do caminho crítico, em vez de somar trabalhos paralelos. Se testes unitários e análise estática rodarem juntos por oito minutos, o usuário esperou oito minutos, não dezesseis. O consumo de recursos ainda pode somar dezesseis minutos de worker, que pertencem ao registro de custos.

Defina objetivos por classe de tarefa. Uma correção de configuração em um arquivo e uma mudança de esquema entre pacotes não devem compartilhar o mesmo limite. Compare o agente ao fluxo humano que ele substitui ou auxilia: tempo até um patch revisável, tempo até o merge aceito e tempo gasto pelo revisor. O agente pode demorar mais para produzir um patch e ainda terminar antes se suas evidências facilitarem a revisão. Também pode ser rápido e consumir uma tarde em correções.

Os tempos esgotados merecem um resultado próprio. Não pontue uma execução interrompida da mesma forma que um patch incorreto. Preserve seu último estado coerente, a trilha de ferramentas e o orçamento utilizado. Tempos esgotados repetidos em um repositório muitas vezes revelam um problema do avaliador, como um comando de teste esperando um serviço indisponível, e não uma geração de código fraca.

Execute o benchmark de latência em workers controlados e observe a CI compartilhada separadamente. Execuções controladas permitem comparar modelos. Execuções compartilhadas mostram a necessidade de capacidade e a experiência real dos desenvolvedores. Misturá-las produz um número ruidoso que não responde a nenhuma das duas perguntas.

Repositórios desconhecidos expõem falhas diferentes

Um agente avaliado apenas em repositórios conhecidos por seus criadores herdará as suposições deles. Um código que você não escreveu testa se o agente consegue descobrir regras, em vez de recebê-las pelo desenho do benchmark.

As falhas comuns começam antes da geração de código. O agente escolhe o comando de teste errado, confunde código gerado com a fonte, ignora uma segunda linguagem no build, desconsidera uma convenção local de patches ou edita um módulo compartilhado sem encontrar seus consumidores. Essas tentativas podem compilar e passar em um teste focado. Elas falham porque o agente formou um mapa errado do sistema.

Selecione repositórios externos ou recém-adquiridos com permissão legal e build reproduzível. Congele-os antes que os autores das tarefas os explorem profundamente. Peça a um grupo para preparar o ambiente e a outro para criar tarefas a partir do histórico real de issues ou de defeitos observados. Se a mesma pessoa estuda o código, escreve dicas detalhadas e julga o resultado, o entendimento dela vaza para a instrução.

Meça o comportamento de descoberta sem prescrever uma sequência ideal. Sinais úteis incluem se o agente lê a orientação do repositório, identifica pontos de entrada do build, procura locais de chamada antes de mudar um símbolo compartilhado, percebe várias implementações e verifica o diff antes de terminar. Não dê pontos pelo volume de chamadas de ferramentas. Dez buscas podem refletir cuidado ou confusão.

Inclua repositórios com características incômodas, mas reais: linguagens misturadas, geradores próprios, poucos testes, fixtures grandes, scripts específicos de plataforma e nomes enganosos de diretórios. Não fabrique armadilhas. O objetivo é descobrir se o agente lida com a história acumulada normal, não se resolve um quebra-cabeça criado pelo avaliador.

A contaminação é difícil de provar, então desenhe o teste para reduzi-la. Use código privado quando tiver autorização, snapshots recentes que não poderiam estar em conjuntos de treinamento antigos e transformações locais como renomear entidades de negócio. A mudança de nomes, sozinha, não cria um novo problema de raciocínio, mas reduz a memorização simples. Evidência forte vem de desempenho comparável em repositórios conhecidos e realmente desconhecidos, não de perguntar ao modelo se ele se lembra do código.

A trajetória explica falhas invisíveis no patch

Guarde as ações observáveis do agente porque o diff final não mostra como ele encontrou a resposta, o que ignorou ou por que esgotou o orçamento. Uma trilha compacta de eventos torna as falhas reproduzíveis sem pedir o raciocínio privado do modelo.

Para cada rodada do modelo, mantenha a versão do prompt, o identificador da resposta, o uso de tokens, a solicitação de ferramenta, o status do resultado, os horários e os arquivos ou comandos afetados. Remova segredos antes de armazenar e imponha limites rígidos ao tamanho da saída dos comandos. O agente pode imprimir valores de ambiente ou dados de clientes durante a depuração, então o acesso às trilhas deve seguir as mesmas regras do acesso ao código-fonte.

Não pontue textos de raciocínio oculto nem recompense o agente por narrar a abordagem esperada. Fornecedores expõem sinais internos diferentes, e uma explicação bem escrita pode esconder decisões ruins. Julgue ações e artefatos: ele leu as instruções de build, procurou chamadas, mudou um arquivo, executou uma verificação focada, viu uma falha e revisou o patch.

Classifique a primeira decisão errada que determinou o resultado. Sintomas posteriores costumam surgir dela. Se o agente edita um cliente gerado, depois luta contra o gerador e finalmente esgota o tempo, "tempo esgotado" descreve o estado final, não a resposta técnica correta. A categoria útil é identificação da fonte verdadeira. Outras categorias podem incluir descoberta do ambiente, interpretação da tarefa, escolha de dependência, análise de impacto, implementação e verificação.

Registre a recuperação além da falha. Um agente que percebe uma suposição errada depois de uma verificação malsucedida é diferente daquele que repete o mesmo comando seis vezes. Métricas úteis de trajetória incluem chamadas idênticas repetidas, tempo entre uma verificação com falha e a próxima edição, proporção de arquivos examinados fora do subsistema alterado e execução da verificação final sobre um estado limpo. Interprete esses sinais junto ao resultado da tarefa. Nenhum deles é, sozinho, uma pontuação de qualidade.

As trilhas também revelam interferência do harness. Uma ferramenta pode truncar justamente o erro do compilador que identifica o defeito, uma política de sandbox pode bloquear um comando normal do repositório ou a camada de orquestração pode declarar sucesso depois de encerrar um processo filho. Mantenha separados os eventos do avaliador e do agente para deixar visível o responsável por cada falha.

A retenção precisa de uma política deliberada. Guarde o patch, os resultados normalizados e as métricas agregadas por mais tempo do que as saídas brutas de comandos. Ao apagar trilhas detalhadas, mantenha os rótulos de falha e as versões do avaliador para permitir comparações históricas. Um arquivo de avaliação que acumula credenciais e trechos de produção silenciosamente já constitui um controle de segurança malsucedido.

O avaliador pode falhar antes do agente

Um harness de avaliação é software de produção. Se seu oráculo estiver errado, a sandbox vazar estado ou o fixture da tarefa não compilar, a pontuação mede defeitos do avaliador.

Valide cada tarefa com dois controles. O controle negativo é o commit quebrado sem alterações e deve falhar no oráculo alvo. O controle positivo é a correção humana conhecida e deve passar nos oráculos alvo e de regressão. Uma tarefa que falha em qualquer controle fica fora do conjunto pontuado até ser corrigida.

Depois, teste o isolamento. Dê a cada tentativa um worktree novo, um espaço de processos limpo, um relógio controlado quando o tempo importar e recursos de serviço exclusivos. Um banco de dados deixado pela execução anterior pode fazer o patch seguinte parecer correto. Caches de dependências compartilhados podem ser aceitáveis, mas não devem conter saídas mutáveis da tarefa.

O runner deve emitir um resultado compacto e estável que a CI possa reter:

$ ./eval-agent fixtures/billing-credit-rounding-014
task=billing-credit-rounding-014 outcome=regression
target=pass hidden=pass repository=fail
cost_usd=3.42 wall_seconds=286 review=required
artifacts=patch.diff,events.json,test-results.xml

Normalize valores não deterministas antes de comparar saídas. Ordene registros sem ordem definida, substitua identificadores gerados por marcadores estáveis e compare dados estruturados no lugar de capturas de tela ou logs quando possível. Toda regra de normalização pode esconder um defeito, então mantenha o artefato bruto junto do normalizado.

Versione o avaliador, a tarefa e o oráculo de maneira independente. Quando um oráculo mudar, preserve metadados suficientes para reproduzir pontuações antigas e recalculá-las quando possível. Uma versão do modelo não deve parecer melhor só porque alguém afrouxou um fixture no mesmo pull request.

Inspecione manualmente uma amostra das falhas do avaliador. Examine erros de infraestrutura, aprovações suspeitamente rápidas e grupos nos quais todas as versões do agente falham da mesma forma. Muitas vezes são tarefas quebradas. Contá-las como falhas do modelo pode parecer cauteloso, mas direciona o trabalho técnico ao sistema errado.

O placar deve preservar falhas graves

O placar deve tornar claras as decisões de lançamento sem diluir uma regressão de segurança ou corrupção de dados em médias. Use barreiras para resultados inaceitáveis e métricas para compensações.

Comece com barreiras de elegibilidade: o agente deve permanecer no ambiente permitido, evitar acesso proibido a segredos, produzir um patch revisável e passar em todos os oráculos de regressão grave. Qualquer violação torna o candidato inelegível, independentemente da taxa média de sucesso. Defina a gravidade antes da comparação, ou as equipes mudarão o rótulo de falhas inconvenientes depois de ver os resultados.

Para candidatos elegíveis, mostre uma tabela por classe de tarefa e repositório. Inclua taxa de tarefas aceitas, taxa de correção do alvo, taxa sem regressões, mediana e cauda do custo por tarefa aceita, mediana e cauda do tempo total, minutos de revisão e categorias de falha. Mostre contagens junto às porcentagens. Três sucessos em quatro e setenta e cinco em cem têm a mesma porcentagem, mas não a mesma confiança.

Evite uma pontuação ponderada única, a menos que um sistema automático de seleção a exija. Os pesos escondem decisões de política e convidam a discussões sobre aritmética. Uma revisão de lançamento pode perguntar se o candidato supera todas as barreiras, melhora as métricas importantes e mantém as regressões dentro da tolerância declarada.

Compare com referências úteis. Inclua a configuração atual do agente, um agente mínimo com menos ferramentas e um estado sem agente, no qual o avaliador não aplica patch algum. Resultados humanos podem ajudar quando as tarefas e condições são comparáveis, mas mantenedores experientes no próprio código não são a referência universal para um agente em um repositório desconhecido.

Segmente os resultados antes de confiar no agregado. Verifique linguagem, tamanho do repositório, qualidade dos testes, tipo de tarefa e se a mudança atravessa limites de subsistemas. Um candidato pode melhorar a taxa principal ao avançar muito em pequenas edições de TypeScript e, ao mesmo tempo, piorar em migrações de banco de dados.

Trate decisões divergentes dos revisores como dados. Se um revisor aceita um patch rejeitado pelo harness, ou rejeita um que o harness aprovou, exija um código de motivo e inspecione o oráculo. O revisor pode estar errado, mas a divergência ensina o placar.

A implantação em CI precisa de controles e regras de parada

Implante um agente de programação pela CI como uma mudança medida, com período fixo de comparação e condições de parada. Executá-lo imediatamente em todos os pull requests transforma os desenvolvedores em infraestrutura de avaliação não remunerada.

Comece no modo sombra com tarefas representativas. O agente recebe o mesmo estado do repositório e a mesma solicitação, mas não pode alterar a branch real. Compare o patch e as evidências dele com o resultado do trabalho normal. O modo sombra revela lacunas do ambiente e carga de revisão sem colocar as mudanças no caminho do merge.

Depois, permita sugestões para classes de tarefas de baixo impacto, com revisão obrigatória. Mantenha aleatoriamente um grupo de controle na versão anterior do agente ou no fluxo normal. Sem um controle simultâneo, mudanças na mistura de tarefas, atividade do repositório e carga da CI podem parecer melhorias.

Escreva regras de parada antes da implantação. Pause as sugestões automáticas se surgir uma regressão grave, limites de segredos forem atravessados, erros de infraestrutura do avaliador excederem a tolerância ou o custo de cauda ultrapassar o orçamento. A regra deve nomear quem pode retomar a implantação e quais evidências serão necessárias.

Observe a adaptação. Os desenvolvedores podem começar a escrever issues detalhadas demais para o agente, evitar tarefas que ele resolve mal ou aprovar sem atenção formatos conhecidos de patch. Essas mudanças afetam o desempenho aparente. Revise uma amostra de solicitações e comentários, e mantenha um benchmark estável fora da fila ativa.

O harness de paridade que usamos na CodeHero compara o comportamento do sistema reescrito com o tráfego de produção gravado, pois um build limpo não comprova que décadas de casos extremos sobreviveram a uma mudança de arquitetura. O mesmo princípio vale para um agente em CI: preserve o comportamento real como evidência executável e julgue cada patch contra ele.

A promoção deve ser reversível. Mantenha disponível a configuração anterior, marque cada patch criado por agente com a versão do avaliador e guarde a tentativa por tempo suficiente para investigar regressões posteriores. Se você não consegue ligar um defeito de produção ao prompt, estado do repositório, patch e verificações que o aprovaram, o registro da avaliação está incompleto.

Repita o benchmark depois de qualquer mudança relevante no modelo, prompt de sistema, permissões das ferramentas, composição do contexto ou imagem do runner. Esses componentes interagem, portanto um rótulo de versão do modelo não identifica o sistema que produziu um patch. Mantenha um conjunto canário pequeno e estável para comparações rápidas e atualize o conjunto amplo conforme o trabalho real mudar. Quando retirar tarefas, execute os conjuntos antigo e novo durante um período comum para que uma mudança de dificuldade não pareça uma mudança de qualidade.

Um agente só merece mais autoridade quando produz repetidamente patches aceitáveis nos repositórios onde trabalhará e dentro de um orçamento que a equipe consegue defender. Testes verdes abrem a revisão. Eles não a encerram.