Lo que todavía nos preguntamos unos a otros

Algo ha cambiado en lo que los desarrolladores se preguntan entre sí, y lo noté primero en mi propio comportamiento. Durante más de una década, entre equipos de grandes empresas y startups, las preguntas que circulaban entre personas estaban dominadas por la mecánica. Por qué esta regex no hace match. Qué significa en realidad este error. Cómo consigo que estas dos librerías se pongan de acuerdo en una versión. Las hice, las respondí, y en algún momento de los últimos dos años dejé de hacer ambas cosas, porque ahora una máquina las contesta en segundos, a cualquier hora, sin hacer que nadie se sienta pequeño por preguntar. Las preguntas que todavía pasan de persona a persona se volvieron más escasas, y más pesadas.

No echo de menos el tráfico de antes. Responder la misma pregunta mecánica por cuadragésima vez nunca fue la parte buena de esta profesión, y que una máquina incansable la absorba es un regalo. Pero fijarme en qué preguntas siguen cruzando de persona a persona, después de que todo lo demás dejara de necesitarlo, me enseñó algo sobre hacia dónde se está moviendo el valor de un desarrollador. Tres tipos siguen haciendo el viaje, y no son igual de duraderos.

Más nuevas que el entrenamiento

El primer tipo nace más deprisa de lo que cualquier modelo puede aprender. Una versión sale un martes y el miércoles ya falla de maneras que nadie ha documentado, porque nadie ha convivido con ella lo suficiente como para documentarlas. Escribo código con dos modelos distintos, a diario, y en el momento en que una herramienta se actualiza debajo de mí, los dos pasan de sabio a adivino seguro de sí mismo sin cambiar el tono en absoluto. Reconocer ese cambio es ya una habilidad.

La objeción obvia es que los modelos navegan. Pueden traerse release notes e hilos de issues bajo demanda, y eso ha estrechado bastante esta ventana. Pero el retrieval lee texto, y en los primeros días después de una rotura, el texto todavía no existe. El conocimiento vive en las cabezas de las cincuenta personas que se dieron contra el mismo muro la misma semana, y en los mensajes que se cruzan cuando se encuentran. Durante ese puñado de días, esas personas son el único lugar donde existe la respuesta. Todo lo que la máquina acabará sabiendo sobre esa rotura tiene que pasar antes por ellas, porque alguien tiene que dejar algo por escrito antes de que nada pueda recuperarlo. La ventana sigue estrechándose, pero cada versión la vuelve a abrir desde cero, así que las preguntas que viven dentro de ella siguen necesitando a una persona. Solo que nunca a la misma persona durante mucho tiempo.

Más profundas que una respuesta plausible

El segundo tipo baja hacia el fondo en vez de avanzar. El rincón oscuro de un compilador. El párrafo de una especificación que dos implementaciones leen de manera distinta. La pregunta en la que una respuesta plausible no sirve de nada, porque lo que hace falta es una demostrablemente correcta, con procedencia, de alguien capaz de señalar la cláusula exacta que la decide. Cuando alguien pregunta por qué el optimizador tiene permitido reordenar esas dos escrituras, no está pidiendo un párrafo que suene a documentación. Está pidiendo el modelo de memoria, capítulo y versículo.

Conviene que aclare desde dónde hablo, porque juega en mi contra. He pasado buena parte de los últimos años trabajando en sistemas de retrieval para los ámbitos legal y sanitario, donde una respuesta que no puede enseñar su fuente no vale nada, suene como suene, y todo el esfuerzo de ingeniería está en anclar cada afirmación al documento que la sostiene. Ese trabajo es una apuesta a que esta categoría se puede automatizar, y la apuesta va bien. Una máquina que responde con la cláusula exacta adjunta no es una fantasía; es más o menos la descripción de mi puesto. Así que, de los tres tipos, este es el que espero que siga encogiéndose. El especialista que se sabe la especificación al dedillo conservará la ventaja en los rincones donde los documentos se contradicen, y en las preguntas que los documentos nunca anticiparon. Pero no voy a construir un ensayo sobre un foso que yo mismo me paso los días de trabajo drenando.

La pregunta que va de ti

El tercer tipo es el que suena menos técnico y resulta ser el más duradero. Mira mi proyecto. Cuál de estas herramientas para mi equipo, con nuestra codebase, nuestra fecha de entrega y las dos personas que de verdad van a mantener esto. Tú qué harías.

