IA en el flujo de trabajo del gerente de ingeniería: lo que realmente ayuda y lo que rompe en silencio

Cada IDE, gestor de proyectos y bot de standup ahora incluye un "asistente de IA". La mayoría produce estimaciones confidentemente incorrectas, convierte las notas de 1:1 en texto insulso y omite en silencio la parte del trabajo que realmente importa: el juicio. La promesa de "IA para managers" se ha convertido, para mí, en una razón para ser más escéptica, no menos.

No soy anti-IA. Uso Claude y Cursor todos los días. He eliminado horas de mi carga de preparación. Pero también me he equivocado, más de una vez, al confiar en un resumen que sonaba bien y era sutilmente incorrecto. Un resumen de 1:1 que aplanó un conflicto tenso en "se discutió la priorización". Un reporte de sprint que alegremente pasó por alto que dos ingenieros habían dejado de revisar los PR del otro. La IA no le dice lo que no ve.

Esta es la guía que ojalá hubiera tenido hace dos años. Dónde la IA justifica su lugar en la semana de un gerente de ingeniería, dónde romperá las cosas en silencio si se lo permite, y un plan de 30 días para incorporarla sin perder las partes del trabajo que deben seguir siendo suyas.

Por qué esto importa ahora

Usted es la última línea de defensa contra el contenido mediocre de IA que llega a su equipo. Si no puede distinguir entre un resumen de IA útil y uno alucinado, hará una de dos cosas, y ambas son malas.

Rechazará las herramientas por completo, y sus colegas silenciosamente ahorrarán cuatro horas a la semana mientras usted no lo hace. O confiará demasiado en ellas, entrará a una calibración de evaluaciones de desempeño con un documento de "temas" generado por IA, repetirá el encuadre alucinado ante la sala y recomendará un ascenso basado en algo que el modelo inventó a partir de un hilo de Slack.

Ninguna opción es aceptable para un gerente de 6 a 10 ingenieros. El trabajo consiste en saber qué flujos de trabajo son suficientemente buenos para la IA, y cuáles se mantienen en sus manos sin importar cuán tentador sea delegarlos.

Dónde la IA realmente ayuda

Estos cinco flujos de trabajo han sobrevivido un año de intentos de romperlos. No son emocionantes, pero representan tiempo real recuperado.

Resúmenes de preparación para 1:1

Antes de cada 1:1, cargo las notas de la semana anterior de ese ingeniero, su lista de PR fusionados y los hilos de Slack en los que participó en Claude. Prompt:

Aquí están las notas de la semana pasada, los PR fusionados y los hilos de Slack de [nombre]. Resume qué cambió desde nuestro último 1:1 en 5 puntos como máximo. Señala cualquier cosa que suene a fricción, trabajo bloqueado o desviación del alcance. No especules sobre sentimientos. Si un hilo no está claro, indícalo.

La línea "no especules sobre sentimientos" importa. Sin ella, el modelo le dirá amablemente que alguien pareció "frustrado" basándose en tres mensajes escuetos, usted entrará a la reunión y lo preguntará, y el ingeniero lo mirará como si hubiera perdido el juicio.

Lo que obtengo de vuelta es una lectura de 90 segundos que capta cosas que me perdí. Aún escribo mis propias preguntas. La IA solo se asegura de que no abra con "¿cómo va todo?" porque olvidé que enviaron la migración el jueves.

Borrador de retroalimentación para evaluaciones de desempeño

Seis meses de notas de 1:1 son mucho material. Una vez por ciclo, cargo esas notas (solo esas notas, no Slack ni PR, eso es un pasada diferente) en Claude con un prompt de agrupamiento:

Agrupa estas notas de 1:1 en 3-5 temas. Para cada tema, dame 2-3 momentos concretos de las notas que lo respalden. Usa citas directas de las notas donde sea posible. No generes temas que no estén respaldados por al menos dos notas distintas.

Esto es útil. No es el borrador. Saca a la superficie patrones que ya sospechaba y me recuerda momentos específicos que había olvidado. A partir de ahí, escribo la evaluación real con mi propia voz y mis propios ejemplos. El resultado de la IA va a un borrador temporal y se elimina.

Una evaluación de desempeño redactada por IA es el peor tipo de contenido mediocre. Suena profesional y no significa nada. El ingeniero que la lea lo sabrá.

Resúmenes de comentarios en PR y delegación de revisión de código

