Cinco vezes mais código, a mesma quantidade de atenção

Nos dados que Cursor e Linear compartilharam com Gergely Orosz, o volume anual de linhas adicionadas por desenvolvedores mais que dobrou, o tamanho dos pull requests triplicou e os times que usam agentes passaram a enviar cinco vezes mais código. A parte preocupante está menos na quantidade produzida do que no tamanho das mudanças que alguém ainda precisa compreender antes de colocá-las em produção.

A capacidade de gerar código cresceu sem que revisão, contexto e responsabilidade ganhassem a mesma escala. Um agente pode trabalhar durante uma reunião, outro pode abrir um pull request em paralelo e um terceiro pode revisar o resultado, mas a empresa continua dependendo de uma pessoa capaz de perceber que a solução duplicou uma regra de negócio, abriu uma falha de autenticação ou alterou um serviço que ninguém lembrava estar conectado àquela tela.

Minha primeira leitura desses números foi produtividade. Hoje, acho que eles descrevem melhor uma transferência de gargalo: escrever deixou de consumir a maior parte do tempo e verificar passou a concentrar o risco.

O gargalo saiu da escrita

Durante anos, empresas de software organizaram roadmaps, contratações e prioridades em torno de uma restrição conhecida. Havia mais coisas para construir do que engenheiros disponíveis para construí-las. Cursor, Claude Code e Codex reduziram essa escassez, especialmente para tarefas que podem ser descritas, divididas e verificadas com alguma objetividade.

🔗 Quer melhorar o onboarding do seu produto sem depender de desenvolvimento? Com a UserGuiding, você cria tours, checklists e experiências dentro do produto de forma simples. Use o cupom PRODUCTGURUS e ganhe 20% de desconto. Acesse a UserGuiding e teste na prática: https://productgurus.short.gy/UBMEF9

A revisão não recebeu a mesma compressão. Quando o tamanho médio de um pull request triplica, o revisor precisa entender mais arquivos, reconstruir mais decisões e imaginar mais formas de o sistema quebrar. A revisão feita por outro agente ajuda a localizar problemas conhecidos, mas também pode repetir a mesma leitura errada que produziu o código.

Código pode ser produzido em paralelo; confiança continua sendo construída em série.

Kent Beck resumiu essa mudança numa conversa com Orosz: “estamos acumulando código mais rápido do que acumulamos confiança”. Software exige mais do que passar nos testes disponíveis. Alguém precisa entender por que aquela mudança existe, qual parte do produto depende dela e o que acontecerá quando o próximo engenheiro pedir ao agente para modificá-la novamente.

Essa diferença aparece com mais força nos sistemas antigos, onde o conhecimento está espalhado entre código, documentação incompleta e pessoas que participaram de decisões tomadas cinco anos atrás. O agente encontra os arquivos em segundos, mas não encontra com a mesma facilidade o motivo pelo qual uma exceção foi criada para um cliente específico ou por que um fluxo aparentemente redundante continua existindo.

Quanto mais código entra, mais conhecimento implícito passa a ser tratado como detalhe técnico. É justamente esse tipo de detalhe que costuma aparecer no post-mortem.

A Uber construiu uma fila para a atenção humana

A Uber tem cerca de 3 mil engenheiros e, segundo Orosz, transformou parte da equipe de developer experience numa estrutura dedicada à experiência com IA. A empresa criou um gateway interno de MCP, o Uber Minion para rodar agentes em background e uma série de ferramentas para controlar o volume produzido.

O Code Inbox ajuda a separar mudanças que exigem atenção. Os Risk Profiles estimam quais alterações merecem uma revisão mais cuidadosa. O uReview automatiza parte da análise. Há até regras para encaminhar um pull request a outra pessoa quando o primeiro revisor não responde dentro do prazo. A Uber percebeu que colocar mais agentes para trabalhar também exige uma forma explícita de decidir onde os humanos devem parar.

A parte mais cara da adoção aparece depois da licença. Cursor, Claude Code ou Codex colocam o agente na mão do engenheiro; a empresa ainda precisa conectá-lo ao monorepo, ao sistema de experimentação, às regras de segurança e ao histórico de decisões que define o que pode chegar à produção.

Spotify tomou uma decisão diferente. O CTO da empresa contou a Orosz que a qualidade deveria permanecer no mesmo nível durante a adoção, mesmo que isso reduzisse o ganho imediato de produção. A companhia construiu controles internos e avançou mais devagar, sem registrar o mesmo salto de output exibido por empresas que priorizaram volume.

