La desconexión con el core

Hay una sensación que cada vez reconozco más en mí y en la gente con la que hablo: la de entregar algo que funciona sin haber entendido del todo por qué funciona. No es no saber una respuesta concreta. Es no saber que no sabes, y descubrirlo tarde, cuando algo se rompe y el código que tienes delante lo has revisado pero no lo has pensado.

Antes, escribir el código obligaba a pasar por el problema. Las decisiones pequeñas, los nombres, los casos límite, eran la forma de entender el core del producto sin proponérselo. Ahora el modelo produce la solución entera y tú ocupas el papel de revisor. Se revisa más deprisa de lo que se piensa, y revisar no deja el mismo poso que construir. El resultado es un desarrollo que avanza y una comprensión que se queda atrás.

Lo más raro es que desde fuera todo parece ir bien. Más funcionalidades, más PRs, más ritmo. Y por dentro, una distancia creciente con lo que hace el sistema, que solo se nota en los momentos malos: un incidente, una pregunta de alguien que sí pregunta por qué, un cambio que no sabes dónde tocar.

Encima, el listón se mueve. Si el ritmo de referencia es el de un LLM, nadie llega. Intentar no quedarse por detrás de una máquina que no se cansa ni duda es una carrera perdida de antemano, y la cuenta la pagamos con una mezcla de ansiedad, de síndrome del impostor y de cansancio que no sale en ningún indicador de productividad. No creo que estemos pasando una buena época con nosotros mismos, y me parece honesto decirlo.

No tengo una solución. Quizá lo que toca es aceptar que el ritmo no es el valor. El valor sigue estando en entender lo que se construye, y eso no se delega.