El Engineering Manager Que No Programa Es Obsoleto. El Que Solo Programa Es el Siguiente.
El debate sobre si los EMs deben programar es una falsa dicotomía. El modelo builder-manager — programar para entender, no para entregar — es el tercer camino que sobrevive al aplanamiento por IA, gana la confianza del equipo y crea apalancamiento organizacional.
El mes pasado, Amazon ordeno que cada cambio de codigo generado por IA requiera la aprobacion de un ingeniero senior, despues de que agentes autonomos causaran una caida de seis horas en Amazon.com y un apagon de trece horas en AWS China. Mientras tanto, Block despidio al 40% de su plantilla y declaro que reconstruiria la empresa como una "mini-AGI" donde la inteligencia artificial mantiene un modelo continuamente actualizado de todo el negocio, reemplazando capas enteras de coordinacion gerencial.
Estas dos respuestas -- mas supervision humana y menos participacion humana -- no pueden ser correctas las dos. A menos que la pregunta en si este mal planteada.
Las Dos Muertes del Engineering Manager
Gartner predice que para 2026, el 20% de las organizaciones usara IA para aplanar sus estructuras, eliminando mas de la mitad de los puestos de middle management actuales. Fortune lo bautizo "The Great Flattening" -- la extincion del mando intermedio. No es teoria. Block elimino 4,000+ posiciones en febrero de 2026. Klarna reemplazo 700 roles de servicio al cliente con IA, y luego tuvo que recontratar humanos urgentemente -- forzando incluso a ingenieros a atender llamadas -- cuando la calidad se desplomo. Meta analizo datos de productividad tras su despliegue de IA y encontro equipos entregando lo mismo en menos horas.
En medio de este aplanamiento, dos arquetipos de engineering manager estan muriendo.
Muerte 1: El Pure Manager. El EM que se convirtio en un operador de meetings y spreadsheets a tiempo completo. No escribe codigo desde hace tres anos. Su valor esta en coordinar: syncs de equipo, reportes de estado, seguimiento de performance. Pero cuando la IA puede generar reportes de Jira, resumir Slack, y automatizar seguimiento de OKRs, la propuesta de valor de este EM se evapora. Estas son las primeras posiciones que desaparecen en el aplanamiento.
Seamos honestos: la mayoria de los EMs que dejaron de programar lo hicieron por comodidad, no por estrategia. Los meetings son mas faciles que el debugging. Los 1:1s se sienten productivos incluso cuando no lo son. El calendario se llena solo. Programar requiere tiempo ininterrumpido que los EMs son demasiado indisciplinados para proteger. En un mundo donde la IA maneja coordinacion, reportes de estado, y resumenes de performance, si tu trabajo entero puede hacerlo un agente de IA con acceso a Jira y Slack, no tienes un trabajo -- tienes un titulo.
Muerte 2: El Player-Coach. El EM que programa el 60% de su tiempo y gestiona en los huecos. Su equipo carece de liderazgo porque esta en meetings la mitad del dia y programando la otra mitad. Su codigo carece de foco porque lo escribe entre 1:1s. Se quema. Jim Grey articulo esto en marzo de 2026 con "The player/coach trap": cuando los managers programan, los equipos pierden liderazgo.
La verdad incomoda aqui es que la mayoria de los player-coach EMs son mediocres en ambos roles. Escriben el 60% del codigo de su equipo y hacen el 40% del management. El codigo no se revisa bien porque el reviewer es tambien el autor. El management no se hace bien porque no hay tiempo. Grey tiene razon en que este modelo esta roto. Se equivoca en que la respuesta es dejar de programar por completo.
LeadDev lo confirma: las posiciones de management se estan convirtiendo en callejones sin salida. Las empresas aplanan organigramas y eliminan capas de gestion de un dia para otro. Los ingenieros vieron desaparecer capas enteras en la era post-ZIRP. Y LeadDev tambien senala que los EMs estan atrapados en un doble vinculo con la IA: presionados para mostrar impacto con IA y cuestionados si la ignoran.
La pregunta se vuelve existencial: si el pure manager muere y el player-coach se quema, que sobrevive?
Escribi sobre el uso indisciplinado de IA por parte de desarrolladores individuales -- el problema del "mono sin cabeza." Aplica igual a managers. Un EM que programa sin estrategia es solo un mono sin cabeza con el calendario lleno de 1:1s.
El Cuello de Botella Se Movio
Armin Ronacher lo explico mejor que nadie en "The Final Bottleneck": la IA elimina el cuello de botella de escribir codigo, pero el propio humano se convierte en el cuello de botella final. Mientras los humanos carguen con la responsabilidad del software que se despliega, maquinas no sentientes no pueden cargar con esa responsabilidad. El cuello de botella se mueve de "escribir codigo" a "entender y ser responsable del codigo."
Ronacher usa un paralelo con la revolucion industrial textil: cuando eliminas un cuello de botella, la innovacion se mueve a la siguiente restriccion downstream.
Los numeros confirman el desplazamiento. La IA escribe el 41-42% del codigo global en 2026, aunque los benchmarks sostenibles se situan entre 25-40% antes de que la calidad se degrade. GitHub reporta que la IA escribe el 46% del codigo del desarrollador promedio, llegando al 61% en Java. Sundar Pichai confirmo que el 25% del codigo de Google ya es asistido por IA. El 95% de los ingenieros usa herramientas de IA al menos semanalmente, y el 75% usa IA para al menos la mitad de su trabajo. El reporte de Jellyfish 2025 muestra que el 90% de los equipos de ingenieria usan herramientas de IA, frente al 61% el ano anterior. El 81% de los desarrolladores espera que el desarrollo significativo pase de humanos a IA.
La generacion de codigo ya no es la restriccion. Las nuevas restricciones en los equipos de ingenieria son tres:
1. Evaluar la calidad del output de IA. Los datos de Stack Overflow 2025 muestran que el 66% de los desarrolladores gasta mas tiempo arreglando codigo de IA que es "casi correcto pero no del todo." Solo el 29% confia en la precision de la IA -- menos que el 40% del ano anterior.
2. Mantener la coherencia arquitectonica. Documente esto extensamente en mi post sobre agentes de IA rompiendo codebases: el 75% de los agentes rompen codigo que antes funcionaba durante ciclos de mantenimiento. Los datos de CodeRabbit muestran 1.7x mas problemas en codigo generado por IA. La investigacion sobre deuda de comprension muestra que los agentes generan codigo 5-7x mas rapido de lo que los humanos pueden comprenderlo.
3. Decidir que construir. Mirek Stanek lo resume con precision: "Si la IA puede generar features en dias y aun asi dos tercios de ellos no mueven la aguja, se vuelve dolorosamente obvio que el problema nunca fue 'programar demasiado lento' sino 'construir las cosas equivocadas.'"
El EM que solo sabe gestionar no puede evaluar el output de IA. El EM que entiende el codigo y el contexto de negocio es ahora la persona mas critica en la sala.
El Builder-Manager: Un Tercer Camino
No estoy proponiendo el player-coach. La diferencia es fundamental:
- Player-Coach: Programa para entregar features. Esta en el camino critico. El equipo espera por su codigo.
- Builder-Manager: Construye para entender el sistema y validar el output de IA. Nunca esta en el camino critico. El equipo nunca se bloquea esperando su codigo.
Esta distincion no es semantica. Es operativa. Determina si tu tiempo construyendo multiplica al equipo o lo frena.
Hay un argumento clasico que dice "los buenos EMs escalan a traves de personas, no a traves de codigo." Es verdad -- y el builder-manager escala a traves de personas construyendo herramientas que hacen a esas personas mas efectivas. Un MCP server que ahorra a cada ingeniero 2 horas por semana en un equipo de 10 personas son 20 horas semanales de apalancamiento. Eso ES escalar a traves de personas. No compite con el liderazgo; lo amplifica.
| Dimension | Pure Manager | Player-Coach | Builder-Manager |
|---|---|---|---|
| Programa? | No | Si (features) | Si (herramientas/infra) |
| En el camino critico? | Nunca | Frecuentemente | Nunca |
| Puede evaluar output de IA? | Mal | Bien (pero sin tiempo) | Bien (por diseno) |
| El equipo se bloquea por el? | No | Si | No |
| Sobrevive al aplanamiento? | No (reemplazado por coordinacion IA) | Quiza (si el equipo es pequeno) | Si (valor unico) |
| Tiempo programando | 0% | 40-60% | 10-20% |
| Que construye | Nada | Features del roadmap | Herramientas internas, governance, POCs |
Lo que el builder-manager construye con sus propias manos:
Tooling interno y prototipos. MCP servers, RAG pipelines, herramientas de workflow de IA. Cosas que hacen al equipo mas rapido, no features en el roadmap. Yo construi MCP servers de produccion para tooling interno. Construi un RAG pipeline que llevo la precision de retrieval de 58% a 91%. Construi un sistema de generacion automatica de documentacion de arquitectura. Ninguno de estos era un feature del sprint. Todos hicieron al equipo mas capaz.
Evaluaciones de proof-of-concept. Probar si una nueva herramienta de IA, framework o arquitectura realmente funciona antes de pedirle al equipo que la adopte. El EM que ha usado Claude Code en su propio codebase puede evaluar cuando un IC propone adoptarlo para todo el equipo. El que no lo ha tocado, solo puede confiar ciegamente.
Archivos CLAUDE.md, .cursorrules y Architecture Decision Records. La capa de configuracion y documentacion que hace que los agentes de IA sean efectivos para todo el equipo. Esto es apalancamiento puro: una hora escribiendo un buen CLAUDE.md ahorra decenas de horas de output erratico de agentes.
Code review con contexto profundo. No rubber-stamping PRs sino evaluar impacto arquitectonico, especialmente para codigo generado por IA.
Lo que el builder-manager nunca construye:
Features en el camino critico. Si el equipo esta esperando tu PR, has fallado como manager. Punto.
Hotfixes de produccion bajo presion. Tu trabajo es asegurar que el equipo pueda manejar esto, no ser el heroe.
Codigo que solo tu entiendes. Si tu codigo crea un silo de conocimiento, has replicado la peor parte de ser un IC.
La tesis central del builder-manager se sostiene en tres principios: construir para entender, no para entregar; construir lo que multiplica al equipo; y construir menos a medida que escalas. He escalado equipos de 3 a 18 ingenieros en multiples empresas. La transicion de programar a tiempo completo a gestionar a tiempo completo es un espectro, no un interruptor. El builder-manager es el punto del espectro que maximiza el valor para la organizacion en la era de IA.
La Regla 20/30/50
Necesitamos un framework concreto, no vibes. Asi distribuyo mi tiempo, y asi lo recomiendo:
- 20% Construyendo -- Trabajo tecnico hands-on: prototipos, tooling, POCs, code review profundo
- 30% Habilitando -- Decisiones de arquitectura, estrategia tecnica, AI governance, desarrollo de habilidades del equipo
- 50% Liderando -- 1:1s, hiring, gestion de stakeholders, coordinacion cross-team, crecimiento de carrera
Por que este ratio y no otro?
El consejo clasico era que los EMs deberian programar el 30% de su tiempo. Pero ese 30% era para escribir features. El builder-manager programa 20% pero en las cosas correctas -- herramientas que multiplican al equipo en lugar de features que compiten con el equipo.
La encuesta de Pragmatic Engineer muestra que el uso de agentes por parte de EMs (46.1%) esta por detras de los Staff+ engineers (63.5%). Esa brecha es el problema. Las personas que aprueban y gobiernan codigo generado por IA usan agentes de IA menos que las personas que lo generan. El tiempo de building es como cierras esa brecha -- no puedes evaluar lo que no entiendes.
Jim Grey dice que programar le roba tiempo al liderazgo. Es verdad -- si estas programando features. Es falso -- si tu tiempo construyendo mejora directamente la capacidad del equipo.
El ratio se ajusta por tamano de equipo:
| Tamano de Equipo | Construir | Habilitar | Liderar |
|---|---|---|---|
| 3-5 reportes | 30% | 25% | 45% |
| 6-10 reportes | 20% | 30% | 50% |
| 11-15 reportes | 10% | 30% | 60% |
| 15+ reportes | 5% | 35% | 60% |
Con 3-5 reportes, tienes mas espacio para construir y menos carga de liderazgo puro. Con 15+ reportes, ya eres director en la practica; construyes solo lo minimo para mantenerte actualizado. Pero incluso ese 5% importa. Ese 5% es la diferencia entre un director que entiende lo que su organizacion construye y uno que solo lee dashboards.
Adam Ferrari lo argumenta bien en su analisis sobre el aplanamiento y el engineering management: el aplanamiento es real pero alcanzara un equilibrio. Cuando los ratios IC-a-EM llegan a 10:1, la calidad se degrada. El rol de EM sobrevive, pero solo para quienes proveen valor mas alla de la coordinacion. El builder-manager es ese valor. No sobrevive al aplanamiento porque sea indispensable como coordinador -- sobrevive porque hace cosas que ni la IA ni los ICs individuales pueden hacer: conectar la vision tecnica con la direccion del negocio a traves de la experiencia directa con el codigo.
Tu Nuevo Trabajo: Director de Calidad de IA
El mandato de Amazon -- aprobacion de ingeniero senior para todo codigo de IA -- es el canario en la mina de carbon. Cada organizacion de ingenieria va a necesitar una politica de codigo IA antes de que termine 2026. La fecha limite de cumplimiento del EU AI Act en agosto de 2026 lo convierte en un requerimiento legal en industrias reguladas.
El EM que entiende el codigo esta en una posicion unica para ser dueno de esto:
Define niveles de riesgo. Que sistemas necesitan revision humana para cada cambio de IA (pagos, autenticacion, datos sensibles) vs. cuales pueden tener supervision mas ligera (herramientas internas, paneles de admin). No todo el codigo generado por IA tiene el mismo riesgo. Tratar todo igual es tan peligroso como no tratar nada.
Mide la calidad del codigo IA. Nosotros empezamos a etiquetar PRs generados por IA y encontramos una tasa 2.3x mayor de bug-fixes de seguimiento en las dos semanas posteriores. Ese numero informo cuanto tiempo extra de review asignamos. Si no mides esto, no sabes donde estas parado.
Construye las barreras. Archivos CLAUDE.md, linting arquitectonico, requerimientos de regression tests, limites de scope para PRs de agentes. Documente las barreras especificas que funcionan en mi post sobre agentes de IA: nunca dejar que los agentes hagan self-merge, regression test suites completas, scope limitado a cambios de un solo concern, tracking separado de codigo generado por agentes.
Entrena al equipo. Los datos de Stack Overflow muestran que el 59% de los desarrolladores usa codigo de IA que no entiende. El trabajo del EM es cerrar esa brecha, no ignorarla. Si tu equipo acepta codigo que no comprende, la IA no tiene la culpa. Tu governance si. Escribi una guia completa sobre como los desarrolladores deberian usar la IA de forma estructurada -- esas practicas deberian ser parte del onboarding de tu equipo, no una sugerencia opcional.
El Stack Overflow blog lo resume: si 2025 fue el ano de la velocidad de codigo IA, 2026 es el ano de la calidad de codigo IA. La organizacion que no tenga un EM construyendo las barreras y midiendo la calidad va a descubrirlo de la peor manera -- en produccion, a las 3 AM, con un agente autonomo que nadie superviso.
Gartner proyecta que para 2027, el 70% de los roles de liderazgo de ingenieria de software requeriran supervision de IA generativa. El EM que ya tenga este musculo desarrollado sera el que las organizaciones paguen $350K-$500K por retener. El que no, sera reemplazado por un IC senior con mejores herramientas y menor overhead.
Por Que Tu Equipo No Seguira a un Manager Que No Puede Leer el Codigo
Los numeros de confianza en la IA son reveladores. Segun Stack Overflow 2025: el 46% de los desarrolladores desconfia activamente del output de IA. Solo el 29% confia en su precision. Y apenas el 3% tiene "alta confianza." La frustracion numero uno, citada por el 45% de los desarrolladores, es "soluciones de IA que estan casi bien, pero no del todo."
Ahora pon a un EM que no puede evaluar output de IA en esa ecuacion. Se convierte en un rubber stamp. El equipo lo sabe. La confianza se erosiona.
El problema se agudiza con los ingenieros senior. Los desarrolladores mas experimentados son los mas cautelosos con la IA: la tasa mas baja de confianza alta (2.6%) y la tasa mas alta de desconfianza alta (20%). Estos son los ingenieros que necesitan review a nivel de par de su manager, no hand-waving gerencial.
La analogia es simple. Un administrador de hospital que nunca ha practicado medicina vs. un jefe de cirugia que todavia opera ocasionalmente. Cuando hay un desacuerdo sobre un procedimiento, a cual escucha el equipo quirurgico?
Esto no se trata de autoridad tecnica ni de ego. Se trata de credibilidad. El builder-manager gana el derecho a tomar decisiones arquitectonicas porque tiene evidencia reciente y de primera mano de que funciona. No porque leyo un resumen en un dashboard.
Si no has usado Claude Code en tu propio codebase en los ultimos 30 dias, no estas calificado para revisar pull requests generados por IA de tu equipo. Suena fuerte? Los datos respaldan la afirmacion. La encuesta de Pragmatic Engineer muestra que los Staff+ engineers usan agentes regularmente al 63.5%. Los engineering managers al 46.1%. Las personas aprobando el codigo generado por IA estan menos familiarizadas con las herramientas que las personas que lo generan. Es como un inspector de edificaciones que nunca ha usado un nivel.
Y hay algo que nadie quiere decir en voz alta: el EM que dice "confio en mi equipo" como excusa para no entender el codigo se ha convertido en el equivalente gerencial del desarrollador que dice "confio en mis tests" sin verificar que los tests cubran los casos correctos. Las dos frases suenan bien. Las dos son abdicaciones de responsabilidad. Confiar en tu equipo significa haberles dado las herramientas, las barreras y el contexto para tomar buenas decisiones -- no ignorar lo que producen y esperar lo mejor.
Boris Cherny, creador de Claude Code de Anthropic, dice que vamos a empezar a ver el titulo de "software engineer" desaparecer. Solo va a ser "builder" o "product manager." LinkedIn ya lanzo un programa de "full stack builder" para todos sus empleados sin importar el titulo. Si los ICs se convierten en builders, el EM se convierte en el "builder-leader" -- y la palabra "builder" implica que realmente construyes algo.
Gregor Ojstersek argumenta que las empresas todavia necesitan desesperadamente EMs fuertes, con compensaciones de $350K-$500K. Pero el EM "fuerte" de 2026 no es el mismo de 2022. El EM fuerte de hoy es el que puede sentarse con su equipo senior, revisar un PR generado por agentes, y explicar por que la decision arquitectonica del agente viola un invariante del sistema que no esta documentado en ningun test. Ese nivel de conversacion tecnica no se mantiene leyendo resumenes. Se mantiene construyendo.
En dos anos, "sigues programando?" no sera una pregunta de entrevista para EMs. Sera un requisito del puesto -- porque la alternativa es un IC con mejores herramientas y menor costo.
Empieza el Lunes: El Playbook del Builder-Manager
Suficiente teoria. Esto es lo que puedes hacer en tu primera semana:
1. Audita tu ultimo mes. Revisa tu calendario y tus commits. Cuanto de tu tiempo fue construir, habilitar o liderar? Si construir esta en 0%, estas expuesto. No digo que debas entrar en panico. Digo que debes ser honesto sobre donde estas parado antes de que alguien mas lo sea por ti.
2. Elige una herramienta interna para construir. No un feature. Una herramienta. Un MCP server que conecte el sistema de tickets de tu equipo con Claude. Un script que auto-genere documentacion de arquitectura. Un archivo CLAUDE.md para tu repositorio principal. Algo que haga a todo el equipo mas efectivo, no algo que este en el sprint backlog.
3. Implementa AI governance. Etiqueta PRs generados por IA. Ejecuta regression suites completas sobre ellos. Mide tasas de bugs durante 30 dias. Nuestros datos mostraron 2.3x mas fix-ups de seguimiento en codigo de agentes -- conoce tu numero. Si no sabes cual es, no tienes governance. Tienes esperanza.
4. Cierra la brecha de agentes. Si tus ICs usan agentes de IA mas que tu (63.5% vs 46.1% segun Pragmatic Engineer), no puedes evaluar su trabajo. Pasa dos horas esta semana usando Claude Code en tu propio codebase. No delegues esto. No lo agendes para "cuando tenga tiempo." Hazlo.
5. Documenta una decision de arquitectura. Escribe un ADR para la decision tecnica significativa mas reciente. Este es el layer de contexto que hace tanto a humanos como a agentes de IA mas efectivos. Escribi sobre el valor de los ADRs en el contexto de sistemas distribuidos escalables -- aplica igual aqui.
El modelo builder-manager no es una idea nueva. Es como los mejores EMs han trabajado siempre. La IA solo hizo imposible fingirlo. Cuando la generacion de codigo era cara y lenta, un EM que no programaba podia argumentar que su valor estaba en desbloquear al equipo. Ahora que la generacion de codigo es barata y rapida, desbloquear al equipo requiere entender que esta produciendo el equipo -- y que esta produciendo la IA que usa el equipo.
Este blog es mi evidencia. Siete posts tecnicos profundos escritos mientras mantengo un titulo de engineering manager. MCP servers de produccion. RAG pipelines. Governance de agentes de IA. Sistemas distribuidos. Cada uno de estos posts existe porque construi lo que describo. No es teoria. Es practica documentada.
El engineering manager que no programa esta siendo reemplazado por IA. El que solo programa esta siendo reemplazado por un IC senior que cuesta menos. El que construye las cosas correctas -- herramientas, governance, contexto, confianza -- es el que el equipo y la organizacion no pueden permitirse perder.
El debate "deberian los EMs programar?" es una falsa dicotomia. La pregunta correcta siempre fue: que deberia construir un EM? Y la respuesta es lo que ninguna IA puede construir sola: el puente entre el codigo y la organizacion que lo produce.