Hazle estas preguntas a un modelo y obtendrás algo genuinamente útil, un mapa del espacio de opciones con todos los tradeoffs desplegados. Insiste un poco más y hasta elegirá una, así que no voy a fingir que la máquina se niega a mojarse. Lo que no puede hacer es ponderar los tradeoffs como los pondera la consecuencia vivida, y creo que el motivo es concreto, no místico. El registro escrito del que aprendió la máquina está sesgado. Los fallos dramáticos tienen su postmortem; los lentos no. Nadie escribe un informe de incidencia titulado «esta librería era ligeramente inadecuada para nuestro equipo y nos costó tres horas a la semana durante dos años». La persona que ha mantenido aquello que un día recomendó carga exactamente con esos datos que faltan: qué tradeoffs del mapa mordieron de verdad, con qué fuerza y cuánto duró el moratón. Cuando colapsa el espacio de opciones en una decisión para tu situación, son esos datos que faltan los que hacen el colapso.

Hay una lectura menos halagadora de todo esto, y voy a conceder una parte. Parte de la gente que pregunta «tú qué harías» busca cobertura más que consejo, un nombre que señalar si la elección sale mal. Pero incluso eso es una demanda que ninguna máquina puede atender, porque a un modelo no se le puede señalar. Y la mejor versión de ese mismo instinto es sensata. Quieren que la decisión venga de alguien que pague algún precio por equivocarse, aunque solo sea en reputación, porque una recomendación que no le cuesta nada a quien la hace es fácil de hacer a la ligera.

El vuelco

Así que la máquina se quedó con la franja del medio. Todo el archivo de mecánica ya resuelta sale ahora de un prompt al instante, y desde donde yo lo veo, el tráfico de esas preguntas entre personas ha quedado reducido a casi nada. Lo que todavía circula se inclina con fuerza hacia el último tipo, las peticiones de gusto, de recomendación y de criterio.

Es un vuelco en el que merece la pena detenerse, porque nuestra cultura entrenó a los desarrolladores para tratar exactamente esas preguntas como menores. Preguntabas qué elegiría alguien y el reflejo era despacharlo como mera opinión, no una pregunta de verdad, porque no tenía respuesta verificable. El reflejo tenía su lógica. Reservábamos las decisiones subjetivas para la gente a la que pagábamos por tomarlas, los tech leads y los arquitectos, y entre compañeros valorábamos las preguntas que la evidencia podía zanjar.

Las preguntas que la evidencia puede zanjar las zanja ahora una máquina antes incluso de llegar a una persona. Lo que queda es el tipo sin respuesta verificable, el que antes se despachaba con un gesto. Ha pasado de ser el ruido del canal a ser la mayor parte de lo que el canal transporta. Y la gente que sigue haciendo esas preguntas no está confundida sobre cómo funciona todo esto. Ha identificado correctamente lo que no puede sacar de un prompt, y está preguntando en el único sitio donde existe.

Conviértete en alguien a quien merezca la pena preguntar

Me toca decir dónde estoy yo en todo esto. Construyo parte de la maquinaria del lado barato de este intercambio, herramientas que generan código y respuestas todo el día, y todas terminan en un humano que tiene que tomar una decisión que la herramienta no puede tomar por él. Cuando digo que el valor se movió hacia la persona dispuesta a decidir, estoy describiendo el punto exacto donde se detienen mis propias herramientas.

Para un desarrollador, la pregunta práctica viene sola. ¿Eres alguien a quien merece la pena preguntar? ¿Hay algún rincón de este campo en el que hayas convivido con tus propias decisiones el tiempo suficiente como para que tu criterio ahí signifique algo?

Y cuando llegue la pregunta, responde con el razonamiento, no solo con el veredicto. Un veredicto se queda viejo con la siguiente versión, y es la única parte de tu respuesta que quien pregunta podría haber conseguido con un prompt. Lo que no puede conseguir con un prompt es la ponderación: cómo comparaste las opciones, qué te costó cuando elegiste mal, qué vigilarías ahora. Entregar eso es lo que hace mejor a quien pregunta, y lo que un día lo convierte también en alguien a quien merece la pena preguntar.

No voy a afirmar que esta ventana aguante para siempre. Todas las demás ventanas de esta historia se han movido, y esta puede moverse también. Pero hoy, cuando alguien te traiga su proyecto y te pregunte qué harías tú, fíjate en lo que acaba de pasar. Tenía una máquina que lo responde todo, y aun así te trajo la pregunta a ti. Tómatela en serio, y respóndela con las razones a la vista.