Systems Thinking Radar - Vol. 8
Atrofia de habilidades por IA. Garbage can model. Efecto Gell-Mann Amnesia
Últimamente gran parte de lo que consumo gira en torno a la IA. Me resisto bastante a traer esos temas aquí porque se vuelven obsoletos muy rápido, y suelo ser lento ordenando mis ideas sobre el papel. Aun así, hay cuestiones que envejecen más lentamente: los modelos mentales que voy coleccionando para entender cómo nos está afectando esta disrupción tecnológica. Así que hoy comparto algunos de ellos.
🔄 Un bucle
El círculo vicioso de la atrofia de habilidades por IA
Que la IA nos hace más productivos en muchos aspectos tiene poca discusión a día de hoy. El debate está más bien en qué tipo de tareas, en qué fases del desarrollo, bajo qué condiciones. Pero el porcentaje de áreas donde estas herramientas nos vuelven más eficaces es ya notable.
No quiero entrar en ese debate (que además, quedaría obsoleto en un par de semanas), sino centrarme en un efecto colateral que empieza a preocupar: la atrofia de habilidades. Allí donde dejamos que la IA haga el trabajo por nosotros, dejamos también de practicar. Y cuando dejamos de practicar algo durante el tiempo suficiente, esa habilidad se deteriora.
Dado que los escenarios en los que trabajar sin IA es lo ideal, son cada vez más escasos y menos evidentes, perdemos incentivos para mantener ciertas capacidades de forma deliberada. Cuando el contexto vuelva a exigirlas, puede que ya sea demasiado tarde.
Addy Osmani advierte sobre este riesgo en una entrega reciente de su newsletter:
El auge de los asistentes de IA en la programación ha generado una paradoja: puede que estemos aumentando la productividad, pero corremos el riesgo de perder nuestra ventaja debido a la atrofia de habilidades si no tenemos cuidado.
Esto es un ejemplo clásico del arquetipo sistémico desplazamiento de la carga hacia la intervención, del que ya hablamos en La trampa de la adicción al parche.
Se pone en marcha un círculo vicioso fácil de reconocer:
Productividad vs. comprensión
Cada vez que dejamos que la IA resuelva algo que podríamos resolver nosotros, estamos cambiando comprensión a largo plazo por productividad a corto plazo.
Y siempre que hay tensión entre el corto y el largo plazo, los sistemas de doble loop es un marco mental que me ayuda a orientarme.
En el corto plazo hay un bucle de refuerzo evidente: usamos la IA y percibimos impacto inmediato. Con la cultura y procesos adecuados, ese impacto puede incluso ir más allá del código y reflejarse en resultados de negocio.
Pero el peaje que pagamos por no practicar nuestras habilidades técnicas tiene un efecto más lento, menos visible, y puede acumular consecuencias que no percibiremos hasta que ya sea demasiado tarde.
Entornos perversos vs. benignos
En ausencia de incentivos inmediatos, mantener nuestras habilidades requiere un esfuerzo deliberado. Y eso no siempre es viable en todos los contextos.
En otra newsletter reciente, David Epstein recupera una distinción del psicólogo Robin Hogarth: no todos los entornos enseñan bien.
Entornos de aprendizaje benignos: feedback claro, rápido y útil. Aprendes rápido, mejoras con la práctica.
Entornos de aprendizaje perversos: feedback tardío, ambiguo o inexistente. Puedes ganar confianza sin mejorar realmente.
Usar IA genera un feedback inmediato: el código aparece, funciona, y lo damos por válido. Es un entorno aparentemente benigno.
Pero el impacto real en nuestras habilidades es más lento y silencioso. No notas que estás perdiendo destreza… hasta que la necesitas. Es ahí donde el entorno se vuelve perverso: operas con confianza, pero sin darte cuenta de que tu capacidad se ha erosionado.
Convertir nuestro entorno en benigno
Las propuestas que plantea Addy Osmani me resonaron especialmente con esta distinción de Epstein, porque lo que hacen es precisamente eso: volver benigno un entorno que, si se deja en piloto automático, tiende a volverse perverso.
Lo hacen introduciendo feedback loops más rápidos, visibilidad del deterioro, y mecanismos de control.
Ideas concretas que he escogido y adaptado:
Días sin IA: simular un apagón para poner a prueba nuestras habilidades sin asistencia. Puede revelar qué hemos olvidado y qué necesitaríamos recuperar si la IA no estuviera disponible.
Práctica deliberada sin asistencia: reservar tiempo intencionalmente para resolver problemas sin apoyos externos.
Métricas de calidad del código, rework o estabilidad: pueden evidenciar que nuestro juicio técnico (y el de la IA) está relajando el estándar.
Registro de consultas frecuentes a la IA: ayuda a identificar patrones de dependencia y áreas donde podríamos estar en riesgo de atrofia.
Cuanto más conscientes seamos de lo que delegamos, más posibilidades tendremos de invertir el bucle vicioso y activar uno virtuoso:
Los mejores desarrolladores del mañana serán aquellos que no permitieron que la IA de hoy les hiciera olvidar cómo pensar. — Addy Osmani
Lecturas recomendadas
Avoiding Skill Atrophy in the Age of AI — Addy Osmany
Making a Wicked Learning Environment More Kind — David Epstein
Los peligros de la IA para tu cerebro — Val Muñoz de Bustillo
🧠 Un modelo
Garbage can model
El Garbage Can Model (Modelo del Cubo de Basura) es una teoría sobre la toma de decisiones en organizaciones desarrollada en 1972 por Cohen, March y Olsen. Propone que, en contextos de alta ambigüedad y procesos caóticos, las decisiones no siguen un proceso racional y estructurado, sino que emergen de la combinación fortuita de cuatro elementos:
Problemas: desafíos que requieren atención, aunque no siempre estén bien definidos.
Soluciones: propuestas que pueden estar disponibles incluso antes de que surja un problema concreto.
Participantes: personas involucradas en el proceso, con distintos niveles de interés, autoridad o energía.
Oportunidades de decisión: momentos en los que formalmente se decide algo, aunque el problema y la solución no siempre coincidan allí.
La metáfora del «cubo de basura» refleja el desorden: estos cuatro elementos se vierten en un contenedor sin un orden ni alineación claros. La toma de decisiones ocurre únicamente cuando, por coincidencia, un problema, una solución y los participantes adecuados confluyen en una oportunidad determinada.
Este modelo sugiere que muchas decisiones no responden a un análisis racional, sino que son el resultado de circunstancias: soluciones huérfanas encuentran problemas, los problemas flotan sin atención clara, y la decisión final depende en gran medida de quién está presente y cuándo.
Desde mi lente sistémica, lo veo como un sistema con flujos desacoplados, bucles de retroalimentación retardada y una dinámica emergente. Es posible que una solución descartada hoy se vuelva clave más adelante, cuando cambie el contexto o surja una oportunidad.
Cuando leí sobre este modelo por primera vez, lo interpreté como una patología organizacional. Pero luego reflexionando, me di cuenta de que en Audiense, como en muchas otras empresas, una buena parte de las innovaciones han surgido de esta manera: soluciones que estaban «por ahí», que en su momento no encajaban del todo, y que de pronto encontraron su lugar gracias a una oportunidad o decisión concreta. No fueron el resultado de un plan maestro, sino de un encuentro afortunado.
Por supuesto, no es deseable operar así todo el tiempo. Cuando las decisiones dependen de factores como quién está en la sala o qué soluciones están en la cabeza de la persona adecuada en el momento justo, es difícil repetir el éxito de forma consistente.
Aquí aplica muy bien algo como la estrategia barbell de Nassim Taleb: operar la mayor parte del tiempo con foco, estructura y alineación, pero reservar un pequeño porcentaje del tiempo y la energía para permitir cierto grado de caos creativo. Ese espacio intencional es donde el Garbage Can puede operar sin dominar el sistema.
Por ejemplo:
Hackathons
Equipos fuera de las reglas y estándares de calidad habitual con libertad para innovar sin necesidad de roadmap o validación de mercado clara.
Tiempo reservado para side-projects, como el famoso 20% de Google del que surgieron Gmail o AdSense.
Soluciones en espera que se reevalúan cada cierto tiempo en lugar de descartarlas por completo.
La utilidad de este modelo para mí, es que me ayuda a detectar cuándo estamos operando demasiado tiempo en este modo. No para evitarlo por completo (como he dicho a veces de ahí emergen grandes cosas) sino para que ese caos no se convierta en nuestra única forma de decidir.
En el contexto actual, con la fiebre por la inteligencia artificial, el cubo está desbordado: soluciones buscando problemas, aprendizajes sin aplicación clara, presión por «tener algo de AI» sin saber si resuelve algo. La velocidad con la que todo esto avanza exige más que nunca saber cuándo estamos operando con intención y cuándo, simplemente, estamos echando más cosas al cubo.
👓 Un Sesgo
Efecto Gell-Mann Amnesia
El efecto Gell-Mann Amnesia, es un sesgo descrito por el escritor Michael Crichton y nombrado en honor al físico Murray Gell-Mann:
Lees un artículo en un periódico (o cualquier medio) sobre un tema que conoces bien y detectas errores claros, incluso graves. Lo descartas: «esto es una tontería». Pero pasas página, encuentras otro artículo sobre un tema que no dominas… y, automáticamente, asumes que es riguroso y fiable.
El sesgo se resume en:
Detectas errores donde tienes experiencia.
Olvidas esos errores al cambiar de tema.
Vuelves a confiar ciegamente en la fuente que acabas de desacreditar.
Es una especie de amnesia selectiva que muestra lo fácil que es confiar en fuentes que ya han demostrado no ser del todo fiables.
¿A qué os suena? Exacto: a nuestra nueva amiga, la IA.
En el chat
Lo típico de «me lo dijo ChatGPT».
Lo usas para cuñadear sobre cómo funciona la energía eólica y el por qué del apagón, pero si eres valenciano te partes con su receta de la paella perfecta.
En el código
Cuando el modelo toca tecnologías que no dominas, lo dejas volar. Pero si escribe sobre tu stack diario, haces memes, compartes capturas de sus errores… y aún así, sigues usándolo para todo.
En productos con IA
Creamos productos IA que son simplemente un prompt y como devuelven respuestas coherentes, ya parece suficiente. Pero en casos de uso abiertos (como experiencias conversacionales, resúmenes, recomendaciones, etc) es difícil saber si el producto realmente cumple lo que espera un cliente.
Para resolver esto me parecen imprescindible herramientas de prompt engineering que permitan:
iterar y versionar los prompts,
comparar con diferentes modelos y sus configuraciones
evaluarlos con criterios objetivos,
observar su comportamiento en producción,
y mejorarlos con datos reales.
Últimamente estoy probando Latitude.so y la verdad es que cubre todo esto muy bien (no patrocinado).
Esto es todo por hoy. Me encantaría que dejaras en los comentarios qué te ha parecido esta entrega y compartieras ideas sobre los temas que te gustaría ver en las próximas ediciones.
¡No olvides suscribirte para no perdértelas!
Me alegra tenerte por aquí Joserra. Totalmente de acuerdo, creo que ese nivel de abstracción subirá, pero queda camino aún y no en todos los contextos puedes dejar la IA por su cuenta. Todavía tenemos que preservar ambas capacidades y ahora mismo estoy viviendo situaciones en ambos extremos, donde el es primero adictivo: hago cosas greenfield con on one shot prompt pero otros tengo que pararme mucho a pensar cuál es la arquitectura correcta antes de dejar intervenir la IA.
Gracias por compartir estas tan necesarias reflexiones.
Al final hablamos de cómo afecta la IA al aprendizaje, en nuestro contexto de creación de software. Me pregunto cómo lo reflejará el próximo informe DORA. Y sí ya habrá estudios que lo aborden en otros contextos, por ejemplo cuando aún no ha ocurrido la adquisición de habilidades (estudios de grado y universidad, etc).
Siempre muy interesante leerte, gracias otra vez 🤗