Quanta revisão humana o código assistido por IA precisa?

A IA pode reduzir o tempo necessário para redigir uma alteração, mas não reduz a lista de coisas que podem dar errado em produção. A revisão humana deve crescer conforme o alcance do dano da alteração, a sensibilidade do código e a força das evidências anexadas ao pull request. A quantidade de texto que uma IA escreveu é quase irrelevante.

Eu uso quatro níveis de revisão. Uma alteração pequena e reversível em um componente isolado pode precisar de um revisor competente e testes direcionados. Uma alteração que toca em identidade, dinheiro, dados de saúde, permissões, implantação ou uma dependência compartilhada precisa de revisores independentes que entendam esse domínio, testes mais amplos, evidências de segurança e uma decisão explícita de liberação. Isso não é desconfiança da IA. É um controle normal de engenharia aplicado a uma fonte que pode produzir código convincente mais rápido do que uma equipe consegue inspecioná-lo.

A política útil cabe em um repositório, roda na integração contínua e informa aos autores exatamente quais evidências eles devem apresentar. Uma política que diz que toda alteração com IA exige cuidado extra acabará virando uma aprovação automática de formulário. Uma política que relaciona fatos observáveis a controles definidos resiste a um dia corrido de liberação.

Revise a consequência, não o autor

O nível certo de revisão vem do que a alteração pode afetar, não de uma pessoa ter digitado, copiado, gerado ou revisado o código gerado. A procedência ainda importa porque os revisores precisam saber o que foi verificado de forma independente. Ela não substitui a classificação de risco.

Comece com dois eixos: tamanho da alteração e sensibilidade do código. O tamanho inclui mais do que linhas alteradas. Conte o número de componentes atravessados, interfaces públicas modificadas, migrações de dados introduzidas, arquivos gerados substituídos, escopos de configuração alterados e caminhos de execução afetados. Uma alteração de doze linhas em autorização pode trazer mais risco do que duas mil linhas de dados de teste. O tamanho do diff ajuda no encaminhamento, mas não mede a segurança.

A sensibilidade pergunta qual autoridade o código possui e que dano um erro pode causar. Trate autenticação, autorização, criptografia, segredos, cobrança, dados pessoais, fluxos clínicos, permissões de infraestrutura, pipelines de compilação, manifestos de dependências e operações destrutivas de dados como áreas sensíveis. Acrescente áreas específicas do produto, como regras de acesso contratado ou limites de segurança. Mantenha a lista no controle de versão para que um autor não possa reinterpretá-la em silêncio quando o prazo apertar.

A reversibilidade é o terceiro fato que muda a resposta. Um texto incorreto em uma página, protegido por uma opção de recurso, pode ser desativado em minutos. Uma migração que apaga colunas, um evento publicado para consumidores externos ou uma credencial exposta em um log não podem ser recuperados de forma limpa. Eleve o nível quando a reversão depender de restaurar dados, coordenar outra equipe ou pedir uma ação aos clientes.

Um classificador prático registra esses fatos no pull request em vez de pedir uma avaliação vaga de risco:

Quais serviços, armazenamentos de dados e interfaces públicas mudam?
O código toma ou aplica uma decisão de segurança ou de negócio?
A equipe consegue revertê-lo sem perder ou reprocessar dados?
Ele altera dependências, instruções de compilação ou permissões de implantação?
Que evidência mostra que o comportamento alterado funciona e o anterior continua funcionando?

Não deixe os autores escolherem um nível baixo apenas pela intuição. As regras do repositório podem elevar uma alteração automaticamente quando aparecem caminhos protegidos, pastas de migração, manifestos de pacotes, arquivos de infraestrutura ou um diff grande. Um revisor também pode elevá-la depois de ler o projeto. A redução de nível deve exigir uma justificativa registrada e a identificação de quem a aprovou.

Quatro níveis tornam a política utilizável

Quatro níveis bastam para a maioria das equipes. Mais categorias criam discussões sobre rótulos, enquanto menos categorias forçam o trabalho rotineiro e o perigoso a passar pelo mesmo controle. Os nomes dos níveis importam menos do que as condições de entrada e as evidências obrigatórias.

