Quando alguém do seu time diz: “Eu não quero mais usar IA”

Assisti recentemente ao relato de Brett Codes no vídeo Why I don’t use AI for just the easy things, um desenvolvedor com mais de vinte anos de carreira que decidiu parar de usar IA para programar.

Não porque não conseguiu aprender as ferramentas. Pelo contrário.

Depois de mais de um ano usando coding agents e experimentando diferentes formas de trabalhar, ele reconhece que conseguia produzir mais. Mesmo assim, decidiu parar.

No relato, aparecem palavras fortes: apatia, perda de propósito, distanciamento do código, sensação de estar desaprendendo, piora na qualidade do trabalho e até a disposição de perder o emprego caso o uso de IA continue sendo uma exigência.

É um relato individual, não uma medida do que acontece com todas as equipes. Ainda assim, coloca uma pergunta relevante para quem lidera.

Eu penso diferente dele em vários pontos.

Uso IA diariamente e acredito que coding agents podem melhorar bastante o desenvolvimento de software. Tenho experimentado agentes, modelos, automações e diferentes formas de incorporar IA ao trabalho de engenharia.

Também não acho que usar IA necessariamente afaste o engenheiro do código, reduza sua capacidade técnica ou produza software pior.

Mas, se alguém do meu time chegasse para mim com esse relato, a pior coisa que eu poderia fazer como CTO seria começar tentando provar que ele está errado.

Porque há duas discussões diferentes ali.

Uma é sobre IA.

A outra é sobre uma pessoa.

Naquele momento, a segunda é mais importante.

Discordar da conclusão não invalida a experiência

Como gestores técnicos, temos uma tendência perigosa: quando alguém apresenta uma conclusão com a qual discordamos, imediatamente começamos a procurar os erros no argumento.

“Talvez ele esteja usando a ferramenta errado.”

“Os modelos melhoraram muito.”

“Com testes adequados isso não acontece.”

“Você não deveria deixar o agente escrever tanto código.”

“IA é apenas mais uma ferramenta.”

Talvez tudo isso seja verdade. E talvez nada disso seja relevante nos primeiros minutos daquela conversa.

Se alguém me diz:

“Estou ficando apático em relação ao meu trabalho.”

Minha primeira pergunta não deveria ser:

“Qual modelo você está usando?”

Deveria ser algo mais próximo de:

“O que mudou no seu trabalho para você começar a se sentir assim?”

Reconhecer a experiência de alguém não significa concordar com todas as conclusões que essa pessoa tirou dela.

Posso acreditar profundamente no potencial da IA e, ao mesmo tempo, reconhecer que a forma como estamos introduzindo essas ferramentas pode estar fazendo mal a alguém.

Essa distinção faz parte do trabalho de liderança.

Às vezes, o problema está em como a organização introduziu a IA

Uma das partes do relato que mais me chamou a atenção não foi técnica. Foi gerencial.

Em determinado momento, a mensagem recebida pelo desenvolvedor foi basicamente:

use IA ou você ficará obsoleto.

Esse tipo de discurso aparece bastante:

“Quem não usar IA será substituído.”

“Você precisa produzir três vezes mais.”

“Todo desenvolvedor precisa trabalhar com agentes.”

“Temos que aumentar a adoção.”

“Precisamos consumir mais tokens.”

Podemos até aumentar o uso das ferramentas dessa maneira. Isso não significa que estamos construindo uma organização melhor.

Quando transformamos uma tecnologia em obrigação identitária — use isso ou você não pertence mais ao futuro da profissão — deixamos de discutir apenas engenharia. Entram na conversa segurança psicológica, identidade profissional e medo.

Para alguém que passou vinte anos construindo software, programar talvez não seja simplesmente uma atividade que produz tickets concluídos.

Existe domínio, prazer, identidade e aprendizado. Existe a satisfação bastante particular de passar algumas horas entendendo um problema difícil e finalmente encontrar uma solução.

Se a nova organização do trabalho transforma essa pessoa de construtora em alguém que passa o dia aprovando diffs produzidos por máquinas, talvez tenhamos aumentado o throughput e destruído justamente aquilo que fazia aquele profissional excelente.

Isso merece atenção.

A ferramenta não pode virar a métrica

Também existe uma discussão técnica importante escondida nesse desconforto.

Se começarmos a avaliar a adoção de IA por quantidade de prompts, tokens consumidos, tarefas concluídas, linhas de código geradas ou percentual de desenvolvedores usando determinada ferramenta, podemos criar incentivos ruins.

Eu não quero que alguém do meu time use IA.

Quero que meu time produza software melhor.

Se uma pessoa resolve um problema complexo em duas horas usando um agente, ótimo.

Se outra resolve o mesmo problema em três horas pensando, programando e testando manualmente, talvez também esteja ótimo.

O que importa é o resultado: se está correto e seguro, se é sustentável, se o time entende o que foi construído, se conseguiremos manter aquilo daqui a dois anos, se estamos aprendendo e se houve algum ganho para o cliente e para a empresa.

A ferramenta é um meio. Não deveria virar o objetivo.

Existe um risco real de afastamento do trabalho

Há outro ponto do relato que considero especialmente interessante: a sensação de distância.

Antes ele escrevia o código.

Depois começou a pedir código.

Depois começou a revisar código.

Em determinado momento, sentiu que já não conhecia tão bem aquilo que estava sendo construído.

