En charlas, conferencias e hilos de LinkedIn, la adopción de IA en ingeniería parece fácil: instalas la herramienta, configuras el prompt y el equipo entrega 3 veces más. Quien está dentro de un equipo real sabe que el guion es otro. Existen cuatro desafíos que nadie cuenta en el escenario, pero que deciden el éxito o el fracaso de la adopción: estandarización, seguridad y homologación, volumen y revisión, y calibración de plazos. Estos cuatro temas rara vez caben en la diapositiva de marketing, pero son lo que efectivamente separa a las empresas que destraban la productividad con IA de las empresas que convierten la adopción en frustración.
Este post profundiza en cada uno de ellos, con los síntomas, las causas reales y los patrones que funcionan para tech leads, ingenieros sénior y líderes de plataforma. No es una receta lista. Es el mapa de lo que realmente hay que atender para que la IA deje de ser un "experimento individual" y se convierta en una capacidad de equipo.
Desafío 1, Estandarización: cada uno con su herramienta se vuelve caos
El primer síntoma suele ser silencioso. El ingeniero A usa Cursor con sus propios prompts. El ingeniero B usa Copilot dentro de VSCode. El ingeniero C usa Claude Code directamente en la terminal. El ingeniero D mantiene una carpeta secreta de prompts en Notion. El ingeniero E ni siquiera sabe que se puede usar la IA de esa forma. Sin estandarización, cada PR tiene una voz distinta, cada feature tiene un patrón de comentario distinto, cada agente está configurado de una forma distinta, y compartir el workflow se vuelve imposible.
El problema no es que las personas tengan preferencias. La preferencia es sana. El problema es que sin contexto compartido, prompts compartidos y workflows compartidos, la empresa no acumula aprendizaje. La idea que tuvo el ingeniero A sobre cómo conducir un agente en una refactorización muere en su carpeta. La siguiente persona que enfrenta el mismo problema lo reinventa, con la mitad de la calidad.
Síntomas prácticos de la falta de estandarización
Cuatro señales de alerta clásicas. 1. PRs con voz inconsistente: un comentario formal, otro casual, otro con emoji, otro solo un comando. 2. Gran variación de calidad del output entre ingenieros: algunos producen código limpio guiado por IA; otros entregan un enredo. La diferencia rara vez es talento; es prompt y contexto. 3. Conocimiento que no escala: alguien descubre un patrón excelente para levantar el scaffolding de un microservicio, pero el equipo no lo absorbe. 4. Onboarding lento: un ingeniero nuevo pierde semanas hasta descubrir, de boca en boca, "qué IAs usamos para qué".
Lo que funciona: kit compartido y contexto vivo
La respuesta no es obligar a todos a usar el mismo IDE. La respuesta es armar un kit compartido: system prompts versionados, slash commands reutilizables, reglas de revisión consensuadas, plantillas de spec, un estándar de mensaje de PR, un estándar de commit, ejemplos comentados. Cada pieza vive en un repositorio, tiene un owner, tiene un PR de cambio, tiene changelog.
La ganancia es doble. Primero, cualquier persona, en cualquier IDE, puede invocar el mismo estándar. Segundo, el aprendizaje de una persona entra en el kit y queda disponible para todas las demás. El kit es un repositorio de inteligencia colectiva de la empresa. Sin él, la IA se vuelve un fenómeno individual; con él, se vuelve una capacidad de equipo.
La estandarización también necesita cubrir el contexto de proyecto: archivos como CLAUDE.md, AGENTS.md, .cursorrules, instrucciones a nivel del repositorio, que describen el stack, los estándares, las decisiones y el contexto que cualquier agente necesita conocer para colaborar sin descarrilar. Sin eso, los agentes lo redescubren todo desde cero en cada conversación y producen inconsistencia.
Desafío 2, Seguridad y homologación: quién aprueba, cómo aprobar, sin volverse una fila eterna
"¿Puedo usar IA?", "¿Este dato puede entrar en el prompt?", "¿Quién aprueba una herramienta nueva?", "¿Cómo garantizar que no se filtre un secreto?". Toda empresa seria con la IA choca con estas preguntas. Las respuestas equivocadas generan dos extremos: política laxa (dato sensible que se va) o política trabada (el ingeniero queda fuera del mercado de la productividad). El punto óptimo está en una política clara, ligera y operacionalizada.
Lo que mantiene despierto al líder técnico por la noche
Cinco riesgos reales. Filtración de código propietario en un prompt hacia una herramienta que entrena con datos. Filtración de dato personal (LGPD) en una conversación con IA. Credenciales y secretos pegados en el prompt e indexados por un motor externo. Output no auditable: nadie logra reconstruir lo que hizo el agente ayer. Conformidad regulatoria (SOC2, ISO 27001, normas del banco central, ley de protección de datos): un auditor pregunta "¿cómo garantizan X?" y la respuesta tiene que existir.
El camino práctico: política en tres capas
Capa 1, Herramientas aprobadas y configuradas bien. Una lista corta de proveedores aprobados, con contratos de procesamiento que prohíben el entrenamiento con datos del cliente, planes enterprise con SSO y auditoría, configuraciones por defecto que bloquean la telemetría innecesaria. Ingeniería elige entre las aprobadas; no necesita pedir aprobación caso por caso.
Capa 2, Clasificación de datos. Una tabla simple: dato público (libre), dato interno (en herramientas aprobadas), dato personal (anonimizar o usar un ambiente aislado), dato regulado/secreto (prohibido en herramienta externa). Cada ingeniero puede mirar la tabla y decidir en segundos, sin fila de aprobación.
Capa 3, Auditoría automática. Logs de prompt, contexto y respuesta capturados en un storage append-only, con retención compatible con el requisito legal. Un detector de secretos en el prompt antes de enviarlo (regex + heurística + IA). Alertas automáticas cuando aparece un patrón sospechoso. El ingeniero no necesita "acordarse" de seguir la política; el ambiente la impone.
Una homologación que no se vuelve cuello de botella
El otro lado de la seguridad es la homologación. Cuando la IA está involucrada, surge la pregunta natural: "¿quién aprueba ese output?". La respuesta varía según el contexto. En código de bajo riesgo (un script interno, un ajuste estético), la revisión estándar de PR basta. En código que toca reglas de negocio críticas (cobro, contratos, salud), la homologación necesita un criterio explícito (pruebas que cubran los criterios de aceptación, revisión doble, validación de producto).
El error es tratar todo igual. O la homologación queda laxa en código crítico (generando incidentes) o queda rigurosa en código irrelevante (matando la velocidad). Una política madura define niveles de riesgo y adecúa el nivel de revisión. Ese escalonamiento es lo que separa a la empresa que homologa bien de la empresa que se vuelve una fila.
Desafío 3, Volumen y revisión: cuando el output se multiplica, la revisión tiene que cambiar
Con la IA escribiendo código, el volumen de output crece mucho más rápido que la capacidad de revisar y absorber. Un ingeniero que abría 2 PRs por día pasa a abrir 8. Un PR que tenía 200 líneas pasa a tener 600. Un revisor que tenía 30 minutos por día para revisar necesitaría, en la vieja ecuación, 4 horas. No da. El efecto es un backlog de revisión, la calidad de revisión cayendo en silencio, retrabajo en el siguiente sprint, y conflictos de merge multiplicándose.
La paradoja de la revisión post-IA
La revisión era barata cuando el código era caro. Ahora el código es barato y la revisión es cara. Las empresas que no perciben esta inversión siguen tratando la revisión como "actividad lateral del sénior" y descubren el problema cuando alguien pregunta por qué la velocidad percibida de entrega cayó incluso con la IA escribiendo "todo".
Patrones que funcionan
1. IA como primer revisor con un checklist explícito: seguridad, performance, conformidad con el style guide, regresión de comportamiento, pruebas que cubran los criterios. El humano entra como segundo revisor, enfocado en la intención, la arquitectura y el trade-off no obvio.
2. PRs más pequeños y más frecuentes. Límites duros: máximo 400 líneas, máximo 24h abierto. Cuando la IA genera un cambio grande, dividirlo en pedazos revisables es tarea del autor (con ayuda de la IA, claro). Un PR gigante es un antipatrón, no una victoria.
3. Revisión por intención, no por línea. El revisor humano no necesita leer cada línea. Necesita entender la intención, validar que la prueba cubre los criterios, verificar los puntos de riesgo señalados por el revisor automático. Línea por línea es trabajo que la IA hace mejor.
4. Adaptación continua de los procesos. La primera versión de la nueva revisión va a estar equivocada. Es normal. El equipo necesita tener el hábito de revisar su propio proceso cada 4-6 semanas: ¿qué está demorando? ¿Dónde se escapan bugs? ¿Dónde estamos retrabajando? Sin esa revisión de proceso, los patrones viejos persisten y la ganancia de la IA se evapora.
5. Métricas de revisión visibles. Tiempo promedio de PR abierto. Tiempo hasta la primera revisión. Tasa de PRs con refactorización post-merge. Cuando estas métricas se vuelven visibles en el dashboard del equipo, el comportamiento cambia. Cuando quedan escondidas, el problema se acumula.
Paralelismo: la frontera que lo cambia todo
El volumen no es solo vertical (más líneas por PR); es horizontal (más cosas ocurriendo en paralelo). Un ingeniero que antes trabajaba una feature a la vez ahora trabaja tres, con ayuda de agentes. Esto exige orquestación: cómo el equipo decide qué está en marcha, quién está bloqueado por quién, cómo evitar conflictos de merge y duplicación de esfuerzo. Los tableros visuales que tenían sentido a un ritmo de 2 PRs/día necesitan repensarse para un ritmo de 8 PRs/día. Los equipos que mantienen la vieja cadencia de stand-up y planning descubren que se volvió un ritual sin efecto.
Desafío 4, Plazos más agresivos, calibrados con inteligencia
Aquí vive una paradoja interesante. La IA acorta partes del ciclo (spec, código, algunos pasos de revisión), lo que da margen para entregas más rápidas. Pero no todas las fases se acortan en la misma proporción: homologación, UX detallada, validación con el cliente, fase de hardening y estabilización siguen su propio ritmo. Quien recorta el plazo por igual en todo entra en rumbo de colisión. Quien mantiene el plazo igual en todo pierde la ganancia real disponible.
El ajuste fino del plazo
La buena noticia: se puede validar antes y correr entregas en ciclos más chicos. El spec sale más rápido; un prototipo funcional sale más rápido; se puede llevar al cliente una versión "navegable" en la mitad del tiempo que antes hacía falta para llegar al mismo punto. Ese acortamiento abre espacio para iteraciones reales, en lugar de "una entrega grande al final".
La mala noticia: la revisión de producto, la homologación rigurosa, la UX bien terminada, la comunicación con stakeholders y la preparación del release siguen un ritmo humano. Forzar esas fases a "andar a la misma velocidad de la IA" genera dos efectos: aprobaciones a las apuradas que se vuelven bugs en producción, o la frustración de un equipo que entrega rápido y se queda esperando la aprobación durante semanas.
El camino: priorizar bien y alinear expectativas
Las empresas que aciertan hacen tres cosas simultáneas. 1. Ciclos más cortos con alcance más enfocado: en lugar de "una entrega trimestral grande", "una entrega quincenal pequeña con validación real". 2. Alineación de expectativas con los stakeholders: dejar claro que código rápido no significa cliente satisfecho rápido; que la UX y la homologación tienen su propio ritmo. 3. Priorización explícita: decir que no a una feature que podría haberse hecho "porque daba el tiempo", y que sí a la feature que mueve la métrica de negocio. Sin priorización, el tiempo extra que la IA libera lo absorbe un backlog más amplio, no una entrega más valiosa.
Los tech leads y el nuevo rol de "calibrador"
El tech lead se vuelve la figura central en esta calibración. No en el sentido de "controlador de plazos", sino de negociador entre el ritmo de la IA y el ritmo de las otras partes. ¿Cuánto de esto va a más iteración? ¿Cuánto a más pulido? ¿Cuánto a más experimentación? ¿Cuánto a liquidar bugs y deuda técnica? Una decisión de tech lead, conversada con producto y stakeholders, con datos, no con intuición.
Los cuatro desafíos juntos: la foto completa
Estandarización, seguridad, volumen de revisión y calibración de plazos son desafíos interconectados. Fallar en estandarización empeora el volumen (cada uno inventa un patrón distinto). Fallar en seguridad traba la velocidad (homologación infinita). Fallar en revisión genera retrabajo. Fallar en plazos genera frustración y burnout. Atacar uno sin atacar los otros genera la ilusión de progreso.
El camino que funciona es tratar la adopción de IA como un cambio de proceso, no como una compra de herramienta. Esto pide tiempo del tech lead, atención del líder de plataforma, una conversación con seguridad, alineación con producto, métricas honestas y disposición a reescribir procesos viejos. No cabe en un PowerPoint de 5 diapositivas. Cabe en un compromiso de 6 a 12 meses de iteración continua.
Lo que separa a quien destraba de quien se traba
Cuatro hábitos. 1. Medir antes de cambiar: sin datos, la intuición se equivoca sobre cuál es el cuello de botella. 2. Tratar el proceso como un producto: tiene owner, tiene versión, tiene revisión regular, tiene retrospectiva. 3. Invertir en tooling interno: el kit compartido, el auditor automático, el dashboard de cycle time. Sin tooling, la política se vuelve folclore. 4. Decirle la verdad al liderazgo: la IA no es magia, el plateau existe, la ganancia real exige rediseño. Un líder que escucha esto correctamente invierte bien; un líder que escucha una promesa la convierte en un misil en PDF y exige resultados imposibles.
Cómo conducimos esto en Steply
Cuando un cliente nos pide "ayúdennos a adoptar IA", el primer sprint es casi siempre un diagnóstico de estos cuatro desafíos. ¿Dónde está la inconsistencia? ¿Cuál es la política de datos vigente? ¿Dónde están los cuellos de botella de revisión? ¿Cómo se negociaron los plazos en las últimas tres entregas? A partir del diagnóstico, armamos un roadmap de 8 a 16 semanas, con entregables específicos: kit compartido, política de datos con niveles, rediseño de la revisión, dashboard de cycle time, ciclos de retrospectiva instrumentados.
El resultado más común no es "la productividad se duplicó". Es "la productividad subió de forma sostenible y visible, y el equipo dejó de sentir que la IA es problema de los demás". Ese "sostenible" es lo que diferencia una adopción que perdura de un hype que se evapora. Los cuatro desafíos que nadie cuenta son, en realidad, los cuatro cimientos. Quien construye sobre ellos destraba el plateau. Quien los ignora paga intereses compuestos durante años.