O nível 1 cobre alterações restritas e reversíveis. Alguns exemplos são textos, estilos isolados, dados de teste, comentários e pequenas refatorações internas sem mudança de comportamento. Exija a compilação normal, verificação de estilo, testes unitários relevantes e um revisor que conheça ou seja responsável pela área. A integração automática pode ser aceitável após a aprovação se a proteção do branch impedir o autor de aprovar a própria alteração e todas as verificações obrigatórias terminarem com sucesso.

O nível 2 cobre o comportamento comum de produção. Isso inclui lógica delimitada de funcionalidades, comportamento de API que preserva o contrato, correções em código estabelecido e alterações modestas de configuração. Exija um revisor independente, testes direcionados ao comportamento alterado, toda a suíte afetada, análise estática, verificação de segredos e uma revisão de dependências sem problemas. O pull request deve explicar o que a IA produziu, o que o autor alterou depois e quais afirmações ele verificou sem depender da explicação gerada.

O nível 3 cobre alterações sensíveis ou amplas. Encaminhe para cá identidade, controle de acesso, fluxo de pagamentos, informações de saúde, migrações, bibliotecas compartilhadas, políticas de implantação, contratos públicos e alterações que atravessam vários componentes. Exija dois revisores, incluindo um responsável pelo domínio; acrescente testes de integração ou de ponta a ponta no limite que carrega o risco; rode análises de segurança adequadas à linguagem; inspecione mudanças em dependências e arquivos de bloqueio; e exija um plano de implantação e reversão. O segundo revisor não deve repetir o primeiro. Atribua comportamento e projeto a um, e segurança, dados ou operações ao outro.

O nível 4 cobre alterações com consequências graves ou difíceis de reverter. Os exemplos incluem projeto criptográfico, limites de privilégios, transformação de dados em massa, políticas de identidade de produção, confiança no processo de compilação, apoio a decisões clínicas e uma nova troca externa de dados. Exija uma revisão de projeto antes da implementação, responsáveis nomeados pelos domínios afetados, modelagem de ameaças, testes de uso indevido e falhas, evidência de liberação gradual e uma pessoa explícita que aceite o risco residual. Algumas equipes também exigem um gerente de liberação ou comitê de mudanças. Use isso apenas quando a pessoa tiver contexto e autoridade para interromper a liberação; uma aprovação cerimonial acrescenta atraso sem controle.

Uma política legível por máquina mantém o mapeamento sob revisão. Este exemplo é simples de propósito, para que uma equipe possa adaptá-lo ao próprio sistema de CI:

review_tiers:
  tier_1:
    approvals: 1
    checks: [build, lint, unit]
  tier_2:
    approvals: 1
    checks: [build, unit, affected_suite, static_analysis, secrets, dependencies]
  tier_3:
    approvals: 2
    required_roles: [code_owner, domain_owner]
    checks: [tier_2, integration, security_scan, rollback_test]
  tier_4:
    approvals: 3
    required_roles: [code_owner, security_owner, release_owner]
    checks: [tier_3, threat_model, misuse_tests, staged_release]
protected_paths:
  tier_3: [auth/, billing/, migrations/, infra/, package-lock.json]
  tier_4: [crypto/, production/identity/, clinical/decision-support/]

Isso evita uma falha comum: um autor classifica uma alteração de permissões como pequena porque o diff tem oito linhas, recebe uma aprovação rápida e publica um branch que concede acesso quando uma consulta falha. Um caminho protegido eleva o nível antes de qualquer discussão sobre a contagem de linhas. Os testes precisam então cobrir negação, dados ausentes e falha do serviço, não apenas a solicitação bem-sucedida.

Os testes devem provar a afirmação de risco

A quantidade de testes diz pouco sobre a prontidão para revisão. A pergunta útil é se os testes falhariam diante dos defeitos plausíveis introduzidos por essa alteração específica. Código gerado costuma vir acompanhado de testes gerados que confirmam a mesma suposição errada. Uma suíte verde pode mostrar consistência interna entre dois artefatos incorretos.

