O Spotify Dobrou os Merges para 17.000 por Mês. O Retrabalho Ficou Estável. A Restrição Mudou.

As mudanças mergeadas no Spotify foram de cerca de 8.100 para 17.000 por mês, comparando agosto com o agosto anterior. A métrica de retrabalho, reconstruída pela empresa, não se moveu. As revisões de incidente, entre os incidentes examinados até agora, não identificaram código escrito por IA como contribuidor direto relevante. Uma frase de Tyson Singer serve como premissa operacional: “A IA aumentou a capacidade de produzir mudança. A próxima restrição passou a ser nossa capacidade de verificá-la.”

Este é o maior relato em primeira mão sobre qualidade de entrega na era da IA que lemos este ano, e chega em setembro de 2026 junto com dois outros textos que, lidos em conjunto, dão a um líder de engenharia algo mais útil do que um alerta. Bharat Sharma publicou uma tabela de cinco linhas, com fórmulas, unidades e cadências, que mede capacidade de controle contra capacidade de geração. O PostHog descreveu um loop que reconfere a correção depois do deploy e só fecha quando uma execução posterior confirma que ela se manteve. Os três encaixam em um único desenho operacional.

O que os números do Spotify dizem, e o que deixam em aberto

O volume é a manchete. O mix por trás dele importa mais. Trabalho de qualidade e otimização subiu de 27% das mudanças mergeadas para 31%. Manutenção e configuração caíram de 31% para 25%. Uma parcela maior da produção dobrada foi para melhorar sistemas, e uma parcela menor para mantê-los configurados.

Retrabalho é a métrica que o Spotify reconstruiu em vez de reaproveitar. Churn bruto conta toda linha tocada de novo. A versão do Spotify é ponderada por idade, e o post a trata como distinta do churn bruto. Nessa medida, a empresa relata que não houve aumento correspondente de retrabalho, e contrasta o resultado com o achado do FAROS 2026 de uma alta de churn em todo o setor. Esse contraste é a leitura que o Spotify faz de dados alheios, e convém mantê-lo a alguma distância: o número do FAROS descreve o setor, o número do Spotify descreve uma empresa com uma métrica de desenho próprio.

O post também relata uma migração de Java em serviços de backend concluída em três dias, com a vasta maioria dessas mudanças mergeada automaticamente após passar pelas verificações de segurança. Os incidentes são onde o relato ganha credibilidade, porque ele os lista. Em 24 de junho, um bug de agendamento reduziu a vazão de processamento de conteúdo em cerca de 10%. Depois de um incidente em maio, a capacidade de borda reservada foi dobrada. Nenhum dos dois é apresentado como IA escrevendo código ruim. O diagnóstico do próprio Spotify é que “o volume de mudança cresceu mais rápido do que alguns dos nossos controles de verificação conseguiram se adaptar”.

Dois sinais de alerta aparecem sem número: complexidade de código e tamanho de PR estão subindo aos poucos. O Spotify diz que deliberadamente ainda não reescreveu os limiares, por falta de convicção. Na nossa leitura, um “ainda não sabemos” honesto em um post corporativo é raro o bastante para merecer registro.

Os controles que o Spotify adicionou ficam todos do lado da verificação

Todo controle que o post lista fica depois do código escrito. Monitoramento de ponta a ponta para que as falhas sejam detectadas antes que os criadores percebam. Mudanças automatizadas agendadas dentro do horário de trabalho do time dono do serviço. Capacidade de rollback ampliada. Uma retrospectiva mensal com duas perguntas fixas: o código escrito por IA contribuiu diretamente para este incidente? O volume de mudança estressou revisão, testes, rollout ou observabilidade? E todo PR mergeado classificado em um de quatro grupos: features, qualidade e otimização, manutenção, documentação.

As duas perguntas e a classificação são as partes que um time de qualquer tamanho consegue adotar este mês, porque custam um template e um hábito. A segunda dá nome ao modo de falha que o Spotify encontrou, e é a que vale adicionar ao seu template de retrospectiva. Na nossa experiência, estresse de volume no caminho de verificação raramente aparece em um campo de causa raiz. Uma pergunta fixa é o que o obriga a entrar na ata.

Já argumentamos que o ganho de 3-5x tem meia-vida de três meses quando a verificação fica fora do loop, e que 82 centavos de cada dólar de IA nunca entregam. O relato do Spotify é evidência em primeira mão do mecanismo. Nossa leitura é que o ganho se manteve porque o lado da verificação foi reconstruído para absorvê-lo.

Cinco linhas que medem controle contra geração

A tabela de Sharma é o instrumento da premissa. Cada linha tem fórmula, unidade de análise e cadência, e é isso que separa uma métrica de um slogan:

Tempo de fila de revisão. Primeira revisão substantiva menos o momento em que o PR ficou pronto. Por time, semanal.
Retrabalho de horizonte curto. Linhas alteradas ou revertidas em 14 dias, divididas pelas linhas introduzidas. Por repositório, semanal.
Taxa de falha na validação. PRs que falham nos gates obrigatórios, divididos pelos PRs que entram em validação. Por pipeline, semanal.
Retrabalho pós-deploy. Deploys de remediação divididos pelo total de deploys. Por serviço, mensal.
Retrabalho por unidade de gasto com IA. Linhas de retrabalho em 14 dias, divididas pelo gasto com assentos e tokens. Por organização, mensal.

