Uma equipe de doze desenvolvedores adotou um assistente de geração de código e, em poucas semanas, dobrou o número de pedidos de revisão abertos. Nada chegou antes ao cliente. A data de lançamento seguiu igual, o volume de chamados de suporte não caiu e a sensação interna era de que todos trabalhavam mais do que antes.
Embora fictício, o caso desenha o que se repete em operações que adotaram código gerado por IA sem mexer no restante do fluxo. Jean Pierre Lessa e Santos Ferreira, diretor de tecnologia, aponta que a aceleração individual não vira entrega quando a etapa seguinte continua com a mesma capacidade de absorção.
Duas semanas depois, a fila de revisão dobrou
O primeiro sinal apareceu no tempo até o primeiro comentário. Pedidos que antes recebiam retorno no mesmo dia passaram a esperar três, quatro dias. Como o número de revisores não mudou, cada pessoa acumulou o dobro de material para ler, e essa leitura entrou na fila atrás do próprio trabalho de escrever.
Enquanto isso, o painel de atividade subia. Commits, linhas alteradas e pedidos abertos cresciam semana a semana, e a liderança lia aquilo como aumento de produtividade. O estoque parado no meio do caminho não aparecia em gráfico nenhum, porque nenhum indicador media o que estava apenas esperando aprovação.
Por que revisar custa mais do que escrever?
Ler o código alheio exige reconstruir a intenção de quem escreveu, e essa reconstrução fica mais lenta quando o autor não é uma pessoa. Conforme nota Jean Pierre Lessa e Santos Ferreira, o revisor de um trecho gerado por modelo não tem a quem perguntar sobre a decisão de projeto: precisa deduzir o porquê a partir do código pronto.
Duzentas linhas geradas custam segundos. Revisar as mesmas duzentas linhas custa a atenção de sempre, e o pedido cresce sem esforço quando quem escreve é um modelo. Aprovação rápida de bloco extenso não significa que o bloco foi entendido. Significa que o revisor desistiu de entender.
O retrabalho que aparece com atraso
A conta chega depois. Pesquisas de referência sobre adoção de IA em engenharia apontam ganho claro na efetividade individual, acompanhado de aumento na instabilidade das entregas, com mais falhas em produção e mais tempo de recuperação. O ganho de escrita é imediato e visível; o custo de manutenção se distribui ao longo de meses.
Nesse ponto, o executivo indica um efeito menos evidente: código quase certo gera correção em cima de correção. O trecho passa nos testes, entra em produção e falha numa condição de borda, e a equipe volta a um problema que considerava resolvido. Cada retorno desses consome revisão outra vez.
O que a equipe mudou para destravar o fluxo?
A primeira medida foi limitar o tamanho do pedido de revisão. Alterações acima de um número definido de linhas passaram a ser quebradas antes de entrar na fila, o que reduziu o tempo de leitura por item e devolveu profundidade ao comentário. Pedido pequeno é lido inteiro. Pedido grande é folheado.
Em seguida, o time atacou o volume em aberto, com um teto de trabalhos simultâneos por pessoa: quem tivesse dois pedidos parados na fila revisava antes de abrir o terceiro. A recomendação de Jean Pierre Lessa e Santos Ferreira segue essa direção, com a revisão tratada como parte do trabalho, e não como interrupção dele.
Medir entrega em vez de medir esforço
O caso descrito não é sobre ferramenta. Um assistente de código não cria gargalo, ele expõe o gargalo que já existia e antes ficava escondido pela lentidão da escrita. Onde o processo de revisão era frágil, o volume adicional converte fragilidade em fila visível em poucas semanas.
Daí a mudança de indicador. Contar o que cada pessoa produz descreve esforço, não resultado, e a geração automática inflou justamente esse número. Tempo entre a abertura do pedido e a chegada em produção, taxa de falha por mudança e volume de retrabalho medem outra coisa: a capacidade real da equipe de terminar aquilo que começa.