No soy revisora de código para el trabajo diario de mi equipo, pero sí leo los diffs para mantenerme al tanto. Si un PR es polémico, abro Claude con el diff y pregunto:

Resume el desacuerdo en este hilo de PR. ¿Cuál es la pregunta arquitectónica central que se debate? ¿Cuáles son los puntos más sólidos de cada lado?

Útil cuando necesito opinar en una decisión de diseño sin releer 80 comentarios en línea. Más sobre el patrón de Cursor y Claude a continuación.

Detección de anomalías en el análisis de sprint

La mayoría de los dashboards de sprint son ruido. Lo que quiero es "este sprint se ve raro, aquí está el qué". Cargo datos de tiempo de ciclo, latencia de revisión y estado de tickets en Claude con un prompt:

Compara las métricas de este sprint con las 4 anteriores. Señala cualquier número que esté más de 1.5 desviaciones estándar por encima del promedio de los últimos sprints. No especules sobre las causas. Solo dime qué es anómalo.

La línea "no especules sobre las causas" hace un trabajo real. Sin ella, el modelo le dirá con confianza que "el equipo está experimentando agotamiento" porque la latencia de revisión aumentó, cuando en realidad un ingeniero senior estaba de vacaciones. La IA es buena en "este número parece raro". Es mala en "y aquí está el porqué".

El porqué es su trabajo. Usted va a hablar con las personas.

Preparación del calendario

El beneficio más pequeño y el último que abandonaría. Cinco minutos antes de cualquier reunión para la que no me haya preparado, pego la agenda (o simplemente el título y los asistentes) y el documento más reciente en Claude:

Resumen de 90 segundos: de qué trata probablemente esta reunión, cuáles son las tensiones probables, en qué debería estar preparada para opinar. Sé específico. Si no lo sabes, indícalo.

No es mágico. Es un momento forzado de "en qué me estoy metiendo" en lugar de llegar sin preparación y quemar los primeros diez minutos poniéndome al día.

Dónde la IA rompe en silencio

Estos son los flujos de trabajo donde la IA parece que está ayudando y no lo está. Algunos los he visto quemar a otros managers. Algunos me los he quemado yo misma.

Decisiones de juicio. ¿Este ingeniero necesita un proyecto desafiante o más apoyo? ¿Este equipo está listo para una reorganización o le falta un trimestre? La IA da una respuesta equilibrada de ambos lados que suena sabia. Su trabajo es elegir. El modelo no tiene nada en juego y no conoce a su equipo.

Dar retroalimentación difícil. Las palabras deben venir de usted, con su voz, cara a cara. No por Slack. No en un documento. No a través de un "borrador asistido por IA" que usted retoca. Si no puede decirlo sin un guion, no lo cree lo suficiente como para entregarlo, y la persona del otro lado lo sentirá.

Decisiones de contratación. Las herramientas de selección de IA derivan hacia el sesgo y el lavado de señales. Premian a los candidatos que parecen el conjunto de entrenamiento, luego blanquean ese sesgo a través de una puntuación que suena confiada. He visto una herramienta bajar la puntuación de una ingeniera senior porque su currículum tenía una brecha de dos años (cuidado de familiares). Use IA para programar, para tomar notas durante un panel de debate, para redactar un correo de rechazo. No la deje filtrar personas.

Conversaciones sobre desempeño. PIP, rechazos de ascenso, cambios de alcance, conversaciones sobre compensación. Estos son temas con implicaciones legales, emocionalmente pesados y que requieren precisión en sus propias palabras. Nunca he visto un documento de PIP asistido por IA que no leyera como frío o incorrecto, a veces ambos.

Decisiones estratégicas. Qué apuesta, qué concesión, qué secuencia. La IA le da opciones plausibles. No le da la opción que su equipo puede ejecutar realmente, la que encaja con su realidad política, la que su director aprobará. Esa síntesis es el trabajo. Es por eso que le pagan.

La trampa del "documento de ascenso con IA"

Un ingeniero le entrega un expediente de ascenso. Los verbos son genéricos ("impulsó", "lideró", "abanderó"). Las afirmaciones de impacto están sospechosamente equilibradas: tres puntos, cada uno de dos líneas, cada uno con un número. No hay voz. Todo el documento lee como un endoso de LinkedIn de otra persona.

Es Claude. Se puede notar. Su skip-level también puede notarlo.

He aquí lo importante: generalmente no significa que el trabajo fue malo. Significa que la auto-narrativa del ingeniero es hueca, lo cual es un problema diferente y entrenable. El trabajo puede ser excelente. La historia es lo que está roto.

