JuanMonsalve

Un turno completo, del micrófono a la respuesta hablada, tarda 135 milisegundos medidos sobre el equipo de destino. Todo ocurre ahí mismo: sin conexión, sin servicios de terceros y sin que un solo byte de audio salga de la máquina.

Ese tiempo es consecuencia de una decisión de arquitectura: el modelo de lenguaje no está en la ruta crítica. Las órdenes se resuelven en cuatro etapas de costo creciente y solo las ambiguas llegan al modelo, de modo que lo que gobierna la latencia y el gasto no es la precisión del modelo, sino qué porcentaje de órdenes necesita llegar hasta él. Ese porcentaje se mide en cada versión.

El control de ejecución va por lista blanca: el modelo elige una intención y sus argumentos dentro de un esquema validado, y nunca genera comandos. El proyecto acumula 307 pruebas automatizadas, y el banco de intenciones se ejecuta entero antes de tocar cualquier umbral.

Una liga de fútbol amateur lleva aquí sus torneos, sus cobros y sus nóminas, todos los días y en producción. Veintidós modelos de dominio repartidos entre una API y un cliente de escritorio, ambos con tipado estricto. Empezó como el refactor de un monolito; hoy es un producto que se instala, se actualiza y se mantiene solo.

La decisión que más cambió el producto no fue técnica sino de dominio. Todo esquema de fútbol modela el partido como local contra visitante, y así estaba construido; pero las ligas amateur alquilan canchas neutrales y ambos equipos viajan al mismo lugar. La distinción no significaba nada y obligaba al administrador a una elección arbitraria en cada partido, así que se eliminó, con su migración de datos.

El despliegue y la operación también son míos: contenedores en un servidor propio, certificado que se renueva solo, base de datos sin puerto expuesto, respaldos diarios y un script que restaura el último en una base aparte para comprobar que sirven. El cliente se actualiza desde ese mismo servidor sin que el usuario configure nada, y los permisos siguen al oficio: el administrador maneja cuentas y nóminas, el planillero solo ve la caja del día.

Servicio que recibe formularios de contacto, descarta con reglas baratas lo que no necesita un modelo y clasifica el resto con la API de Anthropic, validando la respuesta contra un esquema antes de guardarla.

El objetivo es el control de costos: cada consulta queda registrada con sus tokens y su gasto, y un endpoint reporta qué porcentaje de los formularios llegó a necesitar el modelo. Es el mismo criterio de Apollo aplicado a un servicio que cobra por uso.