Uber e Spotify escolheram ritmos diferentes, mas partiram de uma pergunta parecida: qual resultado a empresa quer obter sem deteriorar o sistema que já opera? Essa pergunta parece óbvia, porém desaparece quando a meta interna vira quantidade de pessoas usando IA.

Distribuir uma ferramenta mede distribuição. Uma mudança operacional aparece no tempo de revisão, nos incidentes, nos rollbacks e na capacidade de alterar novamente o código seis meses depois.

Quando consumo vira desempenho

Orosz descreve uma prática que chamou de token maxing. Em empresas como Meta, Amazon e Microsoft, engenheiros teriam passado a acompanhar rankings de consumo ou percebido que uma utilização baixa poderia ser interpretada como resistência à IA. A resposta foi previsível: mais tarefas foram enviadas aos agentes, inclusive atividades que poderiam ser concluídas mais rápido sem eles.

Na Meta, segundo os relatos internos apresentados na palestra, havia classificações ligadas ao consumo de tokens e uma pressão informal para que a utilização aparecesse nas avaliações de desempenho. A empresa encerrou parte dessas iniciativas, mas o comportamento já havia ensinado uma regra aos funcionários: usar IA precisava ser visível.

Eu trataria essa parte com cautela numa publicação. Orosz atribui as informações a funcionários das empresas, e vários detalhes ainda não têm confirmação pública independente. A lógica do incentivo, porém, independe de aceitar cada relato como fato: quando a liderança mede consumo, o funcionário aprende a produzir consumo.

O mesmo problema existia quando empresas contavam linhas de código, tickets fechados ou quantidade de features lançadas. A métrica captura uma atividade fácil de registrar e deixa de fora o trabalho menos visível, como remover complexidade, impedir uma mudança perigosa ou concluir que uma feature não deveria ser construída.

Com agentes, essa distorção ganha velocidade. Um engenheiro consegue abrir vários pull requests durante o dia e acumular sinais claros de produção. O colega que passa horas revisando uma dessas mudanças, encontra um risco e pede que ela seja refeita termina o mesmo dia com menos entregas registradas.

Quem revisa perde a corrida

Orosz relata que engenheiros responsáveis por revisões cuidadosas estão ficando sobrecarregados. Eles recebem mais mudanças, encontram código duplicado, contestam decisões e devolvem pull requests que já passaram por revisores automáticos. Ao fim do ciclo, aparecem como as pessoas que dificultaram o fluxo, enquanto quem enviou mais alterações ocupa o lado positivo do dashboard.

A revisão sempre dependeu de um acordo social. O autor aceita que outra pessoa questione seu trabalho, o revisor dedica tempo a uma tarefa que não receberá seu nome e a liderança protege essa fricção porque sabe que velocidade sem contestação cobra a conta depois.

A geração automática altera esse acordo. É mais difícil pedir que alguém passe quarenta minutos entendendo uma mudança que levou quatro minutos para ser produzida, principalmente quando outras quinze já estão esperando. O custo psicológico também muda: o autor tem menos apego ao código, mas o revisor continua assumindo a responsabilidade de aprová-lo.

Empresas estão tentando resolver o volume com mais revisão automática. A decisão funciona para erros detectáveis por regras, padrões conhecidos e testes existentes. O agente encontra uma função sem cobertura ou uma biblioteca vulnerável; ele tem mais dificuldade para perceber que o comportamento tecnicamente correto contradiz uma decisão tomada pelo time de operações depois de um incidente que nunca virou documentação.

Essa é a parte em que experiência ganha valor. O engenheiro sênior reconhece o risco porque já viu uma solução parecida falhar, conhece a história do serviço ou sabe qual pergunta fazer antes de aprovar. O problema é que esse trabalho produz poucos artefatos visíveis. Ele aparece na mudança que não chegou à produção e no incidente que nunca aconteceu.

Os números de Cursor e Linear provavelmente continuarão subindo. Teremos mais código, pull requests maiores e agentes capazes de assumir partes cada vez mais longas do desenvolvimento. A atenção humana continuará limitada, embora os dashboards de adoção tenham pouca razão para registrar esse limite.

No próximo ciclo de performance, o engenheiro com vinte pull requests terá vinte entregas para apresentar. O colega que bloqueou duas delas antes que causassem um incidente terá uma semana com menos produção. O dashboard consegue contar o código que entrou; as falhas que alguém impediu continuam sem uma linha própria na planilha.

---

Produto bom nasce de conversa com cliente, mas ninguém aguenta transformar cada dúvida em reunião. A ReveLumi faz pesquisa qualitativa pelo WhatsApp, organiza as respostas e ajuda seu time a chegar mais rápido no que realmente importa.

Conheça em https://productgurus.short.gy/miSFA2