Los equipos te muestran cifras de uso de IA todo el tiempo. Lo difícil es encontrar algo que construyan de forma distinta gracias a ella.
Cada organización de ingeniería con la que he hablado este año tiene una versión del mismo gráfico. Activaciones de licencias en aumento. Gasto en tokens en aumento. Alguien presenta una diapositiva con un 80% de usuarios activos semanales. Luego te sientas en la reunión de planificación de ese equipo y nada de cómo construyen software ha cambiado.
Esa brecha es el problema real, y la mayor parte de cómo medimos la adopción de la IA está diseñada, accidentalmente, para ocultarla.
Todo lo que estás midiendo es una métrica de uso
El gasto en tokens te dice que alguien escribió en un cuadro. El número de solicitudes de extracción te dice que se enviaron confirmaciones. El "porcentaje de código escrito por IA" te dice que se aceptó un autocompletado. Nada de eso te dice que el trabajo haya mejorado.
La ley de Goodhart, como siempre. En el momento en que un número se convierte en el objetivo, deja de describir la realidad y empieza a describir el incentivo.
La versión más clara de este fracaso ni siquiera es específica de la IA. Todo ingeniero ha visto a un equipo superar un umbral de cobertura con pruebas que no aseguran nada. expect(true).toBe(true). Línea cubierta, número en verde, nada probado. La métrica se cumplió y el objetivo se abandonó, y el panel no tiene forma de notar la diferencia.
Las métricas de uso de IA tienen la misma forma. Si le digo a mi equipo que el uso es una señal de rendimiento, el uso sube en una semana y no he aprendido nada, excepto que saben leer los incentivos. Lo cual ya sabía.
Una mejor pregunta: si eliminaras estas herramientas mañana, ¿qué se rompería? No de qué se quejaría la gente. Qué se rompería. Si la respuesta honesta es "nada, la gente estaría levemente molesta", no tienes adopción. Tienes una suscripción.
Tres cosas se llaman adopción. Solo una perdura.
Cuando investigo qué significa "hemos adoptado la IA" en un equipo específico, es una de estas tres cosas, y no tienen el mismo valor.
Alguien cambia su propio flujo de trabajo. Escriben mensajes de confirmación con ella o la usan para orientarse en código desconocido. Real, útil, casi totalmente efímero. Ante la primera fecha límite estricta, vuelven a lo que ya saben que funciona. Eso no es un problema de disciplina. Bajo presión, la gente toma el camino de menor incertidumbre disponible, y un nuevo flujo de trabajo es, por definición, el de mayor incertidumbre.
Alguien delega permanentemente una tarea recurrente. No es "usé IA hoy", sino "ya no hago esto, un flujo de trabajo lo hace y yo reviso el resultado". Eso sobrevive a las fechas límite, porque volver atrás significaría crearse trabajo a sí mismos. También se va cuando ellos se van.
O el equipo cambia cómo hace algo, a propósito. Alguien decidió que un paso del proceso ahora funciona de cierta manera, lo dejó por escrito y se mantiene, sin importar si algún individuo se siente entusiasmado o no. Solo la tercera opción sobrevive a la rotación y a un mal trimestre.
La mayoría de las organizaciones celebran la primera, ocasionalmente alcanzan la segunda y nunca llegan a la tercera. Porque la tercera no es un problema de herramientas. Comprar licencias es una conversación de presupuesto. Cambiar una norma significa decir en voz alta que la forma antigua era peor y luego hacerse cargo cuando la nueva forma rompe algo en la tercera semana.
En Webflow, lo que nos funcionó fue tratar los prompts como artefactos compartidos y versionados en lugar de propiedad personal. La gente solía guardarlos en archivos temporales, ajustarlos en privado durante semanas y perderlos la próxima vez que cambiaban de máquina. Ahora, los buenos viven en el repositorio con un propietario, una nota sobre cuándo usarlos y revisión de cambios, igual que cualquier otro código. No costó nada en herramientas. Lo que requirió fue decidir que esta categoría de cosas valía la pena mantenerla.
Se ha mantenido porque no depende del entusiasmo de nadie. Los nuevos ingenieros heredan la buena versión en lugar de pasar un mes redescubriéndola. Cuando alguien encuentra una mejora, todos la obtienen en lugar de que una sola persona mejore silenciosamente en su trabajo.
Los agentes comienzan bien el trabajo pero lo gestionan mal
Este es el patrón que mata la adopción antes de que un equipo llegue a ese tercer nivel.
La ventaja se concentra al inicio de una tarea. Pasar de una página en blanco a un borrador aceptable es mucho más rápido que antes. Pasar de un borrador aceptable a algo correcto y listo para publicar no es más rápido en absoluto, y esa mitad sigue siendo cosa tuya.
Así que un ingeniero calcula que puede empezar cinco cosas a la vez, las lanza todas y se siente productivo haciéndolo. Luego, las cinco cosas vuelven necesitando revisión, y la revisión se ejecuta de forma monohilo en una sola cabeza, sobre un trabajo que no escribió y que tiene que reconstruir desde cero. No ha paralelizado nada. Ha serializado su propia atención, con una profundidad de cola que nadie habría elegido a propósito.
Terminan la semana más ocupados y menos seguros que la anterior, lo cual es una experiencia francamente peor. Mucha gente prueba los flujos de trabajo con agentes una vez, siente exactamente eso y lo deja discretamente. Semanas después, aparece como una caída en el uso y se diagnostica como una falta de formación.
No lo es. Es un problema de la forma en que se trabaja. Delegar en un agente tiene el mismo límite que delegar en una persona: la capacidad de revisión de quien sigue siendo responsable. Los equipos que están sacando valor real de esto han sido específicos sobre qué trabajo es seguro delegar con una revisión ligera y cuál no, en lugar de tratar todo como igualmente delegable.
No puedes gestionar una adopción que no puedes medir.
Si no puedes medir el resultado, cualquier discusión sobre si un flujo de trabajo funciona es una discusión basada en sensaciones. Y las discusiones basadas en sensaciones las gana quien más confianza muestra en la sala, lo cual es una forma terrible de dirigir la ingeniería.
Medir no significa usar benchmarks. Los benchmarks te dicen que un modelo es bueno en general. Necesitas saber si este flujo de trabajo es bueno para lo específico que hace tu equipo, algo que ningún benchmark cubre. Unas cuantas docenas de casos reales de tu propio dominio, evaluados según una rúbrica que tú mismo escribiste, y que se vuelven a ejecutar cada vez que alguien cambia un prompt o cambia de modelo. Lo pequeño está bien. El objetivo no es la precisión, sino tener un número que se mueva por razones que entiendas.
Sin eso, no puedes distinguir un flujo de trabajo que ha mejorado de uno cuyos fallos se han vuelto más fluidos. En una demo, parecen idénticos.
Lo que yo haría realmente
Elimina un trabajo manual recurrente por persona, de forma permanente. No "prueba la IA en él". Quítalo de su semana y haz que el flujo de trabajo sea el responsable oficial. Un trabajo que se elimina para siempre vale más que diez experimentos.
Haz oficial exactamente una norma de equipo, por escrito, este trimestre. Solo una. Lo suficientemente pequeña como para que realmente la cumplas, y lo suficientemente específica como para que alguien pueda incumplirla.
Deja de reportar el uso hacia arriba. Reporta el resultado que se suponía que debía producir ese uso, incluyendo los trimestres en los que ese número parece peor de lo que parecería el uso.
Nada de esto requiere una herramienta nueva, que es gran parte de la cuestión. Las herramientas son la parte más barata de esto y son las que más atención absorben. La parte cara es estar dispuesto a cambiar cómo trabaja un equipo a propósito, en público y dando la cara.
