Una prueba de concepto que nadie fuera del equipo de build ha tocado no es una prueba. Es una presentación con un demo funcionando al lado. En la semana dos de cada proyecto, ponemos a un humano real dentro de lo que existe hasta ese momento y observamos cómo lo usa.
Quién es ese usuario
No un beta tester. No el sponsor ejecutivo. Normalmente uno de los operadores que terminaría viviendo dentro del sistema — un líder de soporte, un sales engineer, un analista. A veces una sola persona. Siempre alguien cuyo trabajo cotidiano se supone que el sistema va a cambiar.
Nos sentamos a su lado. No interrumpimos. No explicamos. Observamos.
Lo que se expone en veinte minutos
En la pizarra, la arquitectura está limpia. Handoff a humano con umbral de confianza. Citas inline en cada respuesta. Política de retry para llamadas a herramientas mal formadas.
En los primeros veinte minutos de un usuario real tocando el sistema, esto es lo que suele pasar en realidad. Copia la respuesta a un documento de Word o a un borrador de correo. Ignora las citas. Nunca dispara el umbral de confianza porque ya se rindió y volvió al flujo viejo antes de que el umbral se alcance. 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 ya damos por descontados
Primer patrón: el destino del output importa más que la calidad del output. Si el usuario va a pegar la respuesta en otro lado, el formato, la estructura y los metadatos del output tienen que coincidir con el lugar donde va. Una respuesta correcta en el formato equivocado sigue siendo trabajo extra.
Segundo patrón: los presupuestos de latencia no son abstractos. Un handoff con umbral de confianza que tarda siete segundos es un handoff que nadie dispara, porque el usuario ya se movió. El presupuesto de latencia entra en la evaluación después de la semana dos, nunca antes.
Tercer patrón: el modo de falla que más le preocupa al equipo casi nunca es el primero que encuentra el usuario. Los equipos de ingeniería se obsesionan con la alucinación. Los usuarios se quedan bloqueados en frescura de datos, frases ambiguas y retries de tool-call que parecen el sistema congelado.
Lo que 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 arquitectónica que el equipo todavía no sabe que está acumulando. La solución no es mejor discovery. La solución es acortar la 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 un borrador de lo que solíamos creer.