A Era do Código de Revisão da IA - Quem Revisa o Código Escrito pela IA?

Na última publicação (AI173), eu incluí a “verificação” como a terceira nova gargalo após o código quase gratuito, e finalizei com a promessa de discutir isso em uma seção separada. Agora é a hora de cumprir essa promessa. Vamos começar com a conclusão: ao olhar para trás em 2026, a maior variável na entrega de ferramentas de programação de IA não é o número de licenças, nem o número de assentos, nem a pontuação do modelo, mas a largura de banda de revisão.

Observação: A tradução foi feita de acordo com as instruções fornecidas, mantendo a estrutura do Markdown e utilizando expressões idiomáticas em português.

Aprendizado Lento de IA: Análise de Código Gerado por IA

Um relatório da CodeRabbit, publicado no final de 2025, analisou 470 solicitações de pull request (PR) de código aberto no GitHub e chegou a uma conclusão surpreendente: o código gerado por IA apresenta 1,7 vezes mais defeitos do que o código escrito puramente por humanos (em média, 10,83 vs 6,45 defeitos por PR, sem considerar o tamanho e a complexidade do arquivo). Além disso, os resultados mostraram que as vulnerabilidades de segurança são 1,57 a 2,74 vezes mais frequentes em código gerado por IA, incluindo:

XSS (Cross-Site Scripting): 2,74 vezes mais frequente
Tratamento inadequado de senhas: 1,88 vezes mais frequente
Referências diretas inseguras: 1,91 vezes mais frequente
Deserialização insegura: 1,82 vezes mais frequente
Lógica e correção: 1,75 vezes mais frequente
Legibilidade: 3 vezes mais frequente
Formatação: 2,66 vezes mais frequente
Tratamento de erros: quase 2 vezes mais frequente

Outro estudo, realizado pela Apiiro em setembro de 2025, analisou repositórios de empresas da Fortune 50 (dados coletados entre dezembro de 2024 e junho de 2025) e descobriu que o uso de código gerado por IA resultou em um aumento de 10 vezes no número de descobertas de segurança mensais (de cerca de 1000 para mais de 10.000). Além disso, os resultados mostraram que as vulnerabilidades de elevação de privilégios aumentaram 322% (em números absolutos; considerando o crescimento do código, a estimativa é de um aumento de 60-80%), enquanto os defeitos de design de arquitetura aumentaram 153%. No mesmo período, os erros de sintaxe diminuíram 76% e os bugs lógicos diminuíram 60%.

Aprendendo AI Lentamente

Dois conjuntos de dados que revelam uma verdade importante, especialmente no contexto da regulação

Os dados da Apiiro mostram um aumento de 322% nos vulnerabilidades de elevação de privilégios, e uma parte significativa dessas vulnerabilidades está relacionada às fronteiras de permissão. No setor financeiro e de telecomunicações, essas fronteiras correspondem a fundos e dados de clientes. O código escrito por IA pode ser executado, mas os defeitos e vulnerabilidades aumentam proporcionalmente, e os mais perigosos estão aumentando secretamente.

(O relatório da CodeRabbit é de uma empresa de fornecedora, enquanto os dados da Apiiro vêm de uma empresa de segurança de terceiros. Embora as conclusões sejam semelhantes, é importante entender as diferenças nos métodos de coleta de dados.)

Essa realidade tem implicações importantes para as empresas, desencadeando duas percepções contrárias à intuição, que contradizem a narrativa de vendas dos ferramentas.

Dois pontos contrários à intuição

Ponto 1: O papel do desenvolvedor muda de “pessoa que escreve código” para “pessoa que revisa código”, mas revisar é mais trabalhoso do que escrever.

(O restante do texto será traduzido de acordo com as instruções fornecidas)

Aprendendo AI Lentamente 001

A JetBrains realizou uma pesquisa em janeiro de 2026, envolvendo mais de 10.000 desenvolvedores em 8 idiomas, e descobriu que 90% dos desenvolvedores usam pelo menos um ferramenta de inteligência artificial (IA). Outra pesquisa realizada pelo Pragmatic Engineer em fevereiro de 2026 trouxe uma informação ainda mais preocupante: 56% dos engenheiros experientes disseram que mais de 70% de seu trabalho de engenharia depende de ferramentas de IA (incluindo desenvolvedores que usam intensivamente essas ferramentas). Isso não é apenas usar IA para escrever algumas linhas de código; é um modo de trabalho padrão. A relação de produção foi mudada: escrever código se tornou uma tarefa que é feita por IA, e os desenvolvedores passam mais tempo lendo e avaliando do que escrevendo. Ler código alheio já é mais difícil e demorado do que escrever; ler código escrito por IA, além disso, requer julgamento sobre conformidade e regras de negócios, aumentando significativamente a carga cognitiva em relação a escrever código próprio. Isso é a causa subjacente da declaração de 2025-2026 de que “IA me deixou mais cansado” feita pelos desenvolvedores - e é uma declaração que foi parcialmente revertida pela pesquisa METR 2026.2 (que inicialmente concluiu que os desenvolvedores experientes eram atrasados em 19% devido à IA, mas que essa conclusão foi parcialmente revertida com uma amostra mais nova, que ainda mostrou uma perda de -4% para os desenvolvedores novos, levando a uma conclusão geral de que “a capacidade de avaliação é mais limitada do que a capacidade de produção”).

Contra-intuição 2: Ferramentas de IA mais avançadas significam que as organizações precisam de mais governança, não mais ferramentas.

Aprendendo Devagar sobre IA: A Armadilha da Automatização

A falha de 1,7 vezes de defeitos no CodeRabbit e a vulnerabilidade de 322% de privilégios no Apiiro podem parecer fracassos da IA quando analisados isoladamente. No entanto, quando observados através da lente da teoria das restrições, revelam-se como consequências inevitáveis do aumento da capacidade de produção das ferramentas, enquanto a capacidade de revisão não acompanha o ritmo.

A saída de um sistema é determinada pelo gargalo mais estreito. A IA ampliou a capacidade de “escrever”, tornando a “revisão” o novo gargalo mais estreito. No entanto, a largura de banda da revisão não consegue acompanhar o ritmo, tornando a acumulação de dívidas organizacionais cada vez mais perigosa à medida que a IA escreve mais rápido.

Essa é a conclusão da IA173: a automatização não elimina os gargalos, apenas os reorganiza. Ao aplicar essa ideia ao desenvolvimento de software, é necessário acrescentar que o desenvolvimento de software não é um processo linear com um único gargalo, mas sim um processo paralelo com múltiplos gargalos que se deslocam dinamicamente.

A teoria das restrições (TOC) se aplica bem a cenários de linha de produção, mas no desenvolvimento de software com IA, o gargalo mais estreito se desloca de “escrever” para “revisar”, e dentro da revisão, há três subprocessos independentes que se tornam gargalos: validação, governança e revisão de conformidade.

Aprendizado Lento de IA

A implementação prática desta regra tem duas camadas. A primeira é garantir que as quatro “freias” estejam instaladas antes de permitir que os agentes autônomos atuem — revisão de código manual obrigatória, testes automatizados (o código alterado pelo AI deve ser executável), varredura de segurança (com os mesmos padrões de código manual) e lançamento gradual (alterações do AI devem ser implantadas em pequena escala primeiro). O PR do AI não pode ser dispensado da revisão.

Isso é o mínimo necessário para transformar o problema de engenharia de “AI escrevendo código” em “AI escrevendo código + organização capaz de lidar com isso”. Faltando uma dessas etapas, há um risco de perda de controle. Carlini registrou um exemplo frequentemente citado em janeiro e fevereiro de 2026: pesquisadores da Anthropic fizeram 16 agentes Claude Opus 4.6 trabalharem em paralelo por 2 semanas, cerca de 2000 sessões e cerca de US$ 20.000 em custos de API, para escrever um compilador C baseado em Rust de 100.000 linhas, capaz de compilar o kernel Linux 6.9 e passar no teste de tortura do GCC 99%. É importante destacar que este é um experimento controlado em um domínio fechado, e Carlini não implantou o código em produção; usar isso como um “contraste extremo sem revisão” é útil, mas usar como um modelo para “implantar agentes autônomos imediatamente” superestima a reutilização.

Em organizações sem revisão de código, testes automatizados, varredura de segurança e lançamento gradual, problemas irão ocorrer eventualmente.

Aprendendo AI Lentamente <002>

A Segunda Camada: Revisão de Código em uma Era de AI

