--- title: "A IA da OpenAI ganhou autorização para barrar merges por falhas de segurança" author: "Gustavo Ramos O. Klein" date: "2026-09-11 09:30:00-03" category: "Inteligência Artificial & Dados" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/11/a-ia-da-openai-ganhou-autorizacao-para-barrar-merges-por-falhas-de-seguranca/md" --- ## Resumo - A OpenAI tornou obrigatória a revisão de pull requests por modelos de IA em seu pipeline interno. - Os modelos podem bloquear merges quando encontram vulnerabilidades de segurança ou falhas de lógica, sem intervenção humana para aplicar o bloqueio. - A IA também atua em atualizações de dependências, regressões, refatorações e resolução de conflitos de merge. - O sistema processava mais de 100 mil pull requests externos por dia em dados internos de outubro de 2025. - O comando /review permite que engenheiros verifiquem o código antes do envio, e 52,7% dos comentários dos modelos geram mudanças dos autores. - A equipe do Codex explora testes funcionais com cliques e capturas de tela, enquanto reduz ferramentas de suporte como o /goal. - O papel humano se desloca para o planejamento e a definição da intenção que o código deve cumprir. --- Na **OpenAI**, o código escrito por engenheiros passou a conversar com um revisor que não apenas sugere mudanças, mas também pode interromper o caminho até a produção. O sistema usa modelos de inteligência artificial para analisar obrigatoriamente os pull requests, que são pedidos para incorporar alterações ao código, e bloquear o **merge**, etapa em que essas alterações entram na base principal, quando encontra riscos de segurança ou falhas de lógica. Como a restrição pode ser aplicada sem intervenção humana, a revisão deixa de funcionar apenas como uma segunda opinião e passa a operar como uma barreira automática no fluxo de desenvolvimento. A proposta ajuda a entender como a OpenAI está conectando planejamento, implementação, testes e manutenção em uma mesma conversa técnica. ## Quando a IA ganha autoridade sobre o merge O bloqueio automático está inserido em um sistema de revisão **mandatório** dentro da OpenAI, aplicado aos pull requests de seus engenheiros. Na prática, o modelo examina a alteração antes que ela seja incorporada e pode impedir o avanço quando identifica uma vulnerabilidade de segurança ou um problema lógico. O detalhe que muda a relação entre pessoa e ferramenta está na autoridade: o revisor não depende de um engenheiro para transformar o alerta em impedimento, porque a própria automação aplica o bloqueio. Em uma analogia diplomática, a IA não está apenas participando da reunião entre equipes; ela recebeu poder para fechar a fronteira quando o código apresenta um risco que não foi resolvido. Segundo **Thibault Sottiaux**, líder de engenharia do time Codex, os modelos são considerados **"superhumanos"** em revisão de código. A avaliação mencionada pela OpenAI cobre tanto a correção lógica quanto a segurança, duas dimensões que costumam se cruzar quando uma alteração funciona em um teste, mas abre uma possibilidade de uso indevido em outro. A consequência prática é uma mudança no ponto de concentração das pessoas: em vez de revisar manualmente cada detalhe depois da implementação, os engenheiros passam a dedicar mais atenção à intenção que o código deve cumprir e ao planejamento da tarefa. A ponte entre a ideia e a execução fica mais explícita, porque o modelo assume parte da conferência da implementação. ## Uma revisão que acompanha o código depois da escrita Essa autoridade sobre o merge é apenas uma parte do trabalho atribuído aos modelos. A OpenAI também usa a IA para administrar **atualizações de dependências**, investigar regressões e executar refatorações complexas. Dependências são componentes externos dos quais um software precisa para funcionar; regressões aparecem quando uma mudança quebra algo que já funcionava; e refatoração reorganiza o código sem alterar o resultado esperado. Explicar esses termos ajuda a enxergar a extensão da proposta: o modelo não atua somente como um porteiro que decide se uma alteração entra, mas também como uma equipe de manutenção que acompanha as conexões entre diferentes partes do sistema. O código, nesse fluxo, é tratado como uma rede de relações que precisa continuar coerente depois de cada mudança. Na rotina do time Codex, a automação também resolve **conflitos de merge** a cada poucas horas, um procedimento necessário quando duas alterações disputam o mesmo trecho de código. A equipe realiza ainda buscas aleatórias por bugs em arquivos escolhidos por um gerador de números aleatórios, criando uma forma de procurar problemas fora das áreas que os engenheiros esperavam examinar. Em outra frente, agentes analisam pull requests do dia anterior e aplicam correções silenciosamente antes que determinadas falhas sejam percebidas. Essas práticas mostram uma revisão que se conecta ao trabalho diário, em vez de aparecer apenas no final do processo, quando o custo de descobrir um defeito já pode ser maior. ## Escala, comando local e retorno dos engenheiros O volume de trabalho ajuda a explicar por que a OpenAI recorreu a esse tipo de integração. Dados internos de **outubro de 2025** indicam que o sistema processava mais de **100 mil pull requests externos por dia**. Para os próprios engenheiros, a interface inclui o comando **/review** na linha de comando do Codex, permitindo uma verificação antes do envio da alteração. Linha de comando é a interface textual em que a pessoa executa instruções diretamente, sem depender de telas gráficas. O desenho aproxima a revisão da mesa de trabalho de quem programa: a conversa com o modelo acontece antes do código atravessar a fronteira do repositório. A OpenAI detalha essa estratégia em seu [post sobre verificação de código em escala](https://alignment.openai.com/scaling-code-verification/). O número de análises, porém, não é o único indicador usado para medir a utilidade do revisor. Quando o modelo deixa um comentário, os autores fazem a alteração solicitada em **52,7% dos casos**, segundo os dados apresentados pela OpenAI. A empresa afirma ainda que o sistema preveniu falhas críticas e validou experimentos de alto impacto, funcionando como um monitor complementar a outras estratégias de defesa em profundidade. Essa expressão descreve o uso de camadas diferentes de controle, de modo que uma falha em uma etapa não deixe todo o processo sem proteção. O retorno dos engenheiros também cria um diálogo: o modelo aponta, a pessoa decide como corrigir e o código volta para uma nova avaliação. ## Do código lido ao resultado observado A equipe do Codex está testando uma ampliação dessa conversa: verificar o resultado funcional do software, e não apenas ler o código como sinal de qualidade. Em uma interface, isso pode significar **clicar em elementos** e produzir capturas de tela para conferir o que realmente aconteceu. A diferença é simples de entender. Uma revisão textual examina as instruções que deveriam produzir determinado comportamento; uma verificação funcional observa se o comportamento apareceu na prática. Quando a IA combina essas duas perspectivas, ela passa a avaliar a ponte inteira entre a intenção de uma alteração e a experiência entregue por ela. O trabalho ainda aparece nas fontes como uma frente explorada pela equipe, não como uma promessa de que toda revisão já ocorre dessa maneira. Essa busca por resultados observáveis reforça a mudança na divisão de tarefas dentro da OpenAI. O modelo pode procurar vulnerabilidades, acompanhar regressões, sugerir correções e verificar uma interface, enquanto a pessoa precisa definir com clareza o que deve ser construído e quais condições caracterizam um resultado aceitável. A fronteira entre quem escreve e quem revisa fica menos rígida, porque a IA participa de vários pontos do ciclo. Para o engenheiro, a pergunta deixa de ser somente se o código está bem escrito e passa a incluir se a intenção foi traduzida corretamente para o sistema. Essa transição dá sentido ao foco humano em planejamento mencionado pela empresa. ## Menos andaimes, mais autonomia para os modelos O movimento também aparece na infraestrutura criada para orientar os agentes. Sottiaux explicou que ferramentas como o comando **/goal**, desenvolvido para manter o modelo concentrado em tarefas longas, estão sendo removidas à medida que os modelos conseguem manter o contexto por conta própria. Nesse vocabulário, *scaffolding* ou *harness* significa o conjunto de suportes, instruções e mecanismos colocados ao redor do modelo para conduzir sua execução. Retirar esses suportes não significa abandonar o controle do código; significa testar se o modelo consegue executar uma tarefa com menos condução externa. A equipe descreve essa retirada como uma decisão deliberada para evitar construir estruturas que podem se tornar obsoletas em poucos meses com a evolução da capacidade de raciocínio. O resultado é uma relação diferente entre automação e engenharia: o sistema ganha mais autonomia para revisar e corrigir, enquanto as pessoas precisam atuar antes, definindo intenção, limites e critérios de aceitação. A **OpenAI** combina esse movimento com bloqueios automáticos de merge, revisão antes do envio, busca de bugs e validação funcional, criando pontos de contato diferentes entre o modelo e o código. Para uma equipe que avalia adotar abordagem semelhante, a lição prática é separar as funções: deixar explícito o que a IA deve verificar, identificar em qual etapa ela pode interromper o fluxo e registrar como os engenheiros respondem aos comentários. O próximo passo não é entregar o projeto inteiro ao revisor, mas construir uma ponte em que autonomia e responsabilidade tenham papéis definidos.