Exija que o autor declare a afirmação arriscada em linguagem simples e depois a conecte às evidências. Para uma verificação de acesso, a afirmação pode ser que apenas profissionais clínicos atribuídos a um caso consigam ver um registro. As evidências devem cobrir um profissional atribuído, outro não atribuído, um usuário sem função clínica, uma resposta ausente do serviço de atribuição e uma sessão desatualizada. Um teste que prova o sucesso do profissional atribuído cobre apenas o caminho feliz.

Os revisores devem fazer uma mutação mental ou real no código: trocar && por ||, remover o filtro de locatário, retornar sucesso diante de uma exceção ou fazer uma coleção vazia passar. Se os testes propostos continuarem verdes, eles não protegem a decisão. Ferramentas de teste de mutação podem automatizar uma parte disso, mas uma mutação manual de cinco minutos geralmente basta para expor um teste gerado que apenas repete a implementação.

Rode os testes no nível mais restrito capaz de refutar a afirmação e depois acrescente testes de limite onde os componentes possam discordar. Testes unitários são bons para desvios e invariantes. Testes de contrato detectam suposições incompatíveis entre solicitações e respostas. Testes de integração expõem restrições de banco de dados, limites de transação, filas, caches e middleware de identidade. Reserve os testes de ponta a ponta para um conjunto pequeno de jornadas cuja falha bloquearia a liberação. Fazer todos os níveis rodarem todos esses testes desperdiça tempo e ensina as equipes a ignorar resultados lentos e instáveis.

Revise os testes com o mesmo cuidado dado ao código de produção. Observe mocks que ignoram a camada de permissões, dados de teste sem valores nulos realistas, asserções que verificam apenas códigos de status, snapshots que aceitam muitas alterações não relacionadas e novas tentativas que escondem condições de corrida. A IA consegue produzir com facilidade um volume impressionante de testes em torno de uma interface que entendeu errado.

O autor deve anexar os comandos exatos usados quando uma verificação local ainda não é aplicada pelo CI. Um revisor pode reproduzir uma execução direcionada e ver uma saída como esta:

$ npm test access-policy.test.ts
PASS access-policy.test.ts
  assigned clinician can read (18 ms)
  unassigned clinician is denied (7 ms)
  missing assignment response fails closed (9 ms)
Tests: 3 passed, 3 total

A saída só é evidência se o commit do pull request a produziu. Prefira artefatos do CI ligados ao commit em vez de capturas de tela coladas. Para os níveis 3 e 4, preserve relatórios de testes, resultados de análises e registros de aprovação junto à liberação para que uma pessoa investigando um incidente consiga reconstruir o que a equipe sabia.

Código sensível precisa de uma visão de segurança independente

Uma revisão geral de código e uma revisão de segurança respondem a perguntas diferentes. A primeira pergunta se a implementação está correta e pode ser mantida. A segunda pergunta como um invasor, uma dependência comprometida, uma entrada maliciosa ou um agente interno com privilégios excessivos pode fazer o sistema violar seus requisitos de segurança. Juntar as duas em uma única caixa de seleção esconde a distinção.

O OWASP Application Security Verification Standard oferece às equipes um vocabulário útil para esse trabalho. O ASVS define níveis de verificação com rigor crescente e agrupa requisitos em áreas como autenticação, controle de acesso, validação, criptografia, registros, proteção de dados, APIs e configuração. Eu não copiaria todo o padrão para cada pull request. Relacione os caminhos sensíveis do produto aos requisitos aplicáveis e torne esses requisitos visíveis quando uma alteração tocar neles.

O NIST SP 800-218 apresenta um ponto relacionado em seu Secure Software Development Framework. A prática de revisão de projeto pede uma pessoa qualificada que não tenha participado do projeto, processos automatizados instalados na cadeia de ferramentas, ou ambos, e solicita que as equipes registrem as descobertas como artefatos. A qualificação importa. Uma segunda aprovação aleatória não cumpre a intenção quando nenhum dos revisores entende o limite de confiança que está sendo alterado.