A segunda camada de revisão de código é mais sutil e envolve julgamentos mais complexos. Em vez de apenas procurar por bugs, a revisão de código em uma era de AI envolve avaliar se a arquitetura está alinhada, se as fronteiras de conformidade estão sendo respeitadas e se a lógica de negócios está correta. Os engenheiros mais experientes tendem a cair na armadilha de tratar a revisão de código em uma era de AI da mesma forma que a revisão de código tradicional.

A revisão de código tradicional se concentra em verificar se o código está correto, enquanto a revisão de código em uma era de AI se concentra em verificar se o código está no lugar certo, com as permissões certas e configurações padrão adequadas. Os problemas identificados por ferramentas como CodeRabbit (1,82-2,74 vezes mais vulnerabilidades de segurança) e Apiiro (322% mais vulnerabilidades de privilégio) são exemplos desses problemas. Esses problemas não podem ser resolvidos apenas com a ajuda de IDEs, mas sim com uma revisão cuidadosa.

Uma prática comum na indústria é usar a proteção de branch do GitHub/GitLab e regras de CODEOWNERS para rotular alterações críticas em esquemas, autenticação, faturamento e fronteiras de conformidade, exigindo uma aprovação de duas pessoas (em prática, geralmente é um veto de backup, e não uma revisão completa, com uma proporção de spot-checks variando de acordo com o nível de risco).

A documentação de decisões arquiteturais (ADR), linhas de base de segurança e conformidade, e a correção das regras de negócios são os verdadeiros pontos de foco para a revisão de código em uma era de AI.

Aqui está a tradução do texto para o português:

Agora que temos essas duas ideias contraintuitivas em mente, a imagem fica clara: na era da IA, a revisão de código exige que as empresas ajustem três coisas - envolver os gerentes de desenvolvimento no processo de revisão, incluir conformidade e linhas de base de arquitetura nas rotas de PR e relatar indicadores de governança, como taxas de falha, ao conselho de administração.

Essas três medidas correspondem diretamente às “três linhas de defesa de governança de modelos” exigidas pelo “Regulamento de Administração de Empréstimos de Internet para Bancos Comerciais“ (negócios, TI e auditoria de conformidade), que são facilmente compreendidas pelos reguladores. Abaixo, vamos expandir essas ideias em quatro camadas.

II. Por que é “agora”: o mecanismo de validação como novo gargalo

Vamos cumprir a promessa feita na seção 3 do AI173. A singularidade da janela de 2026: os agentes autônomos (Claude Code, Codex) estão passando de “teste” para “uso padrão”; as organizações que não atualizaram a revisão de código até o início do segundo semestre serão atingidas por uma onda de problemas no quarto trimestre, durante o período de promoções de fim de ano e inspeções regulamentares.

Vamos explicar por que a “validação” é subestimada no novo gargalo e, em seguida, vamos colocar isso junto com os outros dois gargalos (definir o problema certo e integração de sistemas) em uma imagem.
Efeito tesoura: volume de código 6×, capacidade de revisão 1.3×
H1 2024 → H1 2026 quantidade relativa (linha de base = 1×); Gap = acúmulo de risco

Tempo Quantidade relativa

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

Geração de código por IA 6× Capacidade de revisão 1.3×

Gap = acúmulo de risco (defeitos +1.7×, vulnerabilidades +1.82–2.74×, escalação de privilégios +322%)
Proporções são esquemáticas e direcionais, baseadas em JetBrains 2026.1, CodeRabbit 2025.12 e Apiiro 2025.9

A raiz do problema está subestimada: na maioria das discussões sobre programação de IA, a “verificação” é automaticamente associada a CI/CD, testes unitários e lint.

Este é o mundo dos produtos da internet: o código é implantado na nuvem, os testes unitários estão todos verdes, o CI é aprovado, o merge é feito e o código vai para produção. Este fluxo de trabalho funciona bem no ritmo dos produtos da internet, mas não funciona quando aplicado a setores como telecomunicações, finanças, manufatura e comércio eletrônico: nestes setores, a “verificação” envolve a aprovação de algoritmos, avaliação de segurança de dados, avaliação de saída de dados, aprovação de mudanças pelo Change Advisory Board (CAB) (Change Advisory Board), auditoria de contas e relatórios regulamentares, que não têm nada a ver com o código e podem levar semanas. O AI173 já apresentou um gráfico (aceleração de codificação, gargalo na verificação), que não será repetido aqui. O ponto importante é a pergunta que ele deixa: quantas verificações o código gerado por IA precisa passar para ir para produção?

Sete etapas para começar: testes automatizados + revisão de código + varredura de segurança + revisão de arquitetura/ADR + revisão de regras de negócios + liberação de conformidade + lançamento em escala. Cada etapa consome uma parcela de largura de banda. Essas sete etapas juntas são o “outro lado” do gráfico do AI173 - a aceleração da IA é a parte com o menor custo marginal (tempo de GPU, custos de licença), enquanto a verificação consome a parte com o maior custo institucional (regulamentação, aprovação, auditoria).

Subestimando o Segundo Fator: Reduzindo a “Revisão” a “Code Review”

A revisão de código, que tem duas principais fontes - o egoless programming de Weinberg (1971) e as Fagan Inspections da IBM (1976) - foi construída sobre um mesmo pressuposto: o código é escrito linha por linha, o autor é quem melhor o entende e, após a escrita, outra pessoa o lê para identificar erros. A inteligência artificial (IA) desafia esse pressuposto: o código é gerado em segundos pela IA, o autor (IA) não participa da transmissão de contexto e o leitor (desenvolvedor) se depara com um produto gerado desconhecido.

O antigo pressuposto de “identificar erros” não é mais válido, e um novo pressuposto de revisão surge: Essa linha de código deveria estar nesse arquivo? Ela não contorna as decisões arquiteturais existentes? Ela está dentro dos limites de conformidade ou fora? Sua configuração padrão não se tornará uma vulnerabilidade de segurança em produção?

Essas três perguntas exigem alguém que entenda negócios, arquitetura e conformidade para responder, e as ferramentas apenas auxiliam. Isso eleva a “revisão” de uma etapa de lint no CI/CD para uma “governança de engenharia”.

Três Camadas de Revisão: AI Pre-Review, Controle Humano e Regras de Governança

Transformando a análise anterior em uma estrutura operacional. O modelo de três camadas não é uma relação de substituição, mas sim uma relação de sobreposição - qualquer solicitação de pull (PR) passa simultaneamente pelas três camadas, cada uma lidando com um tipo de problema.

Camada 1 executa em segundos a minutos - cada linha de código escrita por AI é revisada por ferramentas. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot e Antigravity Review podem fornecer comentários em segundos a minutos após a criação de um PR, cobrindo lint, vulnerabilidades de segurança, código duplicado, nomenclatura e riscos de dependência. O orçamento para essa camada é extremamente baixo (o número de PRs pode ser alto, mas as ferramentas têm o mesmo custo de assinatura), com alta taxa de cobertura (qualquer PR é revisado) e é a base da largura de banda. No entanto, suas limitações são claras - **ela não pode resolver problemas de alinhamento de arquitetura, limites de conformidade e correção de negócios**. O relatório do CodeRabbit afirma que "automaticamente bloqueia a maioria dos problemas óbvios", mas os riscos residuais (configurações padrão, limites de permissão, tratamento de caminhos de exceção escondidos em detalhes) exigem intervenção humana. Essa camada é apenas a base, não o ponto final.

Aprenda AI Lentamente

Revisão de Segurança em Camadas: Uma Abordagem para Reduzir Riscos

Em um cenário de desenvolvimento de software em larga escala, a revisão de segurança é fundamental para garantir a confiabilidade e a segurança do código. No entanto, com a crescente adoção de tecnologias de IA, como o GPT e o Token, a revisão de segurança tornou-se ainda mais complexa.

Neste artigo, vamos discutir a importância da revisão de segurança em camadas e como ela pode ser aplicada para reduzir riscos em projetos de desenvolvimento de software.

Camada 2: Revisão de Segurança em Nível de Código

A revisão de segurança em nível de código é fundamental para garantir que o código seja seguro e não contenha vulnerabilidades. No entanto, com a crescente complexidade do código, tornou-se necessário adotar uma abordagem mais estruturada para a revisão de segurança.

Uma abordagem comum é dividir a revisão de segurança em duas camadas:

Camada 1: Revisão de segurança em nível de código, realizada por ferramentas de análise de código, como o CodeRabbit e o Apiiro.
Camada 2: Revisão de segurança em nível de horas-dias, realizada por uma equipe de especialistas em segurança, arquitetos e proprietários de negócios.