Cómo hago coaching sin humillar: no digo "¿es esto IA?". Pregunto: "Explíqueme el impacto principal con sus propias palabras". Si puede, la historia es real y solo externalizó la escritura. Bien, pero lo animaré a escribir el siguiente él mismo porque la escritura es el pensamiento. Si no puede, ese es el problema real, y trabajamos en ello juntos. De cualquier manera, no estoy jugando a ser detective de IA en un 1:1.

El expediente aún tiene que reescribirse. La prosa de IA no sobrevive en una sala de calibración. Los otros managers lo leerán de la misma manera que usted, y su candidato bajará de posición por sonar igual que todos los demás.

Cursor + Claude para la delegación de revisión de código

Aquí está el patrón concreto. Lo adverararé ampliamente después.

Capa 1: Cursor en modo agente. Configurado con las reglas de lint y estilo del equipo. Detecta lo obvio: pruebas faltantes, importaciones muertas, errores de tipo, inconsistencias de nomenclatura. El ingeniero se autocorrige antes de abrir el PR.

Capa 2: Claude en el diff. Cuando el PR se abre, un paso de CI (o el ingeniero manualmente) ejecuta el diff a través de Claude:

Revisa este diff. Señala: (1) funciones de más de 50 líneas, (2) cobertura de pruebas faltante en ramas nuevas, (3) cualquier cambio en rutas de autenticación, facturación o eliminación de datos, (4) lugares donde la nomenclatura no es clara. No comentes sobre el estilo; eso está manejado. No apruebes ni bloquees. Solo señala.

El resultado va como un único comentario en el PR. Los revisores lo leen como una lista de verificación antes de su revisión humana.

Capa 3: Revisión humana. El revisor ahora se concentra en la arquitectura, la intención de nomenclatura, si esto encaja con la dirección del sistema, si la abstracción es correcta. Lo que requiere criterio.

Dónde esto falla. Cualquier cosa que toque autenticación, facturación, pagos, eliminación de datos o PII recibe un revisor humano con formación en seguridad de principio a fin, sin IA en el bucle para la decisión. Dominios nuevos en los que el equipo no ha construido antes: igual. Migraciones críticas: igual. El patrón es bueno para código rutinario; no es bueno para el trabajo que realmente es arriesgado.

Confío en este patrón porque he visto al pasada de Claude perder bugs reales y sé qué se pierde. Si nunca se ha sentado con los diffs y lo ha visto equivocarse, aún no tiene la calibración para usarlo. Ejecútelo durante un mes con revisión humana completa encima antes de dejar que acorte su ciclo de revisión.

Plan de adopción de 30 días

Si está empezando desde cero, no adopte cinco flujos de trabajo de IA a la vez. Perderá el rastro de cuáles realmente ahorran tiempo y cuáles producen silenciosamente contenido mediocre que usted limpia. Uno a la vez.

Semana 1: un solo flujo de trabajo. Elija la preparación de 1:1. Úselo para cada 1:1 esa semana. Después de cada 1:1, escriba una línea: "qué pasó por alto la IA". Para el viernes tendrá 6 a 10 líneas que le indican los puntos ciegos del modelo. Esa es la base para confiar en él.

Semana 2: agregue uno más, ya sea la detección de anomalías de sprint o la preparación del calendario. El mismo ejercicio. Compare el resultado de la IA con su propio instinto. Donde esté de acuerdo, ahorra tiempo. Donde no esté de acuerdo, uno de los dos está equivocado; averigüe cuál.

Semana 3: auditoría. Saque las notas. ¿Dónde la IA ahorró tiempo neto y dónde pasó más tiempo corrigiendo contenido mediocre de lo que hubiera tardado haciéndolo usted mismo? Elimine cualquier flujo de trabajo en la segunda categoría. Si la preparación de 1:1 ahorró 20 minutos a la semana y el análisis de sprint le costó 30 minutos en segundas dudas, abandone el análisis de sprint.

Semana 4: escriba el documento de "normas de uso de IA" de su equipo. Una o dos páginas, escrito por usted. Cubra qué está fomentado, qué está permitido con advertencias, qué está prohibido. Compártalo. Acepte preguntas.

Un punto de partida para el documento:

Normas de uso de IA: [Nombre del equipo]

