Substituir uma equipe por IA antes de entender o trabalho que ela realmente executa é uma decisão de arquitetura — e pode sair caro. Segundo o Sapo.pt, a Gartner prevê que cerca de 30% dos trabalhadores despedidos e substituídos por IA poderão ser recontratados até 2029, provavelmente por um custo maior. O problema não é automatizar; é confundir tarefas automatizáveis com funções inteiras.
Para quem desenvolve software, essa distinção é familiar. Automatizar uma etapa de um pipeline não significa que o pipeline inteiro esteja resolvido. Ainda há exceções, integrações, validação, segurança e manutenção. No trabalho das equipes, a lógica é parecida: um modelo pode escrever código, resumir tickets ou gerar testes, mas isso não elimina automaticamente a responsabilidade por decisões e resultados.
Por que empresas podem recontratar profissionais substituídos por IA
A previsão da Gartner, citada pelo Sapo.pt, aponta para uma falha de planejamento da força de trabalho. Algumas empresas estariam decidindo quantas pessoas dispensar antes de mapear o que precisa ser feito e como a IA altera essas atividades.
Essa ordem inverte o problema. Primeiro se corta o número de pessoas; depois se tenta encaixar o trabalho restante nas ferramentas disponíveis. Se a automação não cobrir exceções, conhecimento tácito ou tarefas de coordenação, alguém ainda precisa assumir essas responsabilidades. A empresa pode acabar recontratando — ou pagando consultorias e horas extras para recuperar capacidade que eliminou cedo demais.
O levantamento da Gartner mencionado na notícia foi realizado em julho de 2026 com 297 responsáveis de recursos humanos. Apenas 19% das empresas consultadas disseram ter práticas para ajudar líderes a entender como o trabalho está mudando, avaliar o impacto da IA e alinhar a estratégia de talentos aos objetivos do negócio.
Esse dado não prova que toda demissão motivada por IA será revertida. A estimativa de 30% é uma previsão, não um resultado observado. Ainda assim, ela chama atenção para um risco operacional: tomar decisões permanentes com base em expectativas de automação que talvez não se confirmem no ambiente real.
Automatizar tarefas não é o mesmo que automatizar cargos
Um cargo costuma ser um conjunto de atividades com níveis diferentes de previsibilidade, risco e necessidade de julgamento. Em desenvolvimento, por exemplo, uma pessoa pode escrever código repetitivo, investigar falhas intermitentes, negociar requisitos, revisar permissões e responder por uma implantação. Um assistente de IA pode ajudar em algumas dessas tarefas sem assumir o conjunto completo.
Eu analisaria cada atividade em vez de perguntar apenas “quantas pessoas a IA substitui?”. Para cada tarefa, vale observar frequência, tempo gasto, qualidade esperada, custo de erro, dados disponíveis e dependência de contexto. Uma tarefa repetitiva, com entrada padronizada e resultado verificável, tende a ser mais adequada à automação do que uma decisão ambígua com consequências difíceis de reverter.
Um exemplo no fluxo de desenvolvimento
Gerar um rascunho de teste unitário a partir de uma função pode ser uma boa aplicação de IA. O resultado é verificável: o teste compila, passa ou falha, e alguém pode revisar se cobre o comportamento esperado. Já decidir sozinho se uma mudança de autenticação está segura exige contexto sobre ameaças, arquitetura, política de acesso e impacto em produção.
Isso não significa que a segunda tarefa não possa receber apoio de IA. Significa que “apoio” e “substituição” são níveis diferentes de automação. Se a empresa ignora essa diferença, pode cortar a capacidade humana que ainda é necessária para verificar as saídas da própria ferramenta.
O custo real da IA inclui integração, revisão e falhas
Uma comparação honesta não coloca apenas salário de um lado e preço da ferramenta do outro. O custo total inclui licenças, integração, observabilidade, segurança, treinamento, revisão humana, retrabalho e tratamento de exceções. Em sistemas críticos, também inclui o custo potencial de uma resposta errada ou de uma mudança não autorizada.
Na prática, a IA pode reduzir o tempo de execução de uma tarefa e aumentar o tempo de verificação. Isso ainda pode ser vantajoso, mas só se a conta considerar o ciclo inteiro. Se um agente gera código em minutos e exige horas para descobrir dependências ocultas, a economia anunciada não corresponde à produtividade líquida.
Também é importante separar capacidade de produção de responsabilidade. Um modelo pode sugerir uma alteração em infraestrutura; alguém precisa definir quem aprova, quais testes são obrigatórios e como reverter a implantação. Sem esse desenho, a organização não automatizou o processo: apenas deslocou o risco para uma etapa menos visível.
Na Prática: avalie o trabalho antes de redesenhar a equipe
Eu começaria com um inventário pequeno, ligado a um processo real — por exemplo, triagem de bugs ou revisão de documentação. Não é necessário mapear cada minuto de todos os cargos para iniciar. É necessário entender o fluxo e medir o que muda quando a ferramenta entra.
- Descreva o resultado esperado. Em vez de “automatizar o suporte”, defina algo observável, como classificar tickets por categoria e encaminhar os casos simples.
- Divida o processo em tarefas. Registre entradas, saídas, exceções, sistemas envolvidos e quem responde por cada decisão.
- Escolha uma tarefa de baixo risco para o piloto. Prefira um fluxo reversível, com dados adequados e uma forma objetiva de conferir o resultado.
- Meça a linha de base. Compare tempo total, taxa de erro, retrabalho e volume de exceções antes e depois. Não use apenas o número de respostas geradas.
- Defina limites e revisão humana. Especifique quais ações a ferramenta pode executar, quais exigem aprovação e quando deve encaminhar o caso para uma pessoa.
- Reavalie o desenho do trabalho. Só depois de observar o piloto decida se tarefas, responsabilidades ou capacidade da equipe precisam mudar.
O pequeno exemplo abaixo calcula uma estimativa de economia líquida por tarefa. Ele considera custo de revisão e uma provisão simples para retrabalho. É um instrumento de triagem, não um modelo financeiro completo nem uma justificativa automática para reduzir pessoal.
from dataclasses import dataclass
@dataclass
class Task:
name: str
runs_per_month: int
manual_minutes: float
ai_minutes: float
review_minutes: float
error_rate: float
rework_minutes_per_error: float
def estimate_monthly_hours(task: Task) -> dict:
if task.runs_per_month < 0:
raise ValueError("runs_per_month não pode ser negativo")
if not 0 <= task.error_rate <= 1:
raise ValueError("error_rate deve estar entre 0 e 1")
manual = task.runs_per_month * task.manual_minutes
ai_and_review = task.runs_per_month * (
task.ai_minutes
+ task.review_minutes
+ task.error_rate * task.rework_minutes_per_error
)
return {
"tarefa": task.name,
"horas_manuais": round(manual / 60, 2),
"horas_com_ia": round(ai_and_review / 60, 2),
"horas_liquidas_economizadas": round((manual - ai_and_review) / 60, 2),
}
task = Task(
name="Rascunho de testes unitários",
runs_per_month=120,
manual_minutes=25,
ai_minutes=6,
review_minutes=8,
error_rate=0.10,
rework_minutes_per_error=20,
)
print(estimate_monthly_hours(task))Os números do exemplo são hipotéticos. O ponto importante é incluir revisão e falhas no cálculo, em vez de comparar apenas o tempo manual com o tempo que a IA leva para produzir uma primeira resposta. Para uma avaliação séria, eu também acompanharia qualidade, severidade dos erros, custo da ferramenta e variação entre tipos de tarefa.
Erros comuns ao adotar IA e reorganizar equipes
- Começar pela meta de redução de pessoal. Isso transforma a tecnologia em justificativa para um número definido previamente, em vez de uma ferramenta para melhorar o trabalho.
- Medir atividade em vez de resultado. Contar prompts, linhas de código ou tickets respondidos não mostra se o sistema resolveu o problema com qualidade.
- Ignorar exceções. Os casos comuns podem parecer fáceis de automatizar, enquanto os casos raros concentram riscos, retrabalho e conhecimento especializado.
- Confundir demonstração com operação. Um protótipo que funciona com dados limpos não comprova que a solução é confiável com permissões reais, integrações e entradas incompletas.
- Retirar a revisão antes de medir a qualidade. Sem avaliação, a equipe perde a capacidade de detectar erros e de saber se a automação está melhorando.
- Eliminar o conhecimento necessário para manter o sistema. Se as pessoas que entendem o processo saem antes de documentar exceções e regras, a empresa pode ficar dependente de uma ferramenta que não sabe corrigir.
O que essa previsão significa para quem programa
Para desenvolvedores, o impacto mais imediato não é simplesmente “a IA vai substituir programadores”. É a mudança na composição do trabalho. Pode haver menos tempo gasto em tarefas repetitivas e mais demanda por revisão, desenho de sistemas, integração, segurança, testes e entendimento de domínio.
Isso também muda o que considero uma boa automação. Um fluxo útil precisa deixar claro de onde vieram os dados, quais ferramentas o modelo pode acionar, como validar a saída e como interromper ou reverter uma ação. Em código, isso pode significar testes automatizados, permissões mínimas, logs e aprovação humana em operações de risco. Não são detalhes burocráticos: são parte do produto.
A orientação atribuída à Gartner é começar pela estratégia do negócio e depois decidir qual combinação de pessoas e tecnologia atende ao trabalho necessário. Para equipes de software, eu traduziria isso em uma pergunta concreta: qual resultado queremos melhorar e quais partes do processo podem ser automatizadas sem perder controle, qualidade ou capacidade de resposta?
Essa abordagem não impede mudanças de equipe. Ela torna as decisões mais informadas. Se a automação realmente reduzir demanda por certas atividades, a empresa terá evidência para redesenhar funções. Se não reduzir, terá evitado tratar uma hipótese como uma economia garantida.
Perguntas frequentes sobre demissões por IA e recontratação
A Gartner afirma que 30% de todos os trabalhadores serão recontratados?
Não. A previsão citada pelo Sapo.pt refere-se a cerca de 30% dos trabalhadores despedidos e substituídos por IA que poderão ser recontratados até 2029. É uma estimativa, não um dado de recontratações já ocorridas.
Por que uma empresa recontrataria alguém depois de automatizar uma função?
Porque a automação pode cobrir apenas parte do trabalho. Exceções, revisão, integração com outros processos e decisões que exigem contexto podem continuar sem cobertura adequada. Se a empresa eliminar essa capacidade antes de avaliar o fluxo, pode precisar recuperá-la depois.
Como medir se uma ferramenta de IA realmente economiza tempo?
Compare o processo completo antes e depois, incluindo execução, revisão, retrabalho, erros e tratamento de exceções. Uma resposta gerada rapidamente não representa economia líquida se a validação e a correção consumirem mais tempo.
É seguro usar IA para automatizar tarefas de programação?
Depende da tarefa, dos dados e das permissões. Comece por atividades verificáveis e de baixo risco, mantenha testes e revisão compatíveis com o impacto da mudança e evite conceder acesso amplo a sistemas sem controles e possibilidade de reversão.
O que um desenvolvedor pode fazer para se adaptar?
Aprenda a avaliar saídas de IA, integrar ferramentas com segurança e medir qualidade do fluxo. Fortaleça também fundamentos que continuam importantes: arquitetura, testes, depuração, segurança e entendimento do domínio. O valor está em entregar resultados confiáveis, não apenas em produzir código mais depressa.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.