Isso não prova que coding agents sejam ruins. Mas revela um risco de design do trabalho que considero real.

Podemos automatizar tanto uma atividade que removemos justamente os ciclos responsáveis pela formação da experiência:

errar, investigar, ler documentação, construir uma hipótese, descobrir que estava errado, depurar, entender o motivo, refatorar.

Esses momentos parecem improdutivos quando medidos apenas por velocidade. Mas são parte importante da formação de um engenheiro.

Por isso, não acredito em uma engenharia de software na qual humanos simplesmente especificam tarefas e revisam milhares de linhas produzidas por agentes.

Quero agentes fazendo trabalho.

Mas quero engenheiros entendendo sistemas.

As duas coisas precisam coexistir.

Como eu conduziria essa conversa

Se alguém do meu time chegasse dizendo que não quer mais usar IA, eu não começaria discutindo política de adoção.

Primeiro, tentaria entender o que mudou para aquela pessoa.

O trabalho deixou de ser prazeroso? Ela sente que perdeu autonomia? Está difícil acompanhar o código produzido? Está aprendendo menos? A quantidade de mudanças aumentou sua carga cognitiva? Existe pressão para demonstrar produtividade? Existe medo relacionado ao emprego?

Depois, tentaria identificar qual parte do sistema de trabalho está provocando isso.

O problema pode estar no agente, mas também no volume de tarefas, na expectativa de velocidade, na forma de revisão, na ausência de limites, na pressão gerencial ou simplesmente na maneira como aquela pessoa trabalha melhor.

Só então procuraria alternativas concretas.

Talvez ela queira escrever determinadas partes manualmente. Talvez prefira usar IA apenas para pesquisa. Talvez queira agentes para testes, documentação ou tarefas mecânicas, mas não para implementação. Talvez precise passar algumas semanas novamente próxima do código.

Ou talvez a conversa revele algo maior: a equipe inteira está produzindo diffs grandes demais para uma revisão responsável.

Tudo isso é informação útil sobre o nosso sistema de engenharia.

Um bom time não precisa usar a ferramenta da mesma maneira

Existe uma tentação nas empresas de padronizar comportamento quando, em muitos casos, deveríamos padronizar resultados e limites.

Eu provavelmente quero regras comuns para segurança, dados que podem ser enviados aos modelos, revisão de código, testes, arquitetura, rastreabilidade, modelos aprovados e ações que exigem supervisão humana.

Mas não necessariamente preciso determinar quantos prompts um desenvolvedor deve fazer durante o dia.

Um engenheiro pode usar agentes intensamente. Outro pode utilizá-los como pair programmer. Outro pode preferir IA apenas para investigação e documentação. Outro talvez quase não a utilize em determinadas atividades.

Se todos entregam dentro dos padrões técnicos e operacionais esperados, essa diversidade pode ser saudável.

Pode, inclusive, ser uma proteção contra pensamento de grupo.

Precisamos permitir que alguém diga: “Isso não está funcionando para mim”

Esse talvez seja o ponto mais importante.

Se queremos aprender a incorporar IA nas organizações, precisamos conseguir receber feedback negativo sobre IA.

Inclusive feedback emocional.

Inclusive feedback com o qual discordamos.

Inclusive de alguém que conclua:

“Para mim, trabalhar assim está pior.”

Se a única resposta aceitável dentro da empresa for entusiasmo, não temos uma estratégia de IA. Temos uma religião corporativa.

Organizações não aprendem quando as pessoas têm medo de dizer que uma iniciativa importante está produzindo efeitos indesejados.

Um CTO deveria querer ouvir essas histórias cedo.

Porque, atrás de uma pessoa dizendo “não quero usar IA”, pode existir um problema maior: revisões impossíveis, código que ninguém entende, perda de ownership, pressão excessiva, métricas ruins, desenvolvedores deixando de aprender ou uma transformação do trabalho que fizemos rápido demais sem perceber as consequências.

Liderar também é observar o que a tecnologia faz com o trabalho

Continuo bastante otimista sobre IA aplicada à engenharia de software.

Acho que estamos apenas começando a descobrir novas formas de desenvolver produtos. Coding agents vão melhorar. Nossos processos também.

Justamente por acreditar nisso, não acho que todo desconforto deva ser tratado como resistência à mudança.

Algumas das pessoas mais experientes de um time carregam vinte ou trinta anos de prática. Quando uma delas diz:

“Alguma coisa importante está se perdendo aqui.”

Vale a pena ouvir.

Talvez ela esteja errada sobre a causa. Talvez esteja certa. Talvez a conversa revele uma terceira explicação.

Essa discussão vem depois.

Primeiro vem a pessoa.

Ser CTO não é apenas decidir quais tecnologias entram na organização. É também observar o que essas tecnologias fazem com o trabalho, com a cultura e com as pessoas que precisam atravessar essa mudança.

Às vezes, a resposta mais útil para alguém que pensa diferente de nós não é tentar convencê-lo. É dizer:

“Eu vejo esse assunto de outra maneira. Mas quero entender o que você está vivendo, porque, se a forma como estamos trabalhando está fazendo você perder o prazer, a autonomia ou a conexão com aquilo que faz bem, isso também é um problema meu como gestor.”

Essa conversa provavelmente ensina mais sobre adoção responsável de IA do que um dashboard mostrando quantos tokens o time consumiu naquele mês.