Revisão de Código com IA da Synthesia Revela o Custo de Gerar Mais Rápido
A revisão de código com IA da Synthesia expõe um conflito acentuado, apesar de um aumento de 120% nos pull requests: gerar código mais rápido não elimina o trabalho de engenharia. Ele apenas o desloca para etapas posteriores.
A Synthesia afirma que 95% de seus pull requests agora contêm código gerado por IA. Ainda assim, menos de 5% das mudanças deixam de passar por revisão humana. Esses números evidenciam o problema emergente para organizações de engenharia que adotam agentes de programação em escala.
O novo gargalo já não é digitar código. É determinar se o código gerado reflete o design pretendido, se se encaixa no sistema existente, se lida com condições incomuns e se permanece seguro após a implantação.
Essa mudança pressiona líderes de engenharia a redesenhar todo o processo de revisão. Amazon, AWS, Bonterra, IBM, Making Sense e Temporal estão testando variações da mesma ideia. A automação deve lidar com inspeções rotineiras, enquanto as pessoas mantêm autoridade sobre decisões consequentes.
Essa divisão parece eficiente. Mas também cria uma pergunta difícil. Se um sistema de IA escreve o código e outro sistema de IA o revisa, que evidência permite ao engenheiro responsável confiar em qualquer um dos dois?
Revisão de Código com IA da Synthesia Revela o Novo Gargalo
O código gerado por IA aumentou a capacidade de produção mais rapidamente do que as empresas ampliaram sua capacidade de verificá-lo.
Os 118 engenheiros da Synthesia adotaram ferramentas de programação com IA em todo o fluxo de trabalho em novembro de 2025. Até agosto de 2026, os pull requests haviam aumentado 120% em relação ao ano anterior, segundo o CTO Peter Hill.
Um pull request é uma mudança proposta que outro engenheiro ou sistema automatizado examina antes de ela entrar na base principal de código. Mais pull requests podem indicar maior produção, mas cada solicitação também cria trabalho de testes, revisão, coordenação e manutenção.
As mudanças na Synthesia não foram apenas pequenas sugestões concluídas por uma ferramenta de preenchimento automático. Hill disse no relato original que 95% dos pull requests da empresa continham código gerado por IA.
Esse volume revelou fragilidades recorrentes. Um agente de programação pode criar uma função sem reconhecer que a mesma capacidade já existe em outra parte do repositório. O contexto limitado então transforma uma implementação em várias versões concorrentes.
A Synthesia teria encontrado até 10 versões da mesma função. Os engenheiros precisam localizar a duplicação, decidir qual implementação pertence ao produto, remover as demais e ensinar o agente a não repetir o erro.
Cada função gerada pode parecer razoável quando analisada isoladamente. O defeito só se torna evidente quando alguém entende o sistema mais amplo. Essa distinção explica por que um código que passa por uma inspeção superficial ainda pode aumentar a dívida técnica.
Dívida técnica é o trabalho futuro de engenharia criado por atalhos, complexidade desnecessária ou escolhas fracas de design no software atual. A IA não precisa gerar sintaxe quebrada para criá-la. Basta que o modelo produza código localmente plausível que entre em conflito com a arquitetura maior.
Hill descreveu a obtenção do resultado pretendido em escala empresarial como uma quantidade enorme de trabalho. Ele também questionou se as equipes algum dia confiarão completamente em código gerado por agentes.
Esse ceticismo não impediu a Synthesia de usar agentes de programação. Em vez disso, a empresa direciona a atenção humana de acordo com o risco. Uma alteração em uma mensagem de erro recebe menos escrutínio do que uma mudança envolvendo dados de clientes ou regras centrais de negócio.
Mesmo com essa triagem, mais de 95% das mudanças ainda recebem revisão humana. A empresa está ganhando capacidade de geração enquanto preserva barreiras humanas em torno da maior parte das implantações.
A mesma tensão aparece em todo o setor. A Sonar pesquisou mais de 1.100 desenvolvedores profissionais e constatou que os participantes atribuíram 42% do código submetido à IA.
No entanto, 96% não confiavam plenamente que o código gerado por IA funcionaria corretamente. Apenas 48% disseram que sempre verificavam código assistido por IA antes de submetê-lo, segundo a pesquisa com desenvolvedores.
A lacuna entre desconfiança e verificação consistente importa mais do que o número bruto de adoção. Ela sugere que algumas organizações estão produzindo código gerado mais rapidamente do que seus controles conseguem avaliá-lo.
Trinta e oito por cento dos participantes disseram que o código gerado por IA exigia mais esforço de revisão do que código escrito por colegas. Sessenta e um por cento disseram que o código gerado frequentemente parecia correto, embora permanecesse pouco confiável.
Essas conclusões não estabelecem que toda mudança gerada por IA seja pior. A Sonar vende produtos de verificação de código, e sua pesquisa reflete experiências relatadas, não medições controladas de produção.
Ainda assim, os números estão alinhados aos relatos operacionais da Synthesia e de outras empresas. A geração de código acelerou, mas a confiança não acelerou na mesma proporção.
Programar Mais Rápido Desloca o Trabalho para Etapas Posteriores
A promessa de produtividade enfraquece quando as organizações medem código gerado em vez de software confiável chegando aos usuários.
Um agente de programação pode criar milhares de linhas em poucos minutos. A contagem de linhas, porém, diz pouco sobre se a mudança deveria existir, se ela se integra corretamente ou se resolve o problema solicitado.
A Amazon encontrou essa distinção ao modernizar 17 anos de código por trás de seu aplicativo de compras para dispositivos móveis. O engenheiro principal sênior McLaren Stanley trabalha com uma equipe de 70 pessoas que dá suporte a mais de 1.000 desenvolvedores.
Stanley descreveu um agente gerando 25.000 linhas na versão errada de Swift, a linguagem de programação da Apple. Converter o resultado criou 600 erros que o agente não conseguiu resolver em conjunto.
A equipe descartou o código gerado em vez de repará-lo linha por linha. Stanley atualizou a especificação, que é um plano detalhado que define o que o agente deve construir e como deve se comportar.
Após essa correção, o agente teria regenerado o código corretamente em 15 minutos. O episódio mostra os dois lados do argumento da produtividade.
O agente se recuperou mais rápido do que uma pessoa conseguiria reescrever 25.000 linhas. Ainda assim, primeiro produziu uma grande mudança inutilizável porque faltava uma restrição importante.
A velocidade de geração ampliou a qualidade do plano. Uma especificação incompleta produziu falha em uma escala incomum. Uma especificação corrigida produziu rapidamente um resultado utilizável.
Essa relação muda onde os engenheiros seniores gastam seu tempo. Eles precisam definir arquitetura, restrições, interfaces, critérios de aceitação e comportamentos proibidos antes que um agente comece a implementação.
O trabalho deixa de ser a expressão de cada instrução em sintaxe de programação e passa a ser a construção e a defesa de um plano executável. Isso continua sendo engenharia de software, mesmo quando menos toques aparecem no editor.
As evidências independentes sobre produtividade geral continuam mistas. Um estudo randomizado da METR de 2025 analisou 16 desenvolvedores experientes de código aberto concluindo 246 tarefas em repositórios que conheciam bem.
Esses desenvolvedores levaram 19% mais tempo quando ferramentas de IA do início de 2025 estavam disponíveis, segundo o teste de produtividade. Antes de participar, eles esperavam que a IA os tornasse 24% mais rápidos.
Depois, eles ainda acreditavam que a IA havia acelerado seu trabalho em cerca de 20%. O resultado medido apontou na direção oposta.
O estudo foi pequeno e concentrou-se em desenvolvedores experientes trabalhando em repositórios familiares e maduros. A METR alertou explicitamente contra aplicar seu resultado a todos os desenvolvedores, ferramentas ou ambientes de programação.
Desenvolvedores trabalhando em sistemas desconhecidos podem obter mais valor de explicações fornecidas por IA e da navegação em repositórios. Modelos mais novos e melhores fluxos de trabalho com agentes também podem alterar o resultado.
A METR reconheceu que ferramentas posteriores provavelmente oferecem benefícios maiores. Seu estudo continua valioso porque separa a sensação de velocidade do tempo de conclusão medido.
Um desenvolvedor pode sentir que está mais rápido ao observar um agente produzir resultados visíveis. Fazer prompts e revisar também pode parecer menos cansativo do que implementar manualmente a mesma mudança.
Nenhuma dessas sensações garante que uma mudança correta chegue mais cedo à produção. O tempo gasto esperando, corrigindo mal-entendidos, lendo resultados gerados e limpando código desnecessário ainda conta.
Um estudo de campo empresarial mais recente oferece um resultado mais otimista, com uma qualificação importante. Pesquisadores examinaram 802 desenvolvedores e 196.212 pull requests de janeiro de 2024 a abril de 2026.
A produtividade por desenvolvedor acabou alcançando 2,09 vezes a linha de base anterior à adoção na empresa estudada. Os pesquisadores alertaram que a adoção não foi atribuída aleatoriamente, portanto não puderam atribuir todo o ganho diretamente à IA.
Mais importante ainda, o sistema de revisão da organização mudou junto com a produção. A carga por revisor praticamente dobrou, e a revisão automatizada superou a revisão humana. As taxas de merge e reversão permaneceram estáveis.
Essa evidência apoia uma conclusão mais restrita do que “a IA duplica a produtividade de engenharia”. Ela sugere que uma produção elevada se torna sustentável quando uma organização redesenha a revisão e acumula experiência com as ferramentas.
A unidade central de valor não é código gerado. É uma mudança que sobrevive à revisão, chega aos usuários, evita incidentes e permanece sustentável.
Planos e Agentes de Revisão Tornam-se a Camada de Controle
A resposta mais forte ao código ruim produzido por IA começa antes da geração e continua por uma revisão em camadas e baseada em risco.
As empresas estão construindo uma camada de controle em torno de agentes de programação. Essa camada combina especificações, testes automatizados, verificações de segurança, aplicação de políticas, sinais de confiança e escalonamento humano.
O planejamento vem primeiro porque a revisão, sozinha, não consegue resgatar com eficiência uma tarefa mal enquadrada. Uma especificação precisa restringe as opções do agente antes que ele gere uma mudança grande.
A especificação deve identificar o comportamento pretendido, os componentes relevantes, os limites arquiteturais, as restrições de dados e os testes de aceitação. Também deve descrever condições de falha e entradas incomuns.
Essa abordagem faz mais do que melhorar prompts. Ela cria uma referência que revisores automatizados e pessoas podem usar para avaliar o resultado.
Sem um plano aprovado, um revisor precisa inferir o que o autor pretendia enquanto lê a implementação. Essa tarefa se torna mais difícil quando o autor nominal é um agente sem entendimento estável além de seu contexto atual.
Com um plano, a pergunta da revisão se torna mais concreta. A implementação corresponde ao design acordado ou o agente inventou uma solução diferente?
A AWS usa agentes especializados para realizar verificações iniciais, segundo o engenheiro principal sênior David Yanacek. Esses agentes testam se o código funciona, comparam-no ao plano original e procuram problemas de segurança antes da revisão humana.
Esse fluxo de trabalho em camadas trata a revisão por IA como filtragem, não como autoridade final. As máquinas lidam com leituras repetitivas e comparações estruturadas. As pessoas julgam compensações ambíguas e assumem responsabilidade.
A Bonterra adotou um modelo semelhante depois que sua carga de revisão aumentou acentuadamente. A fornecedora de software para organizações sem fins lucrativos tem cerca de 290 engenheiros.
Em três meses após adotar IA, as mudanças propostas triplicaram, segundo a CTO Tanuja Korlepra. A quantidade de código entrando em revisão aumentou dez vezes, enquanto os tempos de revisão triplicaram.
Esses números ilustram por que a revisão tradicional linha por linha não pode simplesmente absorver uma quantidade ilimitada de produção gerada. Adicionar um agente de programação pode expandir a produção mais rápido do que uma empresa consegue contratar revisores experientes.
Os agentes de revisão da Bonterra comparam o código proposto com o design aprovado, os requisitos de segurança, os padrões de codificação e as regras de acessibilidade. Eles também produzem uma avaliação de confiança.
Uma pontuação baixa de confiança ou um problema sinalizado encaminha a alteração para uma pessoa. O código que afeta pagamentos, informações pessoais ou outros sistemas sensíveis sempre recebe revisão humana.
Essa abordagem usa o risco como um alocador de atenção escassa. Ela não afirma que a revisão automatizada torna correta toda alteração de baixo risco.
Em vez disso, a triagem baseada em risco pergunta onde uma falha causaria o maior dano. As equipes podem então aplicar sua atenção humana limitada onde o contexto e a responsabilidade mais importam.
Pesquisas sobre pull requests criados por agentes sugerem que sinais estruturais podem ajudar. Um estudo de esforço de revisão de 2026 analisou 33.707 pull requests gerados por agentes em 2.807 repositórios.
Os pesquisadores descobriram que 28,3% foram integrados em menos de um minuto, refletindo alterações pontuais que exigiram pouca interação. Outras solicitações entraram em ciclos de revisão mais longos, nos quais os agentes por vezes travaram ou deixaram de responder ao feedback.
Os pesquisadores construíram um modelo para identificar, no momento da criação, os 20% de pull requests que exigiam mais esforço. Usando sinais estruturais, ele capturou 69% do esforço total de revisão dentro desse orçamento de revisão.
O modelo alcançou uma pontuação de área sob a curva de 0,957 em uma divisão de avaliação baseada no tempo. Essa pontuação mede quão bem um classificador separa alterações de maior esforço das de menor esforço.
As descrições textuais ofereceram pouco valor preditivo adicional. O que os agentes modificaram importou mais do que a forma como descreveram seu trabalho.
Essa descoberta reforça o argumento de revisar a estrutura da alteração logo no início. Número de arquivos, volume de código, mudanças de configuração, alcance das dependências e abrangência arquitetural podem revelar riscos antes que alguém discuta estilo de código.
No entanto, uma camada de controle eficaz precisa de independência entre geração e avaliação. Pedir ao mesmo modelo que aprove premissas que ele introduziu pode reproduzir o ponto cego original.
As equipes precisam de testes determinísticos, análise estática, scanners de segurança, políticas de repositório e conhecimento humano do domínio junto à revisão baseada em modelos. Cada controle captura modos de falha diferentes.
A documentação também se torna infraestrutura operacional. Um agente de programação não pode seguir decisões arquiteturais, regras de responsabilidade ou lições de incidentes anteriores que permanecem dispersas entre reuniões e a memória individual.
Uma base de conhecimento de engenharia pode ajudar as equipes a preservar esse contexto. Ela deve apoiar o processo de revisão sem substituir testes autoritativos ou controles de repositório.
A Aprovação Humana Não Pode Virar Teatro
A revisão falha quando um engenheiro aprova um comportamento funcional sem compreender o design gerado por trás dele.
JD Raimondi, arquiteto-chefe de IA da consultoria de software Making Sense, chama esse resultado de “aprovação teatral”. Um revisor confirma que um recurso aparentemente funciona, examina superficialmente a implementação e a aprova sem entender as escolhas subjacentes.
Esse problema já existia antes da IA generativa. Pull requests grandes, pressão por prazos, responsabilidade pouco clara e testes superficiais sempre enfraqueceram a revisão.
Os agentes de programação aumentam o risco porque podem produzir implementações convincentes em uma velocidade incomum. Formatação limpa e explicações confiantes podem tornar premissas fracas mais difíceis de perceber.
Um agente pode satisfazer testes visíveis enquanto lida incorretamente com entradas raras. Pode introduzir uma dependência que conflita com a política da empresa ou duplicar uma lógica escondida em outro lugar de um grande repositório.
Também pode enfraquecer a segurança sem produzir uma falha funcional óbvia. Limites de autorização, regras de retenção de dados, condições de corrida e padrões inseguros exigem mais do que uma demonstração rápida.
A Temporal responde exigindo que o engenheiro que envia o código defenda o trabalho gerado pelo agente. Sob sua política “Send Back”, os engenheiros devem explicar as escolhas de design com suas próprias palavras.
Eles também devem descrever como o código lida com condições incomuns. Se não conseguirem fazê-lo, o revisor rejeita a submissão.
O CEO Samar Abbas resumiu a política diretamente: “Recusamos deixar que a revisão de código se torne um depósito para saídas de modelos não verificadas.”
A regra altera o incentivo enfrentado pela pessoa que aciona um agente. Gerar um patch maior já não transfere todos os custos de compreensão para outra pessoa.
Quem submete o código deve adquirir entendimento suficiente para responder a perguntas e assumir o resultado. Essa exigência desencoraja volume especulativo de código e recompensa alterações menores e defensáveis.
Ela também preserva a responsabilização. Um agente de IA não pode participar de uma chamada de incidente, explicar uma violação regulatória ou decidir se uma implantação arriscada deve continuar.
A responsabilidade humana permanece essencial mesmo quando as máquinas fazem a maior parte da leitura. A questão é se as organizações dão aos revisores tempo, contexto e autoridade suficientes para exercer essa responsabilidade.
A pesquisa sobre entrega do Google concluiu que a adoção de IA estava associada tanto a maior produtividade de software quanto a maior instabilidade na entrega. O relatório descreveu a IA como um amplificador do sistema ao seu redor.
Testes robustos, plataformas claras, feedback rápido e documentação saudável podem transformar a geração ampliada em produção útil. Controles fracos podem deixar que o mesmo aumento de volume multiplique defeitos e confusão.
Esse enquadramento evita dois exageros comuns. Código gerado por IA não é automaticamente inseguro, e revisão automatizada não é automaticamente suficiente.
O resultado depende do fluxo de trabalho em torno de ambos os sistemas. Uma equipe que mede sugestões aceitas ou linhas geradas pode deixar de perceber o retrabalho posterior.
Um sistema de medição mais forte acompanha as alterações após a integração. Indicadores úteis incluem defeitos que escaparam, implantações com falha, achados de segurança, frequência de reversões, tempo de revisão e esforço de manutenção.
As equipes também devem distinguir automação de baixo risco de lógica de produto com consequências relevantes. Atualizar documentação gerada não traz a mesma exposição que mudar a autorização de pagamentos.
A classificação de risco ainda pode falhar. Uma pequena alteração em um auxiliar de autenticação compartilhado pode ter consequências mais amplas do que uma grande atualização em uma ferramenta isolada.
Por isso, a contagem de linhas por si só não pode determinar o nível de escrutínio. Os sistemas de revisão precisam de mapas de responsabilidade, informações sobre dependências, dados históricos de incidentes e compreensão dos limites sensíveis.
Revisores automatizados introduzem seu próprio ruído. Se os agentes inundarem desenvolvedores com alertas de baixo valor, as pessoas podem se condicionar a ignorar avisos.
A fadiga de alertas então converte um controle técnico em outra forma de teatro. O sistema de revisão parece rigoroso, enquanto descobertas importantes desaparecem em meio a comentários rotineiros.
Por isso, as empresas precisam medir a precisão e a utilidade dos achados automatizados. Um agente de revisão deve reduzir os custos de busca humana, não produzir outra fila que ninguém consiga esvaziar de forma responsável.
A conclusão cética é direta. A revisão assistida por IA pode ajudar a administrar o volume gerado por IA, mas as evidências não sustentam remover a responsabilidade humana de alterações de alto risco.
O Pipeline de Engenheiros Juniores Enfrenta um Risco Diferente
Se os agentes absorverem o trabalho que treinava engenheiros juniores, as empresas precisarão reconstruir deliberadamente o caminho de iniciante a revisor confiável.
Tradicionalmente, desenvolvedores iniciantes desenvolvem discernimento por meio da implementação. Eles rastreiam código existente, fazem alterações delimitadas, recebem feedback detalhado, depuram falhas e passam gradualmente a lidar com sistemas maiores.
Muitas dessas tarefas são adequadas para agentes de programação. Elas são delimitadas, repetitivas e fáceis de descrever para engenheiros seniores.
Automatizá-las pode melhorar a produção no curto prazo. Também pode eliminar a prática que ensina aos recém-chegados como abstrações falham, por que convenções existem e onde os sistemas de produção escondem complexidade.
Um engenheiro júnior não pode se tornar um revisor confiável aprovando código que ainda não entende. Ler a produção gerada ajuda, mas a inspeção passiva não substitui completamente construir, quebrar e reparar software.
A Making Sense teria observado alguns de seus maiores ganhos de produtividade com IA entre engenheiros juniores. A consultoria também se preocupa com o que esses funcionários deixam de aprender quando os agentes cuidam da implementação.
Sua resposta é manter os juniores envolvidos na decisão sobre por que um cliente precisa de um recurso e como esse recurso deve se comportar. Eles participam da definição do problema, em vez de receber apenas um resultado gerado por IA para verificar.
A IBM está tentando outra abordagem. Novos engenheiros recebem atribuições mais exigentes mais cedo, segundo Neel Sundaresan, gerente-geral de automação e IA da empresa.
A IA auxilia na implementação e nos testes. Quando o sistema falha, os engenheiros juniores devem diagnosticar o problema e corrigi-lo antes da aprovação de um sênior.
Sundaresan estima que a IA pode ajudar engenheiros juniores a executar de 70% a 80% de algumas tarefas antes associadas a desenvolvedores seniores. Esse número é uma estimativa executiva, não uma medição independente de produtividade.
A parte importante é a responsabilidade que a acompanha. Os juniores ainda investigam a falha, em vez de tratar o agente como uma fonte inquestionável.
A Synthesia contrata principalmente engenheiros de nível intermediário e sênior. Seus funcionários menos experientes trabalham tanto com um colega sênior quanto com um agente de IA, enquanto assumem partes definidas dos projetos.
A Bonterra também mudou o desenvolvimento de profissionais juniores. Os agentes agora executam muitas tarefas bem definidas que antes serviam como atribuições de treinamento.
Em vez disso, a empresa pede que engenheiros juniores assumam os resultados junto de colegas experientes. Eles aprendem a orientar agentes, questionar resultados e permanecer responsáveis pelo comportamento entregue.
Korlepra resumiu a preocupação de longo prazo de forma clara: “Se o setor para de contratar juniores, o setor para de formar seniores.”
Esse problema de pipeline não aparecerá imediatamente nos painéis de entrega. Uma empresa pode reduzir a contratação de iniciantes e ainda aumentar a produção por vários trimestres.
O custo chega mais tarde, quando ela precisa de engenheiros que entendam sistemas legados, incidentes de produção, restrições dos clientes e histórico arquitetural. Essas capacidades se desenvolvem por meio da exposição acumulada.
Por isso, as organizações precisam de sinais de treinamento ao lado das métricas de produtividade. Elas devem acompanhar se engenheiros juniores conseguem explicar alterações, diagnosticar falhas, escrever testes e lidar com atribuições cada vez mais ambíguas.
A participação na revisão também precisa de estrutura. Entregar a um engenheiro júnior um patch enorme gerado por agente sem contexto ensina resistência, não discernimento.
Alterações menores criam ciclos de aprendizado melhores. Uma especificação clara, escopo limitado, testes observáveis e feedback direto de seniores permitem que recém-chegados conectem intenção e implementação.
As revisões de incidentes oferecem outra sala de aula importante. Os engenheiros aprendem por que decisões aparentemente inofensivas criaram falhas operacionais e como as salvaguardas devem mudar.
As empresas podem incorporar essas lições tanto ao treinamento quanto ao contexto dos agentes. No entanto, o objetivo de aprendizado humano deve continuar explícito, em vez de se tornar um efeito colateral da implementação de ferramentas.
O engenheiro sênior do futuro provavelmente passará mais tempo orientando e avaliando agentes. Isso torna o conhecimento fundamental mais importante, não menos.
O discernimento exige um modelo mental do sistema. Sem experiência para construir esse modelo, um revisor só consegue avaliar se o código gerado parece familiar.
O pipeline de profissionais juniores, portanto, faz parte do problema de revisão de código com IA. As empresas precisam produzir tanto software confiável quanto pessoas capazes de reconhecer quando a automação está errada.
Três Sinais Mostrarão se o Novo Fluxo de Trabalho Funciona
A próxima fase será julgada pela estabilidade em produção, pela economia da revisão e pelo desenvolvimento da expertise humana.
O primeiro sinal é se o maior volume de pull requests melhora a entrega sem aumentar as falhas. As empresas devem publicar ou acompanhar internamente a frequência de deploys ao lado de reversões, defeitos que escaparam, incidentes e descobertas de segurança.
Uma taxa de reversão estável é encorajadora, mas não captura todos os custos de manutenção. Lógica duplicada e desvio arquitetural podem permanecer em produção muito antes de provocarem um incidente visível.
Se o ritmo de entrega aumentar enquanto a confiabilidade e a manutenção permanecerem estáveis, o fluxo de trabalho redesenhado ganhará credibilidade. Se as filas de revisão e o retrabalho continuarem crescendo, a geração apenas deslocou a restrição.
O segundo sinal é se a revisão baseada em risco reduz o esforço humano sem enfraquecer a responsabilização. Bonterra e Synthesia estão encaminhando mudanças de acordo com sua sensibilidade, enquanto a AWS usa agentes para verificações iniciais.
Evidências úteis mostrariam quais descobertas automatizadas os engenheiros aceitam, quais defeitos escapam e com que frequência mudanças supostamente de baixo risco exigem reparos posteriores.
A latência da revisão deve cair porque a automação elimina o trabalho rotineiro, não porque as pessoas aprovam mais código sem entendê-lo. A exigência de explicação da Temporal oferece um teste de compreensão genuína.
Se os engenheiros conseguem defender projetos gerados enquanto dedicam menos tempo à inspeção mecânica, a revisão de código com IA está realizando um trabalho útil. Se a aprovação se tornar cerimonial, o fluxo de trabalho estará falhando.
O terceiro sinal é se os engenheiros juniores continuam evoluindo para assumir responsabilidade técnica independente. As empresas devem acompanhar a prontidão para promoção, o desempenho em depuração, a participação em incidentes e a complexidade das tarefas que os juniores conseguem concluir de forma responsável.
Os ganhos de produtividade de curto prazo não compensarão uma oferta cada vez menor de revisores experientes. Toda tarefa automatizada de treinamento precisa de um ciclo de aprendizado substituto, com consequências e feedback reais.
A revisão de código com IA da Synthesia mostra que o agente de programação em si é apenas um componente. Especificações, contexto do repositório, verificações automatizadas, políticas de escalonamento, explicações humanas e desenvolvimento de carreira determinam o resultado final.
Agora, os líderes de engenharia devem fazer uma pergunta mais difícil do que quanto código a IA gerou. Quanto software verificado e sustentável chegou aos usuários, e a equipe fortaleceu sua capacidade de avaliar a próxima mudança?
As organizações capazes de responder às duas partes terão evidências de produtividade. As que não conseguirem continuarão produzindo código mais rápido enquanto acumulam incerteza nas etapas posteriores.
