Yo Dirijo

 

El que pregunta bien, aprende mejor

Hay una escena que se repite cada vez con mayor frecuencia en las empresas. Alguien termina una tarea, la entrega, y cuando le preguntan cómo la hizo dice: "le pedí a la IA". El resultado está bien. El proceso fue rápido. Y sin embargo, algo falta. No en el output. En la persona.

Lo que falta es lo que esa tarea podría haberle enseñado si la hubiera hecho de otra manera.

No digo esto para romantizar el esfuerzo manual ni para defender que las cosas tengan que ser difíciles para que valgan. Digo algo más específico: que el trabajo intelectual del futuro no va a estar en ejecutar. Va a estar en definir y en evaluar. Y esas dos cosas no se aprenden pidiéndole a un sistema que lo haga todo. Se aprenden en el proceso de entender qué querés, articularlo con precisión, obtener un resultado, juzgarlo y volver a intentarlo mejor.

Alvin Toffler lo dijo antes de que existiera todo esto: "Los analfabetos del siglo XXI no serán los que no sepan leer y escribir, sino los que no puedan aprender, desaprender y reaprender." Hoy esa frase no es una metáfora. Es una descripción del mercado laboral.

La ejecución es algo resuelto

Durante décadas, el valor de una persona en una organización estuvo ligado a su capacidad para ejecutar bien tareas repetitivas. Procesar datos, redactar informes, clasificar información, responder consultas estándar. Esas tareas ya tienen quien las haga. Y quien las hace no se cansa, no se equivoca de la misma manera y trabaja a cualquier hora.

Esto no es una amenaza nueva. Es una continuación de algo que empezó con la industrialización: cada vez que una máquina aprende a hacer algo que antes hacía un humano, ese humano tiene que subir un peldaño. El problema es que esta vez el peldaño no es físico. Es cognitivo.

Lo que sube de valor del humano en el proceso no es la fuerza ni la velocidad. Es el criterio. La capacidad de decidir qué problema vale la pena resolver, cómo formularlo con precisión, y cómo saber si la solución que obtuviste es realmente la que necesitabas.

Peter Drucker lo llamaba "trabajo del conocimiento" y anticipó hace décadas que el verdadero diferenciador de las organizaciones no iba a ser la eficiencia con la que sus personas ejecutaban tareas repetitivas, sino la capacidad de aprender y aplicar lo aprendido. Hoy estamos exactamente ahí.

Definir es el nuevo hacer

Imaginá a Juan, responsable de operaciones en una empresa de logística mediana. Hasta hace dos años, su equipo dedicaba varios días al mes a consolidar reportes de distintas fuentes, cruzar datos, detectar inconsistencias y elaborar el informe ejecutivo. Hoy ese proceso está automatizado. Tarda horas, no días.

Pero lo interesante no es la automatización en sí. Es lo que Juan tuvo que hacer para lograrla.

Tuvo que sentarse a definir con exactitud qué era un "reporte bien consolidado". ¿Qué fuentes eran confiables y cuáles no? ¿Qué tipo de inconsistencias eran críticas y cuáles eran ruido? Cuando el sistema debía detenerse y pedir intervención humana en vez de seguir solo. Tuvo que escribir, en detalle, lo que antes hacía de manera intuitiva y sin documentar.

Ese ejercicio le enseñó más sobre su propio proceso que en los dos años anteriores al ejecutarlo.

Esto es lo que cambia cuando el foco se desplaza de la ejecución a la definición: te obliga a entender lo que hacés a un nivel que la ejecución cotidiana no requiere. Podés hacer algo bien durante años sin saber explicar exactamente por qué lo hacés así. Automatizarlo te fuerza a saberlo.

Hay un concepto que describe esta práctica: el spec-driven design. La idea es simple: antes de construir cualquier cosa, definís el spec. Qué tiene que hacer el sistema, cuál es su input (datos de entrada), cuál es su output esperado (el resultado que querés), qué errores son inaceptables, qué casos borde importan. Primero el spec. Después de la construcción.

