O gargalo mudou de lugar: a conta da produtividade com IA no caso da Linear

Em 21 de setembro, a Linear publicou um relato de engenharia com uma conta pouco confortável.

Desde o início de 2026, os conjuntos de teste automatizado da empresa quase quadruplicaram. Entram cerca de 2.000 testes novos por semana e, segundo a publicação, os agentes de codificação escrevem a maior parte deles. Para dar conta desse volume, o time passou boa parte de um trimestre reconstruindo a esteira de validação — a integração contínua, ou CI, o conjunto de verificações automáticas que roda a cada alteração de código antes de ela ser aprovada.

O resultado, na ponta em que o desenvolvedor sente: a espera por um pull request caiu de mais de 6 minutos para pouco mais de 5, conforme o relato publicado pela própria Linear.

Um minuto.

Essa é a parte que interessa a quem não escreve código. Uma empresa de software acelerou muito a produção com inteligência artificial, investiu um trimestre de engenharia qualificada na etapa seguinte do fluxo e terminou praticamente no mesmo patamar de experiência.

O que a empresa relata ter feito

Os números abaixo são autorreportados pela Linear, sem auditoria independente, e descrevem intervenções técnicas específicas:

• Troca de infraestrutura: a saída do runner padrão para runners de terceiros — as máquinas que executam as verificações — deixou os jobs 34% mais rápidos em média, com algumas cargas, como a verificação de tipos, caindo 52%.

• Troca de compilador: a adoção do tsgo, compilador nativo de TypeScript, cortou em 73% a mediana semanal dessa mesma verificação.

• Detecção de mudanças: a etapa que identifica o que precisa ser testado teve a mediana reduzida de 26 para 8 segundos.

• Preparação de ambiente: o setup por shard, cada fatia paralela da bateria de testes, caiu de 110–140 segundos para 67–73 segundos, uma redução de cerca de 44%. O número de fatias passou de quatro para oito.

• Tempo total de máquina: os shards de teste da API caíram de cerca de 32,8 para 22 minutos de runner por execução.

• Agrupamento de execuções: uma mudança de batching economizou cerca de 87.000 runner-minutos por mês, o que a publicação estima em torno de 12% do consumo total de CI.

São ganhos grandes, medidos e plausíveis. Não é um caso de otimização mal feita.

A aritmética que o resumo esconde

Se cada peça melhorou entre 34% e 73%, por que a espera final caiu só um minuto?

Porque o denominador cresceu junto. A própria empresa dá a chave: sem essas otimizações, o conjunto de testes de hoje levaria cerca de 11 minutos — quase o dobro do que o desenvolvedor espera agora.

Isso reposiciona o investimento. A engenharia não comprou um ganho de um minuto. Ela comprou seis minutos de perda evitada, e sobrou um. O trimestre de trabalho foi defensivo antes de ser ofensivo.

É uma leitura desconfortável para quem aprova orçamento de produtividade, e é a leitura correta. Parte relevante do que se gasta hoje em "eficiência com IA" não produz ganho novo: impede que o ganho da etapa anterior seja devolvido na etapa seguinte.

Não é um caso isolado

Uma semana antes, em 14 de setembro, a Anthropic publicou um relato com a mesma forma. Segundo a publicação de engenharia da empresa, o volume de jobs de CI aumentou 25 vezes em seis meses e o número de testes no código cresceu 10 vezes, enquanto o time de engenharia crescia pouco. A empresa afirma que seus engenheiros entregam, em média, 8 vezes mais código por trimestre do que entregavam entre 2021 e 2025, e que o Claude é autor de 80% desse código.

A resposta da Anthropic foi diferente da resposta da Linear. Em vez de acelerar a execução de todos os testes, a empresa descreve ter investido em um serviço de análise de impacto de testes: um mecanismo que decide quais testes precisam rodar a cada alteração, em vez de rodar tudo sempre.

Duas empresas, dois caminhos técnicos, o mesmo diagnóstico. Vale registrar o viés: as duas têm interesse comercial e reputacional em contar essa história, e as duas são as únicas fontes dos próprios números. Dois casos indicam uma direção. Não estabelecem uma regra de mercado.

O padrão não é de software

Aqui está o que transfere.

