Cuando la IA convierte expertos en dependientes: la lección del Go

El Go lleva décadas siendo el juego de tablero más resistente a la IA: complejo, intuitivo, imposible de reducir a fuerza bruta. Eso cambió en 2016 con AlphaGo. Lo que no se ha analizado tanto es lo que ocurrió después: cómo la comunidad humana de Go reorganizó su forma de aprender, evaluar y justificar sus propias jugadas en torno a los criterios de la máquina. Un artículo publicado en LessWrong lo articula con precisión incómoda.

El texto, que circuló este fin de semana en Hacker News, no habla de que la IA gane partidas. Habla de algo más sutil: los jugadores han dejado de confiar en su propio juicio para confiar en el de la IA, incluso cuando no entienden por qué la IA prefiere una jugada sobre otra. La consecuencia es que la transmisión de conocimiento entre humanos se ha empobrecido: si la respuesta a cualquier pregunta es "el modelo dice que esta jugada tiene un 60% de tasa de victoria", los conceptos, la intuición y el razonamiento propio dejan de entrenarse.

Qué describe el artículo exactamente

El autor traza un patrón concreto: los jugadores utilizan motores de análisis post-partida para revisar cada movimiento, adoptan las recomendaciones del modelo sin comprenderlas en profundidad, y paulatinamente pierden la capacidad de articular por qué una jugada es buena más allá de "la IA lo dice". Esto no es un problema de rendimiento competitivo a corto plazo —los niveles de juego han subido— sino de fragilidad epistémica a largo plazo.

Hay una distinción importante aquí: usar una herramienta para mejorar no es lo mismo que delegar el criterio a la herramienta. La primera es amplificación; la segunda, sustitución. El artículo argumenta que la comunidad del Go ha caído mayoritariamente en la segunda categoría, y que lo ha hecho de forma voluntaria y gradual, sin que nadie tomara una decisión explícita al respecto.

Por qué importa fuera del Go

El paralelismo con el uso cotidiano de LLMs como Claude es directo y no requiere forzarlo. Cualquier equipo de ingeniería que use Claude Code para generar código, revisar arquitecturas o depurar errores puede caer en la misma trampa: adoptar la salida del modelo sin construir el criterio propio para evaluarla. El riesgo no es que el modelo se equivoque —se equivoca, y eso es manejable—, sino que el equipo pierda la capacidad de detectarlo.

Esto es especialmente relevante en entornos donde los modelos son buenos pero no perfectos. Claude Opus 4.7 con ventana de 1M de tokens puede razonar sobre bases de código enteras, pero su salida sigue siendo una propuesta que necesita un evaluador competente. Si ese evaluador ha externalizado su criterio al propio modelo, el circuito de verificación desaparece.

Para quién es útil esta reflexión

El artículo no está dirigido a investigadores de alineamiento, aunque encaja en ese marco. Es útil, de forma muy práctica, para:

• Equipos de desarrollo que han integrado asistentes de código en su flujo diario y no han definido políticas explícitas sobre cuándo y cómo revisar las sugerencias.
• Formadores y educadores en cualquier disciplina técnica, que ven cómo sus estudiantes llegan con respuestas del modelo pero sin el razonamiento que las sostiene.
• Product managers y tech leads que diseñan flujos de trabajo con IA y necesitan pensar en qué capacidades humanas se preservan intencionalmente y cuáles se erosionan por inercia.

La comunidad del Go no adoptó la IA con mala intención. Lo hizo porque los motores eran mejores jugando, y parecía lógico aprender de ellos. El problema es que aprender de algo y aprender a través de algo son procesos distintos, y confundirlos tiene costes diferidos que solo se ven cuando ya es tarde.

Opinión EP

El artículo no ofrece soluciones concretas, lo que es una limitación real, pero la diagnosis está bien hecha y merece circulación fuera del nicho de LessWrong. En el ecosistema Claude, donde cada semana se añaden herramientas que hacen más fácil delegar más, conviene tener este caso encima de la mesa como recordatorio de que la automatización de tareas y la erosión de capacidades no son lo mismo, aunque a veces lleguen juntas.