Charles Kettering, el ingeniero detrás del arranque eléctrico del auto, decía que "un problema bien planteado es un problema resuelto"." El spec es eso, el acto de plantear bien el problema antes de intentar resolverlo. Y escribirlo bien es, en sí mismo, un ejercicio de aprendizaje.

Evaluar es una habilidad, no una consecuencia

La otra cara del trabajo del futuro es la evaluación. Y acá hay una trampa frecuente: creer que evaluar un resultado es algo que cualquiera puede hacer de forma natural. No lo es.

Evaluar bien requiere saber qué esperabas antes de ver el resultado. Requiere tener un criterio explícito, no solo una sensación de que "algo no está bien". Requiere poder distinguir entre un error de ejecución, un error de definición y un error de expectativa. Y requiere, sobre todo, la disposición a preguntarte qué dice el resultado sobre la calidad de tu propia pregunta.

Richard Feynman tenía una forma de estudiar que consistía en explicar lo que aprendía como si se lo estuviera enseñando a alguien que no sabía nada del tema (la lógica del neófito es imbatible). El momento en que no podías explicarlo era exactamente el momento en que descubrías lo que todavía no entendías. Evaluar los outputs de sistemas automatizados funciona igual: el momento en que el resultado no es lo que esperabas es el momento en que descubrís lo que todavía no sabías definir.

Cada evaluación es una retroalimentación sobre tu propio nivel de comprensión del problema. Hay quien lo trata como un trámite —"esto no sirve, hacelo de nuevo"— y así pierde la mitad del valor del proceso; y quien lo trata como información —"¿qué me dice este resultado sobre cómo formulé el problema?"— aprende algo que la próxima iteración va a reflejar.

El conocimiento como acelerador, no como requisito

Hay algo que vale aclarar para no romantizar en exceso: el conocimiento previo que ya tenés acelera enormemente este proceso. No es un requisito de entrada para empezar, pero sí es la diferencia entre ir a 40 o a 120 por hora en la misma ruta.

Alguien con años de experiencia en un dominio específico escribe mejores specs, no porque sepa más de tecnología, sino porque sabe exactamente qué puede salir mal. Conoce los casos borde. Sabe cuándo un resultado que parece correcto en realidad no lo es. Sabe qué preguntas hacerse antes de que el sistema falle.

Eso no lo da ningún tutorial. Lo aporta la experiencia acumulada en el dominio. Y en un mundo donde la ejecución se automatiza, esa experiencia de dominio se vuelve más valiosa, no menos. Porque es exactamente lo que alimenta la calidad de las definiciones y la profundidad de las evaluaciones.

Steve Jobs decía que la creatividad es simplemente conectar puntos y que las personas creativas son las que han tenido más experiencias para conectar. Cada iteración que hacés con estas herramientas es un nuevo punto. Cada spec que escribís, cada output que evaluás, cada pregunta que afinás. Quien lleva más puntos conectados define mejor, evalúa mejor y aprende más rápido en el siguiente ciclo.

El error no es el fracaso. Es el mapa.

Al final, lo que distingue al que crece en este nuevo contexto del que se estanca no es el acceso a las herramientas. Es lo que hace con los errores.

Cuando el sistema produce algo que no era lo que esperabas, tenés dos opciones: frustrarte y culpar a la herramienta, o preguntarte qué decía tu spec que no debería haber dicho, o qué no decía que debería haber dicho. La primera opción es más cómoda en este momento. La segunda es exponencialmente más valiosa en el tiempo.

El futuro del trabajo no es para quien ejecuta más rápido. Es para quien define con más precisión y evalúa con más criterio. Y esas dos capacidades se construyen exactamente igual que siempre se construyó cualquier habilidad: con práctica deliberada, con atención al error y con la disposición a aprender algo nuevo cada vez que algo no sale como esperabas.

El que aprende mientras construye no solo obtiene mejores resultados hoy. Tiene mejores preguntas mañana.

¿Y vos, en tu trabajo, el foco ya se corrió hacia la definición y la evaluación? ¿O todavía estás en modo ejecución?