En abril de 2026, Bessemer Venture Partners publicó un análisis del playbook interno de ingeniería con IA de Shopify. El artículo circuló durante semanas entre engineering managers, CTOs y fundadores de startups. La lectura compartida fue casi siempre operativa: qué herramientas usan, cómo configuran los agentes, qué métricas miden, cómo definen guardarraíles.

Esa lectura es útil pero incompleta. Cuando uno revisa el playbook desde la perspectiva de Product Management y pedagogía, aparecen dos puntos que casi nadie comentó y que probablemente sean los que más van a cambiar la forma de trabajar de los equipos en los próximos dos años. Uno tiene que ver con cómo se reparte el tiempo del ingeniero. El otro con un riesgo nuevo que todavía no tiene nombre estándar en español: comprehension debt.

Este artículo desarrolla esas dos lecciones, las conecta con la tesis de Learning-Driven Development y cierra con cinco patrones operativos del playbook que conviene revisar incluso si no se implementa la receta completa.

Qué cambia el playbook de Shopify

Para quien no leyó el original, un resumen rápido. Shopify estandarizó un workflow donde los ingenieros trabajan con asistentes de IA como parte central del flujo. Construyeron un LLM proxy interno que enruta requests a distintos modelos según el caso, lo que les permite cambiar de modelo sin tocar el workflow del ingeniero. Definieron guardarraíles explícitos sobre qué pueden hacer los agentes sin supervisión humana. Empezaron a medir cosas distintas: demos semanales y problemas resueltos en lugar de líneas de código y pull requests.

Hasta acá la lectura compartida. Lo que sigue es lo que faltó.

Primera lección. El ratio 70/30 se invirtió

Farhan Thawar, head of engineering de Shopify, lo dice de forma directa en el podcast de Convergence: hace dos años un ingeniero pasaba aproximadamente 70% del tiempo ejecutando código y 30% diseñando, decidiendo, pensando arquitectura. Ese ratio se dio vuelta. Hoy un ingeniero senior productivo pasa cerca del 70% del tiempo decidiendo qué construir, validando demanda, mapeando flujos, eligiendo enfoques. La IA toma el 30% que queda.

Esto suena chico hasta que uno lo traduce a horas. Un ingeniero que antes pasaba 28 horas semanales ejecutando ahora pasa 12. Las otras 16 horas se mueven a actividades que históricamente fueron territorio de PMs, arquitectos y tech leads.

Por qué esto valida la tesis de Learning-Driven Development

Learning-Driven Development sostiene una idea simple. El valor de un equipo de producto está en la calidad de las apuestas que valida y descarta, más que en la cantidad de features que produce. Cada feature shippeada que nadie usa es capital quemado. Cada validación rápida que evita una feature innecesaria es capital preservado.

Durante años esa tesis chocó con un problema práctico: la validación temprana era cara porque ejecutar era caro. Si construir un prototipo costaba dos semanas de un ingeniero senior, la organización terminaba validando con mockups y entrevistas, métodos que tienen techo de fidelidad bajo.

El playbook de Shopify es la primera evidencia operativa a escala de qué pasa cuando ejecutar se vuelve barato. Si un agente puede generar un prototipo funcional en una hora, la validación con código real pasa de ser un lujo a ser el default. La tesis de LDD deja la categoría de preferencia metodológica y se vuelve la forma natural de trabajar.

Qué cambia en la práctica para equipos de producto

Tres cambios concretos.

Primero, el handoff entre PM y engineering pierde sentido como fase separada. Antes el PM escribía un spec, lo pasaba a engineering y esperaba que el equipo construyera. Hoy el PM puede sentarse con un agente y producir el prototipo mientras el spec todavía se está escribiendo. La validación con usuarios ocurre sobre código corriendo en vez de mockups en Figma.

