Agentes IA optimizan código: predicción CEO Shopify
Tobi Lütke, CEO de Shopify, usó agentes IA (pi-autoresearch) para optimizar el engine de templates Liquid y logró un 53% de mejora de velocidad en benchmarks. Pero el código resultante es ilegible, poco mantenible, y probablemente nunca se mergee ni cierre—quedará abierto para siempre en el limbo técnico y político.
En 30 segundos
- Tobi Lütke, CEO de Shopify, creó un agente IA llamado pi-autoresearch para optimizar automáticamente Liquid (el template engine de Shopify), ejecutando ~120 experimentos en 93 commits.
- Los benchmarks muestran mejoras concretas: 53% más rápido, 61% menos asignaciones de memoria, con solo 3 tests fallando de 4,192.
- El código generado es poco legible e ilegible para humanos—optimizaciones confusas, patrones no idiomáticos, deuda técnica potencial.
- La predicción de Josh Moody (del equipo): el PR nunca será mergeado ni cerrado. Quedará abierto indefinidamente por dinámica social (nadie rechaza al CEO) + técnica (código de calidad insuficiente).
- Plantea preguntas sobre el rol de IA en optimización: ¿velocidad vs mantenibilidad? ¿Cuándo confiar en código generado automáticamente?
Qué es Liquid y por qué Shopify le cura cada bajada de rendimiento
Liquid es el template engine que Shopify usa para renderizar dinámicamente las tiendas en línea. Cuando un cliente abre su ecommerce, Liquid es lo que procesa las variables, los loops, los condicionales y las funciones custom que convierte un template estático en una página viva. Funciona en 5.6 millones de tiendas activas en todo el mundo.
Ponele que vos sos dueño de una tienda en Shopify y querés mostrar una lista de productos con descuentos condicionados. Eso que ves renderizado en 500 milisegundos—en vez de 2 segundos—es gracias a Liquid. Una mejora del 50% en parsing, iteración o evaluación de expresiones no es un “nice to have”: impacta la experiencia de millones de usuarios, menos latencia, menos carga en los servidores, menos dinero gastado en infra.
Por eso cuando Tobi Lütke dice “optimicemos Liquid con agentes IA”, los números hablan solo. (Sí, en serio: un CEO actual de una empresa de US$14 mil millones está escribiendo commits de optimización de código, no en una reunión de marketing.)
El experimento: 120 iteraciones de IA vs un template engine de 20 años
La historia arranca cuando Tobi Lütke, junto con David Cortés (de su equipo), diseña pi-autoresearch: un agente IA que no solo sugiere optimizaciones, sino que las implementa, las prueba, mide el impacto, y repite. Automáticamente.
El proceso: el agente ejecuta benchmarks locales, identifica cuellos de botella en el código Ruby de Liquid, propone cambios, corre la suite de tests (4,192 tests en total), mide el ThemeRunner benchmark (que simula tiendas reales), registra el resultado, y vuelve a iterar si hay ganancia.
En ~120 experimentos, el agente llegó a 93 commits útiles. Algunos no dejaban ganancia, otros rompían tests, pero la tendencia fue clara: el rendering se aceleró. Mucho.
Los números: 53% más rápido es exactamente lo que dice, pero con letra chica
El benchmark ThemeRunner mide el tiempo que tarda Liquid en renderizar tiendas de verdad (datos reales de stores de producción). Con las optimizaciones del agente: Cubrimos ese tema en detalle en plataformas de control de versiones modernas.
| Métrica | Baseline | Con IA | Mejora |
|---|---|---|---|
| Tiempo de render (ThemeRunner) | 1.0x | 0.47x | 53% más rápido |
| Asignaciones de memoria | 1.0x | 0.39x | 61% menos allocations |
| Tests fallando | 0 de 4,192 | 3 de 4,192 | 99.93% pass rate |
| Commits útiles | — | 93 | De 120 experimentos |
Ahora la letra chica. Tobi lo admitió él mismo en HackerNews: el benchmark probablemente está “somewhat overfit” a los casos de uso que el agente vio. En producción, con patrones de template más variados, la ganancia real podría ser más baja. No 53%, quizás 30-40%.
Eso sí, incluso con descuento por overfitting, una aceleración del 30% en un template engine que renderiza 5.6 millones de tiendas es **una mierda de ganancia** (que no es poco). Menos garbage collection, menos latencia, mejor UX, menores costos operacionales.
El drama: el código es un laberinto donde solo la IA se orienta
Acá viene el conflicto. El código que el agente escribió es ilegible.
No es que sea complicado—es que es optimizaciones microadas, patrones contraintuitivos, reordenamientos confusos que solo tienen sentido en el contexto del benchmark específico que el agente estaba optimizando. Un developer humano leería ese código y se preguntaría “¿por qué esta línea está acá?” Y la respuesta sería: “porque el agente descubrió que mejora 0.003% el caché hit rate en este escenario específico.”
La pregunta técnica legítima es: ¿un equipo puede mantener código que ni entiende? ¿Qué pasa en 6 meses cuando hay que parchear un bug y tocás una línea “optimizada” que rompe todo?
Luego viene lo político. El PR está abierto en GitHub. Tobi es el CEO. Nadie en la empresa tiene los “guts” para decir “rechazo esto” (si es que lo hace). Pero la calidad del código no pasa ningún quality gate estricto. Es ese dilema clásico: demasiado bueno para rechazar, demasiado malo para mergear.
La predicción de Josh Moody: un PR en el limbo eterno
Josh Moody, del equipo que mantiene Liquid, hizo una predicción audaz: ese PR nunca será mergeado ni cerrado. Quedará abierto. Para siempre. En el backlog invisible.
¿Por qué? Porque mergear código ilegible en un sistema crítico para 5.6 millones de tiendas es un riesgo técnico. Pero rechazar públicamente una propuesta del CEO es un riesgo político. Así que la solución más segura es hacer nada: admitir que es impresionante (porque lo es), dejar el PR abierto como “research”, y que nadie toque nada.
Es una profecía que podría ser cierta. Y es un avance interesante sobre cómo las organizaciones modernas navegan la tensión entre optimización automática y responsabilidad humana.
Herramientas similares: dónde está la IA en optimización de código
pi-autoresearch no es el único agente que intenta optimizar código automáticamente. El espacio está creciendo: Complementá con protección en repositorios públicos.
| Herramienta | Enfoque | Entrada | Salida |
|---|---|---|---|
| pi-autoresearch (Shopify) | Búsqueda experimental de optimizaciones | Código + benchmarks | Commits optimizados (ilegibles) |
| Claude Code (Anthropic) | Refactoring guiado + sugerencias | Código + contexto | Cambios legibles, auditable |
| GitHub Copilot | Generación de código basada en context | Comentarios + patrón | Código sugerido (requiere review) |
| DeepSeek (optimización) | Análisis estático + profiling | Código | Reportes + sugerencias legibles |
| Herramientas clásicas (py-spy, Flamegraph) | Profiling humano | Ejecución | Gráficos de call stack |
La diferencia clave: pi-autoresearch es **experimental**. No te da sugerencias legibles—te da código optimizado que funciona, pero que requiere análisis inverso para entender. Las herramientas más maduras (Copilot, Claude Code) buscan un balance: mejora + legibilidad + auditabilidad.
Errores comunes que evitar al usar IA para optimizar código
1. Optimizar sin benchmarks previos
Mucha gente usa agentes IA para “optimizar” código sin medir antes. Tobi es el opuesto: tenía benchmarks (ThemeRunner), sabía el baseline, comparaba iteración a iteración. Si vos usás IA para optimizar sin saber qué estás optimizando, puede que hagas cambios que mejoran un escenario y rompen otro.
2. Confundir ilegibilidad con “optimización avanzada”
El hecho de que el código sea ilegible no lo hace correcto ni mantenible. Algunos developers ven “código ilegible = optimizado a nivel microscópico” y lo aceptan. Error. A menudo es solo ruido. Un buen agente debería poder producir código ilegible *y* documentar por qué es así.
3. No validar en producción
Los benchmarks de Liquid (ThemeRunner) usan datos reales, pero aún así Tobi admitió overfitting. Si vos optimizás código con un agente, tenés que probar en canario o staging *antes* de rollout global. Si solo probás en el benchmark que el agente vio, vas a tener sorpresas feas.
¿Cuándo confiar en IA para optimizar? Guía práctica
Esto es lo que el caso de Shopify enseña:
USÁ IA para optimización si:
- Tenés benchmarks claros y repetibles
- El costo de un cambio roto es bajo (feature flag, feature en beta)
- Un humano puede revisar y entender el cambio (que sea auditable)
- Optimizás en el margen (10-20%), no buscás un moonshot
NO USES IA si:
- Necesitás que el código sea mantenible por otros
- Cambios defectuosos impactan producción inmediatamente
- No tenés métricas claras de éxito
- El resultado debe ser código idiomático en tu stack (porque IA genera código extraño)
Confirmado vs pendiente
✓ Confirmado
- Tobi Lütke experimentó con agentes IA (pi-autoresearch) para optimizar Liquid
- Los benchmarks muestran 53% de mejora en ThemeRunner, 61% menos allocations
- El código generado es poco legible e ilegible para humanos
- El PR está abierto en GitHub (PR #2056)
- 3 de 4,192 tests fallan con el código optimizado
? Pendiente / Especulativo
- Si el PR será mergeado o no (es la predicción de Josh Moody)
- Cómo se comportará el código en producción real (si el benchmark está overfit o no)
- Si Shopify establecerá nuevos estándares de “código generado por IA aceptable” o rechazará esto
Preguntas Frecuentes
¿Qué es pi-autoresearch exactamente?
Es un agente IA creado por Tobi Lütke y David Cortés que automatiza la búsqueda experimental de optimizaciones. Lee código, propone cambios, mide impacto contra benchmarks, y repite. No te pide permiso en cada paso—solo devuelve los commits que funcionan.
¿Por qué 53% más rápido pero 3 tests rotos?
Los benchmarks miden velocidad de render. Los tests validan comportamiento. Es posible que el agente haya encontrado “atajos” que aceleran el caso típico pero rompen edge cases que los tests cubren. Tobi lo sabe—por eso el PR no está mergeado aún.
¿Puedo usar esto en mi proyecto?
No es open source todavía. Pero la idea—agentes IA que buscan optimizaciones experimentalmente—es replicable si tenés: (1) benchmarks claros, (2) tests exhaustivos, (3) un agente IA que pueda escribir código (Claude, GPT-4, DeepSeek). No es trivial, pero es posible.
¿Quién decide si el PR se mergea?
Técnicamente, el equipo de mantenedores de Liquid. Políticamente, es complicado porque es el CEO quien lo propone. La predicción es que quedará abierto “indefinidamente” porque rechazarlo es incómodo, pero mergearlo también. En flujos de trabajo en desarrollo de software profundizamos sobre esto.
¿Esto significa que los developers van a ser reemplazados por IA?
No. Lo que ves acá es IA haciendo búsqueda microscópica de micro-optimizaciones en un dominio super específico (un template engine con 20 años de historia). Un developer sigue siendo necesario para diseñar, auditar, mantener, y tomar decisiones sobre qué optimizar. IA acelera la búsqueda, pero no reemplaza el criterio humano.
¿Hacia dónde va esto? Lo que significa para el futuro
El caso de Shopify es un primer experimento en la intersección de: (1) agentes IA que pueden ejecutar código, (2) optimización automática, (3) procesos de review en empresas grandes.
Dos escenarios probables:
Escenario A: Las herramientas mejoran. En 2 años, agentes IA como pi-autoresearch no solo optimizan, sino que *explican* sus cambios en lenguaje natural. Entonces el código ilegible se acompaña de documentación generada por IA que lo justifica. Eso resuelve el problema de mantenibilidad.
Escenario B: Las empresas establecen quality gates más estrictos. “Si la IA lo genera, tiene que ser auditable por humanos” se vuelve estándar. Muchos cambios micro-optimizados se rechazan porque no pasan esa prueba.
Lo probable es una mezcla: agentes IA optimizando sistemas no-críticos u en-beta, mientras que en producción estricta el bar es “optimización legible + auditable”.
Para vos como developer: si alguien te propone usar IA para optimizar, pedí benchmarks, pedí tests, pedí auditabilidad. No des por sentado que “53% más rápido” = “bueno para producción”. Tobi lo sabe. Josh Moody lo sabe. Vos también deberías.
Conclusión
El experimento de Tobi Lütke es brillante y problemático a la vez. Brillante porque demuestra que agentes IA pueden descubrir optimizaciones legítimas en código complejo. Problemático porque produce código que solo máquinas pueden mantener.
La predicción de que el PR quedará en el limbo eterno probablemente sea acertada—no porque sea “malo”, sino porque expone una tensión real en la ingeniería moderna: cuando optimización automática choca con responsabilidad humana, alguien pierde.
La lección para vos: IA es una herramienta de exploración y aceleración. No es un sustituto del criterio. Si usás agentes IA para optimizar, mantené el control: benchmarks claros, tests exhaustivos, código auditable. Velocidad sin mantenibilidad es deuda técnica con interés compuesto.
