> 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/es/2026/w13-meituans-q4-earnings-and-why-the-ai-era-needs-a-unified-efficient-toolchain.md).

# W13-Resultados de Meituan Q4 y por qué la IA exige una cadena de herramientas unificada y eficiente

El año pasado leía los resultados cada trimestre y escribía un balance apoyándome también en el contenido de las cuentas públicas. Este año puedo automatizar ese trabajo con Schedule de Cowork. La IA ya puede recopilar información, analizarla, organizarla y publicarla en Xuecheng de forma autónoma, con una calidad mucho mayor que la que consigo yo. A partir de ahora incorporaré cada trimestre las fuentes que considere buenas y ejecutaré Schedule manualmente, manteniendo estable el marco de análisis.

Uno de mis principales objetivos al analizar resultados es aprender a estudiar una empresa de forma objetiva. En esta etapa, Meituan es la compañía que más me interesa investigar. Durante el último medio año he tenido una sensación: estudiar una empresa desde dentro puede generar puntos ciegos precisamente en lo que tenemos más cerca. Dentro de la compañía no solo nos influye el mercado. Tenemos una posición propia, ruido local y una tendencia a extrapolar linealmente desde una parte al conjunto. Creemos que estar dentro nos permite conocer bien la empresa y acceder a mucha información interna. Sin embargo, a menudo obtenemos primero desde fuera información clave. LongCat es un ejemplo. Lo había descartado con demasiada facilidad por su rendimiento en programación. Pero comparto la idea de que los modelos evolucionan hacia la especialización. Juzgar LongCat sin haberlo estudiado con atención no es un buen hábito de investigación. Creo que este tipo de cuestiones también marca una diferencia central entre un analista de banca de inversión y un comentarista bursátil aficionado.

***

### ¿Por qué la era de la IA necesita una cadena de herramientas unificada y eficiente?

Dos acontecimientos de la semana pasada me hicieron pensar que debía tomar esta pregunta en serio.

El primero fue que Evan You siguió promoviendo en D2 una cadena de herramientas frontend integrada y reescrita en Rust. Su argumento central es que escribir código ya no es el cuello de botella. La IA necesita comprobar y validar continuamente su propio código. Si no podemos ofrecerle una cadena de herramientas limpia y eficiente, eso impedirá que nuestra productividad aumente sustancialmente en el futuro.

El segundo fue [el anuncio de OpenAI de que adquirirá Astral](https://openai.com/index/openai-to-acquire-astral/) e incorporará su conjunto de herramientas Python a Codex. En cierto sentido, la operación se parece a [la adquisición de Bun por Anthropic](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone). Astral desarrolla uv, el gestor de paquetes de Python; Ruff, el analizador de código; y ty, el comprobador de tipos.

Jeff Dean expuso una idea relacionada en la GTC que acaba de terminar. La mayoría de las herramientas actuales se diseñaron para humanos. Nuestra interacción ocurre a escala de segundos, por lo que el tiempo de arranque de un compilador de C o la latencia de respuesta de una API no resultaban decisivos. Pero cuando un agente trabaja 50 veces más rápido que una persona, esos retrasos de milisegundos pasan a dominar el resultado. Según la ley de Amdahl, la aceleración total de un sistema queda limitada por la parte que no puede acelerarse. Si la inferencia del modelo tarda solo 100 milisegundos, pero inicializar e invocar la cadena de herramientas requiere 2 segundos, mejorar el modelo apenas contribuirá a la eficiencia de extremo a extremo.

La misma lógica ayuda a explicar por qué Anthropic adquirió Bun. Lo decisivo no es que Bun sea más rápido, sino que ofrece un entorno de ejecución completo y controlable. Las herramientas tradicionales, como Bash, se diseñaron para personas y transmiten información mediante texto. La IA necesita respuestas estructuradas, con poco ruido y fáciles de interpretar. Si la propia capa de herramientas está diseñada para agentes, el costo de alinear el contexto y corregir errores disminuye de forma notable.

Ahora agrupo estas cuestiones bajo el concepto de Harness Engineering. Su esencia es diseñar un mejor entorno de control para que, con un contexto y unas capacidades de herramientas limitados, un grupo de agentes y unas pocas personas formen un sistema de ingeniería controlable, verificable y ampliable.

La IA puede generar código con rapidez, pero no acertar a la primera. El proceso real consiste en invocar herramientas una y otra vez: instalar dependencias, compilar, ejecutar el linter, comprobar tipos, pasar pruebas y ejecutar programas. Si esta cadena es lenta, fragmentaria e impredecible, la mayor parte del tiempo se consumirá en esperas e incertidumbre.

Por eso, al evaluar si una base de ingeniería está preparada para la IA, conviene comprobar si dispone de una cadena de herramientas limpia, rápida y unificada que permita a los agentes trabajar de forma continua.