Análise estática de segurança de aplicações, verificação de segredos e análise de dependências são controles úteis, mas não conseguem decidir se um enfermeiro deve ver o prontuário de determinado paciente ou se uma regra de reembolso permite abuso. As ferramentas encontram padrões. As pessoas precisam inspecionar a autorização de negócio, o isolamento entre locatários, o comportamento diante de falhas, o significado da auditoria e a relação entre os dados coletados e os dados realmente necessários.

Para uma alteração de segurança de nível 3, exija um caso curto de abuso junto ao caso normal de aceitação. Um bom caso de abuso identifica um agente, a capacidade que ele não deveria ter, o caminho que pode tentar e o controle que o bloqueia. Por exemplo: um usuário de suporte altera o identificador da conta em uma solicitação; a autorização no servidor rejeita a solicitação antes da busca do registro; a entrada de auditoria registra a tentativa negada sem armazenar os dados sensíveis.

O nível 4 precisa de um modelo de ameaças antes que a implementação fique cara de mudar. Mantenha-o concreto: ativos, limites de confiança, pontos de entrada, capacidades do invasor, controles e decisões não resolvidas. O responsável por segurança deve revisar o modelo e o código, enquanto o responsável pelo serviço verifica suposições operacionais como disponibilidade de identidade, comportamento do relógio, retenção de dados e reversão.

Não aprove código sensível porque a IA o explica de maneira convincente. Explicações geradas podem justificar a implementação recebida, inclusive quando ela contém uma falha. Relacione toda afirmação de segurança a um teste, uma configuração, uma decisão de projeto revisada ou um comportamento observado da plataforma.

Alterações de dependências trazem código invisível no diff

Uma edição de uma linha no manifesto pode adicionar milhares de linhas de código executável por meio de dependências diretas e indiretas. Isso transforma alterações de dependência em uma dimensão separada de revisão, não em uma pequena variação da revisão de código-fonte. Eleve qualquer dependência nova de execução e qualquer reescrita relevante do arquivo de bloqueio para pelo menos o nível 2. Eleve mais se o pacote rodar durante a compilação, lidar com dados não confiáveis, receber segredos ou executar em um serviço sensível.

Uma verificação de dependências deve responder quais pacotes foram adicionados, removidos e atualizados; se pacotes indiretos mudaram; se vulnerabilidades conhecidas se aplicam; quais licenças entram no produto; e se o registro e a identidade esperados do pacote correspondem. A revisão de dependências do GitHub, por exemplo, compara alterações entre os commits de base e de destino e pode aplicar um limite de falha em um pull request. Outros sistemas de hospedagem têm equivalentes. O resultado da política importa mais do que o fornecedor.

Não aceite um diff enorme do arquivo de bloqueio com a explicação de que o gerenciador de pacotes o criou. Gere o arquivo novamente a partir do manifesto declarado usando o gerenciador fixado no repositório e compare o resultado. URLs inesperadas de registro, scripts de ciclo de vida, nomes de pacotes parecidos, alterações de integridade e atualizações não relacionadas merecem investigação.

Novas dependências também precisam de uma verificação humana de necessidade. As equipes muitas vezes adicionam um pacote porque o código gerado o importa e depois verificam apenas se ele tem uma vulnerabilidade publicada. Pergunte se a biblioteca padrão ou uma dependência existente já resolve a tarefa, se o pacote recebe manutenção ativa, qual código roda durante a instalação e qual seria a dificuldade de removê-lo. Bancos de dados de vulnerabilidades informam defeitos conhecidos; não conseguem dizer que um pacote amplia a confiança sem necessidade.

Para liberações de nível 3 e 4, preserve uma lista de materiais de software quando o sistema de compilação puder produzi-la e mantenha a procedência do artefato compilado. O SLSA trata procedência como informação verificável sobre onde, quando e como um artefato foi produzido. Isso não prova que o código é seguro, mas permite que um revisor conecte o artefato implantado ao código-fonte e ao processo de compilação revisados.

Aprovadores explícitos evitam confirmações vazias

Duas aprovações não ajudam se os dois revisores presumirem que o outro verificou segurança, comportamento dos dados e implantação. Toda aprovação obrigatória deve ter uma preocupação nomeada. Os responsáveis pelo código podem encaminhar uma alteração para pessoas, mas o modelo do pull request deve dizer a cada pessoa qual decisão ela assume.