A Camada 2 é responsável por revisar as alterações de alto risco, como mudanças no esquema de banco de dados, autenticação e autorização. Essa revisão é realizada por uma equipe de especialistas que verificam se as alterações estão de acordo com as políticas de segurança da empresa.

Vantagens da Revisão de Segurança em Camadas

A revisão de segurança em camadas oferece várias vantagens, incluindo:

Redução de riscos: A revisão de segurança em camadas ajuda a identificar e corrigir vulnerabilidades antes que elas se tornem problemas.
Melhoria da eficiência: A revisão de segurança em camadas permite que a equipe de desenvolvimento se concentre em escrever código seguro, em vez de gastar tempo e recursos na revisão de segurança.
Aumento da confiabilidade: A revisão de segurança em camadas ajuda a garantir que o código seja seguro e confiável, o que é fundamental para a reputação da empresa.

Conclusão

A revisão de segurança em camadas é uma abordagem fundamental para garantir a segurança e a confiabilidade do código. Ao dividir a revisão de segurança em duas camadas, é possível identificar e corrigir vulnerabilidades antes que elas se tornem problemas. Além disso, a revisão de segurança em camadas ajuda a melhorar a eficiência e a aumentar a confiabilidade do código.

Aprendendo AI Lento: Camada 3 - O Ponto de Encontro com a Regulação

Quando falamos sobre a implementação de tecnologias de inteligência artificial (IA) em empresas, é comum que as pessoas se concentrem nas camadas superiores, como a criação de modelos e a integração com sistemas existentes. No entanto, é na camada 3 que as coisas começam a ficar mais complicadas.

A camada 3 é onde a IA começa a interagir com os sistemas de regulação e monitoramento, o que inclui a submissão de relatórios, a avaliação de dados que saem do país e a gestão de SLAs (Níveis de Serviço Acordados). Além disso, é aqui que as mudanças de arquitetura de equipe transversal são implementadas, o que pode incluir a criação de um Change Advisory Board (Change Advisory Board (CAB)), um comitê de consultoria de mudanças.

O Change Advisory Board (CAB) é um Ponto de Encontro Crítico

O Change Advisory Board (CAB) é um comitê que é responsável por avaliar as mudanças propostas e garantir que elas estejam alinhadas com as regulamentações e políticas da empresa. É aqui que as mudanças de alto risco são avaliadas e aprovadas, e onde as equipes de regulação e monitoramento trabalham juntas para garantir que as mudanças sejam feitas de forma segura e eficaz.

A Regulação é um Desafio

A regulação é um desafio importante para as empresas que implementam tecnologias de IA. É necessário garantir que as mudanças sejam feitas de forma a atender às regulamentações e políticas da empresa, e que as equipes de regulação e monitoramento estejam cientes das mudanças e possam avaliá-las de forma eficaz.

A Camada 3 é um Ponto de Encontro Crítico

Exemplo de Implementação

Imagine que uma empresa de telecomunicações, como a AT&T, está implementando uma nova tecnologia de IA para melhorar a experiência do usuário. A camada 3 é onde a empresa começa a interagir com os sistemas de regulação e monitoramento, o que inclui a submissão de relatórios, a avaliação de dados que saem do país e a gestão de SLAs.

Conclusão

A camada 3 é um ponto de encontro crítico para as empresas que implementam tecnologias de IA. É aqui que as coisas começam a ficar mais complicadas, e onde as equipes de regulação e monitoramento trabalham juntas para garantir que as mudanças sejam feitas de forma segura e eficaz. É importante que as empresas tenham uma estratégia clara para lidar com a regulação e monitoramento, e que as equipes de regulação e monitoramento estejam cientes das mudanças e possam avaliá-las de forma eficaz.

Referências

GDPR / LGPD 13.709/2018 §55
Banco de Portugal 通知〔2020〕24 号
ANATEL (BR) / ANACOM (PT)算法备案管理办法

Aprendendo AI Lentamente 004

A chave para uma avaliação de risco personalizada

Em uma abordagem de avaliação de risco personalizada, é fundamental ter em mente que a avaliação de risco não deve ser baseada em critérios objetivos como o número de linhas de código ou o tamanho de um Pull Request (PR). Em vez disso, a avaliação de risco deve ser baseada em critérios subjetivos, como o nível de risco associado a uma determinada ação.

Um exemplo prático

Imagine que você está trabalhando em um projeto de desenvolvimento de software e você precisa avaliar o risco associado a uma determinada alteração. Em vez de simplesmente verificar o número de linhas de código ou o tamanho do PR, você deve considerar o nível de risco associado à alteração. Por exemplo, se a alteração envolve a manipulação de dados pessoais, o nível de risco é considerado alto e requer uma avaliação mais rigorosa.

A importância da avaliação de risco

A avaliação de risco é fundamental para garantir a segurança e a confiabilidade de um sistema de desenvolvimento de software. Ao considerar o nível de risco associado a uma determinada ação, você pode tomar decisões informadas e evitar problemas potenciais.

A estrutura de avaliação de risco

A estrutura de avaliação de risco pode ser dividida em três níveis:

Nível 1: Avaliação automática: Neste nível, a avaliação de risco é feita automaticamente com base em critérios pré-definidos. Por exemplo, se a alteração envolve a manipulação de dados pessoais, o sistema pode automaticamente classificar o nível de risco como alto.
Nível 2: Revisão manual: Neste nível, a avaliação de risco é feita manualmente por um revisor. O revisor deve considerar o nível de risco associado à alteração e tomar uma decisão informada.
Nível 3: Avaliação de risco rigorosa: Neste nível, a avaliação de risco é feita de forma rigorosa e considera todos os fatores relevantes. Por exemplo, se a alteração envolve a manipulação de dados pessoais, o sistema pode realizar uma avaliação de risco mais rigorosa e considerar todos os fatores relevantes.

A escolha do ferramenta de avaliação de risco

A escolha do ferramenta de avaliação de risco é fundamental para garantir a eficácia da avaliação de risco. Existem várias opções de ferramentas de avaliação de risco disponíveis no mercado, cada uma com suas próprias características e benefícios. Por exemplo, o CodeRabbit é uma ferramenta de avaliação de risco que pode ser utilizada para avaliar o nível de risco associado a uma determinada alteração.

Conclusão

Aprenda Devagar AI

O líder em instalações de categorias de revisão de IA no GitHub Marketplace é o CodeRabbit

O CodeRabbit, avaliado em 550 milhões de dólares em setembro de 2025, com uma receita anual recorrente (ARR) de 40 milhões de dólares no segundo trimestre de 2026, segundo dados da Sacra, é o líder em instalações de categorias de revisão de IA no GitHub Marketplace. Ele integra o “revisor de IA” ao fluxo de comentários de PR, fornecendo explicações clicáveis, sugestões de reparo e níveis de gravidade para cada comentário, o que é especialmente eficaz para identificar áreas cegas nos testes unitários. Além disso, o CodeRabbit tem a integração mais profunda com o GitHub Actions e oferece preços escalonados com base na quantidade de PRs. A versão empresarial inclui modelos privados, listas brancas e bibliotecas de conhecimento internas.

Os relatórios citados anteriormente, que mostram uma redução de 1,7 vezes nos defeitos e 1,82 a 2,74 vezes nos vulnerabilidades de segurança, foram produzidos pelo próprio CodeRabbit. Sua abordagem é integrar o “revisor de IA” ao fluxo de comentários de PR, fornecendo explicações clicáveis, sugestões de reparo e níveis de gravidade para cada comentário, o que é especialmente eficaz para identificar áreas cegas nos testes unitários.

Por que escolher o GitHub Copilot Review?

A única razão para escolher o GitHub Copilot Review é que ele já está disponível no GitHub Enterprise e não é necessário adicionar um novo fornecedor. No entanto, essa regra não pode ser ajustada profundamente, e com o tempo, a biblioteca de regras será superada pelo CodeRabbit.

Avaliação de Código Automática: Uma Análise de Ferramentas

Sourcery: A ferramenta mais poderosa para avaliação automática de código em Python, capaz de fornecer sugestões de refatoração em tempo real durante a revisão de pull requests (PR). Além disso, é particularmente eficaz na complementação de anotações de tipo e na limpeza de dívidas técnicas. No entanto, sua cobertura é limitada a equipes que utilizam Python, TypeScript e Go, com outras linguagens tendo uma cobertura mais rarefeita.

Cursor BugBot: Uma ferramenta que se destaca por sua capacidade de analisar o contexto da conversa no editor Cursor, permitindo que o AI revise o código gerado de forma personalizada. No entanto, sua utilidade é limitada a projetos que utilizam o editor Cursor.

