¿Soltar elementos de UI es realmente un problema de arquitectura y no de modelo?

Sí. A través de las superficies de producción que hemos auditado, la tasa a la que el modelo deja caer silenciosamente un elemento UI requerido se sitúa típicamente en el rango del 10–25% cuando el modelo es responsable de emitir esa UI como parte de su salida de texto. Mover la responsabilidad de renderizado fuera del modelo hacia directivas de UI tipadas hace el modo de fallo estructuralmente imposible.

¿En qué se diferencia un contrato de UI tipado de simplemente que el modelo devuelva JSON?

Devolver JSON es una táctica. Un contrato de UI tipado es una arquitectura: el modelo emite qué elementos interactivos son apropiados (y sus datos), la aplicación posee cómo se renderizan esos elementos. El frontend puede refrescar su renderizado sin tocar el modelo; el modelo se puede reentrenar sin forzar un rediseño del frontend. Sólo el contrato tiene que permanecer estable.

¿Cuándo este patrón es excesivo?

Para una sola superficie de chat mantenida por un equipo pequeño donde todo el producto es de corta vida, el enfoque markdown-renderiza-todo sale más rápido y está bien. El patrón se gana su sitio cuando la superficie es multi-equipo, multi-plataforma, multi-idioma o crítica para el negocio — donde quiera que la fiabilidad y la longevidad importen.

Por qué tu producto de chat con IA se olvida de los botones (y qué te cuesta a escala)

body{background:#050510;color:#fff;font-family:system-ui,sans-serif;padding:2rem;max-width:720px;margin:0 auto;line-height:1.6}Por qué tu producto de chat con IA se olvida de los botones (y qué te cuesta a escala)Un producto de chat con IA que de vez en cuando se salta un elemento de UI obligatorio, formatea mal una lista u omite silenciosamente un paso de confirmación no tiene un problema de modelo. Tiene un problema de arquitectura — el mismo que seguimos encontrando en despliegues empresariales de IA. Qué aspecto tiene un sistema sano y cómo llegar ahí.Continue