Notas (3)
La columna invisible de todo trade-off (sesión 2026-08-30): el coste operativo. Al sacar el historial a Postgres vi la latencia enseguida, pero no que acababa de contratar una pieza encendida todo el rato con datos de clientes dentro — backups, monitorización, actualizaciones, alguien de guardia, un componente más que puede caerse. No aparece en ningún diagrama de arquitectura y es lo que más quema equipos. Regla: cuando evalúe una opción, preguntar siempre «¿quién la mantiene encendida?». Matiz técnico a no olvidar: el LLM no consulta mi base de datos — la consulta mi backend y le pasa el historial dentro del prompt. Otra de la misma sesión: se cachea lo que es igual para todos; en cuanto la respuesta depende de quién pregunta («¿cuánto debo?»), la caché deja de ser optimización y es una fuga de datos entre clientes esperando fecha.
La Ley de los Trade-offs30 ago 2026Tema a trabajar en el futuro (sesión 2026-08-30): el reflejo defensivo. Ante una propuesta discutible del CTO fui tres veces al "no, porque" — objeciones con signo de interrogación, y después un "muy buena idea, no obstante" que seguía siendo un no. El riesgo del rol no es equivocarse técnicamente, es convertirse en el que siempre frena: a ese dejan de consultarlo y se entera de las decisiones cuando ya están tomadas. Contrapeso: preguntar por el problema sin nombrar la solución propuesta ("¿qué querrías que fuese verdad dentro de seis semanas que hoy no lo es?" en vez de "¿qué objetivos buscas CON el multiagente?" — nombrar la solución en la pregunta ya la acepta). Nota positiva del mismo ejercicio: identifiqué solo el coste no lineal por tokens de orquestador + subagentes, que casi nadie menciona en esa reunión.
El Rol del Arquitecto de Software30 ago 2026Fallo propio (sesión 2026-08-30): clasifiqué el objeto `Message` como decisión de diseño mirando DÓNDE VIVE ("solo es un objeto, un solo componente") en vez de QUIÉN LO CONSUME. Un tipo de dato que cruza fronteras (se serializa al LLM, se guarda en Postgres, se manda al frontend) deja de ser estructura interna y pasa a ser contrato publicado. Regla que me llevo: antes de cambiar un nombre o una forma de dato, preguntar «¿esto está escrito en algún sitio que yo no pueda editar?». Si sí, no es refactor, es migración. Y las filas ya escritas no se pueden avisar. El patrón adulto para hacerlo es expand and contract: escribir las dos claves, migrar los datos, esperar a que todos los consumidores pasen a la nueva, y solo entonces retirar la vieja — cuatro despliegues para cambiar una palabra.
Arquitectura vs. Diseño de software30 ago 2026