Liderar un equipo de ingeniería nativo de IA: en qué se convirtió el trabajo cuando el output dejó de escasear (2026)
By Surya Pratap
2 de agosto de 2026
12 min read
Startup Strategy
2 de agosto de 2026
12 min read
Casi todo lo que se escribe sobre la IA y los equipos de ingeniería trata de plantilla: a quién contratar, a quién recortar. Se escribe mucho menos sobre la parte que de verdad consume la semana de un fundador: liderar a las personas que siguen ahí. Ese trabajo cambió de forma más silenciosa y más completa que la aritmética de las contrataciones, y el cambio tiene una sola causa de fondo. Durante toda la historia del software, el recurso escaso fue el output. Liderar consistía en gran medida en conseguir más: desbloquear, priorizar, proteger la concentración, contratar. El output ya no escasea.
Lo que escasea ahora es la comprensión, el criterio y las ganas de los buenos ingenieros de seguir haciendo este trabajo. Esas tres cosas son lo que gestiona de verdad un líder de ingeniería nativo de IA, y ninguna aparece en los paneles que la mayoría de los equipos sigue usando. Esto es lo que se rompe, lo que han descubierto los equipos que lo hacen bien y en qué se están equivocando los fundadores sin darse cuenta.
Empecemos por la instrumentación, porque liderar con números rotos es peor que liderar sin ellos. Cuando los agentes generan la mayor parte del código que se integra, las líneas de código, la velocidad de pull requests y el tiempo de ciclo dejan de medir lo que crees que miden. Pasan a medir cuánto generaron tus herramientas, que es una decisión de presupuesto y no una señal de rendimiento. Cualquier equipo puede duplicarlas esta misma tarde.
Las métricas que sobrevivieron son las que siguen el flujo a través de la restricción, no el volumen que entra en ella. La profundidad de la cola de revisión y la frecuencia de cambios de contexto son los indicadores adelantados útiles: predicen cuellos de botella antes de que los muestren las cifras de entrega, porque miden la parte del proceso que no se aceleró. Junto a ellas, las prácticas que merece la pena adoptar son la velocidad de decisión, el cumplimiento de las políticas y el análisis por cohortes para detectar la manipulación de métricas, porque un cuadro de mando que premia el volumen en una era de volumen gratuito se manipulará en un sprint, normalmente sin que nadie lo pretenda.
Una advertencia honesta: las ganancias de productividad medidas gracias a la IA varían enormemente entre equipos, y la variación sigue cuánto invirtió un equipo en evaluación, gobernanza y la fontanería de integración, no qué modelo eligió. La frontera de capacidades rara vez es el cuello de botella. Todo lo que hay entre un modelo de frontera y un resultado medible sí lo es.
El concepto más útil que he visto nombrado este año es la deuda de comprensión: ingenieros que lanzan rápido sin entender los sistemas en los que están lanzando más allá de dos o tres capas, y que van perdiendo poco a poco la capacidad de diagnóstico y razonamiento que los hacía valiosos. Es la hermana de la deuda técnica y bastante más difícil de ver, porque el código parece correcto. El déficit solo aflora durante un incidente, cuando nadie en la llamada sabe razonar por qué el sistema se comporta como se comporta.
El diagnóstico es reconfortantemente poco tecnológico: demos semanales. No informes de estado: demos, en las que un ingeniero recorre lo que construyó y responde preguntas sobre el porqué. Que un equipo sepa explicar su propio trabajo es una señal mucho mejor que el hecho de que produzca más, y a diferencia de cualquier métrica de panel, un agente no puede manipularla. El principio rector, según los equipos que lo hacen de forma deliberada: hay que delegar el trabajo pesado, no el pensamiento.
La cuestión de la calidad, respondida
Esto no es un argumento de que el código asistido por IA sea peor. Shopify informa de tasas de reversión del código asistido por IA más o menos equivalentes a su referencia anterior a la IA: la paridad de calidad es alcanzable. El riesgo no es que el código sea malo. Es que las personas dejen de entenderlo, lo que no te cuesta nada este trimestre y te lo cuesta todo durante tu primera caída seria.
El error de liderazgo más común ahora mismo es imponer una herramienta. Un fundador lee que un asistente va por delante, declara que el equipo lo usará y trata la adopción como una métrica de cumplimiento. Es la capa equivocada para estandarizar, y te cuesta buena voluntad sin ningún beneficio duradero: la clasificación cambiará antes de que termine el despliegue.
El enfoque de Shopify es el mejor patrón: en lugar de imponer un asistente, construyeron un proxy interno de LLM, un gateway central que enruta las peticiones de Claude Code, Copilot, Cursor o cualquier otra herramienta a través de una sola plataforma. Eso da a la dirección lo que de verdad necesita, que es control de costes, analítica de uso por equipo y proyecto, y la posibilidad de cambiar de modelo sin tocar el flujo de trabajo de nadie. Los ingenieros conservan sus herramientas. La empresa conserva su opcionalidad. El razonamiento es de una honestidad desarmante: nadie sabe todavía qué empresa, qué flujo de trabajo ni qué modelo va a ganar.
Esto se puede generalizar. Estandariza lo que es caro de cambiar e invisible para cada ingeniero: el gateway, el harness de evaluación, los requisitos de revisión, la ruta de despliegue. Deja en paz lo que es barato de cambiar y muy personal: el editor, el asistente, el estilo de los prompts.
Cuando el output se multiplica, el proceso de lanzamiento se convierte en el lugar donde de verdad se ejerce el liderazgo, y una única puerta a producción se convierte en una cola con un responsable delante tomando decisiones apresuradas. La respuesta de Ramp es un sistema de dos niveles: los equipos despliegan en acceso anticipado cuando están listos, llegando a aproximadamente el 10 % de los clientes, y llegar a disponibilidad general exige pruebas según una lista de comprobación estándar —justificación de la funcionalidad, vídeo de demo, resumen de KPI, opiniones de clientes, análisis del recorrido del usuario, preparación del equipo, estrategia de despliegue—, con la dirección resolviendo las revisiones en menos de 48 horas.
La idea de fondo merece interiorizarse: la velocidad y la calidad dejan de ser un intercambio en cuanto tienes dos niveles de lanzamiento. Los ingenieros pueden lanzar de forma continua, que es lo que hace que el trabajo resulte satisfactorio. El negocio tiene un listón real antes de que algo llegue a todo el mundo. Y, sobre todo, el líder deja de ser el cuello de botella de cada decisión individual, porque la lista de comprobación saca fuera lo que significa «listo» en lugar de dejarlo en la cabeza de una sola persona.
Esta es la parte que se infravalora, y es un problema de liderazgo, no técnico. Aproximadamente el 84 % de los desarrolladores usa o piensa usar herramientas de IA, pero la percepción ha empeorado, y alrededor del 46 % declara desconfiar de lo que producen esas herramientas. La principal frustración no es que la IA sea inútil; es el sufrimiento concreto del output «casi correcto» y la pesadez de depurar código que nadie escribió.
Adopción no es aprobación. Si interpretas un uso elevado de las herramientas como prueba de que tu equipo está contento con la transición, estás leyendo una cifra que no dice eso. Y en los foros donde los ingenieros hablan con más libertad, las quejas son coherentes y concretas: aumentos de productividad impuestos, métricas impuestas, presión para revisar código generado por máquinas todo el día y la sensación de que su propio desarrollo profesional se estanca. Algunos dicen sin rodeos que aceptarían cobrar menos antes que pasar cincuenta horas a la semana orquestando agentes en lugar de ejercer el oficio por el que firmaron.
Compáralo con lo que de verdad impulsa la satisfacción de los desarrolladores, que según las encuestas es sistemáticamente la autonomía y la confianza, por delante de la retribución. Y fíjate en que el manual habitual —imponer la herramienta, medir la adopción, subir el objetivo de output— ataca directamente la autonomía y la confianza. Así es como un líder acaba con un equipo que usa mucho la IA, cumple sus cifras y empieza a buscar trabajo sin hacer ruido.
La historia de adopción más eficaz que encontré no incluye ninguna imposición. El vicepresidente de Shopify Farhan Thawar impulsó la adopción mostrando su propio uso y presentándolo como palanca, no como brillantez: «No dije mirad cuánto trabajo he hecho y lo listo que soy. Dije: "Mirad lo vago que soy"». Ese enfoque se extendió más allá de ingeniería, porque daba permiso en lugar de imponer una obligación.
También resuelve un problema de estatus que los líderes suelen pasar por alto. Cuando el uso de la IA se impone y se mide, usarla se convierte en reconocer que necesitabas ayuda. Cuando un líder sénior la usa públicamente para evitar lo tedioso, se convierte en lo que debería ser: una herramienta que los buenos ingenieros usan porque tienen cosas mejores que hacer. Esos dos enfoques producen culturas muy distintas a partir de las mismas herramientas.
Un correctivo útil para todo esto: el liderazgo técnico adecuado cambia con el tamaño del equipo. Desde la fase semilla hasta unos diez ingenieros quieres constructores que se manchen las manos y optimicen la velocidad, no arquitectos que planifiquen una escala que no tienes. Entre diez y veinte está el verdadero punto de inflexión, donde las decisiones de arquitectura irreversibles —almacenes de datos, modelo de DevOps, infraestructura de pruebas— se endurecen hasta convertirse en cimientos culturales muy difíciles de revertir. Entre veinte y cincuenta, la cuestión de liderazgo pasa a ser de diagnóstico: ¿tus problemas son de personas o de arquitectura, y tu estructura encaja con la respuesta?
La mayoría de los fundadores que leen esto están en el primer tramo, donde el consejo honesto es que todavía no necesitas casi nada del aparato anterior. Necesitas demos semanales, un gateway en lugar de una herramienta impuesta y la disciplina de seguir entendiendo tu propio sistema.
Esa última cifra de presupuesto es todo el argumento comprimido en una proporción. Los equipos gastan casi todo en capacidad y casi nada en las personas que tienen que absorberla, y luego se preguntan por qué la adopción es desigual y la percepción va a peor. La restricción nunca fue el modelo.
Los líderes que salgan bien de esta época no serán los que adoptaron más rápido. Serán aquellos cuyos ingenieros siguen entendiendo el sistema, siguen ejerciendo su criterio sobre qué debe construirse y siguen queriendo estar ahí dentro de dos años. El output nunca fue la parte difícil del trabajo. Solo lo parecía.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.