Quando eu leio “demissões na era da IA”, eu não vejo só uma manchete — eu vejo um padrão técnico e organizacional que já esbarrou em times de produto e engenharia por todo o ecossistema. Segundo o OlharDigital.com.br, funcionários do Google entregaram uma petição cobrando proteção contra demissões, argumentando que a IA pode virar justificativa para cortes. Na minha experiência, o risco real não é a IA “substituir pessoas” de forma mágica; é a empresa usar a narrativa de eficiência para recalibrar orçamento e headcount sem transparência — e isso pode acontecer inclusive com ganhos legítimos de produtividade.
O que está acontecendo no Google (e por que devs precisam ligar)
Segundo o OlharDigital.com.br, funcionários do Google (via o Alphabet Workers Union) entregaram uma petição à direção exigindo medidas de proteção. A pauta inclui indenizações garantidas, opção de desligamento voluntário antes de cortes obrigatórios e mudanças no sistema de avaliação interna. Eles também afirmam que não é uma questão de dificuldade financeira, mas de uma decisão administrativa: priorizar lucro sobre pessoas.
Do ponto de vista de engenharia, há um detalhe importante: “IA” vira um argumento conveniente porque é difícil mensurar internamente o quanto cada melhoria foi atribuível. Muita coisa pode ser reclassificada como “transformação” quando, na prática, significa redução de custo ou reforma de estrutura. E, quando a avaliação interna é opaca, a decisão pode parecer “técnica”, mas ser essencialmente “financeira”.
IA e reestruturação: o mecanismo que costuma dar errado
Eu já vi reestruturação usando IA como acelerador retórico em três fases. Não é sempre igual, mas o modelo mental se repete:
- Fase 1 — Congelar contratações: “Estamos otimizando, então vamos contratar menos”.
- Fase 2 — Reclassificar times: funções são redesenhadas e parte do trabalho migra para “produtos com IA”, frequentemente sem manter a mesma proporção de pessoas.
- Fase 3 — Avaliar por impacto narrativo: métricas são substituídas por indicadores de “alinhamento com IA”, que são mais fáceis de demonstrar do que de auditar.
O que os trabalhadores estão pedindo na petição — inclusive mudanças na avaliação e regras de desligamento — é, na prática, uma tentativa de reduzir o “gap” entre o que é medido e o que é decidido.
Por que o sistema de avaliação interna vira ponto crítico
Em engenharia, avaliação geralmente deveria ser baseada em entrega: qualidade, estabilidade, desempenho, impacto no usuário, custo/benefício de longo prazo. Só que “IA” costuma introduzir métricas que parecem objetivas, mas são instáveis:
- “Uso de modelos” como proxy de valor (nem sempre corresponde a resultado real).
- “Inovação” sem auditoria de impacto (vira placar político).
- Atividades de suporte (incidentes, observabilidade, custo de infra) que ficam invisíveis.
Quando a avaliação passa a privilegiar sinais fáceis de reportar, a organização pode acabar premiando quem “narra bem” e penalizando quem “entrega bem”, mesmo que o usuário ganhe pouco.
O lado técnico: IA pode reduzir esforço, mas não elimina custos
Vamos ser honestos: IA pode melhorar produtividade. Eu uso isso o tempo todo para acelerar rascunhos, testes, revisão de código, documentação e até geração de boilerplate. O problema é que produtividade não é sinônimo de redução imediata de headcount. O custo migra.
Na prática, quando você “coloca IA no meio”, você cria novas categorias de trabalho:
- Governança (políticas de uso, auditoria, compliance)
- Observabilidade (logs de prompts, rastreio de falhas, métricas de qualidade)
- Segurança (prompt injection, dados sensíveis, riscos de exfiltração)
- Custos variáveis (tokens, latência, throughput)
Então a pergunta que devs deveriam fazer internamente é: “A IA está diminuindo o custo total do produto, ou apenas redistribuindo o trabalho e permitindo cortes em áreas que não são visíveis no slide?”
Comparando: como isso costuma ser tratado em outras empresas (e por que muda pouco)
Você encontra padrões parecidos em vários lugares do mercado:
- Big Tech: redesenho de times e programas com “IA-first”, seguido de consolidação de funções.
- Startups: layoffs por “runway”, com IA sendo usada para prometer eficiência sem orçamento para implementar observabilidade e qualidade.
- Empresas de enterprise: migração para “copilots” com mudanças mínimas em governança, e depois cortes em áreas de suporte e integração.
O ponto é: a ferramenta é menos relevante do que o processo. Se o processo de avaliação e decisão for frágil, IA vira justificativa. Se o processo for sólido e auditável, IA vira melhoria real sem virar desculpa.
Na Prática: como você mede “impacto IA” sem cair em armadilha
Se você trabalha em produto ou engenharia, dá para colocar um guard-rail técnico e evitar que “IA” vire só narrativa. Eu faço isso com um pacote simples: métricas de custo, métricas de qualidade e métricas de usuário, amarradas por experimento.
Passo a passo (checklist para evitar cortes injustos baseados em narrativa)
- Defina o objetivo (ex.: reduzir tempo de resolução, melhorar taxa de acerto, diminuir custo por tarefa).
- Separe métricas em 3 camadas: qualidade (ex.: precisão), eficiência (ex.: latência/custo), e impacto (ex.: satisfação/retention).
- Meça antes e depois com baseline. Sem baseline, vira “achismo”.
- Faça alocação de custo (tokens, retries, tempo de GPU/CPU, custo de observabilidade). Sem custo, a IA parece “barata”.
- Inclua custo operacional: incidentes, regressões e suporte pós-lançamento.
- Documente critérios de sucesso e mantenha auditoria dos logs relevantes (com privacidade).
Exemplo funcional: calcular custo estimado por 1.000 requisições
Em projetos com LLM, uma das métricas mais “auditáveis” é custo por volume. Aqui vai um exemplo de script que eu uso como base para estimar custo com tokens e taxa de retriable errors.
from dataclasses import dataclass
@dataclass
class ModelCost:
input_cost_per_1k: float # R$ por 1.000 tokens de entrada
output_cost_per_1k: float # R$ por 1.000 tokens de saída
def estimate_cost_per_1000(
cost: ModelCost,
avg_input_tokens: int,
avg_output_tokens: int,
retry_rate: float = 0.0
) -> float:
"""
retry_rate: fração adicional de requisições que serão reexecutadas (0.02 = 2%).
"""
total_input = avg_input_tokens * (1.0 + retry_rate)
total_output = avg_output_tokens * (1.0 + retry_rate)
input_cost = (total_input / 1000.0) * cost.input_cost_per_1k
output_cost = (total_output / 1000.0) * cost.output_cost_per_1k
return input_cost + output_cost
if __name__ == "__main__":
cost = ModelCost(input_cost_per_1k=0.012, output_cost_per_1k=0.024)
estimated = estimate_cost_per_1000(
cost=cost,
avg_input_tokens=1200,
avg_output_tokens=450,
retry_rate=0.03
)
print(f"Custo estimado por 1.000 requisições: R$ {estimated:.4f}")Por que isso ajuda? Porque corta a discussão subjetiva. Quando custo por 1.000 requisições cai e qualidade sobe (e o baseline é real), você tem evidência. Quando o custo explode e mesmo assim o discurso é “eficiência”, a probabilidade de a decisão ser financeira (e não técnica) aumenta.
Erros Comuns: o que evitar quando “IA” entra em avaliação e decisões
Dev experiente detecta superficialidade rápido. Em layoffs e reestruturação na era da IA, os erros mais comuns que eu vejo (e que você deve observar) são:
1) Usar “uso de IA” como métrica de desempenho
Se o time só mede “quantas pessoas usaram um copiloto”, você terá viés. Uso não é resultado. É possível usar e piorar qualidade.
2) Ignorar custo operacional e observabilidade
LLMs exigem monitoramento. Sem isso, a qualidade desanda e o time de suporte “paga a conta”. Depois, esse custo some da contabilidade e vira desculpa para cortar pessoas.
3) Trocar métricas de qualidade por métricas fáceis
Por exemplo: “quantidade de respostas geradas” sem medir taxa de correção, completude e satisfação do usuário final.
4) Não fazer baseline comparável
Se você compara uma era antiga com outra com mudanças de produto, você perde a causalidade. A IA pode ser só coincidência.
5) Reclassificar tarefas sem transparência
O trabalho continua, mas muda de nome: “manutenção virou treinamento”, “suporte virou governança”, e assim por diante. Se ninguém rastrear o que foi efetivamente absorvido, você cria o terreno perfeito para cortes “sem impacto”, que na verdade criam gargalo depois.
O que essa petição indica para o futuro do trabalho em engenharia
Quando trabalhadores pedem indenização garantida e desligamento voluntário antes de cortes obrigatórios, isso não é só política trabalhista. É uma tentativa de criar previsibilidade. Em engenharia, previsibilidade é o que impede duas coisas:
- piora de qualidade por perda súbita de conhecimento tácito (sistemas que “só funcionam porque alguém conhece”);
- desorganização técnica em cascata (falhas em observabilidade, incidentes, rollback lento).
Além disso, mudanças no sistema de avaliação interna tendem a pressionar por critérios mais objetivos — e isso, mesmo para quem não está buscando emprego, melhora o desenho organizacional. Menos teatro, mais entrega mensurável.
FAQ
IA realmente substitui engenheiros?
Na prática, o mais comum é substituir parte do trabalho repetitivo e acelerar algumas etapas. O risco maior é organizacional: usar a narrativa de eficiência para reduzir headcount sem medir impacto no produto ou sem considerar o custo operacional novo que a IA cria.
Como devs podem defender métricas mais justas em times com IA?
Exija baseline e métricas em camadas: qualidade, eficiência e impacto no usuário. E inclua custo total (incluindo observabilidade e retries). Métrica justa é auditável.
O que eu deveria observar quando uma empresa diz “prioridade em IA”?
Veja se eles estão reduzindo risco técnico ou só redistribuindo trabalho. Procure transparência em avaliação, governança, custos e como incidentes e suporte são contabilizados.
Como lidar com decisões que parecem “inevitáveis” ligadas à IA?
Documente entregas com evidências. Mantenha rastreabilidade de impacto (antes/depois). Isso não impede toda reestruturação, mas te coloca em vantagem para negociações internas e para proteger qualidade em projetos.
Qual a diferença entre automação de tarefas e transformação de produto com IA?
Automação de tarefa melhora fluxo. Transformação de produto altera arquitetura, dados, métricas e governança. Só a segunda muda de verdade o tipo de custo e os riscos — e é aí que as avaliações precisam ser mais rigorosas.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.