220% mais código, 36% mais features: o que a Meta ensina sobre produtividade com IA

Produtividade com IA não é produzir mais artefatos com menos pessoas. É fazer mais trabalho útil chegar ao resultado, com qualidade e sem criar uma conta escondida de incidentes, revisão e retrabalho. Quando o volume gerado dispara, mas o fluxo que chega ao usuário cresce muito menos, a automação pode estar acelerando uma parte do sistema e piorando outra.

Uma investigação publicada pela Reuters em 26 de agosto de 2026 oferece um caso raro porque expõe simultaneamente ambição, desenho organizacional e indicadores internos. Segundo documentos e fontes consultadas pela agência, a Meta criou o Project OT, de Organization Transformation, para explorar uma organização mais “AI native”, com equipes menores, funções mais fluidas e agentes assumindo parte do trabalho cotidiano. Nos cenários mais agressivos, alguns times poderiam ser reduzidos em até 60% — número que a própria Meta confirmou como parte de exercícios de planejamento, deixando claro que nunca se tratou de cortar 60% da empresa inteira.

A discussão poderia parar no tema mais chamativo, o emprego. Para gestão, porém, o dado mais interessante aparece depois. Em uma publicação interna citada pela Reuters, mudanças de código em plataformas e infraestrutura internas cresceram 220% ano contra ano. No mesmo período, alterações que efetivamente resultaram em funcionalidades novas ou melhoradas chegando aos usuários cresceram 36%. E os sinais de qualidade se deterioraram: incidentes técnicos e de segurança subiram 40%, enquanto o tempo gasto em “firefighting” aumentou 70%.

Esses números não provam que IA reduziu a produtividade da Meta como um todo. Eles vêm de recortes internos específicos e a empresa não comentou os dados de incidentes. Mas mostram algo que muitas transformações ignoram: atividade, throughput e valor são métricas diferentes. Aumentar uma delas não garante as outras.

O erro começa quando redução de equipe vira premissa

Há uma diferença importante entre descobrir que uma automação permite operar com menos esforço e começar a transformação definindo quantas pessoas deveriam sobrar no final. No primeiro caso, o desenho do trabalho produz a consequência. No segundo, a consequência desejada passa a moldar o diagnóstico.

Isso pode gerar uma sequência perigosa. A empresa escolhe um alvo de eficiência, assume que IA absorverá determinado conjunto de tarefas e então reorganiza papéis antes de saber quais partes do fluxo realmente ficaram autônomas. Se a tecnologia não amadurece no ritmo esperado, o trabalho não desaparece. Ele volta como fila, revisão manual, suporte informal, reunião, incidente ou carga concentrada em quem permaneceu.

A própria Meta recuou de uma segunda onda de reorganização planejada para novembro. A Reuters relata que Mark Zuckerberg reconheceu internamente, em julho, que a tecnologia de agentes não havia “acelerado” tão rápido quanto esperava. O ponto não é usar isso como argumento contra agentes. É tratar maturidade técnica como evidência a ser observada, não como hipótese que autoriza antecipadamente uma mudança irreversível na operação.

Essa é uma continuação natural da pergunta feita no artigo da Munnius sobre robôs humanoides e tarefas reais. Ali, a questão era se uma automação aguenta variação, exceções e recuperação. Aqui, a pergunta sobe um nível: quando essa automação é colocada dentro de uma organização, ela realmente permite redesenhar capacidade sem degradar o sistema ao redor?

Mais produção local pode esconder menos fluxo ponta a ponta

O contraste entre 220% mais mudanças de código e 36% mais funcionalidades entregues é útil porque expõe um efeito conhecido em operações. Otimizar uma etapa pode apenas empurrar o gargalo para a próxima.

Se desenvolvedores geram código muito mais rápido, revisão, testes, segurança, integração, decisão de produto e rollout passam a receber mais volume. Se essas etapas não acompanham o ritmo, a organização acumula estoque intermediário. O dashboard de atividade fica exuberante, enquanto o tempo entre ideia e resultado não cai na mesma proporção.

O mesmo acontece fora de engenharia. Um agente pode produzir atas instantaneamente, mas ninguém fecha as decisões. Pode criar cinquenta follow-ups, mas o cliente recebe mensagens demais e responde menos. Pode gerar cenários de teste em minutos, mas homologação continua limitada pelo ambiente e pela disponibilidade de usuários. Pode classificar centenas de solicitações, mas todas as exceções continuam chegando ao mesmo especialista.

Por isso, uma transformação com IA deveria mapear primeiro o fluxo de valor e seus pontos de espera. O artigo sobre redesenhar processos antes de automatizar trata da necessidade de questionar regras e etapas. A lição da Meta adiciona outra camada: depois de redesenhar, é preciso medir se a automação melhorou o sistema inteiro — e não apenas a estação onde foi instalada.

Código gerado é output. Feature usada é outcome intermediário

Empresas precisam de métricas de atividade. Elas ajudam a entender volume, adoção da ferramenta e capacidade técnica. O erro é promovê-las a prova de valor.

Linhas de código, documentos gerados, tickets classificados, respostas automáticas e tarefas concluídas são outputs. Eles descrevem algo que o sistema produziu. O resultado operacional aparece depois: feature disponível e utilizada, ciclo mais curto, menos erro, cliente ativado, menos retrabalho, mais receita protegida ou risco reduzido.

Mesmo “features entregues” ainda é uma medida intermediária. Uma funcionalidade pode chegar ao usuário e não melhorar nada. Mas ela está mais perto do valor do que o volume de código porque atravessou mais partes do fluxo.