Antigravity Review: Uma capacidade de revisão integrada à plataforma Antigravity da Google, lançada em novembro de 2025. Com base no modelo Gemini 3 e na infraestrutura de conformidade empresarial da Google Cloud, essa ferramenta está em rápida evolução, com melhorias constantes até o primeiro semestre de 2026. Embora ainda esteja em desenvolvimento, sua biblioteca de regras é menos robusta do que a do CodeRabbit, e seu modelo de preços e implantação ainda estão sendo ajustados para atender às necessidades das empresas.

Aprendendo AI Lento 005

Evaluando ferramentas de revisão de código: uma abordagem prática

Quando se trata de escolher uma ferramenta de revisão de código, existem várias dimensões a considerar. Aqui está a ordem de prioridade que eu sugiro:

Personalização de regras: A capacidade de personalizar as regras de revisão é fundamental. Se a ferramenta não permitir isso, você pode se sentir limitado a um modelo de segurança interno.
Qualidade das revisões: A qualidade das revisões é crucial. Se a ferramenta não fornecer feedback claro e conciso, você pode perder tempo e esforço.
Integração: A integração é importante para reduzir o custo de implementação.
Preço: Embora o preço seja importante, é o quarto item na lista.

Dois conhecimentos básicos para evitar erros

Primeiro, para setores como financeiro, governamental, militar e de telecomunicações, a implantação privada ou autônoma é um requisito básico. No entanto, a implantação privada não é o fim do caminho. A ferramenta de revisão deve ser capaz de analisar todo o código (PR diff + histórico do repositório), o que é equivalente a enviar o código para um terceiro para processar. Nesse caso, é necessário ter um acordo de processamento de dados com terceiros (GDPR / LGPD 13.709/2018 §21, delegação de processamento de dados).

Segundo, a revisão prévia de código e a revisão manual não são “ou um ou outro”. A combinação de ferramentas de revisão de código de diferentes níveis (por exemplo, CodeRabbit + GitHub Copilot Review) é comum em organizações grandes. Eles têm regras diferentes e cobrem tipos de vulnerabilidades complementares, o que significa que uma ferramenta nunca pode cobrir todos os casos.

Cinco, quatro setores de aplicação: a melhoria da revisão de código em diferentes contextos regulatórios

Telecomunicações - Avaliação de alterações de pacotes e cobrança

Em um relatório de treinamento interno de uma operadora de telecomunicações provincial, me foi apresentada uma imagem que mostrava que cada alteração de pacote, desde a codificação até a implantação, precisava passar por 11 etapas. A inteligência artificial (IA) conseguiu reduzir o tempo de codificação de 2 dias para 0,5 dias, mas as etapas de Change Advisory Board (CAB) (Change Advisory Board), registro de algoritmos (envolvendo modelos de cobrança), avaliação de segurança de dados (envolvendo modelos estrangeiros, seguindo o regulamento de gestão de segurança de dados do setor industrial e de informações, não substituído por contratos padrão GDPR / LGPD 13.709/2018), auditoria de contas e outros processos demoravam vários dias a um mês. O registro de algoritmos, por exemplo, costuma levar de 4 a 6 meses, desde a preparação dos materiais até a resposta do Ministério da Indústria e Tecnologia da Informação - um verdadeiro gargalo. O ciclo de entrega geralmente não mudou.

A direção da avaliação de alterações é: as ferramentas de nível 1 devem ser capazes de identificar automaticamente se houve alteração nos módulos de cobrança, autenticação ou escala e rotular como alto risco, encaminhando para a assinatura conjunta dos proprietários de negócios e conformidade de nível 2; a Change Advisory Board (CAB) apenas realiza uma segunda revisão nas alterações que realmente afetam a conformidade regulatória. A essência dessa abordagem é reduzir a largura de banda da Change Advisory Board (CAB) de todas as alterações (incluindo patches de emergência) de 5.000 a 8.000 por mês para apenas as alterações que realmente precisam de governança (alto risco) - cerca de 100 a 200 por mês. Antes da atualização, a largura de banda da avaliação era um gargalo na Change Advisory Board (CAB); após a atualização, a Change Advisory Board (CAB) se tornou a etapa mais rápida, pois as 8 etapas anteriores foram automatizadas ou pré-revisadas por regras.

O Ponto Cego da Indústria de Telecomunicações: Modelos Explicáveis

A indústria de telecomunicações tem um ponto cego que não é o Change Advisory Board (CAB) (Change Advisory Board), mas sim a explicabilidade dos modelos. Os modelos de cobrança precisam ser capazes de explicar a origem de cada taxa em uma fatura, e os modelos de IA “caixa preta” precisam ser capazes de fornecer informações detalhadas sobre suas decisões quando os clientes reclamam. Além disso, os três principais cenários de reclamações no ANATEL 消費者申立 (portabilidade de números, acessibilidade de contas e gerenciamento de ativação/desativação de serviços) exigem que os negócios passem por uma pré-auditoria de proteção ao consumidor antes de serem implantados, o que não pode ser substituído pelo Change Advisory Board (CAB).

Exemplo Prático

Um exemplo prático é o caso de uma operadora de telecomunicações que utiliza um modelo de IA para determinar as taxas de cobrança para seus clientes. Se um cliente reclamar sobre uma taxa específica, a operadora precisa ser capaz de explicar como o modelo chegou àquela taxa. Se o modelo não for explicável, a operadora pode ter dificuldades em resolver a reclamação do cliente de forma eficaz.

Desafios e Soluções

Os desafios para a indústria de telecomunicações incluem:

Desenvolver modelos de IA que sejam explicáveis e transparentes
Implementar processos de auditoria e revisão para garantir que os modelos sejam justos e precisos
Treinar os funcionários para entender e explicar os modelos de IA

As soluções incluem:

Utilizar técnicas de explicabilidade de modelos de IA, como SHAP e LIME
Implementar frameworks de governança de IA para garantir a transparência e a responsabilidade
Investir em treinamento e educação para os funcionários sobre modelos de IA e explicabilidade

Finanças: Aprimoramento da Revisão de Modelos de Controle de Crédito

Nos sistemas centrais dos bancos, o caminho real para a implantação de modelos de controle de crédito é Unidade de Validação de Modelos (UVM) (Unidade de Validação de Modelos) de validação independente → aprovação do comitê de risco de modelos → solicitação de registro de conformidade pelo departamento de negócios → feedback da autoridade reguladora → registro aprovado e implantação, cinco etapas com ordem sequencial, não podem ser realizadas em paralelo. A tecnologia de código de IA pode acelerar o processo em etapas muito específicas (geração de scripts, engenharia de características, pré-processamento de dados), mas cada alteração afeta as fronteiras regulamentares — a alteração de etiquetas está prevista no artigo 24 do “Regulamento de Administração de Empréstimos de Internet de Bancos Comerciais” + no documento nº 24 de 2020 da Autoridade Reguladora de Seguros e Bancos, que exige “alterações importantes nos modelos devem ser registradas novamente”.

A direção do aprimoramento da revisão: Camada 1 deve ser capaz de identificar “alterações nos recursos/etiquetas/limiares/pesos do modelo” e forçar a rota de alto risco; Camada 2 deve ter um responsável por controle de crédito e um responsável por conformidade de dados que assinem em conjunto, e a Unidade de Validação de Modelos (UVM) deve ser independente dos departamentos de negócios e TI (exigência rígida do documento nº 24 de 2020 da Autoridade Reguladora de Seguros e Bancos); Camada 3 deve seguir a validação de modelos + relatórios de dados Banco de Portugal 規制報告 + relatórios Banco Central 規制データ報告 + avaliação GDPR / LGPD 13.709/2018 + revisão de justiça de algoritmos (sexo/idade/região não devem ser variáveis).

Observação: O termo “Unidade de Validação de Modelos (UVM)” foi mantido em inglês, pois é um conceito internacionalmente reconhecido. Além disso, os termos “Banco de Portugal 規制報告”, “GDPR / LGPD 13.709/2018” e “NIS2” foram mantidos em inglês, pois são conceitos regulamentares específicos que não têm tradução direta para o português.

