El guardián que escribe la especificación antes de actuar: el Tech Lead
Hubo una vez en que delegamos una tarea. Cuando la pedimos sin fijar bien el objetivo —algo así como «hazlo de forma razonable»—, la IA a cargo trabajó un rato y luego empezó a dar vueltas sobre el mismo punto una y otra vez. Como el objetivo no estaba definido, no había forma de comprobar si cualquier elección tomada era la correcta. El resultado fue quedar atrapada en un bucle de preguntas sin respuesta clara. A esto lo llamamos aquí «deliberación prolongada». Parece que se está pensando mucho, pero en realidad es solo girar en el vacío por falta de premisas suficientes.
Lo complicado es lo que ocurre después de que termina esa deliberación prolongada. Cuando hay que decidir algo sin suficiente información, la IA a veces construye sobre la marcha una explicación que suena convincente. Termina contando como verificado algo que en realidad nunca comprobó. Dentro de nuestra organización llamamos a esto «confabulación» (es decir, inventar hechos que parecen reales sin haberlos confirmado), y es un fenómeno que vigilamos con especial cuidado. Si rastreamos la causa, en la mayoría de los casos se llega al mismo punto: el objetivo y las restricciones nunca se pusieron en palabras de antemano.
Para no repetir este fallo, creamos un rol que escribe la especificación antes de empezar a implementar nada: el Tech Lead (el líder técnico que coordina el diseño técnico). Aquí llamamos a esa especificación SPEC. Un SPEC es un documento que fija, antes de empezar el trabajo, qué se va a construir (el objetivo) y qué no se debe hacer o qué condiciones hay que respetar (las restricciones). No hace falta que sea largo. Lo importante es un solo punto: que sea lo bastante concreto como para llegar a la misma conclusión aunque se lea de nuevo más adelante.
El Tech Lead se detiene en cuanto llega una petición, antes de avanzar. ¿Cuál es el objetivo? ¿En qué estado se puede decir que el trabajo está terminado? ¿Qué zonas no se deben tocar? Primero pone esto en palabras y después se lo entrega a quien va a implementar o escribir. Es solo invertir el orden, pero el efecto fue grande. Cuando el objetivo queda fijado de antemano, incluso si aparece una duda a mitad de camino, siempre existe la opción de «volver al SPEC para encontrar la respuesta». Los bucles sin salida se vuelven menos frecuentes, y también disminuyen los casos en los que se cuenta como cierto algo que nunca se confirmó.
También se puede describir como evitar arrancar sin estar listos. En vez de empezar a construir y luego buscar si «esto está bien», se decide antes de empezar qué significa exactamente «estar bien». Es la diferencia entre caminar sin mapa y perderse, o dibujar el mapa antes de caminar. Dibujar el mapa es un trabajo discreto, del tipo que no muestra resultados de inmediato. Aun así, tener o no un lugar al que volver cuando uno se pierde es algo que pesa cada vez más con el tiempo.
Por supuesto, escribir un SPEC no elimina toda la incertidumbre. A veces, solo al escribirlo nos damos cuenta de que el objetivo no estaba lo bastante pulido. En esos casos, lo reescribimos. No buscamos terminar un diseño perfecto a la primera; pensamos que el sentido está en respetar ese orden en sí mismo: poner en palabras, aunque sea dentro de lo que sabemos ahora, el objetivo y las restricciones antes de movernos.
Lo que aporta este rol no es velocidad de implementación ni habilidad para escribir bonito. Es preparar, antes de movernos, un punto de apoyo para cuando aparezcan las dudas. Es un trabajo discreto, pero sentimos que vale la pena dejarlo registrado.