Agentes Não Fazem Standups: A PFF e a Inversão Organizacional

A gestão de engenharia de software passou vinte anos otimizando para velocidade do engenheiro. Scrum, sprint planning, daily standup, refinamento, retrospectiva. Toda cerimônia descende da mesma premissa: hora de desenvolvedor é o recurso escasso, então é preciso coordená-la com cuidado.

Na AI Engineer Conference de maio de 2026, Mike Spitz, CTO da Pro Football Focus, descreveu um experimento de três meses que testou o que acontece quando essa premissa deixa de valer. Dois engenheiros, trabalhando com agentes, contra um time de aproximadamente dez engenheiros sem agentes. Mesma base de código, mesmos clientes, de janeiro a março de 2026. Números autodeclarados: 25x mais frequência de deploy, 10x mais entrega medida por contagem de tickets ponderada por complexidade de código, satisfação média do cliente em 8.6 contra uma linha de base pré-IA próxima a 7.5.

A PFF não é um laboratório de pesquisa. É uma empresa de dados esportivos com 100 milhões de page views por ano, nove milhões de drafts de fantasy por ano, 200 funcionários e cerca de 20 engenheiros, atendendo times da NFL e da NCAA junto com um produto consumer de fantasy e apostas. O caso aterrissa em escala, em código de produção, com clientes pagantes. É isso que o torna interessante.

A pergunta interessante não é se dois engenheiros conseguem substituir dez. Já escrevemos antes sobre o experimento do compilador com 16 agentes conduzido por Carlini e o que ele indica sobre agentes como força de trabalho. A pergunta interessante é como a organização ao redor se reconfigura quando você para de otimizar para ergonomia do engenheiro e começa a otimizar para vazão de agentes. A resposta de Spitz: as cerimônias caem primeiro.

As Cerimônias Resolviam um Problema que Desapareceu

Scrum não desceu de uma montanha. É um artefato, projetado no fim dos anos 1990 e nos anos 2000, para resolver um problema específico de coordenação: como fazer com que um número pequeno de engenheiros humanos, caros e lentos, entregue software coerente sem pisar no pé um do outro. A daily responde “o que está te bloqueando hoje, enquanto você ainda tem oito horas de digitação pela frente?” O sprint plan responde “qual é a capacidade realista desses humanos nas próximas duas semanas?” A retrospectiva responde “como deixamos esses humanos um pouco menos frustrados no próximo sprint?”

Cada uma dessas perguntas assume que hora de engenheiro é a restrição dominante.

A PFF desmontou a pilha inteira. Spitz lista o que saiu: o papel de product manager, sprint planning, daily standup, refinamento de sprint, retrospectiva. O que entrou no lugar é quase constrangedoramente enxuto. Uma reunião curta de meia hora, em dias alternados. Engenheiros sinalizam bloqueios em tempo real, não às 10 da manhã do dia seguinte. O sinal da retrospectiva foi substituído por uma pesquisa de satisfação dos clientes, porque são eles que sabem se o trabalho da semana passada foi bom. A função de PM, a escrita de spec, o grooming de tickets, a sincronização de status, tudo migrou para agentes.

Isso não é “ainda fazemos Scrum, mas com ajuda de IA”. É a deleção explícita das cerimônias, com base no raciocínio explícito de que a restrição para a qual elas foram desenhadas não existe mais.

O Fluxo que Toma o Lugar

Spitz descreveu o loop que a PFF roda agora, e vale traçar porque a topologia importa.

Chega uma spec. Um agente escreve um Lightweight Design Document, que ele compõe lendo todos os LDDs anteriores no repositório para aprender o formato que esses documentos têm na PFF. Tickets são gerados automaticamente a partir do LDD, preservando a topologia não-bloqueante para que trabalhos independentes possam avançar em paralelo. Pull requests carregam status que se sincroniza automaticamente de volta para o sistema de tickets. Depois do merge, um agente de QA sobe em staging e valida cada ticket contra seus critérios de aceitação.

O que precisa ser notado é que isso não é “agentes ajudam engenheiros a codar mais rápido”. É “agentes substituem o tecido conjuntivo entre engenheiros”. O LDD, os tickets, as atualizações de status, as passadas de QA. Todo o trabalho que historicamente exigia um PM, um tech lead, um scrum master, um engenheiro de QA e os próprios engenheiros para manter sincronizado. A maior parte desse trabalho não tem nada a ver com escrever código. É overhead de coordenação, e overhead de coordenação é exatamente o tipo de trabalho em que agentes são bons quando os artefatos são estruturados e as regras são explícitas.

Os dois engenheiros focam nas partes do loop que ainda exigem julgamento: decisões de design de sistema, revisão de código em escolhas arquiteturais, e julgamento sobre experiência do cliente. Tudo no meio é delegado.

A Revisão de Código se Divide, Não Morre

O movimento mais sutil do redesenho de Spitz é a divisão que ele fez na revisão de código. Ele não eliminou a prática. Ele a partiu em duas.

Revisão de estilo, convenção de nomes, “eu teria feito diferente” e opiniões bikeshed, o tipo de feedback que ninguém gosta de dar nem de receber: agentes assumem. Revisão de design de sistema, coerência arquitetural, a pergunta sobre se a mudança encaixa no modelo da plataforma: engenheiros assumem. Como ele formulou: “Usamos agentes para fazer as revisões de código que engenheiros odeiam receber. Tira todo o aspecto emocional fora disso.”

Esse é um daqueles detalhes operacionais que parecem pequenos e não são. Uma fração relevante da dor cultural em engenharia vem de feedback de revisão entregue mal. Sêniores que criticam estilo, juniores que se sentem atacados, a erosão lenta de segurança psicológica quando o feedback é tecnicamente correto mas socialmente caro. Mover a superfície de revisão de baixo valor para um agente não só economiza tempo. Remove uma fonte recorrente de atrito organizacional. A revisão humana que resta é reservada para as conversas que de fato exigem humanos, o que torna essas conversas tanto mais focadas quanto mais respeitadas.