Fomentado: resúmenes de preparación de 1:1 (privados para el manager), resúmenes de preparación para reuniones y calendario, primera pasada de revisión de código (solo señales de Cursor y Claude, sin aprobación automática), detección de anomalías en métricas de sprint, resumen de documentación para contexto, borradores de correos no sensibles.

Permitido con advertencias: agrupamiento de temas para evaluación de desempeño (solo como insumo, nunca como borrador). Esquema de expediente de ascenso (solo el esquema, la escritura debe ser del ingeniero). Resumen de notas de standup (está bien si el equipo está de acuerdo).

Prohibido: IA como borrador final de cualquier evaluación de desempeño, documento de calibración o PIP. IA como las palabras de cualquier retroalimentación difícil entregada a una persona. Selección de candidatos por IA. Justificaciones de compensación generadas por IA. Aprobación automática de PR que toquen autenticación, facturación o PII.

Por qué: la IA es un asistente junior. Es suficientemente buena para borrar, resumir y señalar. No es suficientemente buena para tomar decisiones sobre personas, y las decisiones sobre personas son la mayor parte de lo que hacemos.

Ese documento es el artefacto que su equipo necesita. No una lista de herramientas. Una comprensión compartida de qué sigue siendo humano.

Opcional: lente del ACE Framework

Si está rastreando la adopción de IA en toda la organización y alguien pregunta dónde encaja la gestión de ingeniería en el ACE Framework, aquí está la correspondencia rápida. Úsela con moderación; el framework es más útil para decisiones de producto que para flujos de trabajo personales.

• Ingest: cargar notas de 1:1, datos de PR, hilos de Slack, métricas de sprint en un único contexto de trabajo
• Analyze: agrupamiento de anomalías de sprint, agrupamiento de temas para evaluaciones de desempeño, resumen de hilos de PR
• Predict: pronóstico de tiempo de ciclo y "¿está en riesgo este sprint?". Úselo con extrema precaución; estas son las salidas más propensas a alucinaciones que verá.
• Generate: solo insumos de borrador, nunca versiones finales. Resúmenes de 1:1, resúmenes de calendario, reportes de anomalías.
• Execute: no. Mantenga a los humanos al mando de cualquier acción que impacte a las personas. Sin excepciones.

El paso execute es donde la mayoría de los despliegues de IA en equipo se tuercen. "Auto-asignamos revisores" está bien. "Auto-aprobamos PR bajo N líneas" es el inicio de una revisión de incidente.

Errores comunes

Confiar en estimaciones de IA. Suenan seguras. Están construidas a partir de una distribución de entrenamiento que no incluye su codebase. Verifíquelas como máximo.

Dejar que la IA escriba retroalimentación que usted entregará. Si no puede escribirla usted mismo, no debería entregarla. La escritura es parte de creerla.

Resumir 1:1 en una forma que pierde la señal. Los resúmenes de cinco puntos colapsan una conversación tensa en "se discutió la priorización". Lea también sus notas sin procesar.

Dependencia de una sola herramienta. Los precios cambian, los modelos se retiran, los proveedores pivotan. La habilidad es el flujo de trabajo, no la herramienta. Si todo su sistema de preparación depende de que Claude sea gratuito en este nivel para siempre, tiene un problema de continuidad.

Cómo medir el éxito

Sabrá que el flujo de trabajo está funcionando cuando:

1. Ahorre 2 a 4 horas a la semana en preparación y síntesis. No 10. Si alguien le está vendiendo 10, le está vendiendo contenido mediocre.
2. Su equipo confía en que las conversaciones difíciles vienen de usted, con sus palabras, en persona.
3. Ningún contenido generado por IA llega a una evaluación de desempeño, decisión de contratación o sala de calibración sin editar.
4. Puede articular, en una oración cada uno, en qué flujos de trabajo confía a la IA y en cuáles no.
5. Sus subordinados directos pueden articular lo mismo sobre su propio trabajo, porque usted ha escrito el documento de normas y lo han leído.

Ese es el listón. La IA es un asistente junior. El trabajo (el juicio, las conversaciones difíciles, la decisión que nadie más está dispuesto a tomar) sigue siendo suyo. Si un flujo de trabajo le tienta a externalizar el juicio, ese es el flujo de trabajo que debe prohibir.

Aprenda más

• Cómo conducir 1:1s con ingenieros que impulsan el cambio
• Conversaciones sobre ascenso y desempeño
• Métricas del gerente de ingeniería: velocidad de entrega, calidad, retención de personal y contratación
• Herramientas y tech stack del gerente de ingeniería
• JD complementario: Staff Software Engineer