Em qualquer operação, existe uma etapa que gera e uma etapa que aprova. A inteligência artificial, hoje, é muito melhor em acelerar a primeira do que a segunda. Quando isso acontece e ninguém mexe no desenho do fluxo, o ganho não some: ele se transforma em fila na etapa seguinte.

O formato se repete fora da engenharia de software:

• Comercial: propostas passam a ser montadas em minutos, mas a aprovação jurídica continua dependendo das mesmas duas pessoas e dos mesmos três dias.

• Marketing: o volume de peças produzidas multiplica, e a revisão de marca vira o posto único por onde tudo precisa passar.

• Crédito: o funil de entrada cresce com automação de captação, e a análise de risco continua com a mesma equipe e o mesmo comitê semanal.

• Serviços técnicos: laudos e relatórios são gerados mais rápido, mas a validação exige assinatura de um profissional habilitado, que não multiplica.

Há uma característica comum às etapas que engargalam: quase sempre são aquelas em que alguém assume responsabilidade formal. Aprovar, assinar, responder. Capacidade de geração escala com ferramenta. Capacidade de verificação escala com atenção humana, alçada e risco — três coisas que não se compram por assinatura mensal.

O custo aparece na conta errada

Há um efeito financeiro que costuma passar despercebido.

Quando o volume de geração multiplica, a infraestrutura de validação vira linha de custo relevante. Na Linear, uma única mudança de agrupamento liberou 87.000 runner-minutos por mês. Fora do software, o equivalente é horas extras na revisão, contratação na área que virou gargalo, prazo estourado que vira desconto comercial.

O ganho e o custo raramente moram no mesmo centro de custo. A área que acelerou comemora. A área seguinte pede orçamento. E a diretoria, olhando o consolidado, conclui que o projeto de IA "não deu resultado" — quando o resultado existiu e foi consumido duas casas adiante no fluxo.

O limite que nenhuma das duas resolveu

Vale separar o que os dois relatos atacam do que eles não atacam.

Ambos tratam de tempo de espera e de custo de máquina. Nenhum deles afirma ter resolvido a questão de fundo: mais código produzido em menos tempo significa mais superfície para revisar, com menos contexto humano acumulado por linha escrita. Otimizar a validação faz a fila andar. Não responde quem entende o que está passando por ela, nem quem responde quando algo quebra.

Não há, nas duas publicações, dado sobre taxa de defeito em produção nesse novo regime. Sem isso, não é possível concluir nada sobre qualidade — nem a favor, nem contra. É uma lacuna que vale acompanhar nos próximos relatos do setor, e um bom motivo para desconfiar de qualquer leitura que trate velocidade de entrega como prova de saúde do processo.

A pergunta que muda o diagnóstico

A maioria dos projetos de automação que chegam até nós começa pela pergunta errada: onde eu posso usar IA?

A pergunta que muda o resultado é outra. Qual é a etapa de menor capacidade do meu processo hoje — e o que acontece com ela se a etapa anterior triplicar de volume?

Automatizar uma etapa sem redesenhar o fluxo não elimina a fila. Muda a fila de lugar, geralmente para um lugar mais caro, mais lento e menos visível no painel de indicadores.

Quatro perguntas antes de automatizar uma etapa

1. Qual etapa tem a menor capacidade hoje, medida em itens processados por semana — e não em esforço percebido por quem trabalha nela?

2. Se a etapa anterior dobrar de volume em 90 dias, qual vira o tempo de fila dessa etapa?

3. O gargalo existe por falta de ferramenta ou por exigir responsabilidade humana? São problemas diferentes, com soluções diferentes: o primeiro se resolve com tecnologia, o segundo com alçada, critério e redesenho de quem decide o quê.

4. Quem paga o aumento de capacidade da etapa seguinte — e esse custo está no mesmo orçamento que contabilizou o ganho?

A Linear gastou um trimestre de engenharia para ganhar um minuto. Lido de fora, parece pouco. Lido corretamente, é o contrário: sem esse trimestre, a empresa teria perdido seis.

O ganho de produtividade com inteligência artificial existe. Ele só quase nunca está onde a empresa está olhando.

Lincoln Ferraz é Arquiteto de Negócios e fundador da ASTX — Design de Negócios e Inovação.