Durante anos, trabalhar na Meta era quase sinônimo de engenharia com autonomia. O relato publicado nesta semana por Gergely Orosz, no Pragmatic Engineer, pinta outro cenário: uma empresa obcecada por acelerar IA, medindo tudo, redistribuindo gente à força e empurrando parte dos times para tarefas de rotulagem e avaliação de modelos.
O texto chamou atenção porque não veio como rumor solto. Veio como reportagem longa, com contexto da cultura antiga da empresa, detalhes operacionais e links para cobertura da Reuters. Quando a discussão foi parar no Hacker News, o tom dos comentários mostrou duas reações ao mesmo tempo: espanto com o tamanho da virada e ceticismo sobre até onde ela chegou.
Vale olhar para esse caso com calma porque ele toca numa ansiedade que já saiu da bolha da big tech. Em muita empresa, IA deixou de ser só ferramenta de produtividade e virou métrica de desempenho, discurso de corte e justificativa para mexer em estruturas que antes pareciam estáveis.
o que o texto original diz que mudou dentro da Meta
Orosz descreve uma quebra forte entre a Meta que por anos tratou engenharia como centro de vantagem competitiva e a Meta de agora, que estaria tratando boa parte desse capital técnico como insumo para a corrida de modelos. O argumento central não é só “a empresa quer usar mais IA”. É que a forma escolhida teria virado o trabalho de muitos times de cabeça para baixo.
Entre os pontos mais fortes do texto, quatro chamam mais atenção:
- coleta de teclado e mouse para treinar sistemas internos, com reação forte de funcionários e posterior recuo parcial;
- realocação forçada de engenheiros para atividades de data labeling e RLHF;
- medição agressiva de performance, com medo de que números passem a valer mais do que trabalho real;
- pressão por uso de IA que incentiva comportamento performático, como gerar tokens para não parecer “baixo uso”.
O ponto mais desconfortável do caso é esse último. Quando uma empresa transforma adoção de IA em placar, o risco deixa de ser técnico e vira organizacional. O time não usa a ferramenta porque ela ajuda. Usa porque não quer parecer atrasado diante da régua interna.
a parte que mais assustou devs foi a troca de autonomia por trabalho de rotulagem
Um dos trechos mais pesados do texto é o que descreve a ida de engenheiros de produto, infra e segurança para tarefas ligadas ao treinamento de modelos. Não se trata de um apoio lateral ou temporário descrito como oportunidade bonita de carreira. O enquadramento do relato é bem menos glamouroso: gente que antes escolhia time e impacto passou a cumprir trabalho repetitivo, com menos clareza de futuro técnico.
Isso mexe num ponto sensível para qualquer profissional de software. Boa parte da motivação de quem trabalha em produto, plataforma ou infraestrutura está no tipo de problema que resolve. Quando a empresa troca isso por uma fila de tarefas de avaliação de modelo, ela não está só mudando backlog. Está mudando a percepção de valor do próprio trabalho.
O texto até reconhece que há engenheiros que tentaram fazer esse novo papel funcionar e encontrar desafio ali. Mas a leitura dominante é outra: muita gente passou a olhar o crachá e sentir que o trabalho foi encolhido.
no Hacker News, a discussão virou menos “isso é bom ou ruim” e mais “isso é sustentável?”
Os comentários no Hacker News ajudam a medir a temperatura da comunidade técnica. Houve quem duvidasse do número de engenheiros movidos para data labeling, argumentando que usar dev caro dos EUA para isso parece economicamente torto. Mas mesmo entre os céticos, a reação principal foi de preocupação com os incentivos criados.
Um comentário resumiu bem esse medo ao reagir à ideia de usar contagem de tokens como sinal de performance: “Holy shit, talking about perverse incentives!”. Outro focou no impacto humano da virada: sair de um ambiente com alta autonomia para virar rotulador de dados em poucas semanas seria o tipo de quebra de cultura que não se corrige com memo interno.
Esse pedaço da discussão é importante porque tira o caso do terreno do fofocalho corporativo. O interesse real aqui não está em saber se a Meta está “mal” ou “bem”. Está em observar um laboratório extremo de algo que outras empresas podem tentar copiar em escala menor: vigiar mais, medir mais, exigir IA em tudo e chamar isso de modernização.
o caso conversa com um medo mais amplo do mercado
Nos últimos dias, outra pauta vem aparecendo com força: o aperto nas vagas de entrada e a pressão para provar produtividade com IA desde cedo. Em uma análise publicada pela UNSW, o pesquisador Toby Walsh diz que as ferramentas atuais já fazem com facilidade parte das tarefas de começo de carreira e alerta para um problema simples: se as empresas afunilarem demais a base, de onde virão os profissionais mais experientes depois.
O caso da Meta encosta justamente nessa fronteira. Mesmo falando de big tech e de times seniores, ele mostra um jeito de pensar que pode vazar para o resto do mercado: usar IA para comprimir camadas de trabalho, encurtar espaço de aprendizado e transformar o que antes era formação de carreira em trabalho de supervisão de máquina.
Nem toda empresa vai chegar ao mesmo extremo. Mas o raciocínio pode se espalhar com facilidade, principalmente onde liderança quer mostrar ganho rápido para investidor ou conselho.
o que vale tirar desse caso sem cair em exagero
- adoção de IA não é neutra. O problema não é só usar ferramenta nova. É o modelo de gestão que vem junto.
- métrica ruim muda comportamento rápido. Se token, clique ou volume viram proxy de desempenho, o trabalho começa a ser otimizado para o placar.
- cultura técnica pode desandar depressa. Não precisa desmontar a empresa inteira. Basta trocar autonomia por controle em pontos-chave.
- o mercado olha e aprende. Casos assim viram referência, para o bem e para o mal, em outras organizações tentando mostrar que “também estão fazendo IA”.
no fim, a pergunta não é se a Meta usa IA demais
A pergunta mais útil é outra: o que uma empresa passa a sacrificar quando decide que tudo deve servir à corrida de IA? No relato do Pragmatic Engineer, a conta aparece em forma de vigilância, deslocamento forçado, ansiedade de performance e perda de sentido do trabalho.
Talvez parte do caso ainda seja contestada por gente de dentro ou ajustada com o tempo. Mas a discussão já vale por si só. Ela mostra como a narrativa de produtividade pode esconder uma troca ruim: menos engenharia de verdade, mais teatro de adoção.
