Imagina la escena: sprint planning un lunes por la mañana. Tres desarrolladores usan Cursor, dos copian y pegan desde ChatGPT, el senior se niega a tocar nada de esto porque «no me fío del código que genera» y el junior lo usa para absolutamente todo, incluyendo cosas para las que no debería. El resultado: cada PR tiene un estilo diferente, nadie sabe qué herramienta generó qué, y cuando preguntas cómo va la adopción de IA en el equipo, la respuesta más honesta es un encogimiento de hombros.
Si te suena familiar, no estás solo. Según los últimos datos de Pragmatic Engineer (2026), el 95% de los ingenieros ya usan herramientas de IA semanalmente. Pero el número que importa de verdad es otro: el 70% usa entre 2 y 4 herramientas o modelos diferentes cada semana. No hay un stack unificado. No hay criterio compartido. Solo fragmentación total disfrazada de adopción.
Y ese es el problema real: la mayoría de empresas creen que adoptar IA significa comprar licencias. Eso es el paso cero.
El espejismo de la licencia
El patrón se repite en todas las organizaciones. Alguien en dirección aprueba el presupuesto para licencias de Copilot o Claude, envía un email diciendo «ya tenéis acceso» y espera a que la magia ocurra sola.
Los números de Harvard Business Review de este año son demoledores: el 95% de las organizaciones no ven ningún ROI en sus iniciativas de GenAI, y el 74% están atrapadas en el «purgatorio del PoC», pruebas de concepto que nunca escalan a producción real.
Bain cuantificó la brecha con precisión: las herramientas de IA para código usadas de forma aislada producen una mejora del 10-15% en productividad. Pero cuando hay transformación de extremo a extremo (directrices, procesos, métricas y cultura), ese número sube al 25-30%. La diferencia no es la herramienta. Es todo lo que la rodea.
La analogía que ya he vivido: Mobile-First
Cuando Android empezó a explotar, las empresas no se limitaron a decir «haced una app» y listo. Bueno, algunas sí. Y esas apps se convirtieron en desastres legendarios. Las que lo hicieron bien cambiaron procesos, construyeron equipos dedicados, adaptaron sus métricas, definieron guías de UX para iOS y Android, y redefinieron lo que significaba «release» cuando ya no controlabas cuándo actualizaba el usuario.
Lo mismo pasó con Kotlin. Decir «podéis usar Kotlin» sin un plan de migración, sin directrices para la coexistencia con Java, sin formación – receta para un codebase Frankenstein.
La adopción de IA sigue exactamente el mismo patrón. Dar licencias sin un plan es el equivalente en 2012 de «haced una app móvil» sin cambiar nada más. Puedes tener la mejor herramienta del mercado: Claude Code ha superado a GitHub Copilot como la herramienta más usada en 2026 [1], pero si cada uno la usa a su manera, sin criterio compartido, el resultado es inconsistencia disfrazada de velocidad.
Cómo es una adopción real de IA
Si me preguntas, hay cinco bloques que no te puedes saltar.
1. Define el stack de IA de tu equipo
No se trata de prohibir herramientas, sino de tener un stack recomendado y documentado. Igual que tienes estándares para linting, testing y CI, necesitas uno para IA. Qué herramienta para generación de código. Cuál para code review. Cuál para documentación. Y por qué.
Pero un stack no es solo una lista de herramientas aprobadas. Es configuración compartida. En mi equipo, hemos desarrollado algo que la verdad llevábamos tiempo queriendo hacer; al final lo conseguimos al tener más recursos en el equipo core. Hemos ido un paso más allá: construimos un plugin de Claude Code que empaqueta todo el toolkit de IA del equipo en una única unidad instalable. Cada desarrollador tiene la misma configuración con un solo comando. Los mismos prompts, el mismo conocimiento de la arquitectura, los mismos estándares de código integrados. No una página de documentación que diga «por favor, usad estas herramientas». Una configuración real compartida por la que pasa cada interacción con IA. Estamos actualmente en proceso de desplegarlo en todo el equipo; quizá lo cubra en un futuro artículo.
Hay que ir mucho más allá: no solo elegimos la herramienta, la configuramos para que conozca nuestro codebase.
2. Crea directrices de uso reales
El informe DORA 2025 reveló un número que debería estar en la pared de cada Engineering Manager: los equipos con políticas claras de uso de IA ven una adopción 4,5 veces mayor que los que no las tienen. No es un matiz – es la diferencia entre adoptar de verdad y estar jugando.
¿Qué incluyen esas directrices? Cuándo usar IA y cuándo no. Qué tipo de código requiere revisión humana exhaustiva (pista: todo lo que toca seguridad, datos personales o lógica de negocio crítica). Cómo documentar qué partes del código fueron generadas o asistidas por IA. Qué prompts y configuraciones comparte el equipo.
El concepto de AI Usage Charter de LeadDev – co-creado con los ingenieros, no impuesto por dirección, revisado trimestralmente – es un buen punto de partida. Pero la evolución que he visto en la práctica es esta: el destino natural de los estándares de código no es un documento que el equipo debería leer. Son esos estándares embebidos en la propia herramienta de IA, ejecutándose automáticamente en cada PR, sin depender de que nadie se acuerde de consultar la wiki. En el plugin que estamos ideando en el equipo, cuando un desarrollador lanza una review de PR, no recibe una review genérica de IA. Recibe una review contra la arquitectura real del equipo: nuestros patrones de Compose, nuestro modelo de manejo de errores, nuestras directrices de testing, nuestras reglas de seguridad. Todo precargado. Los estándares de código ya no son un documento de referencia. Son un sistema en ejecución.
3. Onboarding progresivo, no Big Bang
No todo el mundo parte del mismo punto. Los early adopters ya están experimentando, el riesgo con ellos es evangelizar sin criterio. Los escépticos (normalmente los seniors más experimentados) necesitan algo diferente: no un pitch, sino evidencia concreta de que la herramienta resuelve problemas que ellos reconocen como reales.
Lo que la mayoría de líderes no ven: la resistencia senior a la IA rara vez es técnica. Es una cuestión de identidad profesional. Si llevas 15 años resolviendo problemas complejos y alguien te dice que una IA puede hacerlo, la reacción natural no es curiosidad: es amenaza. Ignorar esto y etiquetarlo como «resistencia al cambio» es un fallo de liderazgo, no un problema de ingeniería.
Barry O’Reilly lo clavó en HBR este año: la resistencia basada en identidad es el patrón dominante en la adopción de IA, no el escepticismo técnico. El senior que cuestiona todo no es tu obstáculo, está haciendo stress testing de tu plan de adopción gratis. Sus preguntas («Y el testing?» «Quién es responsable del código generado?» «Qué pasa con la seguridad?») son tu hoja de ruta de adopción.
Es interesante medir el sentimiento del equipo hacia las herramientas de IA de forma continua, no solo el throughput. Porque si tu equipo odia la herramienta pero saca más PRs, tienes una bomba de relojería a seis meses vista, no un caso de éxito.
4. Adapta el code review al mundo post-IA
Este es el punto del que casi nadie habla. Si tu equipo genera código un 20% más rápido, ¿quién revisa ese 20% extra? ¿Con qué criterio? Hay estimaciones de un aumento del 2.500% en defectos de código generado por IA sin supervisión adecuada. Velocidad sin quality gates es deuda técnica acelerada.
La respuesta no es un checklist manual pegado al monitor. La review asistida por IA necesita llevar el mismo contexto que la generación asistida por IA. Si la IA que escribe el código no conoce tu arquitectura, va a producir basura con buena pinta. Si la IA que lo revisa tampoco la conoce, va a dar el visto bueno a esa basura con un pulgar arriba.
Por eso construimos tooling de IA consciente del equipo. Cuando nuestro plugin ejecuta una review de PR en código Android, no busca problemas genéricos – comprueba contra los patrones concretos que hemos acordado como equipo. Nuestras convenciones de Compose. Nuestro enfoque de testing de ViewModels. Nuestros patrones de inyección de dependencias. La review está enmarcada bajo unos criterios porque nosotros la hicimos así, y esos criterios son las del equipo, no los defaults del modelo.
Y esto conecta con algo que escribí en Tokenmaxxing: medir tokens consumidos como proxy de productividad es exactamente el tipo de métrica vacía que surge de una adopción sin plan. Es la versión IA de medir líneas de código – un número bonito que no te dice absolutamente nada sobre el impacto real.
5. Mide lo que importa, no lo fácil de medir
Las métricas de adopción de IA deberían responder preguntas concretas: ¿Ha bajado el time-to-merge? ¿Ha mejorado la calidad del código en PRs asistidas frente a las no asistidas? ¿Ha disminuido el tiempo de onboarding de nuevos desarrolladores?
Pero medir la adopción no es suficiente. Necesitas medir la calidad y la eficiencia. Y para eso, no puedes fiarte de los benchmarks del vendor.
Esto es otro proyecto que estamos construyendo ahora: un framework de evaluación interno para nuestro codebase Android (primer paso, después iOS). Tareas reales, las mismas que nuestros desarrolladores resuelven cada semana. El agente de IA corre en un contenedor Docker aislado con el Android SDK, intenta la tarea, y el framework evalúa el resultado ejecutando tests de Gradle. Escribir tests de ViewModel. Construir una pantalla Compose desde cero. Crear componentes de UI reutilizables. Mutation testing para verificar que los tests de la IA realmente pillan bugs reales.
En lugar de enviar manualmente 50 PRs idénticas para comparar herramientas, automatizas la comparación. Puedes ejecutarlo contra diferentes modelos, diferentes versiones del agente, diferentes configuraciones de prompts, y obtener resultados reproducibles y comparables. No confíes en el benchmark de Anthropic para saber si Claude Code funciona bien con tu código. Construye el tuyo. Las tareas que uses para evaluar deberían ser las mismas que tu equipo resuelve cada semana.
Estos dos sistemas, el plugin que da a la IA el contexto de tu equipo, y el framework de evaluación que mide si la IA realmente funciona bien con tu código, son las dos caras de la misma moneda. Contexto más medición. Esa es la brecha entre la mejora del 10-15% y la del 25-30%.
Los tres errores que veo una y otra vez
Después de participar en adopciones tecnológicas de esta escala, Android en empresas que solo hacían web, Kotlin en codebases Java con cientos de miles de líneas. Los errores siguen un patrón predecible:
- Dejar que los early adopters evangelicen solos. El entusiasta que monta una demo un viernes por la tarde no es una estrategia de adopción. Es una persona que se va a quemar cuando nadie le escuche.
- Ignorar a los escépticos en vez de integrarlos. Los seniors que cuestionan la IA suelen tener las mejores preguntas: «Y el testing?» «Quién se responsabiliza del código generado?» «Cómo afecta esto a la seguridad?» Esas preguntas son tu hoja de ruta de adopción, no tu obstáculo.
- No adaptar los procesos downstream. Generar código más rápido sin adaptar code review, QA y deploy es como ponerle un motor de F1 a un coche con frenos de bicicleta. Las ganancias de velocidad se evaporan o, peor, se convierten en deuda técnica que pagarás con intereses.
En definitiva
Adoptar IA en un equipo de desarrollo no es un problema de herramientas. Es un problema de gestión del cambio. Y como cada cambio tecnológico que hemos vivido – móvil, cloud, microservicios, Kubernetes – los que lo hacen bien no son los que llegan primero, sino los que llegan con un plan.
Si buscas por dónde empezar mañana, mi sugerencia: elige dos cosas.
Primero, codifica los estándares de tu equipo como conocimiento del agente. Coge tus convenciones de código, tus decisiones de arquitectura, tus directrices de testing – todo lo que actualmente vive en una página de Notion o Confluence que nadie lee – y conviértelo en configuración que tus herramientas de IA realmente consuman. No un documento de referencia. Un sistema que se ejecuta.
Segundo, define 3-5 tareas reales como tu benchmark interno. Tareas que tu equipo resuelve cada semana de verdad. Ejecuta tu tooling de IA contra ellas. Mide los resultados. Y vuelve a ejecutarlas el mes que viene después de mejorar la configuración. Ese es tu feedback loop. Vale más que cualquier benchmark de vendor.
Define tu stack de IA. Crea directrices con el equipo, no para el equipo. Mide impacto real, no tokens consumidos. Integra a los escépticos. Adapta tus procesos.
La pregunta no es si tu equipo va a usar IA. Ya la usan. La pregunta es si tú, como líder técnico, vas a dejar que eso ocurra de forma caótica o lo vas a liderar con la misma intencionalidad que aplicas a cada decisión técnica relevante.
Deja un comentario