Segundo, la skill central del PM cambia de gestión de roadmap a framing de problemas. Cuando ejecutar es barato, lo escaso es saber qué construir. Los PMs que rinden bien en este contexto saben formular hipótesis precisas, diseñar experimentos limpios y leer evidencia ambigua. Quienes se especializaron en mantener el flujo de Jira van a tener que ampliar el repertorio.

Tercero, la línea entre PM e ingeniero se vuelve borrosa para tareas exploratorias. El rol no desaparece. Lo que cambia es el momento donde aporta valor cada uno. El ingeniero senior cada vez aporta más en decisiones de arquitectura tempranas. El PM cada vez aporta más en validación con prototipos reales.

Segunda lección. Comprehension debt, el riesgo que el artículo viral omitió

El artículo de Bessemer mencionó muchos beneficios y casi ningún riesgo. Farhan, en cambio, en el podcast de Convergence dedica varios minutos a algo que él llama comprehension debt. La idea es la siguiente.

Cuando un equipo delega más y más ejecución a la IA, los ingenieros pasan menos tiempo dentro del código. Eso libera tiempo para decidir y genera un costo oculto: los miembros del equipo dejan de entender los sistemas que mantienen. El código sigue corriendo, los tests siguen pasando, pero la capacidad colectiva de razonar sobre el sistema se erosiona.

Esto es distinto del tech debt clásico. Tech debt vive en el código y se puede refactorizar. Comprehension debt vive en las cabezas y se manifiesta el día que algo se rompe y nadie sabe por qué. El sistema funciona perfectamente hasta que deja de hacerlo, y para ese momento ya nadie tiene los modelos mentales para repararlo.

La guardarraíl de Farhan: entender dos o tres capas por debajo

La heurística que propone Shopify es concreta. Cada ingeniero tiene que entender la arquitectura dos o tres capas por debajo del nivel donde trabaja habitualmente. Si alguien trabaja en la capa de aplicación, tiene que poder explicar qué hace la base de datos y cómo se comunican los servicios. Si trabaja en infraestructura, tiene que poder leer el código de aplicación que la consume.

Dos o tres capas funciona como umbral razonable porque alcanza para diagnosticar problemas reales sin pedirle a todos que entiendan todo. Una sola capa por debajo deja a la gente atrapada en su nivel, sin contexto para tomar decisiones. Cuatro o cinco capas se vuelve aspiracional y nadie lo sostiene en serio.

La aplicación práctica: en cada code review, el revisor tiene que poder responder qué hace el cambio, por qué fue necesario y qué pasaría si fallara la capa de abajo. Cuando no puede, el equipo tiene una señal temprana de que la deuda está creciendo.

El problema pedagógico que comprehension debt abre

Acá la lección se vuelve incómoda para cualquiera que enseñe Product Management o ingeniería.

Cuando un estudiante usa IA para producir un prototipo en una clase de PM, la salida se ve excelente. Mejor que lo que producía hace dos años sin IA. La trampa es que la fluidez del output no se correlaciona con la calidad del pensamiento que lo generó. Un estudiante puede entregar un PRD impecable sin haber entendido el problema que está resolviendo.

Esto cambia la forma de evaluar y la forma de enseñar. Evaluar el deliverable solo deja de funcionar porque el deliverable ya está optimizado por la IA. Hay que evaluar el proceso: qué hipótesis formuló el estudiante antes del prompt, qué descartó del output del modelo y por qué, qué decisiones tomó cuando la IA le devolvió algo incorrecto.

La pregunta pedagógica central también se mueve. Hasta ahora preguntábamos cómo enseñar a usar IA con efectividad. La pregunta que viene es cómo enseñar a no perder criterio cuando la herramienta produce resultados que se ven bien. Esto aplica igual a PMs, ingenieros, diseñadores y cualquier rol cognitivo.

