Un solo agente no puede tener un producto móvil entero en la cabeza

Todas las demos enseñan un asistente, un repositorio, una tarea limpia. El trabajo real de cliente es un producto multiplataforma con integraciones nativas en iOS, ciclos de vida de UI en Android, una capa de datos compartida y un contrato de API que lo une todo. Apunta un único agente generalista a eso y el fallo no es que escriba código malo. Es que escribe código plausible en la capa equivocada: parchea un estado de UI en Jetpack Compose cuando el problema real es cómo el cliente de red compartido en commonMain analiza el contrato JSON, o «arregla» un desajuste cambiando en silencio el lado que estaba bien.

El problema no es la capacidad del modelo. Es el alcance. Un agente al que le das el producto entero no tiene motivo para creer que alguna parte esté fuera de sus límites, ni ninguna señal estructural que le diga dónde corresponde un cambio. Todo es un montón plano de archivos.

Así que dejamos de intentar hacer un agente más listo y empezamos a hacer cada agente más pequeño.

Un solo carril por agente

Dividimos cada proyecto en carriles siguiendo las fronteras arquitectónicas que ya existen: commonMain para la lógica de negocio compartida y la red con Ktor, androidMain para Jetpack Compose, e iosMain para integraciones específicas de Apple. Cada carril tiene un agente especialista que lo posee y que no puede escribir fuera de él. No «no debería»: no puede, porque su acceso a herramientas está limitado así.

Esto compra tres cosas de inmediato:

• El radio de impacto está acotado. Un agente que trabaja en la UI de Compose no puede meter mano en la lógica de base de datos compartida. Depuras un carril, no un producto.
• El contexto se mantiene relevante. Un especialista carga las convenciones de su carril y nada más. No gasta su ventana analizando macros de Swift cuando necesita escribir Kotlin.
• La revisión es abordable. Un diff que toca exactamente un carril es un diff que una persona puede leer de verdad.

El orquestador es ignorante a propósito

Por encima de los especialistas hay un coordinador cuyo único trabajo es enrutar: leer la petición, deducir qué carril la posee y delegar. No distingue un lenguaje de otro. Y no le hace falta.

Esa ignorancia es la característica principal. Como el enrutado depende solo de dónde pertenece el trabajo, el coordinador sobrevive a cualquier cambio de tecnología. Cambia la librería de navegación, añade un target de WebAssembly, sustituye una API de sensor nativa: la lógica de enrutado no se toca. La capa que más cambia es justamente la que hicimos invisible para el coordinador.

Planificar primero, y que una persona lea el plan

Los errores más caros que hemos visto en agentes de IA no son errores de sintaxis. Son una solución bien ejecutada a un problema ligeramente equivocado, descubierta tres horas después.

Por eso el trabajo de varios pasos pasa por una fase de planificación antes de escribir código. Un rol dedicado a planificar lee el brief de producto, los contratos y el código, decide un enfoque, secuencia el trabajo por carriles y escribe un archivo de plan. Es consultivo por construcción: puede leer cualquier cosa y no puede escribir nada salvo el plan.

Después una persona lee ese plan antes de que actúe un solo agente. Un mal plan aprobado deprisa cuesta un día de implementación muy segura y muy equivocada. Revisar la intención es órdenes de magnitud más barato que revisar el resultado.

Entre carriles, contratos, no costumbres

Los carriles tienen que hablar entre sí, y ahí es donde suelen pudrirse los sistemas multiagente.

Tratamos cada interfaz entre carriles como un contrato. El cambio aterriza primero en el lado que lo posee (por ejemplo, la declaración expect en commonMain). Después se pasa únicamente un resumen del diff a los carriles nativos consumidores, que actualizan sus implementaciones para encajar. Nunca un cambio silencioso de un solo lado.

La misma disciplina cubre el sistema de diseño. Un archivo de tokens neutral es la única fuente de verdad; los agentes de UI traducen a mano cada cambio de token a su propio código de MaterialTheme en Compose o vistas de SwiftUI. Hace que un cambio de diseño sea siempre un evento visible y revisable en ambos carriles nativos.

Las instrucciones inclinan la conducta. Solo la aplicación la obliga.

Las instrucciones escritas, «haz siempre X», influyen en un agente. No lo restringen. Con suficiente presión, un modelo razonará hasta saltarse una directriz que leyó diez mil tokens atrás.

Por eso aplicamos las reglas en tres capas que no dependen de que el modelo colabore:

• Acceso a herramientas. Un agente revisor recibe herramientas de lectura y nada más. Capacidad, no instrucción.
• Permisos. Ciertas acciones requieren aprobación humana explícita cada vez.
• Hooks en el momento de la acción. Comprobaciones automáticas bloquean la operación antes de que llegue a un pull request. Se rechaza un commit si el nombre de la rama no identifica a qué carril pertenece el trabajo. Estos hooks protegen el código del cliente contra las alucinaciones de la IA de forma nativa.

Gestión del proyecto: un historial que se explica solo

El trabajo terminado pasa por dos revisiones separadas. Primera: ¿esto coincide con lo que realmente se pidió, la especificación, el contrato, el plan aprobado? Segunda, y solo después: ¿es buen código? Fusionarlas en una sola revisión produce de forma fiable código bien escrito que resuelve el problema equivocado.

Y nada se da por terminado sin evidencia. Un agente que asegura el éxito no es lo mismo que el éxito real.

Lo que cuesta

Contabilidad honesta, porque esto no es gratis:

• Hay un umbral de tamaño. En una app minúscula de una sola pantalla, esto es puro sobrecoste. La estructura se gana el sueldo cuando un producto escala a múltiples módulos y requiere una gestión de estado compleja, y no antes.
• Enrutar y planificar añade latencia. Se pasa por un plan y una entrega entre carriles. Se empieza más lento y se termina bien bastante más rápido, pero lo que se nota es la primera parte.

Nuestro enfoque

Esta arquitectura multiagente disciplinada es nuestra forma de construir productos móviles en TRIUUM. No dejamos que una IA genérica adivine tu arquitectura, y no pagamos el impuesto de las alucinaciones. Al imponer fronteras estrictas en nuestro código multiplataforma, entregamos aplicaciones robustas y escalables a un ritmo que los flujos de trabajo tradicionales no pueden igualar.

Si buscas construir una aplicación móvil rápido, sin comprometer el rigor de la ingeniería, hablemos.