Tem time produzindo mais código com IA e, ao mesmo tempo, terminando o dia mais cansado. Parece contradição, mas não é.
O ganho veio na largada: ficou mais fácil abrir tarefa, gerar rascunho, subir PR, testar ideia e tocar várias frentes ao mesmo tempo. O problema é que a parte mais cara do trabalho não sumiu. Ela só mudou de lugar. Agora pesa mais em revisão, contexto, priorização e julgamento.
Essa leitura apareceu com força num texto recente do Stack Overflow Blog sobre decision fatigue em times de engenharia e bate com dois sinais que valem atenção. A Smartsheet diz que a intensidade de automação em contas enterprise subiu 55% em um ano, com atividade total 46% maior. Já pesquisadores da UC Berkeley Haas observaram, em oito meses de etnografia numa empresa de tecnologia, que a IA não encurtou o trabalho: ela adensou o dia.
o ganho veio na entrada, não na saída
Quando um agente ou copiloto acelera a primeira metade do fluxo, tudo parece melhor muito rápido. Ideias viram ticket. Ticket vira rascunho. Rascunho vira código. Código vira PR.
Só que isso não significa que a entrega ficou mais simples. Significa que mais coisa chega mais cedo na esteira. E alguém ainda precisa decidir se aquilo faz sentido para aquele sistema, para aquele padrão de arquitetura, para aquele prazo e para aquele nível de risco.
É por isso que a sensação de produtividade subiu junto com a fadiga. Você não está necessariamente trabalhando mais horas. Está tomando mais microdecisões por hora.
o novo gargalo não é escrever código
No texto do Stack Overflow, a executiva Pratima Arora resume bem a mudança: o problema deixou de ser produção pura e passou a ser julgamento. A IA ajuda a despejar volume. O que ela não resolve sozinha é a capacidade humana de revisar, aprovar, cortar excesso e segurar coerência entre peças do sistema.
A Smartsheet colocou isso em números. Segundo o relatório, 80% do conteúdo gerado por IA ainda é editado antes de virar versão final. Em outras palavras: o rascunho escala primeiro; o critério ainda não.
Em engenharia isso pesa mais, porque revisão ruim cobra juros depois. Um PR pode até parecer bom em isolamento, mas quebrar padrão interno, aumentar complexidade ou empurrar dívida para outra squad. Quando o time começa a gerar muito mais coisa do que consegue revisar com calma, o ganho inicial vira fila.
isso bate direto em quem segura o contexto
Tem um detalhe importante aqui: esse tipo de pressão não cai igual para todo mundo.
Quem mais sente costuma ser justamente o sênior, o staff, o tech lead, ou qualquer pessoa que já carrega contexto de produto, arquitetura e operação. É essa galera que precisa olhar além do diff bonito e perguntar o que aquela mudança puxa no resto do sistema.
A Berkeley descreve um padrão bem familiar: com IA rodando em paralelo, muita gente passou a manter várias trilhas vivas ao mesmo tempo, enquanto revisa código, entra em reunião, ajusta documento e responde nova saída da ferramenta. O dia não fica necessariamente maior. Fica mais espremido.
E dia espremido costuma cobrar de um jeito chato: menos pausa, mais troca de contexto e mais chance de aceitar coisa meia-boca porque o cérebro já quer andar logo.
o risco não é a IA escrever errado. é o time desaprender a frear
Boa parte da discussão pública ainda gira em torno de uma pergunta antiga: “a IA escreve bem ou mal?”. Isso importa, claro. Mas o risco prático para o time pode ser outro.
O risco é normalizar um ritmo em que tudo chega pronto demais para ser questionado e rápido demais para ser digerido. Nessa fase, a empresa começa a confundir vazão com maturidade. Vê mais PR, mais tarefa andando, mais volume saindo do teclado e conclui que o processo melhorou. Nem sempre melhorou.
Às vezes só ficou mais fácil empilhar trabalho em cima da mesma camada humana de validação.
É aí que nascem dois problemas de uma vez:
- o time júnior aprende menos do que parece, porque mexe mais na superfície do que no entendimento;
- o time sênior vira gargalo silencioso, porque passa a viver em revisão, correção de rumo e contenção de dano.
Não é um colapso inevitável. Mas é um tipo bem novo de desgaste para engenharia.
o que vale observar no time agora
Se você trabalha com dev, liderança técnica ou plataforma interna, talvez a pergunta mais útil não seja “quanto código a IA gerou?”. Talvez seja esta:
o nosso fluxo ficou realmente melhor ou só ficou mais barulhento?
Alguns sinais ajudam a separar uma coisa da outra:
- PRs maiores ou mais frequentes estão demorando mais para serem entendidos do que para serem escritos;
- review virou gargalo constante nas mesmas pessoas;
- o time sente que está produzindo muito, mas com mais retrabalho e menos clareza;
- cresceu a quantidade de código “aceitável no diff, ruim no sistema”.
Quando esses sintomas aparecem juntos, o problema não é simplesmente adoção de IA. É descompasso entre velocidade de geração e capacidade de julgamento.
Talvez a resposta não seja usar menos ferramenta. Talvez seja redesenhar melhor o fluxo: PR menor, contexto melhor, guardrail claro, revisão mais bem distribuída e expectativa mais honesta sobre o que é produtividade de verdade.
Porque código barato não torna decisão barata. E, pelo jeito, é exatamente aí que muita equipe está começando a sentir o peso.