O princípio generaliza. Onde quer que no seu processo de engenharia o trabalho seja baseado em regra mas a entrega seja emocionalmente carregada, o agente é o operador melhor.

A Satisfação do Cliente Subiu, Não Caiu

A parte do caso que mais resiste ao ceticismo padrão é o número de satisfação do cliente. A linha de base pré-IA na PFF estava entre 7.0 e 7.5. Ao longo dos três meses de experimento, a satisfação média do cliente foi 8.6.

Uma objeção comum à engenharia aumentada por IA é que velocidade vem ao custo de qualidade, e que clientes vão notar. Os números da PFF, autodeclarados e em uma única empresa, apontam para a direção oposta. Deploys mais frequentes encurtam o ciclo de feedback, o que significa que defeitos são pegos mais rápido e pedidos de funcionalidade são atendidos mais rápido. O agente de QA rodando contra critérios de aceitação em staging captura uma classe de regressões que antes escapava. Os 25x de frequência de deploy não são 25x mais superfície de risco; são 25x mais chances de detectar e corrigir.

A ressalva precisa ser sublinhada: esses números foram divulgados pelo CTO em uma conferência. Não foram validados por terceiros. Refletem uma empresa, três meses. Trate como prova de existência, não como benchmark a ser copiado. O ponto não é “todo time deveria esperar CSAT de 8.6”. O ponto é “a tese de que velocidade com IA precisa trocar qualidade está, no mínimo, a um contraexemplo forte de ser considerada segura.”

O Perfil do Engenheiro Muda

Spitz mencionou uma implicação de contratação e retenção que a maior parte das discussões sobre engenharia aumentada por IA pula. O novo arranjo não funciona para todo engenheiro.

Engenheiros que prosperam: os curiosos, dispostos a se aprofundar em sistemas desconhecidos, confortáveis em operar sem uma especificação prescritiva entregue na mão. Tratam o agente como um time júnior que pode pegar trabalho, mas assumem a responsabilidade pela direção arquitetural. São intrinsecamente motivados a descobrir o que deveria ser construído.

Engenheiros que sofrem: os que precisam de um ticket do Jira totalmente especificado antes de começar a trabalhar, que dependiam do PM e do documento de spec como fonte de direção. O suporte estrutural de que esses engenheiros precisavam foi removido, e os agentes não o repõem. Os agentes amplificam qualquer direção que o engenheiro fornece, o que é maravilhoso se o engenheiro tem direção e difícil se o engenheiro dependia da organização para fornecer essa direção.

Essa é uma questão real de design organizacional para qualquer time considerando a mudança. Os engenheiros que têm sucesso em um ambiente pós-cerimônia são um perfil específico. Práticas de contratação e gestão que filtravam por “entrega de forma confiável contra specs apertadas” vão produzir um time que não combina com o novo modelo operacional.

Composição, Não Ganho Linear

Um dado interno anterior da PFF merece atenção. Antes da IA, o mesmo conjunto de funcionalidades que o time de dois engenheiros entregou havia sido estimado em quatro meses. O time de dois entregou em menos de dois meses, e um dos engenheiros estava desbloqueado o suficiente, dentro do primeiro mês, para começar outra frente em paralelo.

Isso não é um ganho de 2x ou de 5x. É um ganho não-linear porque o gargalo se deslocou. Quando a contribuição de um engenheiro desbloqueia não só ele mesmo, mas também abre espaço para a frota de agentes operar em uma segunda frente, a capacidade do time se compõe. A variável relevante não é “quão rápido o engenheiro digita”, e sim “quantas frentes paralelas dirigidas por agentes o engenheiro consegue manter abertas ao mesmo tempo”.

A implicação para planejamento de capacidade é desconfortável. As estimativas que seu time produz hoje assumem a restrição antiga. As estimativas que correspondem ao que vocês de fato conseguem entregar, com as ferramentas atuais, são diferentes por um múltiplo que depende de quão fundo vocês inverteram a organização.

Faça Isso Agora

Você não precisa desmontar o Scrum na semana que vem. Você precisa rodar um exercício único e concreto.

Pegue o próximo sprint de duas semanas. Liste toda cerimônia que vocês rodam: daily, refinamento, retro, sprint planning, demo. Para cada cerimônia, anote o problema original que ela resolvia. A maioria desses problemas vai se revelar como “humanos precisam coordenar tempo escasso em teclados escassos”. Em seguida, olhe quais desses problemas ainda existem no seu ambiente agora que agentes fazem parte do time. Alguns vão existir. A maioria não.

O exercício não é matar o Scrum. É nomear restrições. A PFF não deletou cerimônias porque cerimônias são ruins. Deletou cerimônias porque as restrições que aquelas cerimônias resolviam haviam se movido. O exercício é descobrir, com honestidade, quais das suas cerimônias ainda resolvem um problema real e quais são memória muscular organizacional.

Os times que vão superar o mercado nos próximos dois anos não são os que adotam agentes. Quase todo mundo vai adotar agentes. São os que redesenharam a organização ao redor para parar de otimizar por uma restrição que já se moveu.

Fontes

Mike Spitz, PFF. “Agents Don’t Do Standups.” AI Engineer Conference, Maio de 2026.
Pro Football Focus. “PFF.” 2026.
AI Engineer. “AI Engineer Conference.” Maio de 2026.

A Victorino ajuda líderes de engenharia a redesenharem processos organizacionais quando o tempo do engenheiro deixa de ser a restrição dominante: contato@victorino.com.br | www.victorino.com.br