Essa distinção conversa com o artigo da Copa sobre métricas e baselines de automação, mas o problema aqui é organizacional. Não basta avaliar se o modelo acerta. É preciso observar se o trabalho que ficou mais rápido produz um efeito econômico ou operacional melhor depois de atravessar pessoas, sistemas, controles e clientes.

Qualidade precisa entrar na mesma conta da velocidade

Se uma equipe dobra a produção e dobra também a necessidade de correção, a produtividade líquida pode ter mudado pouco. Em software isso aparece como incidentes, rollbacks e tempo de engenharia consumido por suporte. Em onboarding, aparece como reabertura de pendências, explicações adicionais, erro de configuração e cliente voltando etapas. Em operações financeiras ou fiscais, pode aparecer como exceção que exige análise manual justamente nos casos de maior risco.

Por isso, ganhos de IA deveriam ser avaliados junto com uma métrica de qualidade ou custo de recuperação. Não é necessário criar um painel enorme. Para uma automação de follow-up, por exemplo, poderia ser suficiente acompanhar tempo até resolução, taxa de reabertura e intervenção humana. Para geração de código, throughput até produção, incidentes e horas de correção dizem mais do que quantidade gerada.

O aumento de “firefighting” relatado na Meta é especialmente útil como conceito. Trabalho de recuperação consome capacidade sem aparecer no plano original. Quando ele cresce, parte da eficiência prometida já foi devolvida à operação em uma forma menos previsível.

Transformação também é um problema de confiança

A investigação registra queda no indicador interno de sentimento dos funcionários, de 74% favorável para 55%, em meio a demissões, incerteza sobre papéis e iniciativas de captura de interações para treinamento de agentes. Não é possível atribuir essa variação a uma única causa. Ainda assim, o episódio mostra que desenho organizacional e adoção tecnológica não acontecem em universos separados.

Quando pessoas acreditam que sua contribuição será usada apenas para tornar sua posição descartável, colaboração muda. Conhecimento pode ser menos compartilhado, experimentos recebem resistência e qualquer falha técnica vira também uma disputa sobre intenção. Comunicação não resolve uma estratégia ruim, mas ambiguidade pode sabotar uma estratégia boa.

Isso importa em projetos muito menores. Uma automação criada para aliviar tarefas repetitivas pode ser percebida como mecanismo de controle. Um agente para acompanhar clientes pode parecer uma tentativa de substituir o consultor. Um novo ERP pode ser tecnicamente sólido e enfrentar baixa adoção porque os usuários só conheceram a solução depois que todas as decisões já estavam tomadas.

A gestão precisa explicitar o contrato da mudança: que trabalho queremos eliminar, que responsabilidade continua humana, como qualidade será medida, o que acontece quando a automação erra e qual capacidade nova se espera das pessoas. Sem isso, “AI native” vira slogan organizacional antes de virar desenho operacional.

O contraponto: a Meta continua crescendo e investindo pesado em IA

Seria errado ler o caso como prova de fracasso da estratégia de IA da Meta. Nos resultados do segundo trimestre, a companhia reportou receita de US$ 60,8 bilhões, contra US$ 47,5 bilhões um ano antes. A empresa continua colocando IA no centro do negócio e investindo agressivamente em infraestrutura e produto.

Também existe uma tensão interessante dentro da própria visão pública de Mark Zuckerberg. No ensaio “The Future is for Everyone”, ele argumenta que o melhor uso da superinteligência pode estar em ampliar a capacidade das pessoas para criar coisas novas, e não simplesmente automatizar empregos existentes. Essa ideia é mais ampla do que o Project OT e não elimina decisões de eficiência, mas oferece uma régua melhor para transformação: a tecnologia está apenas retirando trabalho ou está aumentando o que a organização consegue realizar?

Essa pergunta evita dois extremos. O primeiro é romantizar emprego e impedir qualquer automação que torne uma função menor. O segundo é assumir que menos pessoas sempre significa mais produtividade. Organizações saudáveis podem sim operar com equipes menores depois de redesenhar processos. O importante é que a redução seja sustentada por capacidade comprovada, não pela expectativa de que a tecnologia preencherá o espaço depois.

Antes de redesenhar a equipe, redesenhe a medição

Uma empresa que queira testar uma transformação semelhante não precisa esperar meses para descobrir se está produzindo o tipo errado de eficiência. Antes do piloto, pode registrar poucas medidas em três níveis.

No primeiro, observe o trabalho produzido: código, documentos, análises, contatos ou tarefas. No segundo, observe o fluxo concluído: itens que atravessaram revisão, chegaram ao cliente, entraram em produção ou resolveram a demanda. No terceiro, acompanhe o custo de sustentar o resultado: incidentes, retrabalho, intervenção humana, espera e qualidade.

Se o primeiro nível dispara e os outros não melhoram, a tecnologia provavelmente encontrou um gargalo novo. A resposta pode ser ampliar automação, simplificar controles, mudar arquitetura, aumentar uma capacidade específica ou até reduzir o ritmo de geração. O que não faz sentido é comemorar a primeira métrica e cortar a capacidade que seria necessária para resolver as duas seguintes.

IA pode mudar profundamente quantas pessoas uma organização precisa e quais papéis existirão. Mas essa é uma conclusão de desenho operacional, não um KPI de transformação. A melhor evidência de uma empresa mais “AI native” não é que ela produz muito mais artefatos com menos gente. É que o trabalho útil atravessa o sistema mais rápido, com qualidade melhor e menos esforço total.