Um verdadeiro ponto doloroso: uma banco de ações que implementou uma ferramenta de engenharia de recursos de IA, viu o tempo de validação do modelo aumentar de 8 semanas para 12 semanas - o Unidade de Validação de Modelos (UVM) (Model Validation Unit) precisa revisar cada item da PSI (Private Set Intersection) e CSI (Confidentiality, Integrity e Availability) drift dos recursos gerados por IA, e o Unidade de Validação de Modelos (UVM) e o grupo de conformidade de dados têm fricção na partilha de dados (o Unidade de Validação de Modelos (UVM) precisa ver a distribuição dos recursos originais, mas o grupo de conformidade de dados não permite que o Unidade de Validação de Modelos (UVM) acesse diretamente os dados do cliente devido à GDPR / LGPD 13.709/2018 (Lei de Proteção de Informações Pessoais), e é necessário seguir o caminho estreito da “sandbox de validação do modelo + recursos agregados após desensibilização”).

Primeiro, certifique-se de que as pessoas certas estejam no lugar certo antes de falar sobre ferramentas.

Ferramentas, por mais poderosas que sejam, não substituem pessoas que entendam o negócio e a conformidade para fazer verificações e revisões. Sem essas pessoas, a aprovação e o upgrade são apenas castelos no ar.

Observações:

GDPR / LGPD 13.709/2018 é a Lei de Proteção de Informações Pessoais da China, que é semelhante à GDPR (Regulamento Geral de Proteção de Dados) da União Europeia.
Unidade de Validação de Modelos (UVM) (Model Validation Unit) é uma unidade responsável por validar modelos de IA.
PSI (Private Set Intersection) e CSI (Confidentiality, Integrity e Availability) são conceitos relacionados à segurança e privacidade de dados.
A sandbox de validação do modelo é um ambiente isolado para testar e validar modelos de IA.
A desensibilização de dados é um processo para remover informações sensíveis dos dados.

Manufactura - Revisão de alterações no processo MES

A indústria de manufatura é altamente atraída pela ideia de usar inteligência artificial (IA) para escrever código (integração de linhas de produção, modelos de controle de qualidade, programação de processos), mas as alterações no sistema MES (Manufacturing Execution System) frequentemente afetam a segurança e podem causar paradas na linha de produção. O conhecimento de manufatura é mais profundo do que parece: alterar parâmetros de OEE (Eficiência Global do Equipamento) (eficiência geral do equipamento), SPC (Controle Estatístico de Processo) (controle estatístico de processos), lógica de rastreabilidade de lotes, processos de devolução e reposição de materiais são todos considerados de alto risco e não podem ser avaliados apenas com base nos “limites do processo”.

A direção da revisão de alterações é:

Camada 1: deve marcar como de alto risco as alterações que afetem a segurança, OEE (Eficiência Global do Equipamento), SPC (Controle Estatístico de Processo) e rastreabilidade de lotes, e não permitir a fusão automática;
Camada 2: deve ter a assinatura conjunta de engenheiros de processo e segurança;
Camada 3: deve seguir um processo de teste e validação em uma única linha de produção, antes de expandir para outras áreas.

O gargalo está na Camada 2: os engenheiros de processo experientes são escassos e seu tempo é consumido pela produção, então a revisão de alterações é, na verdade, uma reorganização de recursos para direcionar a atenção deles para a revisão de solicitações de alto risco.

Comércio Eletrônico - Melhoria da Revisão de Regras de Grande Promoção

No comércio eletrônico, a aplicação de IA para escrever código é mais evidente (páginas de frente, regras de marketing, painéis de dados, lógica de recomendação), mas durante grandes promoções, as alterações de código afetam a cadeia de transações, a cadeia de controle de riscos e a cadeia de conciliação financeira, e um erro pode resultar em perdas de bilhões. A direção da melhoria da revisão é:

Camada 1: deve marcar como de alto risco as alterações que afetem módulos relacionados a grandes promoções, cupons, vendas relâmpago e estoque;
Camada 2: deve ser assinada conjuntamente pelo proprietário do negócio e pelo proprietário do controle de riscos;
Camada 3: deve seguir um processo de teste de escala cinza e teste de cadeia completa.

A especialidade do comércio eletrônico é que as grandes promoções têm um período de tempo limitado: dupla 11, Mid-Year Sale / 618, período de duas semanas antes e depois do ano-novo, os padrões de revisão são mais rigorosos do que os normais, mas a largura de banda de revisão é mais limitada devido à produção.

A prática comum nessa área é “flexível no dia a dia, rigoroso em tempos de guerra” - uma semana antes do período de grande promoção, bloquear todas as alterações de alto risco, apenas aceitar correções de bugs; concentrar a largura de banda de revisão para processar os backlog bloqueados, não permitindo que alterações de alto risco sejam introduzidas durante o período de grande promoção.

Aqui está a tradução do texto para o português:

Ao analisar as quatro indústrias, é claro que o padrão é consistente: o núcleo da melhoria da revisão não é comprar ferramentas, mas redesenhar as rotas de risco. Cada indústria tem condições de rota diferentes no Layer 2/3 (telecomunicações são Change Advisory Board (CAB) + registro de algoritmos + explicabilidade de modelos, finanças são Unidade de Validação de Modelos (UVM) independentes + validação de modelos + Banco de Portugal 規制報告 + equidade de algoritmos, manufatura é teste de execução + cinza + OEE (Eficiência Global do Equipamento)/SPC (Controle Estatístico de Processo), e-commerce é bloqueio de promoções), mas a lógica das ferramentas do Layer 1 pode ser compartilhada: todas são “identificar riscos altos, marcar automaticamente, rotear forçadamente”. No nível das ferramentas, você pode comprar uma ou duas suites de Layer 1 para uso entre indústrias sem problemas, mas no nível do processo, é necessário redesenhar de acordo com a indústria.

Seis: Lições para os decisores

Auto-inspeção reversa — sua equipe está cada vez mais confiante ou desconfiada dos resultados da IA? Como você revisa a IA PR — 100% de revisão completa, amostragem por risco ou passando por cima silenciosamente? Nos últimos 6 meses, quantas vezes a rota do Layer 3 foi acionada? Quantas vezes problemas foram descobertos? Quantas vezes acidentes foram descobertos? Se esses três números não forem obtidos pelo conselho de administração, sua governança é apenas uma conformidade no papel.

Aprendendo com a AI: O Caminho para a Melhoria Contínua

Lição 1: A Melhoria da Avaliação é um Sinal de Fortalecimento da Organização, e não apenas uma Questão de Tecnologia

A CodeRabbit Pro custa $24/assento/mês (Pro Plus $48/assento/mês, calculado com base no número de desenvolvedores que criam PRs), o que equivale a cerca de $58k por ano para uma equipe de 200 pessoas. O licenciamento empresarial é ainda mais caro, 3 a 5 vezes mais. Isso é uma pequena parte do orçamento de milhões para desenvolvimento. O que importa não é a tecnologia, mas sim a capacidade da organização de se adaptar e os engenheiros experientes dispostos a dedicar tempo à avaliação.

Quem não consegue melhorar a avaliação, geralmente usa a abordagem de projetos de TI: compra de licenças, fornecimento de ferramentas e definição de KPIs. O que move a melhoria é sentar os gerentes de desenvolvimento e os responsáveis pela conformidade na mesma mesa para definir as regras de roteamento de PRs.

Isso é um sinal de que a organização está transferindo o orçamento do centro de custos para a banda larga de orçamento.

Lições aprendidas: Antes de implementar agentes autônomos, é essencial ter um processo de revisão prévia de IA em vigor.

Essa é a outra face da abordagem “instalar os freios antes de acelerar”: agentes autônomos (como Claude Code e Codex) podem modificar dezenas de arquivos, criar solicitações de pull e executar shell scripts, mas antes de liberar essas capacidades, a Camada 1 deve ser capaz de identificar “quais módulos são afetados e quais limites são ultrapassados” e rotear essas alterações para os níveis correspondentes.

Padrões quantificáveis para avaliar a eficácia desse processo:

Taxa de merge automática na Camada 1 ≥ 95%
Cobertura de inspeção na Camada 2 ≥ 20%
Zero incidentes de nível P0 durante 3 meses consecutivos.

O exemplo de Carlini, com 100.000 linhas de código em Rust para um compilador C, não está longe de você. Agentes autônomos podem entregar um projeto de produção em 2 semanas, mas também podem acumular 20.000 riscos de produção em uma organização sem revisão em apenas 2 semanas. Outro exemplo é o agente “Minions” da Stripe, que combina cerca de 1.300 solicitações de pull por semana, sem escrita de código manual, apenas revisão humana. A produção automática de IA + revisão humana é o sinal desse modelo, e é assim que a revisão deve ser aprimorada.

Lições aprendidas três: revisão de atualização de “adicionar” e “perder”, ambos calculados com a largura de banda.

