Una prueba de concepto que nadie fuera del equipo del build ha tocado no es una prueba. Es una presentación con una demo funcionando al lado. En la semana dos de un build sentamos a un humano real frente a lo que exista hasta ese momento y miramos cómo lo usa.
Quién es ese usuario
No un beta tester. No el sponsor ejecutivo. Casi siempre uno de los operadores que va a terminar viviendo dentro del sistema: un líder de soporte, un sales engineer, un analista. A veces una sola persona. Siempre alguien cuyo trabajo diario el sistema promete cambiar.
Nos sentamos al lado. No interrumpimos. No explicamos. Miramos.
Lo que queda al descubierto en veinte minutos
En la pizarra la arquitectura se ve limpia. Handoff a un humano cuando baja la confianza. Citas en línea en cada respuesta. Política de retry para las tool calls mal formadas.
Esto es lo que suele pasar en los primeros veinte minutos con un usuario real. Copia la respuesta a un documento de Word o al borrador de un correo. Ignora las citas. Nunca llega a disparar el umbral de confianza, porque se rindió y volvió al flujo viejo antes de alcanzarlo. Y reintenta apretando el botón tres veces en vez de esperar al retry estructurado.
Nada de eso estaba en la spec. Todo eso cambia la arquitectura.
Tres patrones que puedes dar por seguros
Primero: el destino del output pesa más que su calidad. Si el usuario va a pegar la respuesta en otro sitio, el formato, la estructura y los metadatos tienen que encajar con ese destino. Una respuesta correcta en el formato equivocado sigue siendo trabajo extra.
Segundo: los presupuestos de latencia no son una abstracción. Un handoff por baja confianza que tarda siete segundos es un handoff que nadie dispara, porque el usuario ya siguió con otra cosa. El presupuesto de latencia entra en el eval después de la semana dos, nunca antes.
Tercero: el modo de fallo que obsesiona al equipo casi nunca es el primero que encuentra el usuario. Los equipos de ingeniería se desvelan con la alucinación. Los usuarios se atascan con datos desactualizados, frases ambiguas y retries de tool call que parecen el sistema colgado.
Qué cambia después de la semana dos
Cada semana entre «el sistema existe» y «un usuario real ya lo tocó» es una semana de deuda de arquitectura que el equipo acumula sin saberlo. El remedio no es un discovery mejor. Es acortar esa distancia.
Las decisiones de arquitectura se toman contra la transcripción de un usuario real peleándose con el sistema, no contra un diagrama en la pizarra. La transcripción es la fuente de verdad. La pizarra es el borrador de lo que creíamos.