Un equipo de ingeniería cree que tiene un problema de adopción de IA. En realidad tiene tres, y son distintos entre sí.
Cuando se observa cómo usa IA cada persona de un equipo de ingeniería, aparecen de forma consistente tres niveles.
- Quienes usan IA en modo chat: con prompt engineering más o menos elaborado, lanzando consultas puntuales y copiando el resultado —código o texto— a su entregable.
- Quienes ya la tienen integrada en el IDE: para generación de código, con alguna skill definida, un archivo de contexto propio, y un pequeño framework de trabajo que aplican a diario.
- Quienes manejan varios agentes en paralelo: a veces de forma colaborativa entre ellos, apoyados en un harness propio que mantiene contexto, orquesta llamadas y controla qué modelo se usa en cada paso.
La tentación al definir el stack estándar del equipo es resolverlo por arriba o por abajo.
- Por arriba: dar a todos acceso a los agentes y modelos más potentes, asumiendo que así se acelera la madurez del conjunto.
- Por abajo: limitar el stack al nivel más básico para simplificar la gestión y evitar dispersión.
Las dos fallan por el mismo motivo: ignoran que la madurez con IA no se decreta, se construye, y un stack mal calibrado frena tanto a quien ya opera en el nivel tres como a quien todavía está en el nivel uno.
Hay un hallazgo adicional que ayuda a calibrar el stack con más precisión, y que tiene que ver con el tipo de tarea, no solo con el nivel de madurez de la persona.
Los roles centrados en definición y análisis —perfiles de producto y de liderazgo técnico— obtienen más valor diferencial de los modelos frontera, los más recientes y capaces, precisamente en tareas abstractas, poco acotadas, que exigen entender el problema antes de resolverlo. En cambio, cuando la definición ya está clara y lo que queda es implementar, ese diferencial de los modelos frontera se reduce mucho. Con un buen harness de orquestación —o incluso trabajando de forma directa en tareas sencillas y bien acotadas— los modelos estándar dan resultados equivalentes a un coste muy inferior.
El riesgo oculto de no tener esto en cuenta es doble. Pagar el precio de un modelo frontera para tareas de implementación acotada es gasto sin retorno real. Pero el error inverso es igual de caro: usar un modelo económico sin contexto ni harness para tareas de definición abstracta, donde sí importa la capacidad de razonamiento del modelo, produce resultados mediocres que luego hay que rehacer. El stack no se define por presupuesto ni por moda. Se define cruzando el nivel de madurez de quien lo usa con el tipo de tarea que va a resolver.
La prescripción para este bloque del framework es mapear, no imponer:
Identificar en qué nivel está cada persona del equipo hoy, y qué tipo de tareas —de definición abstracta o de implementación acotada— resuelve habitualmente. A partir de ahí, reservar el acceso a modelos frontera para las fases de análisis y diseño donde de verdad marcan diferencia, y estandarizar modelos más económicos, bien integrados en IDE y con contexto persistente, para el grueso del trabajo de implementación diario.
Un equipo de ingeniería no tiene un único nivel de madurez con IA, tiene varios conviviendo a la vez. El stack que funciona es el que reconoce esa diversidad en vez de intentar borrarla.
Cada semana sigo analizando este tipo de temas aquí. Si llegaste por primera vez, bienvenido. Y si no quieres perderte la siguientes, suscríbete que es GRATIS. 😉