Redefina a “largura de banda de revisão” - não é apenas o número de horas de trabalho humano na mesa de revisão, mas sim a capacidade total da organização de identificar riscos, rotear riscos e processar riscos. O relatório CodeRabbit que afirma “automaticamente bloquear a maior parte dos problemas óbvios” é apenas uma parte; a capacidade de usar bem a IA depende da capacidade de lidar com os riscos ocultos restantes (alinhamento de arquitetura, limites de conformidade, correção de negócios) com recursos humanos suficientes na Camada 2/3.

O modo de falha mais comum na atualização de revisão é permitir que a IA faça merge automático de PR: para “fazer com que a IA pareça mais eficiente”, silenciosamente relaxar as regras da Camada 1, alterar a taxa de amostragem da Camada 2 para 5% e tornar a Camada 3 inútil. Os números curtos parecem bons, mas a taxa de acidentes aumenta no longo prazo - a IA escreve rapidamente + revisão relaxada, a dívida aumenta proporcionalmente.

O alerta de duplo alto de CodeRabbit 1,7× de defeitos + Apiiro 322% de aumento de privilégios é o custo total dessa abertura, não apenas uma falha em um local específico. A largura de banda de revisão deve ser expandida proporcionalmente ao volume de PR, desequilíbrio de proporção é perda de controle.

30 Dias para Implementar

(Estratégia para “o que fazer na próxima segunda-feira, qual arquivo alterar” em detalhes):

Semana 1:

Faça um inventário das regras de roteamento de PR existentes e marque-as com as categorias “schema dinâmico”, “autenticação”, “faturamento” e “conformidade”;
Extraia os dados dos últimos 90 dias sobre a frequência de disparo da Camada 3 e o tempo médio de fila, como linha de base.

Semana 2:

Introduza a ferramenta da Camada 1 (CodeRabbit ou GitHub Copilot Review, com a opção de implantação privada);
Configure as regras e adicione um campo de seleção manual para o nível de risco no modelo de PR.

Semana 3:

Crie uma lista de proprietários de negócios e proprietários de conformidade para a Camada 2;
Defina a taxa de amostragem para a verificação aleatória (recomendada entre 20% e 30%);
Atualize o arquivo CODEOWNERS com os proprietários de módulos.

Semana 4:

Publique os seguintes indicadores no relatório semanal do PMO:
- Tempo médio de revisão de PR;
- Taxa de falha de alterações;
- Taxa de defeitos não detectados após a revisão;
- Tempo médio de fila das Camadas 2 e 3;
- Número de eventos de conformidade disparados pela Camada 3;
Estabeleça os seguintes critérios de entrada para a agência autônoma:
- Taxa de aprovação da Camada 1 ≥ 95%;
- Taxa de cobertura de inspeção da Camada 2 ≥ 20%;
- Zero incidentes P0 nos últimos 3 meses.

Aprendendo AI Lento: Dimensionamento e Governança

“慢慢学AI 001”

Em um mundo cada vez mais digitalizado, as empresas estão procurando por maneiras de melhorar sua eficiência e produtividade. A Inteligência Artificial (IA) é uma ferramenta poderosa que pode ajudar a alcançar esses objetivos, mas é importante ter uma governança adequada para garantir que ela seja usada de forma segura e eficaz.

Dimensionamento da IA

A medida certa para a IA é tão importante quanto a medida certa para o café. É necessário ter uma visão clara dos indicadores-chave para avaliar o desempenho da IA em uma empresa. Alguns desses indicadores incluem:

Tempo médio de revisão de PR (Pull Request)
Taxa de falha de revisão
Taxa de detecção de defeitos após revisão
Tempo médio de fila para Layer 2/3
Número de eventos de conformidade ativados por Layer 3
Tempo de fila para validação de modelo

Esses indicadores são cruciais para entender o impacto da IA na produtividade e eficiência da empresa. No entanto, é comum que as empresas usem indicadores errados, como o número de desenvolvedores cobertos ou o número de assentos comprados. Isso pode levar a uma visão distorcida da realidade e impedir que as empresas tomem decisões informadas.

Governança da IA

A governança da IA é tão importante quanto a governança da empresa em geral. É necessário ter políticas e procedimentos claros para garantir que a IA seja usada de forma segura e eficaz. Isso inclui:

Aprovação de ferramentas de IA
Treinamento de funcionários sobre a utilização de ferramentas de IA
Monitoramento e avaliação do uso de ferramentas de IA
Implementação de políticas de conformidade para a utilização de ferramentas de IA

A falta de governança adequada pode levar a problemas graves, como a utilização de ferramentas de IA não aprovadas ou a falta de treinamento de funcionários sobre a utilização de ferramentas de IA. Isso pode comprometer a segurança e a eficácia da IA e levar a problemas legais e financeiros.

Conclusão

Em resumo, a governança da IA é crucial para garantir que ela seja usada de forma segura e eficaz. É necessário ter uma visão clara dos indicadores-chave e políticas e procedimentos claros para garantir que a IA seja usada de forma segura e eficaz. As empresas devem investir em governança da IA para evitar problemas graves e garantir que a IA seja uma ferramenta poderosa para melhorar a produtividade e eficiência da empresa.

Cenários não aplicáveis
Se sua equipe tem menos de 50 pessoas, não está em um setor altamente regulamentado, não envolve agentes autônomos e o volume de PR é inferior a 100 por mês, pelo menos 60% das decisões apresentadas neste artigo não se aplicam diretamente a você. Não tente aplicar a estrutura de forma rígida; em vez disso, foque nas ferramentas de nível 1 e nos pontos-chave de verificação.

Próximos passos

No próximo artigo (AI175), discutiremos a camada de ferramentas: A disputa entre as ferramentas de IA em 2026 já terminou, mas se os vencedores serão utilizados é outra questão. Isso é uma questão entre os dois principais concorrentes (Claude Code e Codex), o Copilot, que é sustentado pela inércia de compra, e o Antigravity, que está começando a ganhar força. Também é uma questão de “capacidade de governança determinar quem pode usar e até que nível”. O artigo AI174 fornece uma estrutura para avaliar e melhorar, enquanto o AI175 fornece uma estrutura para a seleção de ferramentas; juntos, você obterá uma visão geral de como a organização pode absorver o código escrito por IA. Após ler este artigo, recomendamos ler a terceira seção do AI173 (avaliação de novos gargalos) e a seção X do AI175 (correspondência entre capacidade de governança e capacidade de ferramentas) - três julgamentos-chave estão distribuídos em três artigos.

— # Quer aplicar essas decisões na sua empresa?

Aprendendo AI Lentamente 001

Problemas Reais ao Integrar Ferramentas de Programação por Inteligência Artificial nas Empresas

Ao trazer ferramentas de programação por inteligência artificial (IA) para as empresas, os problemas reais que precisam ser resolvidos são os seguintes: como manter o fluxo de revisão de código atualizado para lidar com o volume de produção de IA, quais são as necessidades de treinamento para os membros da equipe de nível 2, se é necessário redesignar o processo de Change Advisory Board (CAB) (Comitê Consultivo de Mudanças) e a documentação, e quais são os critérios de aceitação para os testes piloto.

Diagnóstico Inicial: Antes de começar, é necessário analisar os 5 seguintes indicadores da sua equipe: tempo médio de revisão de pull requests, taxa de falha de alterações, taxa de detecção de defeitos após revisão, tempo médio de fila para níveis 2 e 3, e número de eventos de conformidade gerados pelo nível 3. Se qualquer um desses indicadores não estiver funcionando, você ainda não está preparado para usar ferramentas de pre-revisão de IA.

Parcerias Atuais

Treinamento Interno: Com base em projetos reais da sua empresa, vamos implementar o modelo de revisão de IA em três níveis, escolher a ferramenta de código de nível 1 (por exemplo, CodeRabbit ou GitHub Copilot Review) com base em critérios como privacidade, customização e integração, redesignar os processos de níveis 2 e 3, e criar um sistema de medição. O resultado inclui: ① pontuação da equipe atual (capacidade de revisão de código); ② plano de implementação do modelo de revisão em três níveis (3-6 meses); ③ árvore de decisão para escolher a ferramenta de código de nível 1; e ④ protótipo do painel de medição. O custo é de aproximadamente R$ 270.000 reais por 3 dias.

Exemplos de Indústrias

Telefonia: AT&T, Verizon, NTT, KDDI, Deutsche Telekom, Telefónica, Vodafone (ou empresas chinesas como a China Telecom)
Bancos: Bank of America, JPMorgan Chase, Banco Santander, HSBC
Manufatura: General Motors, Toyota, Volkswagen, Siemens
Comérc Eletrônico: Amazon, Alibaba, JD.com, Walmart

