A Armadilha do Planalto

Eu recentemente escreveu sobre a fadiga da IAArgumentando que o que os engenheiros estão sentindo não é uma condição crônica, mas sim dores musculares decorrentes do treinamento. Supere isso, adapte-se e saia mais forte.

Tudo isso é muito bom e lógico, mas há mais nessa história, e está ficando cada vez mais evidente. O verdadeiro risco que as equipes de engenharia enfrentam agora não é o esgotamento profissional, mas sim a estagnação.

A Nova Divisão

Quase todos os engenheiros seniores usam IA hoje em dia. Copilot, Claude, Cursor, Codex, entre outras. Essa parte já está consolidada. Se você lidera uma equipe de engenharia, provavelmente já viu altos índices de adoção e se sente bem com isso.

Você não deveria.

O número de adoções não significa nada. O que importa é a divisão que acontece por trás dele. Sua equipe está silenciosamente se dividindo em dois grupos. Há os engenheiros que tiveram um aumento de produtividade e se adaptaram, e os engenheiros que continuam se esforçando a cada semana. Novos fluxos de trabalho, novas configurações de agentes, novas maneiras de decompor problemas para a IA resolver.

Ambos os grupos aparecem nos seus painéis como "adotantes de IA". Mas um está em um programa de treinamento progressivo. O outro parou no primeiro peso que pareceu confortável.

Há seis meses, a diferença entre esses dois grupos era quase imperceptível. Agora, é óbvia para qualquer pessoa atenta. Em mais seis meses, será estrutural.

Como é, na realidade, o Planalto

O engenheiro que atingiu um platô não está fazendo nada de errado no sentido tradicional. Ele é competente. Ele entrega os projetos. Ele usa seu agente para tarefas simples e resolve tudo depois. Ele conseguiu um aumento de produtividade de talvez 20 a 30% e considerou o trabalho concluído.

O problema é que o engenheiro ao lado não parou por aí. Esse engenheiro agora está executando fluxos de trabalho multiagentes, aprimorando loops de verificação, decompondo funcionalidades inteiras em partes executáveis ​​por IA, revisando em nível arquitetural em vez de linha por linha e entregando em um ritmo 2 a 3 vezes maior do que antes. Não porque ele seja mais talentoso. Mas sim porque ele continuou se capacitando enquanto todos os outros tiravam um dia de folga que se transformou em um trimestre inteiro de descanso.

Não se trata de entusiasmo pela IA ou de ser um dos primeiros a adotá-la. A fase inicial de adoção já passou. Trata-se de adaptação contínua versus ajustes pontuais. E a diferença cumulativa entre essas duas abordagens está se tornando impossível de ignorar.

A pressão competitiva é real e está se intensificando.

Se suas equipes tivessem a possibilidade de se adaptar no seu próprio ritmo, o problema da estagnação seria apenas uma questão de gestão de desempenho. Incômodo, mas administrável.

Mas, se você observar o panorama geral da indústria de software, é provável que não tenha esse luxo.

Em geral, a indústria de software foi criada para auxiliar humanos em tarefas digitais: ajudando agentes de suporte a visualizar chamados recebidos, rastrear respostas a clientes e gerenciar fluxos de trabalho. Agora, agentes de IA estão substituindo todo o fluxo de trabalho e, com isso, impactando as plataformas SaaS subjacentes. Além disso, com a IA se tornando cada vez mais capaz, seus clientes começam a se perguntar: "Ainda precisamos comprar isso ou podemos desenvolver a solução internamente?". A IA começou a reduzir a barreira entre "comprar" e "desenvolver" para um conjunto crescente de casos de uso. A fidelização que antes protegia sua receita está diminuindo a cada trimestre.

Seus engenheiros, que atingiram um patamar de estagnação, estão operando em um ritmo calibrado para um ambiente competitivo que não existe mais.

A citação que mudou tudo para mim

Já ouvi isso mais de uma vez, de gerentes de produto que arregaçaram as mangas e desenvolveram funcionalidades intuitivamente, de líderes de engenharia que redesenharam arquiteturas problemáticas, em diferentes empresas e contextos:

“Para mim, foi mais fácil trabalhar nisso com meus agentes do que com aquele engenheiro.”

Na primeira vez que ouvi isso, pensei que fosse um exagero. Na terceira vez, percebi que era um indicador antecipado.

Na minha opinião, existem engenheiros que prosperarão neste novo mundo e serão "multiplicadores" das capacidades da IA. Para isso, eles precisam ser fortes em duas áreas, ambas passíveis de desenvolvimento próprio com motivação intrínseca e curiosidade intelectual suficientes:

• Eles operam "na mesma sintonia" que seus stakeholders (gerentes de projeto, gerentes de engenharia, etc.). Eles entendem o que é um bom trabalho, então você não precisa explicar as coisas em excesso para eles. Porque se eles gerarem o mesmo número de mal-entendidos que seu agente de codificação, o agente sempre sairá vitorioso. Está disponível instantaneamente, 24 horas por dia, 7 dias por semana, e é incansável.
• Eles aprimoram constantemente suas configurações de IA, então, quando você lhes confia uma tarefa, sabe que ela será feita não apenas bem (veja o ponto acima), mas também com rapidez suficiente para acompanhar o novo ritmo do mercado.

