Sigue aprendiendo mientras Claude Code escribe tu software

Imagina a un desarrollador que aprendió PHP 5 años antes de que aparecieran los asistentes de IA. Un punto y coma olvidado podía costarle unos minutos o una tarde entera buscando la única línea mala. Una web dinámica llevaba semanas: diseño del esquema, estructura del código, planificar todo el proyecto de antemano. Cada etapa resultaba satisfactoria, de la planificación a la construcción, y la recompensa era real. Habías hecho algo con tus propias manos después de pelearte con ello y salías sabiendo más que al entrar.

Compáralo ahora con hoy. En 2025 llegó Claude Code y los desarrolladores empezaron a delegarle cada vez más trabajo diario. Un año después, muchos apenas abren Stack Overflow, dibujan menos en pizarras o en papel antes de diseñar una funcionalidad y hablan menos con sus compañeros, porque la mayor parte de su conversación ocurre con Claude. La velocidad es real y nadie que la haya probado quiere renunciar a ella. Pero tiene un precio. Se está perdiendo una buena parte del proceso clásico, el que convierte sin hacer ruido a los juniors en seniors.

Esto no es una queja, ni un llamamiento a programarlo todo a mano, ni una rebelión contra la IA. Es una preocupación por algo muy concreto. Mucha gente elige esta profesión en parte para seguir aprendiendo siempre, y ese aprendizaje se apaga cuando un modelo se encarga de pensar.

Qué dice la investigación

Anthropic, la empresa detrás de Claude Code, publicó un estudio sobre cómo afecta la ayuda de la IA a la formación de habilidades de programación. Señala una paradoja: las ganancias de productividad gracias a la IA pueden ir acompañadas de un desarrollo más lento de las habilidades, sobre todo en principiantes. El consejo que se desprende coincide con lo que muchos desarrolladores intuyen. El esfuerzo mental, incluido quedarse atascado un rato, sigue siendo necesario si quieres dominar algo.

Así que la pregunta pasa a ser cómo seguir aprendiendo cuando Claude Code lo hace todo.

La fricción que perdimos

Empecemos por nombrar lo que te imponía la forma de trabajar de antes:

• Probar cosas hasta que algo funcionara
• Leer y releer la documentación
• Repasar tu propio código
• Seguir cómo fluye una funcionalidad y en qué orden se ejecutan sus funciones
• Depurar durante minutos, horas o, de vez en cuando, días

No eran obstáculos para aprender. Eran las condiciones para hacerlo. Los niños del futuro oirán hablar de esta época como quien cuenta que iba al colegio andando kilómetros, cuesta arriba a la ida y a la vuelta.

Con esa fricción se ha ido también lo que el estudio llama esfuerzo cognitivo, la distancia entre escribir código y entender lo que has escrito. Si el trabajo ya no aporta la fricción, tienes que volver a añadirla a propósito.

Usa la herramienta para aprender

Un buen punto de partida es tratar a Claude como una herramienta, extraordinaria, sí, pero una herramienta que no debería sustituir al desarrollador. Debería facilitar el trabajo y ayudarle a crecer. El viejo dicho asegura que, si solo tienes un martillo, todo problema parece un clavo. Pero un desarrollador también se encuentra tornillos, pernos y tacos, y ahí es donde vive el oficio.

En lugar de pelearte con el asistente, ponlo a enseñarte a usar las demás herramientas. Si Claude puede escribir una funcionalidad entera a partir de un único prompt explicativo, también puede hacer preguntas sobre lo que está haciendo. La idea, por tanto, es introducir fricción deliberada en las sesiones. No para impedir que Claude trabaje ni para volver a escribirlo todo a mano. En mitad de su trabajo, de vez en cuando se detiene y te pregunta algo, por ejemplo por qué elegiste cierto enfoque.

Las preguntas típicas son de este estilo:

• ¿Por qué esta función se comporta así?
• ¿Qué pasa si esta llamada falla?
• ¿Hace falta esta línea?
• ¿Puedes terminar de escribir esta función?
• ¿Por qué esta arquitectura y no otra?

El objetivo es sencillo: que Claude haga su trabajo mientras tú sigues aprendiendo y, de paso, no pierdes de vista lo que está produciendo.

Cómo podría funcionar un modo de aprendizaje

Puedes montarlo como un skill de Claude Code más unos cuantos hooks. Lo instalas una vez y queda disponible en tu máquina para todas las sesiones. Tras un cambio, Claude mira el diff, elige un punto interesante del código y te pide que lo expliques. Una pregunta podría ser así:

🎓 Learner — src/auth/session.ts
You modified `refreshSession()` to delete the old session line before inserting the new one.
Why use this order rather than “insert then delete,” and what does a caller see if the insert fails after the delete has been committed?

Claude pregunta y vuelve a lo que estaba haciendo. Si respondes skip, sigue adelante sin insistir.

La variante más interesante toma una función corta que acabas de cambiar, recupera la versión correcta de Git y recorta partes del archivo real en disco. La frecuencia la controla un pequeño helper de shell que traduce un ajuste a un número:

learner_synthesis_n() {
  case "${1:-}" in
    off)   printf '0' ;;
    rare)  printf '8' ;;
    often) printf '2' ;;
    # LEARNER-TODO Complete this part of code
    *)     printf '4' ;;
  esac
}

Después Claude te pide que rellenes el hueco y espera. No terminará el código por ti salvo que reconozcas que no sabes hacerlo o escribas skip.

Es el tipo de pregunta más valioso, porque destapa los momentos en que crees seguir el código de Claude pero en realidad no sabrías escribirlo. Una advertencia: rompe brevemente tu código fuente real. Una salvaguarda impide que una sesión termine con un agujero en el árbol, y esa salvaguarda es la parte del diseño que más merece una revisión crítica.

También puedes lanzar un cuestionario directamente escribiendo learner quiz en una rama, en vez de esperar al hook. Es un hábito excelente. Si no sabes responder preguntas sobre tu propia rama, quienes la revisen tampoco sabrán.

Una advertencia honesta: tras unas semanas de uso, todavía no está claro si todo funciona sin problemas ni si de verdad ayuda a todo el que quiere aprender mientras usa Claude Code. Lo que mejoraría la siguiente iteración son los comentarios, sobre todo los que no estén de acuerdo.

Cuando el código lo escribes tú

Todo esto da por hecho que Claude escribe el código. ¿Y si no? Incluso con todo lo que puede hacer Claude Code, quizá no quieras que escriba cada línea. A veces te apetece teclearlo tú, no porque sea más rápido ni porque Claude no pudiera, sino porque escribir líneas es como se aprende.

Así que dale la vuelta al reparto. Tú escribes. Claude observa. En el momento oportuno, te pone a prueba. No corrige tu código, no toma el control ni te da la respuesta. Solo te empuja a pensar más a fondo. Un asistente así hace más que completar tareas y comprobar lo que entiendes. Actúa como compañero de sparring, alguien que mira lo que haces y aporta una pregunta en el momento justo.

Esa es la dirección que podría tomar una próxima versión: entrenador en lugar de profesor. En el modelo de profesor, el asistente construye primero y te examina después. En el de entrenador, tú sigues al volante, el asistente calla hasta que una pregunta de verdad ayude y cada línea del archivo sigue siendo algo que decidiste escribir tú. El crecimiento sale entonces de lo que tecleas y piensas, con un segundo par de ojos práctico en lugar de complaciente. Los desarrolladores que valoran el oficio probablemente prefieran ese equilibrio a ceder el teclado por completo, y mantiene vivo en el día a día el hábito de pelearse con los problemas de forma productiva. Si tienes ideas sobre cómo debería ponerte a prueba, vale la pena compartirlas.