Três regras acompanham a tabela e fazem mais trabalho do que as linhas. Acompanhe cada linha como tendência contra a linha de base anterior à IA, porque um número absoluto nada diz sobre o que a ferramenta mudou. Jamais reporte qualquer linha no nível individual. Sharma cita Goodhart pelo nome, e nós cobrimos a versão da mesma falha no nível do modelo em julho. Combine a tabela com medidas de satisfação do SPACE, para que um time batendo todas as linhas enquanto se esgota fique visível.

O contexto que Sharma constrói em torno da tabela vem inteiro de trabalhos alheios, e ele mantém as próprias ressalvas em cada número. Uma pesquisa da Halkwinds de 2026 com 758 organizações de engenharia encontrou 76% com assistente de código por IA implantado em toda a organização (41% em 2024), e apenas 34% capazes de apontar uma mudança mensurável e auditada nas métricas de entrega. Uma análise de 2026 sobre cerca de 110.000 PRs de código aberto encontrou PRs escritos pelo Claude Code com cerca de seis vezes o tamanho dos escritos por humanos. A telemetria de campo da Apiiro reporta caminhos de escalação de privilégio 322% acima. Os 211 milhões de linhas do GitClear, de 2020 a 2024, mostram código duplicado por copiar e colar superando código movido pela primeira vez. Uma pesquisa do primeiro trimestre de 2026 coloca o churn entre usuários intensivos de IA em até nove vezes o dos não usuários. O número observacional do Copilot, até 40,5% mais PRs entre usuários intensivos em 16.223 desenvolvedores, vem de uma amostra autosselecionada; a instrução de Sharma é lê-lo como teto.

Coloque o par da Halkwinds ao lado do Spotify. 76% implantaram o assistente. 34% conseguem provar o que ele mudou. O post do Spotify é como poderia parecer uma empresa dentro desses 34%: uma métrica de retrabalho reconstruída e todo PR classificado antes de qualquer conclusão.

O loop que falta na tabela

A linha quatro de Sharma, retrabalho pós-deploy, é uma razão mensal. Ela diz com que frequência um serviço precisou de um deploy de remediação. Ela silencia sobre se a remediação funcionou. Os loops do PostHog fornecem o passo que falta.

O exemplo trabalhado é um único incidente, e o PostHog não anexa nenhum número agregado aos seus loops, então o que segue descreve um mecanismo e não reivindica resultado além desse caso. Um alerta de taxa de erro em MCP disparou em cerca de 9,9% contra uma linha de base de 0,3% a 1,2% nas duas semanas anteriores: 88 erros em uma hora, em cerca de 44 projetos. Um agente scout rastreou os erros até uma única ferramenta e a corrigiu. A regra anexada ao loop é a parte para copiar: “mergeado não é o mesmo que verificado em produção”. O scout reconfere depois do deploy e fecha o loop apenas quando uma execução posterior encontra o problema corrigido.

Esse é o passo que as perguntas de retrospectiva do Spotify e a tabela de Sharma deixam de fora. As duas perguntas rodam mensalmente, depois do fato. A linha quatro conta deploys de remediação; uma remediação confirmada é outro evento, e nenhuma linha o registra. O loop do PostHog é o agente voltando à métrica que o acionou e se recusando a marcar concluído até a métrica concordar. Nossa taxonomia de travas antes de o agente escrever cobriu o lado da aprovação dessa fronteira. A reconferência depois do deploy é o lado do fechamento.

Faça isto agora

Três movimentos, em ordem, nos próximos 90 dias, seguindo o roteiro de Sharma: linha de base, guardrails e depois o relatório.

Linha de base primeiro. Extraia as cinco linhas para o último trimestre anterior à implantação de IA, ou para o trimestre mais antigo que existir. Sem a linha anterior à IA, todo número posterior é anedota. Reporte por time, repositório, pipeline, serviço e organização, exatamente como a tabela especifica, e nunca por pessoa.

Guardrails em segundo. Sharma nomeia limites de tamanho de PR e limites de iteração de loop. O próprio sinal do Spotify de que o tamanho de PR está subindo, com limiares que a empresa deliberadamente ainda não reescreveu, é o argumento para definir um limite agora e revisá-lo conforme os dados chegam.

Depois, refaça o relatório que o executivo lê. Adicione as duas perguntas de retrospectiva do Spotify a toda revisão de incidente, e classifique todo PR mergeado nos quatro grupos. Adicione a regra do PostHog à definição de pronto de qualquer remediação automatizada: a correção fecha quando uma execução posterior confirma que a métrica voltou à linha de base, e em nenhum momento anterior.

A medida de sucesso é um par de números que dá para mostrar ao conselho no ano que vem: quanto a capacidade de geração cresceu, e se as cinco linhas de controle se mantiveram. O par do Spotify foi dobrou e estável. Essa é a meta.

Fontes

Spotify Engineering (Tyson Singer). “AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity.” Setembro de 2026.
Bharat Sharma. “AI Is Making Activity-Based Engineering Metrics Obsolete.” Setembro de 2026.
PostHog (Andy Maguire). “6-7 loops we use every day to make PostHog self-driving.” Setembro de 2026.

A Victorino ajuda líderes de engenharia a construir a capacidade de verificação, rollout e rollback que permite ao crescimento de produção na era da IA manter sua linha de qualidade: contato@victorino.com.br | www.victorino.com.br