Quando a produtividade esconde o verdadeiro custo
Passei os últimos meses acompanhando equipes que adotaram GitHub Copilot, Cursor e Claude Code em ritmo acelerado. O discurso inicial era sempre o mesmo: “vamos aumentar a velocidade de entrega, os devs vão focar em lógica complexa”. O que testemunhei, porém, foi um fenômeno mais sutil e perigoso. As tarefas repetitivas realmente encolheram, mas um novo gargalo surgiu — a revisão de código. Um desenvolvedor júnior consegue gerar um endpoint completo em 15 minutos; a reunião de code review para validar aquele mesmo trecho pode consumir duas horas de três pessoas. A conta não fecha, e o pior: ninguém está medindo isso.
A sensação de estabilidade nos papéis de Tech Lead e Tech Manager é ilusória. O nome do cargo não mudou, mas o trabalho mudou profundamente. O líder técnico hoje não é mais a pessoa que escreve os blocos mais complexos; é a pessoa que sabe filtrar o que a máquina gerou, identificar riscos implícitos e manter a integridade arquitetural. Quando a IA sugere um trecho que funciona mas viola uma regra de negócio ou expõe dados sensíveis, o revisor precisa ter um faro que nenhum modelo de linguagem possui: o entendimento do contexto humano e regulatório.
Para quem atua com privacidade em produto, esse ponto merece atenção redobrada. Muitos dos acidentes de segurança que investiguei nos últimos anos não vieram de falhas complexas, mas de código que parecia correto na superfície — exatamente o perfil do que uma IA generativa produz. Se a ferramenta não entende que a variável cpf não pode ser logada sem criptografia, ou que determinada API não pode expor dados de terceiros, a responsabilidade cai inteiramente sobre o humano que revisa. E se esse humano está sobrecarregado pelo volume de PRs gerados por IA, o risco de vazamento cresce exponencialmente.
O descompasso entre geração e revisão
Em times com mais de vinte desenvolvedores, a heterogeneidade no uso da IA cria atritos invisíveis. Um dev que domina prompts avançados produz PRs de 400 linhas em quarenta minutos. Outro, que prefere não usar IA ou usa de forma conservadora, revisa manualmente cada linha. O resultado é uma percepção torta de produtividade: quem gera rápido parece eficiente, e quem revisa devagar parece lento. A verdade é que o sistema de medição está quebrado. Métricas como ‘tickets fechados por semana’ ou ‘linhas de código commitadas’ se tornaram enganosas, porque não capturam a carga de revisão gerada por cada artefato.
Do ponto de vista de privacidade, esse descompasso é crítico. Um PR grande e acelerado tende a receber revisões menos atentas justamente porque o revisor sabe que o código foi gerado por IA e pode confiar cegamente — confiança essa que é frequentemente injustificada. Já vi casos em que uma função de busca, gerada pelo Copilot, incluía parâmetros de depuração que vazavam IDs internos de usuários para o front-end. O teste unitário passava, a integração parecia funcionar, mas a violação de privacidade estava lá, silenciosa. A correção, semanas depois, exigiu refatoração e rollback de uma funcionalidade inteira.
Reinventando a revisão de código com foco em privacidade
O protocolo tradicional de code review — olhar lógica, estilo e cobertura de testes — é insuficiente quando a máquina escreve o código. Precisamos de uma camada extra de validação que questione a origem da solução. Isso não significa desconfiar de toda linha gerada por IA, mas sim estabelecer uma triagem de confiança baseada em contexto. Por exemplo: se o código envolve manipulação de dados pessoais, o revisor deve obrigatoriamente verificar se há logging inadequado, se a anonimização foi aplicada e se a permissão de acesso está de acordo com a política da empresa.
Uma prática que implementei em uma squad recente foi o uso de um checklist híbrido de revisão. Ele inclui itens tradicionais (testes, estilo) e itens específicos para código gerado por IA: dependências implícitas, presença de chaves de API hardcoded, chamadas a bibliotecas com vulnerabilidades conhecidas, e conformidade com a LGPD. O revisor também é incentivado a pedir que a própria IA explique o código — usando o mesmo assistente que gerou o trecho — criando uma camada de validação cruzada. Isso não elimina o erro, mas reduz a falsa confiança.
Outro ponto que aprendi na prática é a importância de marcar explicitamente nos commits o que foi gerado total ou parcialmente por IA. Parece burocrático, mas quando um bug aparece seis meses depois, o desenvolvedor que investiga precisa saber que aquele trecho veio de um modelo, não de um raciocínio humano. Isso muda a abordagem de debugging: em vez de tentar entender a intenção original (que pode não existir), a equipe foca em reescrever a lógica a partir dos requisitos atuais.
Métricas que importam: manutenibilidade, não velocidade
Tech Managers precisam reavaliar as métricas de sucesso. Contar PRs aprovados ou deploys por dia é um convite para times inflarem a produção com código de baixa qualidade. A métrica que venho adotando nas equipes que assessoro é o tempo médio de compreensão de um PR: quanto tempo um novo membro leva para entender o que aquele código faz e por que foi escrito daquela forma. Esse indicador, ainda subjetivo, reflete diretamente a dívida técnica e o risco de incidentes de segurança. Quando o tempo de compreensão sobe, é sinal de que a IA está gerando soluções que ninguém realmente domina.
Outra métrica útil é a taxa de regressões associadas a código gerado por IA. Na minha experiência, essa taxa é mais alta do que a média do time, especialmente nos primeiros três meses de adoção da ferramenta. Isso não significa que a IA seja ruim, mas que o processo de revisão ainda não se adaptou. Ao rastrear esses números, o Tech Manager pode identificar quais áreas do sistema são mais sensíveis e estabelecer regras mais rígidas para geração assistida naquelas camadas — por exemplo, proibir IA na lógica de pagamento ou na manipulação de tokens de autenticação.
O guardião do contexto na era da máquina
O Tech Lead que se destaca hoje não é aquele que escreve o código mais rápido, mas aquele que sabe contextualizar as saídas da IA. Em uma arquitetura legada com décadas de decisões técnicas, a ferramenta não conhece as restrições históricas — por que determinado módulo foi descontinuado, qual API não pode ser alterada por contrato, quais dados não podem ser replicados por questões de compliance. Cabe ao líder técnico atuar como um filtro cultural, garantindo que a sugestão da IA não entre em conflito com regras de negócio que estão no papel ou na cabeça dos stakeholders.
Essa função de guardião é particularmente relevante para a privacidade. A LGPD, a GDPR e outras regulamentações não são apenas leis; são restrições de design que a IA não compreende. Se um modelo sugerir uma função que coleta dados sem consentimento explícito, ou uma biblioteca que armazena logs em servidores fora da jurisdição, é o Tech Lead quem deve barrar. E isso exige não apenas conhecimento técnico, mas uma cultura de compliance embedada no time. Reuniões quinzenais de alinhamento sobre riscos de privacidade, com participação do DPO, ajudam a criar esse radar.
Contratação: o novo teste é revisar, não criar
O processo seletivo também precisa mudar. Perguntar “escreva uma função que faça X” já não separa candidatos medianos dos bons; qualquer pessoa com um assistente de IA faz isso em segundos. O verdadeiro diferencial é a capacidade de criticar e refatorar código gerado. Nas últimas entrevistas que conduzi, substituí o exercício de codificação por um PR simulado: entreguei um trecho gerado por IA com erros sutis de segurança e contexto, e pedi que o candidato revisasse, apontasse problemas e propusesse correções. Os resultados foram reveladores. Candidatos que se saíam bem em coding challenges tradicionais muitas vezes não conseguiam identificar a falta de sanitização de entrada ou o vazamento de dados pessoais no log.
Essa mudança reflete uma verdade incômoda: a IA generativa torna a habilidade de criação mais acessível, mas a habilidade de julgamento continua escassa. Para times que lidam com privacidade em produto — fintechs, healthtechs, plataformas de dados — essa escassez é crítica. Contratar pessoas que sabem ler código gerado com olhos de auditor é mais importante do que contratar pessoas que sabem escrever código rápido.
Riscos que vi na prática e como evitá-los
Um erro recorrente é tratar a IA como um par confiável. Em um projeto recente, o time inteiro passou a usar o mesmo assistente para gerar consultas SQL. O código funcionava, mas as consultas ignoravam índices existentes e geravam full scans em tabelas com milhões de registros. O impacto em performance só foi detectado em produção, três semanas depois. O Tech Lead, que aprovara os PRs sem verificar o plano de execução, admitiu que confiara que a IA geraria consultas otimizadas. A lição: a IA não otimiza para o seu banco de dados; ela gera código genérico que funciona, mas raramente é o melhor para o contexto.
Outro risco que subestimei no início foi a dívida técnica invisível. Código gerado por IA tende a ser mais verboso e a usar padrões que o time não conhece. Quando um desenvolvedor que não domina aquele padrão precisa manter o código, gasta o dobro do tempo. Em uma ocasião, uma classe inteira de 300 linhas foi gerada e ninguém se sentia dono dela — quando um bug surgiu, ninguém queria mexer, porque “não foi escrito por ninguém”. A solução foi forçar que cada trecho gerado fosse atribuído a um responsável pela manutenção, mesmo que o autor original fosse a IA. Isso criou um senso de ownership que reduziu o medo de refatorar.
O que fazer amanhã: um roteiro prático
Para quem está começando a lidar com esse cenário, sugiro três ações concretas. Primeiro, crie um glossário de confiança para seu time: mapeie quais partes do sistema podem ser geradas por IA sem supervisão (CRUDs padronizados, por exemplo) e quais exigem revisão presencial obrigatória (lógica de negócio complexa, manipulação de dados sensíveis). Segundo, estabeleça a regra do PR reverso: o revisor deve usar a mesma IA para pedir uma explicação do código antes de aprovar. Isso não é perder tempo, é criar uma trilha de auditoria. Terceiro, treine a equipe em pensamento crítico: promova sessões onde o time inteiro revisa um PR gerado por IA e debate os riscos escondidos. Os desenvolvedores que passam por esse treino ficam mais atentos e cometem menos erros de confiança excessiva.
A IA generativa não vai desaparecer, nem deveria. Ela libera energia mental para decisões de alto impacto — arquitetura, estratégia de produto, desenvolvimento de pessoas. Mas essa energia não é automaticamente benéfica. Se não houver um novo contrato de qualidade na revisão, se as métricas não forem atualizadas, se a privacidade não for tratada como requisito de design, o ganho de produtividade será rapidamente consumido pelo custo de correções e incidentes. O Tech Lead e o Tech Manager têm, hoje, a oportunidade de liderar essa transição com lucidez. O que não podem é fingir que nada mudou.