Ángulo

"¿Qué pasa si el cliente anula este elemento después de la validación?" — la pregunta cae en Slack, la página de soporte no cubre el caso, y un Product Manager abre un entorno de pruebas durante media hora. Ir a buscar la respuesta al repositorio en lugar de a la página solo suprime esa media hora: una respuesta extraída del código se equivoca igual que una documentación caducada, y con más aplomo. Lo que reduce realmente el riesgo no es el cambio de fuente, es el régimen impuesto a la respuesta — cada afirmación vinculada a un elemento señalable, la función que aplica la regla, el test que cubre el escenario, la merge request que introdujo el comportamiento, el estado del feature flag; y cada zona no establecida nombrada, el test que falta, la configuración de ese cliente concreto a la que no se llega, la decisión de producto que el código parece contradecir. Sin ese doble régimen, se sustituye la memoria imperfecta del Product Manager por la memoria probabilística de un modelo, y el riesgo no disminuye: cambia de portador, pasando de quien sabía que no sabía al agente de soporte que cree saber.

Síntesis

El razonamiento parte de un coste que nadie contabiliza, y ese punto de entrada no es banal: explica que se haya convivido tanto tiempo con la situación. Cada verificación lleva media hora y no aparece en ningún ticket, ninguna estimación, ninguna línea de roadmap. Se le añade un segundo coste, aún menos visible, y que no se reduce por los mismos medios: la interrupción destruye el estado de trabajo de quien la recibe, y una respuesta obtenida en dos minutos en lugar de treinta lo deja intacto.

El desplazamiento hacia el código se presenta como una respuesta a ese coste, y lo es — a condición de no tomarlo por una respuesta al problema de fiabilidad, que es otro problema. El repositorio es la única representación que no diverge de lo que el producto hace; pero no dice todo lo que decía un documento. El corte útil no pasa entre el código y la documentación, pasa entre lo que describe — regenerable — y lo que explica — que hay que conservar, porque ninguna lectura del repositorio lo reconstruye. Y el propio repositorio no basta para zanjar: un feature flag deja en él dos comportamientos posibles, y es la configuración desplegada la que decide cuál se aplica a un cliente.

Aquí es donde el régimen de respuesta se convierte en el verdadero tema. Dos exigencias simétricas, y ninguna sustituye a la otra: citar acota lo que se afirma, reconocer acota lo que no. La primera actúa en el momento en que se produce la respuesta, no en el momento en que se relee — eso la distingue de una exigencia de trazabilidad, que supone un lector. La segunda da valor a lo que parece un fracaso: señalar que ningún test cubre un caso, o que una decisión de producto y el código divergen, es en sí una información de producto.

Queda la cuestión de a quién beneficia todo esto, y se resuelve por la forma más que por la duplicación: una respuesta única troceada en ángulos — la respuesta corta, el uso, el valor, los límites, las pruebas — evita mantener coherentes tantas versiones como oficios, y da a las pruebas un sitio donde existir sin estorbar a quienes no las abrirán.

Por último, dos condiciones enmarcan el conjunto, y no dependen del dispositivo. La primera tiene que ver con la materia leída: un código cuyas excepciones llevan el vocabulario del dominio se deja interrogar, un código donde las reglas están dispersas tras nombres técnicos se resiste — tanto a un modelo como a un desarrollador. La segunda tiene que ver con la criba previa: no todas las preguntas de producto son lecturas. Las que exigen un arbitraje no se delegan en nada, sean cuales sean las herramientas.

Lo que el conjunto deja ver: cambiar de fuente de verdad resuelve un problema de acceso, no un problema de confianza. La confianza no se gana por el origen de la respuesta, se gana por lo que la respuesta se obliga a mostrar — y el mismo régimen valdría para una respuesta extraída de un corpus jurídico o de un conjunto de actas.

Tensiones / contradicciones

Dos exigencias de este conjunto se contrarían en un umbral que nada establece. Una respuesta debe nombrar lo que no sabe; una respuesta con reservas en cada frase vuelve a ser inservible, y su lector acaba abriendo un entorno de pruebas — el coste que se quería suprimir vuelve entero. El punto de equilibrio se describe como necesario y nunca se sitúa.

Segunda tensión, sobre lo que el dispositivo trata realmente. Ataca el tiempo de búsqueda; el coste dominante, para un rol cuyo trabajo es acumulativo, es el de la interrupción. Responder más rápido puede, por tanto, mejorar una cifra sin cambiar nada de lo que se pierde, y el artículo no dice cómo dejaría de llegar la pregunta.

Tercera tensión, con la manera en que el desplazamiento hacia el código se ha contado en otro sitio: el paso de la autoridad de la especificación al repositorio se explica allí por el desplome del coste de acceso. Aquí, el acceso está conseguido y resulta insuficiente. Ambas se sostienen juntas, pero el orden de prioridades se invierte según cuál se lea primero.

Por último, el propio término de fuente de verdad se resiste al conjunto: el repositorio da fe sobre las reglas, el entorno desplegado da fe sobre lo que ve un cliente concreto, y el historial da fe sobre la intención. Tres fuentes, cada una soberana sobre una pregunta — algo que el singular de la expresión no dice.

Preguntas

• ¿Qué verifica, en una organización, que las pruebas citadas establecen realmente lo que la respuesta les hace decir, y con qué frecuencia?
• ¿Cómo acoge una empresa que juzga sus respuestas por su nitidez un dispositivo en el que parte del entregable es reconocer un hueco?
• ¿En qué condiciones un hueco señalado — un test ausente, una decisión de producto que el código contradice — se convierte en trabajo comprometido en lugar de en una mención más al pie de las respuestas?
• ¿En qué se convierte este régimen cuando el comportamiento interrogado ya no depende de un repositorio legible sino de un modelo entrenado, en el que ninguna función lleva la regla?