Toda ideia consolidada tem prazo de validade

O git era a ideia mais consolidada do software. Vinte e um anos, tão dominante que "git" e "controle de versão" viraram sinônimos, costurado dentro de todo sistema de CI, todo IDE e na memória muscular de qualquer dev em atividade. E então, em quatro meses, ele parou de ser a resposta certa dentro da Anthropic — não porque estivesse errado, mas porque a única condição em torno da qual ele foi desenhado se multiplicou por doze. É essa a forma que a obsolescência realmente tem. Ela não chega nas coisas que estão quebradas. Ela chega nas coisas que ainda funcionam.

O que quebrou não estava quebrado

O git não falhou. Ele fez exatamente aquilo pra que foi construído: dar a cada cliente uma cópia completa e offline do histórico, pra que um grupo distribuído de pessoas com conexão ruim pudesse trabalhar de forma independente. Esse desenho estava correto em 2005 e continua correto pra quase todo mundo que está lendo isso.

O que mudou é que os clientes da Anthropic deixaram de ser pessoas. A maioria virou job de CI e agente de código — sempre online, sem precisar de cópia local de nada. Os merges diários saíram de 2.500 pra mais de 30.000 entre maio e setembro de 2026. A premissa embaixo do git — que o recurso caro e escasso é conectividade, e o barato e abundante é disco local e paciência humana — simplesmente se inverteu. O detalhe de engenharia é uma história à parte; o que importa aqui é o mecanismo.

Toda ideia consolidada é uma aposta numa condição. O git apostou em clientes offline-first. A aposta deu certo por duas décadas. Ninguém percebeu que era uma aposta, porque quando uma aposta continua pagando ela para de parecer aposta e começa a parecer lei.

A obsolescência não se anuncia

É essa a parte difícil de ver chegando. Uma coisa que falha se anuncia: ela cai, dá prejuízo, as pessoas reclamam. Uma coisa obsoleta se comporta perfeitamente e silenciosamente vira o teto.

A merge queue da Anthropic não estava quebrada. Funcionava precisamente como projetada, serializando cada mudança pra que cada uma fosse testada contra o estado exato em que ia cair. Isso é uma best practice de verdade. E, a 30.000 merges por dia, virou a única coisa limitando o throughput de toda a organização de engenharia, não importa o quanto o que vinha antes ficasse rápido.

Então o sinal a observar não é falha. É este: aquilo em que você tem mais confiança virou aquilo que você fica esperando. Quando o seu processo mais maduro é também a sua fila mais longa, o que você tem na frente não é um problema de execução. É uma premissa vencida.

Separe a necessidade da implementação

Essa é a distinção que quase todo mundo nessa conversa esmaga — nas duas direções.

A necessidade que o git atende é permanente: saber quem mudou o quê e conseguir voltar atrás. Essa necessidade não vai a lugar nenhum, nunca. A implementação — clone local completo, offline-first, um packfile em cada notebook — sempre foi condicional. A Anthropic manteve a necessidade e jogou a implementação fora.

Quase todo argumento sobre o que a IA está fazendo com o trabalho inverte isso. O pânico trata uma implementação condicional como se fosse a necessidade ("se ninguém digita o código, acabou a engenharia"). A negação faz a mesma coisa pelo outro lado ("code review sempre funcionou, então sempre vai funcionar"). As duas estão defendendo uma implementação e chamando isso de princípio.

Veja o que essa distinção faz com as coisas em cima das quais a nossa vida de trabalho foi construída:

A coluna da esquerda está a salvo. A da direita é um conjunto de proxies inventados porque a coluna da esquerda era difícil de observar direto. Currículo existe porque o seu trabalho de verdade era invisível pra um estranho. Anos de experiência existe porque julgamento acumula devagar e não dá pra inspecionar. Headcount como capacidade existe porque a entrega era mais ou menos proporcional a gente.

Cada um desses proxies foi uma aposta razoável numa condição. Várias dessas condições estão se movendo agora, e os proxies não estão indo junto.

Três perguntas que separam o durável do vencido

Nem tudo que é consolidado está vencendo — e isso importa, porque a maioria das coisas duráveis é durável por bons motivos. O git ganhou vinte e um anos de forma honesta. Então o que vem aqui é um teste, não uma profecia. Pra qualquer coisa de que você depende:

1. Você ainda consegue nomear a condição pra qual aquilo foi desenhado? Se não consegue — se a resposta é "é assim que se faz" — você não está seguindo um princípio, está mantendo um fóssil. A incapacidade de enunciar o trade-off original é o sinal mais claro.
2. Essa condição se moveu, e em que direção? Direção importa mais que magnitude. Mudança reversível é ruído. Mudança de mão única — o custo de gerar código, o custo de guardar dado, o custo de abrir uma empresa — é a que aposenta ideias.
3. Aquilo ainda te habilita ou já te limita? Habilitar é você andar mais rápido por causa daquilo. Limitar é você ficar esperando por aquilo. A transição entre os dois estados é exatamente onde a obsolescência mora, e nada cai pra marcar o momento.