Use funções que correspondam ao risco: responsável pela implementação, pelo domínio, pela segurança, pelos dados e pela liberação. Uma alteração de nível 2 pode precisar apenas de um responsável pela implementação. Uma migração que muda dados de pacientes pode precisar de um responsável pelo domínio para confirmar o significado, um responsável pelos dados para verificar migração e recuperação e um responsável por segurança ou privacidade para conferir a exposição. Uma pessoa pode exercer duas funções se tiver qualificação, mas o registro deve informar isso.

O autor não pode fornecer a aprovação independente. A pessoa que deu instruções à IA também não deve ser considerada independente apenas porque o modelo produziu o código. O autor é responsável pela alteração: entendê-la, editá-la, testá-la e explicar seus limites. Se não consegue explicar um desvio ou uma dependência, a revisão deve parar até que consiga.

Comentários de aprovação devem registrar uma decisão, não uma confirmação social. Uma aprovação útil de nível 3 poderia dizer: revisei o isolamento entre locatários nas camadas de consulta e serviço; reproduzi a negação para um usuário de outro locatário; verifiquei a reversão da migração em uma cópia de dados representativos; aceito o risco restante de que a reversão exija uma breve pausa de gravação. Essa nota oferece algo concreto ao responsável pela liberação e a uma futura pessoa investigando um incidente.

Descarte aprovações quando o autor enviar uma alteração material depois da revisão. Defina o que é material de forma mecânica sempre que possível: alterações em caminhos protegidos, arquivos de dependências, migrações, permissões ou um diff maior do que o pequeno limite configurado. Um erro de digitação em um comentário não deve reiniciar uma revisão de três pessoas, mas um novo tratamento de erro em um caminho de autorização deve.

Evite aprovação por exaustão. Pull requests grandes e gerados são difíceis de revisar porque o modelo pode produzi-los rapidamente e o revisor ainda lê em velocidade humana. Defina um limite de tamanho revisável e exija que o autor divida alterações independentes ou forneça uma sequência de commits que separe edições mecânicas de mudanças de comportamento. Não reduza o exame porque dividir a alteração parece inconveniente. Se o código não puder ser separado, eleve o nível e reserve tempo de revisão focada.

Uma equipe distribuída também precisa de uma passagem de trabalho clara. Registre quais verificações faltam, quem pode aprová-las e se a implantação está bloqueada. A SaaS Production usa engenheiros experientes para controlar seu processo de desenvolvimento assistido por IA, uma divisão adequada do trabalho: a IA acelera a produção, enquanto as pessoas mantêm as decisões que exigem contexto e responsabilidade.

A saída da IA exige verificação além do diff

Os revisores precisam inspecionar as suposições em torno do código gerado, não apenas sua sintaxe. A IA pode chamar uma API inexistente, usar uma API real na versão errada, inventar um campo de configuração, copiar um padrão de segurança ultrapassado ou ampliar silenciosamente o comportamento solicitado. O código resultante pode compilar se mocks ou tipos flexíveis esconderem o erro.

Peça ao autor para declarar o uso de IA no nível da alteração, não para relatar toda sugestão aceita. O registro útil diz quais arquivos ou funções foram gerados de forma substancial, qual modelo forneceu o rascunho se a política exigir essa informação, qual material externo entrou no prompt e o que o autor verificou de forma independente. Não cole prompts sensíveis nem dados proprietários no pull request. A declaração existe para direcionar o trabalho de revisão e apoiar a procedência, não para constranger o autor.

Verifique afirmações relacionadas ao código em fontes autorizadas. Se o código gerado usa uma opção de segurança de um framework, leia o manual da versão instalada e confira o valor padrão. Se chama um serviço em nuvem, compare solicitação e resposta com o esquema oficial da API. Se implementa um protocolo, teste o comportamento correspondente do RFC. A memória do modelo não é evidência, e uma citação convincente que ninguém abriu é pior do que nenhuma citação porque pode encerrar a revisão cedo demais.