Por que isso é um problema de liderança, e não um problema individual?

É tentador enquadrar isso como responsabilidade individual de cada engenheiro. "Acompanhe o ritmo ou ficará para trás." Mas se você lidera uma organização de engenharia, essa perspectiva te exime da responsabilidade.

Seus engenheiros que atingiram um platô não chegaram a esse ponto isoladamente. Eles estagnaram porque nada em seu ambiente os impulsionou além do ajuste inicial. Eles alcançaram um ganho de produtividade aparentemente razoável, ninguém os desafiou a ir além, e a inércia fez o resto.

Os engenheiros que persistiram? A maioria deles é automotivada. Eles persistiriam independentemente das circunstâncias. Mas não é possível preencher uma equipe de engenharia inteiramente com pessoas automotivadas e ambiciosas. A questão para os líderes é: como mobilizar a classe média?

Este é um problema de gestão de mudanças, e uma das minhas estruturas favoritas para resolvê-lo vem do livro dos irmãos Heath. InterruptorResumindo: você precisa dar às pessoas uma direção clara, fazê-las sentir por que isso é importante e remodelar o ambiente para que o novo comportamento seja o caminho de menor resistência. Aplicado a equipes de engenharia, isso se parece com:

Identifique seus pontos fortes e torne-os visíveis. Identifique os engenheiros que mais se destacaram em seus fluxos de trabalho de IA e peça que façam demonstrações regulares para a equipe. Não sessões de treinamento. Demonstrações ao vivo de trabalhos reais. Quando os membros da equipe percebem a diferença entre seu fluxo de trabalho e o dos profissionais que mais utilizam IA, isso gera um desconforto produtivo que nenhuma imposição consegue igualar.

• Reduza a mudança. "Adotar IA" é um conceito abstrato demais para ser colocado em prática. Nesta sprint, conclua os testes de ponta a ponta com agentes; na próxima, implemente em toda a organização, e assim por diante. Etapas específicas e gerenciáveis ​​sempre superam programas de transformação ambiciosos, e pequenas vitórias fazem a diferença.
• Remodelar as configurações padrão. Codifique o processo de verificação em habilidades de IA e assegure-se de que elas sejam implementadas em toda a sua equipe e em todos os seus agentes. Defina seus fluxos de trabalho e utilize as ferramentas que os suportam. Faça com que a nova forma de trabalho seja o caminho de menor resistência, para que as pessoas a adotem naturalmente, em vez de terem que lutar para chegar lá.

A janela está se fechando

Eis o que torna isso urgente, e não apenas importante.

No momento, a diferença de adaptação se reflete em um diferencial de desempenho. Seus engenheiros que atingiram um platô são mais lentos do que os que se adaptaram, mas ainda são produtivos. Eles ainda contribuem. Você pode contar com eles.

Essa janela está se fechando. À medida que as capacidades da IA ​​se aceleram e a pressão competitiva aumenta, o ritmo mínimo viável do trabalho de engenharia está se elevando. O engenheiro "bom o suficiente" de hoje não tem garantia de ser bom o suficiente no próximo trimestre. Não porque tenha piorado, mas porque o nível mínimo exigido aumentou.

As organizações que descobrirem como fazer com que todas as suas equipes avancem na curva de adaptação, e não apenas os primeiros a adotá-la, terão uma vantagem estrutural cumulativa. Aquelas que não o fizerem se verão com equipes preparadas para um ritmo de competição que já não existe.

Todos os líderes de engenharia com quem converso entendem isso intelectualmente. Pouquíssimos mudaram a forma como gerenciam suas equipes em resposta a essa situação. A lacuna entre o entendimento e a ação é um obstáculo intransponível.

Não existe um ritmo confortável.

No artigo sobre fadiga induzida por IA, argumentei que a dor muscular é a prova de que o treinamento está funcionando. Isso ainda é verdade. Mas a verdade seguinte é mais difícil de alcançar: o peso continua aumentando.

Numa academia normal, você pode escolher um peso confortável e mantê-lo para sempre. Ninguém adiciona anilhas à sua barra sem pedir. No cenário atual de software, a cada novo lançamento de modelo, a cada nova funcionalidade de agente, a cada novo fluxo de trabalho que alguém descobre e compartilha, a barra se move. Fique parado e o peso eventualmente o prenderá.

Atualmente, não existe um espaço confortável na indústria de software. Nem para os engenheiros individualmente, nem para as equipes em que trabalham, nem para as empresas que essas equipes constroem. A única posição segura é o movimento constante. E a única pergunta que importa para os líderes de engenharia é se toda a equipe está se movimentando, ou apenas aqueles que já se movimentariam de qualquer forma.