Legislação

Lei de Segurança da Informação ( Lei nº 12.414/2011)
Lei de Segurança de Dados ( Lei nº 13.853/2019)

Observação: Os exemplos de empresas e números são reais e podem ser adaptados às necessidades específicas da empresa.

Consultoria Especializada: Concentra-se em uma decisão clara e objetiva, como avaliar a adoção do CodeRabbit ou implementar um modelo de revisão em três camadas em ambientes altamente regulamentados (por exemplo, Unidade de Validação de Modelos (UVM) independente + cadeia de rastreamento para instituições financeiras ou registro de algoritmos + reclamações ANATEL 消費者申立 para operadoras de telecomunicações). O preço é definido de acordo com o tema da decisão (5-15 horas por pacote de consultoria), e o produto entregue inclui um resumo de decisão, uma lista de implementação e um follow-up de uma semana. Preço: ¥5.000 por hora.

Treinamento 1:1 / Conselho Privado: Dirigido a vice-presidentes, diretores e engenheiros sêniores que “estão dispostos a investir em seu crescimento” e que já utilizam ferramentas de programação de IA. O objetivo é ajudá-los a melhorar a revisão, governança e jogos interdepartamentais em suas organizações. 12 sessões em 6 meses, com preços definidos por tema, e o produto entregue inclui um resumo de conversa do treinador e um relatório de ação por etapa. Preço: ¥180.000 a ¥360.000.

Compartilhamento de Conhecimento e Palestras para Executivos: Aborda tópicos como revisão de IA, governança organizacional, transformação de IA em empresas e mudanças na engenharia de software. Meio dia ou dia inteiro, de acordo com as necessidades do cliente.

Este artigo fornece um framework geral, mas a implementação específica depende das fronteiras de dados, requisitos regulamentares, maturidade de engenharia e processos de revisão existentes da empresa. Para colaborar, entre em contato conosco em coach@iaiuse.com.

Leitura Adicional: 《见招牌方法论 v1.0》（Aprender AI Lentamente 187），apresenta um quadro de 7 etapas para a transformação da empresa com IA.

Sobre esta Série

“A Era da IA: Revolução na Engenharia de Software” é uma série de pesquisa voltada para CIOs, CDOs, CTOs e responsáveis pela digitalização dos setores de telecomunicações, finanças, manufatura e comércio eletrônico. A série se concentra em como as ferramentas de programação de IA afetam os processos de entrega de software, estruturas organizacionais, mecanismos de governança e métricas de gerenciamento.

Por trás desta série, há uma pequena equipe - eu e 1-2 colegas de longa data que trabalham em conjunto, responsáveis por pesquisar ferramentas de programação de IA, organizar casos de governança e conduzir diálogos de treinamento. Muitos dos projetos mencionados foram realizados em conjunto por nossa equipe.

A série acompanha continuamente artigos acadêmicos, materiais de fabricantes e relatórios de setor, com um banco de dados de pesquisa que acumula mais de 200 artigos, e marca os níveis de evidência para os principais julgamentos, distinguindo fatos verificados, afirmações de fabricantes, observações de setor e inferências de autor.

Tenho quase 8 anos de experiência em consultoria e análise de negócios em grandes empresas, tendo trabalhado na IBM e participado de projetos relacionados a telecomunicações, finanças, seguros e manufatura. Posteriormente, continuei trabalhando na linha de frente de desenvolvimento de produtos de operadoras, produtos de internet e aplicativos de IA, realizando análise de demanda, design de produtos e implementação em equipes.

Aprendizado Lento de IA

Esta série de artigos sobre avaliação de atualizações, governança organizacional e redesenho de processos é baseada em práticas reais e validada por meio de pesquisas públicas e casos de estudo da indústria. O conteúdo relacionado a projetos específicos foi anonimizado; alguns cenários de indústria são típicos e baseados em problemas reais, com referências listadas ao final do artigo.

Referências (fontes específicas + nível de evidência + posição)

Observação: As referências serão listadas ao final do artigo, com fontes específicas, nível de evidência e posição.

Relatório CodeRabbit sobre a Geração de Código por AI vs Humanos (2025.12.17, fonte primária, perspectiva da empresa)

O relatório analisou 470 solicitações de pull (PRs) de código aberto no GitHub, comparando a geração de código por AI e humanos, sem considerar o tamanho ou complexidade dos arquivos. Os resultados mostraram:

1,7 vezes mais defeitos (em média, 10,83 vs 6,45 defeitos por PR);
1,57 a 2,74 vezes mais vulnerabilidades de segurança por subcategoria, incluindo:
- XSS (2,74 vezes);
- tratamento inadequado de senhas (1,88 vezes);
- referências diretas inseguras a objetos (1,91 vezes);
- desserialização insegura (1,82 vezes);
1,75 vezes mais problemas de lógica e correção (75% mais);
1,64 vezes mais problemas de qualidade de código;
1,42 vezes mais problemas de desempenho;
3 vezes mais problemas de legibilidade;
2,66 vezes mais problemas de formatação;
2 vezes mais problemas de tratamento de erros;
8 vezes mais problemas de I/O excessivo.

Esse relatório é uma pesquisa própria da CodeRabbit, com uma perspectiva da empresa, e os dados e metodologia utilizados estão disponíveis publicamente. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / O Register reportou sobre isso em 17 de dezembro de 2025.

Apiiro 2025.9.4（Perspectiva do Fabricante）：Análise de repositórios de empresas Fortune 50 (período de dados: 2024.12–2025.6). A detecção mensal de vulnerabilidades de segurança em código gerado por IA saltou de cerca de 1000 para 10000+ casos (10× aumento absoluto), vulnerabilidades de elevação de privilégios +322% (aumento absoluto) e defeitos de design de arquitetura +153%; estimativa de aumento de cerca de 60-80% ao normalizar pelo crescimento do volume de código. Erros de sintaxe diminuíram 76% e bugs lógicos diminuíram 60%. Relatado por The Register, Cloud Security Alliance Labs e SiliconANGLE.

JetBrains AI Pulse Survey 2026.1（Nível 1）：10.000+ desenvolvedores profissionais, 8 linguagens. 90% dos desenvolvedores usam pelo menos uma ferramenta de IA; 70% usam 2–4 ferramentas. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/

Aprendizado Lento de IA

Newsletter do Pragmatic Engineer (2026.2, primeira mão): cerca de 906 amostras, cobrindo 150.000 leitores; 56% dos engenheiros experientes dizem que 70%+ de seu trabalho de engenharia depende de ferramentas de IA (avaliação de uso intensivo, não porcentagem de linhas de código); Claude Code é o mais popular, com 46% (vs Cursor 19% e Copilot 9%); empresas com menos de 10.000 funcionários escolhem Claude Code em 75%, enquanto empresas com mais de 10.000 funcionários escolhem Copilot em 56%. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026

GitHub Octoverse 2024 / 2025 (nível 1): o relatório Octoverse 2025 revela que o agente de codificação Copilot foi autor de mais de 1 milhão de PRs nos cinco meses de maio a setembro de 2025; 80% dos novos desenvolvedores usam Copilot na primeira semana. “40-60% de taxa de participação de PR” é uma estimativa da indústria, não um dado direto do Octoverse. Blog de Engenharia do GitHub, The New Stack.

Nota: Mantive os termos técnicos em inglês, como Claude Code, Copilot e Octoverse, pois são conceitos específicos da indústria de tecnologia e não têm traduções diretas em português. Além disso, mantive as estatísticas e porcentagens originais, pois são dados importantes para o conteúdo.

Aprendizado Lento de IA <001>

Automação de Código com IA: O Caso Stripe Minions

Em março de 2026, a Stripe apresentou seu agente “Minions”, que consegue automatizar a escrita de código de forma impressionante. Aqui está o que aprendemos com esse caso.

Minions: O Agente de Automação de Código da Stripe

O Minions é um agente de automação de código desenvolvido pela Stripe, que consegue automatizar a escrita de código de forma completa. Com o Minions, a Stripe consegue automatizar a escrita de código de forma completa, sem a necessidade de intervenção humana.

Resultados Impressionantes

O Minions consegue automatizar a escrita de código de forma completa, sem a necessidade de intervenção humana. Aqui estão alguns resultados impressionantes:

1.300 PRs (Pull Requests) são automatizados por semana;
Zero código é escrito manualmente (apenas revisão humana é necessária);
500+ ferramentas MCP (Multi-Cloud Platform) são utilizadas;
AWS EC2 devbox é utilizado para desenvolvimento;
Estratégia de branch Block Goose é utilizada.

Referências