Alterações geradas precisam de uma verificação de escopo em relação ao pedido. Compare a tarefa aceita com o diff e liste comportamentos que a alteração adiciona além dessa tarefa. Observe novos registros, telemetria, comportamentos alternativos, dependências, configuração, chamadas de rede e recuperação de erros. Esses extras costumam parecer úteis, mas podem criar consequências de privacidade, custo e segurança que ninguém pediu para aceitar.

Verifique a exposição de dados nos dois sentidos. Revise o que o autor enviou ao sistema de IA segundo as regras da organização e depois o que o código gerado envia durante a execução. Uma função auxiliar aparentemente inofensiva pode serializar um objeto inteiro quando a API precisa de dois campos. Os testes devem confirmar o formato de saída e garantir que logs, exceções e análises excluam segredos e dados regulamentados.

Por fim, exija responsabilidade sem pedir uma reescrita manual para manter as aparências. Fazer as pessoas redigitarem código gerado não o torna mais seguro. Exigir que expliquem invariantes, reproduzam testes, verifiquem APIs, removam escopo desnecessário e respondam à revisão torna o processo mais seguro. O padrão é compreensão apoiada por evidências.

Exceções precisam de validade e plano de recuperação

Incidentes em produção às vezes justificam integrar uma alteração com evidências incompletas, mas a urgência não elimina o controle ausente. Uma exceção deve identificar a verificação que falhou ou foi ignorada, o dano imediato que a alteração evita, a pessoa que aceita o risco adicional, o limite de exposição, o gatilho de reversão e o momento em que a revisão normal será concluída.

Mantenha a alteração de emergência o menor possível. Evite adicionar dependências, fazer refatorações oportunistas, alterações gerais de formatação e correções geradas não relacionadas. Use uma opção de recurso, limite de tráfego, configuração direcionada ou correção reversível quando o sistema permitir. Coloque o autor ao lado do comandante do incidente ou responsável pelo serviço e registre comandos e observações no histórico do incidente.

Algumas verificações devem continuar obrigatórias mesmo durante um incidente. O código deve vir de um colaborador autenticado, a compilação deve identificar o commit, testes básicos devem rodar a menos que o próprio sistema de testes esteja quebrado, a verificação de segredos não pode apontar uma credencial nova e uma pessoa nomeada deve autorizar a produção. Se uma verificação não puder rodar, registre esse fato e use a melhor avaliação independente disponível. O silêncio não substitui uma verificação.

Defina uma validade medida em horas ou dias, conforme o sistema, e não uma exceção sem fim. A revisão posterior deve decidir se mantém, substitui ou reverte a alteração de emergência. Também deve acrescentar o teste ausente e examinar por que o caminho normal não respondeu rápido o bastante. Acompanhe esse trabalho como parte do incidente, com um responsável e prazo.

Nunca crie um nível baixo permanente para correções rotuladas como urgentes. Esse rótulo vai se espalhar para o trabalho normal. Preserve um caminho de exceção com registro mais rigoroso e revisão posterior, depois meça a frequência de uso pelas equipes. Exceções frequentes costumam apontar testes lentos, responsáveis indisponíveis, políticas confusas ou implantações difíceis demais de reverter.

Ajuste os níveis com evidências das liberações

Uma política de revisão deve mudar quando as evidências de produção mostram que ela encaminha mal o trabalho. Registre o nível atribuído, o motivo, o tempo de revisão, quais verificações encontraram um problema, alterações solicitadas depois da aprovação, referências de reversão ou incidente e se uma exceção foi usada. Não transforme esses registros em uma disputa pela velocidade do revisor.

Procure erros de encaminhamento. Se alterações de nível 1 causam repetidamente correções em produção, os caminhos protegidos ou as condições de entrada são fracos demais. Se alterações de nível 3 esperam dias enquanto os revisores não encontram nada além da suíte normal de testes, o nível pode estar exigindo o especialista errado ou duplicando uma verificação automatizada confiável. Se análises de segurança relatam o mesmo padrão sem ação repetidamente, ajuste a regra e documente o motivo em vez de ensinar os revisores a ignorar compilações vermelhas.

