Idea principal

Una competencia que el uso corriente ya no solicita no se mantiene sola. Un desarrollador que pide a un asistente que lea, explique y corrija en su lugar conserva la habilidad de pilotar la herramienta y pierde progresivamente la de leer un código desconocido, sostener un diagnóstico o simplificar una arquitectura.

El remedio no es renunciar a la herramienta, sino crear situaciones en las que no esté disponible: dojos sin asistente, ejercicios con asistente limitado, revisiones donde hay que explicar el código uno mismo, momentos tomados a propósito para leer, entender y simplificar. La misma lógica se admite en otros ámbitos sin discusión: la calculadora es útil, pero no hacer nunca una operación uno mismo produce dependencia; en deporte se añade peso y resistencia porque es la resistencia la que desarrolla el músculo.

No es una nostalgia del desarrollador que sufre para merecer su oficio, y el objetivo no es ralentizar en todas partes. Es ralentizar en el sitio adecuado: producir muy rápido una parte del tiempo, y santuarizar tiempo largo —un día de mejora continua, revisiones de arquitectura, ADR, refactorizaciones lentas, post-mortems de generación fallida— para entender lo que se ha producido.

Por qué es importante

Esto trata una carencia que ninguna regla de producción cubre: las contramedidas que protegen la calidad del sistema no protegen la aptitud de quienes lo sostienen. Un equipo puede aplicar una disciplina de merge impecable y dejar que se apague la competencia que le permitiría juzgar lo que fusiona.

También ofrece una lectura de un problema anterior a las herramientas: muchos desarrolladores ya estaban con la nariz pegada al manillar, produciendo sin tomar la distancia que hace ganar competencia. La aceleración agrava ese defecto si llena todo el espacio liberado con más producción, y lo corrige si sirve para distinguir el tiempo de hacer y el tiempo de entender.

Matices y límites

La dificultad añadida debe parecerse a la del oficio real. Un ejercicio artificial mantiene la soltura en el ejercicio, no la competencia buscada, y una restricción mal elegida cuesta tiempo sin formar nada.

Y algunas competencias vueltas inútiles merecen desaparecer: nadie se entrena a escribir ensamblador para mantenerse lúcido sobre su código. Distinguir lo que hay que mantener de lo que se puede abandonar es un arbitraje abierto que esta idea no resuelve.

Preguntas abiertas

• ¿Con qué señal se da cuenta un equipo de que una competencia se ha apagado, cuando su producción diaria hacía tiempo que ya no la solicitaba y parecía normal?