Rode essas três numa merge queue dentro de um repo cheio de agentes e a resposta é óbvia. Rode num processo de contratação que filtra quem digita código rápido e a resposta também é óbvia — só é menos confortável.

Como isso aparece quando é a sua carreira

A versão honesta desse argumento não é "tudo que você sabe não vale nada". É mais estreita e mais útil: o conceito em cima do qual você construiu sua identidade provavelmente era um proxy, e proxy vence mais rápido que necessidade.

"Eu sou engenheiro de backend" é uma identidade construída sobre uma tarefa. "Eu sei o que vai quebrar às 3 da manhã e percebo quando um design está mentindo" é uma identidade construída sobre uma capacidade. A primeira é um proxy da segunda, e foi um proxy decente por vinte anos. Virou um proxy pior a cada trimestre.

A evidência mais clara que a gente viu é o relato da própria Anthropic sobre o time do Scion. Todos os engenheiros do time diriam hoje que o Claude escreve código melhor que eles. O valor deles estava em julgamento de design, em entender como os sistemas interagem e — nas palavras deles — em dizer "não" pro modelo quando ele violava uma restrição. Isso não é engenheiro tornado redundante por uma ferramenta. É a mesma necessidade atendida por uma implementação radicalmente diferente, e o cargo no crachá não mudou pra refletir isso.

É por isso que a gente organiza a prática em torno de capacidades e não de cadeiras, e por isso "construímos produtos construindo pessoas" é uma afirmação sobre durabilidade, não sentimento. A gente escreveu sobre o rearranjo específico dos papéis de produto em quem leva pra produção quando o protótipo é de graça. Isso aqui é a camada debaixo: papel também é implementação.

O que não concluir

Três guarda-corpos, porque esse argumento é fácil de aplicar demais:

• A maioria das coisas consolidadas está bem. O teste acima vai devolver "durável" muito mais vezes que "vencido". Partidas dobradas têm quinhentos anos e não vão a lugar nenhum. Idade não é evidência de obsolescência.
• Estar adiantado é indistinguível de estar errado, por um tempo. A Anthropic trocou o git porque já havia batido na parede, não porque previu uma. Aposentar uma prática que funciona antes de a condição realmente se mover é só agitação com vocabulário melhor.
• A necessidade é a sua âncora. Quando você aposenta uma implementação, nomeie a necessidade que ela atendia e substitua de propósito. A Anthropic abandonou a merge queue e colocou resolução automática de conflito e teste pós-merge no lugar. Não abandonou a necessidade de uma branch principal confiável.

Principais conclusões

• A obsolescência chega nas coisas que ainda funcionam. Um processo que falha se anuncia; um processo vencido funciona perfeitamente e silenciosamente vira o seu teto.
• Toda ideia consolidada é uma aposta numa condição. Quando a aposta continua pagando, as pessoas param de vê-la como aposta e passam a tratá-la como lei.
• Separe a necessidade permanente da implementação condicional. Quase todo argumento sobre IA e trabalho defende uma implementação chamando ela de princípio.
• As coisas em cima das quais nossas carreiras foram construídas — cargo, currículo, anos de experiência, headcount como capacidade — são proxies inventados porque a coisa real era difícil de observar. Proxy vence mais rápido que necessidade.
• Teste o que você usa com três perguntas: você sabe nomear a condição que aquilo assumia, essa condição se moveu em mão única, e aquilo hoje te habilita ou te limita?
• Idade não é evidência de obsolescência, e aposentar uma prática antes de a condição se mover é só agitação.

FAQ

O que a Anthropic trocar o git tem a ver com algo fora da engenharia?

O mecanismo, não o assunto. O git era a ferramenta mais consolidada do software e foi aposentado dentro de uma organização em quatro meses — não por ser ruim, mas porque uma única condição que ele assumia se multiplicou por doze. Qualquer ideia de que você depende está apoiada numa condição parecida. A lição é saber qual.

Como eu diferencio uma prática obsoleta de uma durável?

Pergunte se você ainda consegue nomear a condição pra qual ela foi desenhada, se essa condição se moveu em uma só direção e se a prática hoje te deixa mais rápido ou te deixa esperando. Prática durável sobrevive às três perguntas. Fóssil cai na primeira.

Isso quer dizer que cargo e diploma não valem mais nada?

Não. Quer dizer que eles são proxies, não necessidades. A necessidade que eles atendem — demonstrar que você é confiável pra um trabalho de consequência — é permanente. O proxy foi inventado porque isso era difícil de observar direto, e ele degrada à medida que o trabalho embaixo muda de forma. Construa a capacidade; trate a credencial como recibo, não como o ativo.

Isso não é só dizer que tudo está mudando?

É o contrário. A maioria das coisas consolidadas é consolidada por bons motivos, e o teste acima normalmente vai te dizer pra deixar aquilo em paz. O ponto é que "funciona há muito tempo" não é um argumento, e o desconforto de examinar aquilo não é prova de que está de pé.

Qual é a primeira coisa a examinar?

Aquilo em que você tem mais confiança e que também tem uma fila na frente. Confiança mais fila de espera é a assinatura de uma premissa que venceu enquanto ninguém olhava.