Amostre alterações aprovadas, não apenas as que falharam. Uma revisão periódica feita por um engenheiro experiente pode comparar o diff, as evidências, o nível e o resultado em produção. O objetivo é encontrar confiança falsa: aprovações sem uma decisão atribuída, testes que não cobriram a afirmação de risco, revisões de dependências que perderam alterações indiretas ou planos de reversão que nunca poderiam ser executados.

Mantenha a primeira implementação simples. Coloque a tabela de níveis no repositório, proteja caminhos sensíveis, exija verificações de status, atribua responsáveis pelo código e acrescente campos para a afirmação de risco, evidências, reversão e verificação da IA. Depois de vários ciclos de liberação, ajuste o mapeamento com as falhas e os atrasos observados.

A revisão humana é suficiente quando uma pessoa independente com o conhecimento certo do domínio consegue relacionar toda afirmação material a evidências e pode interromper a liberação. Para um trabalho de baixa consequência, isso pode levar minutos. Para código capaz de expor prontuários, mover dinheiro, conceder autoridade ou corromper dados, a equipe deve à produção uma decisão mais lenta e explícita, não importa a velocidade com que o primeiro rascunho apareceu.

Perguntas Frequentes

Todo código gerado por IA precisa de revisão humana?

Sim, código de produção precisa de revisão humana responsável, mas nem todo código exige a mesma profundidade. Encaminhe uma edição restrita e reversível de forma diferente de uma alteração em permissões, pagamentos, dados de saúde, implantação ou confiança na compilação.

Testes automatizados podem substituir um revisor humano?

Não. Os testes podem provar comportamentos selecionados, enquanto um revisor verifica se o comportamento, o escopo, as suposições e o risco escolhidos estão certos. Uma automação forte pode reduzir a inspeção rotineira, mas uma pessoa deve assumir a decisão de produção.

Como uma equipe deve classificar uma alteração pequena mas sensível?

A sensibilidade deve superar a contagem de linhas. Uma alteração mínima em autorização, criptografia, segredos, migrações ou identidade de produção pertence a um nível mais alto porque sua consequência pode ser grande e difícil de reverter.

Os revisores devem saber qual código foi escrito por IA?

Eles devem saber quais partes foram geradas de forma substancial para inspecionar suposições e evidências de verificação. A declaração deve direcionar a atenção, não dispensar o autor de entender cada linha.

Quantos aprovadores uma alteração de IA de alto risco deve ter?

Use pelo menos dois revisores independentes para alterações sensíveis ou amplas, com responsabilidade definida pelos domínios afetados. Alterações graves podem precisar de responsáveis por segurança, dados e liberação, mas assinaturas extras sem experiência relevante acrescentam pouco.

Quais análises de segurança devem rodar em código assistido por IA?

Rode análise estática adequada à linguagem, verificação de segredos e controles de dependências como base para alterações normais de produção. Acrescente modelagem de ameaças, testes de uso indevido e revisão manual de autorização e fluxo de dados quando o código tocar em um limite sensível.

Como revisar atualizações de dependências geradas por IA?

Inspecione alterações diretas e indiretas, vulnerabilidades conhecidas, licenças, identidade do registro, dados de integridade e scripts de instalação. Uma pessoa também deve decidir se a nova dependência é necessária, pois os analisadores não julgam uma ampliação evitável da confiança.

Uma correção urgente em produção pode ignorar os níveis?

Ela pode usar um caminho de exceção documentado, mas ainda precisa de autor autenticado, commit identificado, evidência básica, uma pessoa nomeada para aprovar a produção e um gatilho de reversão. Dê validade à exceção e conclua a revisão ausente depois do incidente.

Que evidências um pull request de código com IA deve incluir?

Inclua a afirmação de comportamento arriscado, resultados de testes direcionados ligados ao commit, resultados das análises exigidas, alterações de dependências e um plano de reversão quando ela não for simples. Para código gerado, acrescente as APIs e suposições que o autor verificou de forma independente.

Com que frequência os níveis de revisão devem ser atualizados?

Revise os níveis depois de liberações suficientes para enxergar erros recorrentes de encaminhamento e imediatamente após uma falha grave expor uma regra ruim. Use achados de testes, incidentes, exceções e amostras de aprovações em vez de alterar a política apenas por opinião.