Los engineering managers que no codean con IA no entienden a su equipo
El EM que dejó de codear pre-AI vive en un mundo que ya no existe. Y sus decisiones —estimaciones, hiring, prioridades— se notan.
Hay una conversación incómoda que pocos equipos están teniendo: el engineering manager promedio dejó de codear hace 3-5 años, y la herramienta de codear cambió radicalmente hace 18 meses.
Cuando ese EM estima una feature, planifica un sprint, o decide contratar — usa intuiciones formadas en un mundo donde escribir código era 70% del trabajo. Ese mundo ya no existe. Y las decisiones empiezan a notarse.
Tres signos del EM que se quedó atrás
1. Estimaciones que se desmoronan. “Esta feature toma 2 semanas” dice el EM. Su mejor dev la termina en día y medio porque la mitad la escribió Claude Code. ¿Resultado? El sprint está mal calibrado, el equipo se aburre los últimos 8 días, o se inventan tareas para llenar tiempo. El EM cree que el equipo es lento. El equipo cree que el EM no entiende.
2. Prioridades basadas en la fricción vieja. “Esa refactor es muy cara, ahora no” — frase del EM que no sabe que con AI esa refactor toma 4 horas, no 4 semanas. El backlog se llena de cosas “para después” que ya podrían estar hechas. La deuda técnica se acumula no por flojera del equipo, sino por mal-estimación del manager.
3. Hiring que filtra mal. El EM contrata por habilidades que ya no son escasas (LeetCode, fluency en lenguaje X) y no detecta habilidades nuevas (curaduría de contexto, dirección de agentes, review crítico). El equipo se llena de “buenos developers” que no destacan en lo que ahora importa.
Por qué pasa
El EM moderno fue developer hace años, ascendió, dejó de codear para “enfocarse en gente”. La industria le dijo que eso es lo correcto.
Era correcto cuando codear era 70% del trabajo. La parte del 30% que es “gente, prioridades, coaching” se podía hacer bien sin tocar código semanas.
Pero ahora codear es 20% del trabajo. El 80% es decidir qué codear, revisar lo que el agente generó, y mantener contexto compartido. Ese 80% es exactamente lo que el EM podría estar liderando — si tuviera la calibración para hacerlo.
El EM que no toca AI coding pierde calibración sobre las tres cosas que más importan en su rol nuevo.
Lo que sí funciona
Los EMs que vemos prosperar en 2026 hacen un compromiso simple: una feature al mes de su mano, end-to-end, con AI coding.
No para “competir con los devs”. Para mantener calibración:
- Sabe cuánto tarda realmente una feature de complejidad X en su stack actual
- Sabe qué pain points tiene el equipo en su día a día (porque los siente)
- Sabe qué looks like un buen PR vs uno hecho con prisa
- Puede hacer code review con criterio, no con corazonadas
Esa una feature al mes cuesta 8-12 horas de su tiempo. A cambio, las decisiones de roadmap, hiring y estimación dejan de basarse en datos de 2022.
Para los EMs que están leyendo esto
Si llevas más de 6 meses sin mergear un PR, no estás liderando ingeniería — estás administrando un equipo de ingeniería desde afuera. La diferencia importa más cada mes.
No es señal de debilidad pedir a un dev senior que te dé un setup de Claude Code y resolver una feature chica. Es señal de seriedad sobre tu propio rol.
La pregunta dura
¿Cuándo fue la última vez que abriste el repo de tu equipo y mergeaste algo? Si la respuesta es “hace meses” o “no me acuerdo”, ya tienes el dato de qué tan calibrado estás con tu propio equipo.
Si eres EM y quieres explorar cómo volver a tener manos en el código sin perder el rol de manager, conversemos — el chat está abierto.