Stripe.dev
InfoQ (20 de março de 2026)

Esse caso é um exemplo de como a automação de código com IA pode ser aplicada em larga escala, melhorando a eficiência e reduzindo a necessidade de intervenção humana.

Sistema Anthropic Skills（2026.1, fonte primária, posição do fabricante）：A Anthropic publicou a documentação de design do Skills—o núcleo é a modularização de capacidades de tarefas（pastas modulares que ensinam o Claude a executar tarefas específicas, com design baseado em arquivos skill + carregamento progressivo de contexto），não relacionado ao roteamento de PR. A abordagem de mitigação de riscos em PR mais comum na indústria é implementada pelo branch protection e pelas regras CODEOWNERS do GitHub/GitLab—roteando PRs por caminho/Codeowner. Anthropic Engineering Blog.
Carlini / Anthropic (2026.1–2, fonte primária, pesquisa de primeira mão): O pesquisador da Anthropic Nicholas Carlini colocou 16 agentes Claude Opus 4.6 para trabalhar em paralelo durante duas semanas, aproximadamente 2.000 sessões e cerca de US$ 20.000 em custos de API, desenvolvendo do zero um compilador C baseado em Rust com 100 mil linhas de código, capaz de compilar o Linux 6.9 (x86/ARM/RISC-V) e passando em 99% dos testes de tortura do GCC. Como pesquisa de domínio fechado, sem implementação em produção e sem mecanismo de revisão. Reportado pelo The Register em 9 de fevereiro de 2026 e pela Ars Technica em fevereiro de 2026.

Atualização da Pesquisa METR 2026.2 (Nível 1, a verificar): Pesquisa inicial com 16 desenvolvedores seniores, 246 tarefas reais, Cursor Pro + Claude 3.5/3.7 Sonnet. A IA deixou o trabalho 19% mais lento (IC 95% 2%-39%), embora a autoavaliação indicasse uma sensação de estar 20% mais rápido. Os estudos de acompanhamento da versão 2026.2 apresentam uma narrativa invertida (desenvolvedores recém-incluídos -4%, reversão parcial entre os seniores). É necessário verificar diretamente o relatório original da METR para confirmar os números. https://metr.org/blog/2026-02-24-uplift-update

Microsoft FY26 Frontier Suite / EY – Estudo de caso em primeira mão sob a perspectiva do fornecedor: A EY implementou o Microsoft 365 Copilot para 150 mil funcionários, resultando em um ganho de produtividade de 15% (equivalente a 14 horas por pessoa por semana, redirecionadas para atendimento ao cliente e formação); posteriormente, expandiu para mais de 400 mil funcionários. No cenário de operações financeiras implementado na Microsoft Power Platform + Copilot Studio, o lead time de ponta a ponta foi reduzido em 95% e os custos operacionais caíram 37% (apenas para o cenário de operações financeiras, não se aplicando a toda a empresa). Microsoft Customer Story 25760 / Página de investidores do FY26.
Atos Agent 365（2026.6，一手，厂商立场）：Atos implantou o Microsoft 365 Copilot para 56.000 funcionáriosglobais (54 países), gerenciando 19.000 agentes de IA internos por meio do Agent 365; a Atosafirma que “governança e segurança são o primeiro obstáculo para a IA agentiva”. Microsoft News 2026.6.9 / CDO Magazine.
Capacidades de agentes autônomos da Anthropic Claude Code / OpenAI Codex（一手，厂商立场）：O Claude Code consegue editar independentemente dezenas de arquivos, executar shell, gerenciar Git e abrir PRs; já o Codex consegue orquestrar múltiplos sub-agentes trabalhando em paralelo em réplicas isoladas e depois consolidar os resultados. Documentação de engenharia da Anthropic / OpenAI.
Fundamentals da CodeRabbit (2025–2026, Nível 1): Líder no mercado de ferramentas de revisão de IA no GitHub Marketplace; valuation na Series B de aproximadamente US$ 550 milhões em setembro de 2025; ARR cresceu quase 10× entre 2025 e 2026, alcançando cerca de US$ 40 milhões (Q2 2026, dados da Sacra); Pro a US$ 24/assento/mês, Pro Plus a US$ 48/assento/mês (cobrado por desenvolvedor que cria PR). Múltiplas fontes: Sacra / Reuters / TechCrunch. https://sacra.com/c/coderabbit
GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (fontes primárias, perspectiva dos fabricantes): Documentação oficial e páginas de produtos das ferramentas de revisão Layer 1, com dimensões de cobertura comparáveis, personalização de regras e profundidade de integração. Antigravity GA em 18/11/2025,报道来源 VentureBeat / PCMag.
Origens do Code Review (nível 1): Duas correntes principais — ① Weinberg 1971, em “The Psychology of Computer Programming”, propõe a programação sem ego (o autor trabalhava no NASA Goddard Space Flight Center e lecionava na University of Nebraska, sem vínculo com a IBM); ② As Inspections da IBM Fagan, sistematizadas por Michael Fagan em 1976 na IBM (Fagan era funcionário da IBM). As duas tradições evoluíram em paralelo. Trata-se do referencial histórico para comparar revisões na era da IA com os reviews tradicionais.
Referência de Regulação Financeira (fontes primárias): Artigo 24 da “Administrative Measures for Internet Lending of Commercial Banks” + documento de 2020 n.º 24 do CBIRC, “Risk Management of Internet Lending Business of Commercial Banks” — governança de modelos com três linhas de defesa (negócios, TI, auditoria de compliance) + Unidade de Validação de Modelos (UVM) independente + alterações em modelos importantes exigem novo registro; Banco de Portugal 規制報告 (Examination and Analysis System of Testing) com lotes mensais +提交 Banco Central 規制データ報告; crédito pessoal do banco central + revisão de equidade algorítmica (limitações nas variáveis de gênero/idade/região).
Referência regulatória de telecomunicações (fonte primária): Medidas Administrativas para o Registro de Algoritmos do Ministério da Indústria e Tecnologia da Informação (MITI) (com supervisão dupla de algoritmos de cobrança e serviços financeiros); Avaliação de Conformidade de Segurança da Informação (Nível 2: 30 dias úteis / Nível 3: 45 dias úteis); Top 3 reclamações via ANATEL 消費者申立 (portabilidade de número, acessibilidade de faturas, gestão de suspensão/reativação de linha); Medidas de Gestão de Segurança de Dados no Setor Industrial e de Tecnologia da Informação (Em fase de teste) — lista negativa de transferência de dados para o exterior.
Tratamento de dados por terceiros sob a GDPR / LGPD 13.709/2018 (fonte primária): Artigos 21 e 55 da Lei de Proteção de Informações Pessoais — acordos de processamento por terceiros + período de retenção de registros de 3 a 5 anos (conforme o setor).
Pesquisa Stack Overflow 2025 com Desenvolvedores (fonte primária): Mais de 49.000 desenvolvedores pesquisados. A proporção de desenvolvedores que confiam na precisão da IA caiu de 40% em 2024 para 29% em 2025 (queda de 11 pontos percentuais); simultaneamente, 46% dos desenvolvedores desconfiam ativamente das saídas da IA (acima dos 31% em 2024). O code churn subiu de 3,1% em 2020 para 5,7% em 2024. https://survey.stackoverflow.co/2025/
Shadow AI (UpGuard 2025, nível dois): 80% dos funcionários globais usam ferramentas de IA generativa não aprovadas (não apenas desenvolvedores), 68% dos responsáveis pela segurança admitem IA não autorizada. A modernização da governança não acompanha a governança de Shadow AI, constituindo uma lacuna de conformidade. https://www.upguard.com/resources/the-state-of-shadow-ai
Casos próprios do autor (anonimizados): ① Treinamento interno de IA de uma operadora regional (Q4 2024, 11 etapas de revisão, já anonimizado) ② Discussão sobre atualização da avaliação de risco de crédito em um banco de capital aberto (H1 2025, anonimizado) ③ Redesenho do processo de revisão de mudanças de processo em uma grande empresa industrial (H2 2025, anonimizado) ④ Lock prático durante a promoção de grande porte de uma grande plataforma de e‑commerce (2025 Black Friday, anonimizado).
Nota sobre a anonimização dos casos: Os casos de operadora, banco, indústria e e‑commerce mencionados neste artigo baseiam‑se na experiência de treinamento interno de IA e no acompanhamento da equipe de transformação digital do autor desta série, tendo sido anonimizados; os parágrafos sobre implementação setorial representam projeções de problemas típicos e não constituem consultoria específica para clientes. Qualquer citação deve mencionar a anonimização.