Software e IA para executivos · Capítulo 24 de 41 · 7 min
Revisar a entrega pela lista do que mudou linha a linha
Pacote de mudança grande demais para uma sessão de leitura esconde as linhas que decidem a aprovação, fora do resumo do agente.
Este capítulo faz parte do curso gratuito Software e IA para executivos.
Recusar um pedido de mudança de 1.400 linhas custa menos do que aprová-lo picado pelo relato do agente que o escreveu (o assistente de IA que programa sozinho e relata o que fez). Na telemetria da Faros AI, de 2026, a mediana do tempo em revisão subiu 441,5% e 31% mais mudanças entraram na linha principal sem revisão nenhuma.
O agente escreve um resumo do que fez, e o resumo costuma estar correto naquilo que diz. A aprovação depende do que ele deixa de fora, e isso só aparece no diff, a lista do que mudou linha a linha.
Branch é a linha paralela de trabalho, onde uma mudança é desenvolvida sem afetar o que já está no ar. Pull request é o pedido formal para incorporar essa linha.
Quem revisa pode comentar e pode recusar. Diff é a lista exata do que foi acrescentado e do que foi removido, linha a linha, como o controle de alterações de um contrato.
Revisores precisam conferir as linhas removidas, adicionadas e alteradas, inclusive validações, acesso e efeitos em outras partes do sistema. O resumo descreve a intenção; a comparação entre versões mostra a alteração de código, e testes e revisão técnica ajudam a avaliar seus efeitos.
Isso não é tempo até a primeira revisão, nem prova de que a inteligência artificial causou o aumento. Use o achado para investigar o processo do seu time, comparando o antes e o depois da adoção.
Três critérios tornam uma mudança revisável: escopo coeso, revisão proporcional ao risco e plano de reversão testável. Não existe teto universal de linhas nem número de revisores adequado a todo produto.
Laboratório ao vivo: o relato e o diff do mesmo pedido
1. Escolha o documento que você vai ler
Os dois descrevem a mesma entrega, de dez linhas, no cadastro de pedidos. Um deles foi escrito por quem fez a mudança.
2. A mesma entrega, nos dois documentos
Resumo escrito pelo agente
- Ajustei o cadastro de pedidos para aceitar CNPJ em formatos variados.
- Simplifiquei a checagem que estava rejeitando cliente legítimo.
- Conectei o envio ao ERP com a credencial já usada pelo time.
- Mudança pequena, dez linhas, sem impacto em segurança.
Nada aqui é falso. O que decide a aprovação está no que a lista não diz.
As dez linhas alteradas
- Linhas 2 a 5: qualquer texto passa a valer como CNPJ, e o pedido entra sem cliente identificado.
- Linha 8: a credencial do ERP sai do cofre e passa a viver no repositório, visível para quem tiver acesso ao código.
- Linhas 1, 6, 9 e 10: inalteradas. São elas que fazem o resumo do agente parecer verdadeiro.
Vermelho sobre rosa é linha removida, verde sobre verde claro é linha acrescentada, e as duas cores valem igual no tema claro e no escuro. Sem suporte ao seletor de estado, os dois documentos aparecem em sequência.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Na reunião de revisão, peça o diff antes do resumo: aprovação de entrega olha o que mudou linha a linha, e usa o resumo só como índice de leitura.
Pergunte quantas linhas foram removidas e quantas foram acrescentadas. Verificação automática aprovada prova o que foi testado, nunca o que deixou de existir.
A Distribuidora Aurora, cenário ilustrativo do curso, recebeu do fornecedor o cadastro de clientes num pedido de 1.400 linhas, com os testes automatizados aprovados e o resumo do agente descrevendo mudança simples.
As duas linhas que decidiam a aprovação estavam fora do resumo: uma removia a validação de CNPJ, outra trocava a leitura do cofre por uma credencial escrita no código.
Teste automatizado confirma que o comportamento previsto continua funcionando; não enxerga a regra que sumiu, porque ninguém escreve teste para uma validação que acabou de ser apagada.
Fragmentar a entrega em pacotes que cabem numa sessão de leitura é trabalho de engenharia, e o fornecedor cobra por ele de qualquer jeito, antes ou depois do incidente.
Antes de aprovar a próxima entrega, peça o número de linhas alteradas e o tempo de revisão registrado. Confira quem aprovou e se essa pessoa também escreveu a mudança, e escreva o teto de linhas que a sua empresa aceita revisar de uma vez.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Engenharia de Software para ExecutivosLer o que mudou em cada alteração antes de aprovarExaminar conexões de Ler o que mudou em cada alteração antes de aprovar
- Do Agile ao Agentic Operating ModelO contrato que você assina antes de delegar ao agenteExaminar conexões de O contrato que você assina antes de delegar ao agente
- Letramento em IA para ExecutivosPeça à IA como quem contrata uma agênciaExaminar conexões de Peça à IA como quem contrata uma agência
- Prompt Engineering para ExecutivosConduzir a revisão executiva de um sistema de IA em 30 minutosExaminar conexões de Conduzir a revisão executiva de um sistema de IA em 30 minutos
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.