# O que a liderança aprende quando alguém do time não quer mais usar IA

Published: 2026-08-14
Author: Gilmar Pupo
Editorial: tecnologia
Content type: article
Canonical: https://www.gpupo.com/posts/quando-alguem-do-seu-time-diz-eu-nao-quero-mais-usar-ia/
Tags: Liderança, Cultura, Inteligência Artificial, Engenharia de Software, Trabalho

---

Assisti recentemente ao [relato de Brett Codes no vídeo *Why I don't use AI
for just the easy things*](https://youtu.be/P6FZKrE-Hfo), 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.