> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2026/w13-meituans-q4-earnings-and-why-the-ai-era-needs-a-unified-efficient-toolchain.md).

# W13-Resultados da Meituan no Q4 e a necessidade de ferramentas unificadas e eficientes na era da IA

No ano passado, eu lia os resultados de cada trimestre e escrevia uma revisão, combinando-os com textos de canais públicos do WeChat. Neste ano, esse trabalho também pode ser automatizado pelas tarefas agendadas do Cowork. Hoje a IA consegue buscar informações, analisar, organizar e publicar no Xuecheng por conta própria, com uma qualidade muito superior à que eu alcançaria sozinho. A cada trimestre, vou acrescentar as fontes que considerar boas e disparar manualmente a tarefa, mantendo a estrutura de análise estável.

Um objetivo importante da minha análise de resultados é entender como estudar uma empresa de forma objetiva. A Meituan é, neste momento, a empresa que mais vale a pena eu estudar. Nos últimos seis meses, comecei a sentir que estudar a empresa em que se trabalha pode criar pontos cegos. Lá dentro, não sofremos apenas a influência do mercado: temos uma posição própria, ruído local e a tendência a extrapolar linearmente uma parte para o todo. Achamos que trabalhar na empresa significa conhecê-la bem e ter acesso a muitas informações internas. Na prática, muitas informações essenciais chegam primeiro de fora. Um exemplo é o LongCat. Pelo seu desempenho em programação, eu o rejeitei com facilidade no passado. Mas concordo com a tendência de especialização dos modelos. Julgar o LongCat sem estudá-lo com atenção não é um bom hábito de pesquisa. Acho que problemas assim também estão entre as principais diferenças entre um analista de banco de investimento e um comentarista amador de ações.

***

### Por que a era da IA precisa de uma cadeia de ferramentas unificada e eficiente?

Dois acontecimentos da semana passada me fizeram pensar que precisamos levar essa pergunta a sério.

O primeiro foi Evan You continuar promovendo na D2 a cadeia integrada de ferramentas de frontend reescrita em Rust. Sua ideia central é que escrever código deixou de ser o gargalo. A IA precisa verificar e validar seu código continuamente. Se não receber uma cadeia de ferramentas limpa e eficiente, isso impedirá grandes ganhos futuros de produtividade.

O segundo foi o [anúncio da OpenAI de que comprará a Astral](https://openai.com/index/openai-to-acquire-astral/), incorporando ao Codex uma cadeia de ferramentas Python. Em certa medida, a aquisição lembra a [compra do Bun pela Anthropic](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone). A Astral desenvolve uv, um gerenciador de pacotes Python; Ruff, um verificador de código; e ty, um verificador de tipos.

Por coincidência, Jeff Dean também abordou um ponto relacionado na GTC que acabou de ocorrer. A maioria das ferramentas atuais foi projetada para humanos. Nossa interação acontece na escala de segundos; por isso, o tempo de inicialização de um compilador C ou a latência de uma API não eram decisivos. Mas, quando agentes operam cinquenta vezes mais rápido que pessoas, atrasos de milissegundos passam a dominar. Pela Lei de Amdahl, o ganho total de velocidade de um sistema é limitado pela parte que não pode ser acelerada. Se a inferência do modelo leva apenas 100 milissegundos, mas inicializar e chamar as ferramentas leva dois segundos, melhorar o desempenho do modelo quase não contribui para a eficiência de ponta a ponta.

A mesma lógica ajuda a explicar a compra do Bun pela Anthropic. O ponto central não é só o Bun ser mais rápido, mas oferecer um ambiente de execução completo e controlável. Ferramentas tradicionais, como Bash, foram feitas para humanos e transmitem informações por texto. A IA precisa de feedback estruturado, com pouco ruído e fácil de interpretar. Se a própria camada de ferramentas for projetada para agentes, os custos de alinhamento de contexto e correção de erros caem bastante.

Hoje, reúno esses acontecimentos sob a ideia de Harness Engineering. Sua essência é projetar um harness melhor: com contexto e ferramentas limitados, fazer um grupo de agentes e poucas pessoas formarem um sistema de engenharia controlável, verificável e escalável.

A IA gera código rapidamente, mas não acerta tudo na primeira tentativa. O processo real envolve chamadas repetidas a ferramentas: instalar dependências, compilar, executar lint, verificar tipos, rodar testes e executar programas. Se essa cadeia for lenta, fragmentada e imprevisível, a maior parte do tempo será consumida por espera e incerteza.

Por isso, ao avaliar uma engenharia AI-ready, vale perguntar se existe uma cadeia de ferramentas limpa, rápida e unificada que sustente a execução contínua dos agentes.