La respuesta corta: forzar momentos de fricción explícita. Pedir que el estudiante critique la salida de la IA antes de seguir. Hacer que defienda decisiones que no escribió personalmente. Mantener actividades sin IA donde la única forma de avanzar es razonar desde primeros principios. El equilibrio fino entre fluidez asistida y criterio propio va a ser la habilidad central de la próxima década.

Los otros patrones del playbook, en una línea cada uno

Cinco puntos del playbook que también vale revisar, aunque no diferencien tanto como los dos anteriores.

Estandarizar la infraestructura y no la herramienta. Shopify enruta todas las requests de IA por un proxy interno propio. Eso les permite cambiar de modelo sin tocar el workflow del ingeniero y mantener control de costos y analytics. En ecosistemas que cambian cada semana, la capa que se estandariza está abajo.

Métricas reales sobre métricas vanidosas. Líneas de código y pull requests son gameables y cada vez menos significativos. Shopify mide demos semanales y problemas resueltos. Farhan estima alrededor de 20% de productividad ganada, atribuida a probar diez enfoques en vez de dos.

Dos patrones de uso de agentes. Para tareas independientes los ingenieros corren múltiples agentes en paralelo, cada uno trabajando en una parte distinta del codebase. Para decisiones arquitectónicas un solo agente entra en loops de crítica extendida, donde genera, critica su propia salida, revisa y vuelve a criticar durante cuarenta y cinco minutos o más.

CLAUDE.md como infraestructura de equipo. Se commitea a git, se comparte entre todos los miembros. La advertencia clave es contraintuitiva: inflarlo con todos los standards empeora el rendimiento porque cada turno paga el costo de leer todo el contexto. Hay que ser quirúrgico.

MCP servers como capa de contexto real. El Shopify AI Toolkit conecta los asistentes a documentación viva y schemas reales de la plataforma. La lección aplica a cualquier dominio: sin contexto de plataforma el agente alucina, con MCP trabaja con datos reales.

Qué hacer el lunes a la mañana

Tres bloques cortos, según el rol del lector.

Si lideras producto, pregúntale a tu equipo en la próxima reunión qué porcentaje de su semana pasa decidiendo qué construir versus ejecutando. Cuando la respuesta sigue siendo 30/70, hay margen para reasignar tiempo. Después pregunta cuál fue la última vez que descartaron una feature antes de empezar a construirla. Cuando nadie recuerda, el problema está en la cultura de validación, más que en la capacidad del equipo.

Si formas PMs o ingenieros, revisa una de tus evaluaciones recientes y pregúntate si un estudiante con IA podría haber producido ese entregable sin entender el problema. Cuando la respuesta es sí, el formato necesita ajuste. Después introduce al menos una actividad por curso donde la IA esté prohibida y la única forma de avanzar sea razonar desde cero.

Si construyes con IA hoy, define dos cosas concretas. Primero, qué puede hacer el agente sin pedir permiso (leer, escribir, correr tests) y qué requiere supervisión humana (push a main, deploys, lectura de secrets). Segundo, qué dos capas por debajo de tu trabajo habitual te exigen entender de verdad. Esa segunda definición funciona como defensa temprana contra comprehension debt.

Conclusión

El playbook de Shopify importa por lo que revela sobre el oficio, más que por la receta concreta. Revela que cuando ejecutar se vuelve barato, la pregunta central de Product Management se mueve. Antes la pregunta era cómo construyo esto bien. Ahora es qué deberíamos construir y cómo sabemos si funciona antes de construirlo a escala.

También revela un riesgo que el optimismo del momento tiende a opacar. Mientras más rápido producimos código que no escribimos, más rápido perdemos la capacidad colectiva de entender lo que producimos. La fluidez tiene un costo y todavía no sabemos pagarlo bien.

La próxima generación de equipos que van a rendir bien se va a distinguir por hacer dos cosas en simultáneo: validar hipótesis más rápido y proteger el criterio humano más en serio. Las dos lecciones que el resumen viral pasó por alto apuntan exactamente a eso.

Fuentes