La premisa: comer nuestra propia cocina

AIVAR se define como una fábrica de software AI-native. No es una etiqueta de marketing: significa que nuestros procesos de construcción están diseñados desde el inicio para que agentes de IA hagan gran parte del trabajo de ejecución, con humanos decidiendo la dirección y los criterios de calidad. La forma más honesta de demostrarlo no es un slide, es un artefacto. Esta web —la que estás leyendo ahora— fue construida con ese método, y este post cuenta cómo, sin adornos.

Antes de escribir una línea de código hubo una fase de documentación: definimos la identidad visual, las reglas de marca y el roadmap en documentos de texto plano. Esa decisión, que parece burocrática, es la pieza central de todo lo demás. Si un agente va a ejecutar trabajo por su cuenta, necesita un contrato claro que le diga qué está permitido y qué no. Los documentos son ese contrato.

El flujo real: orquestador, ejecutores en paralelo, auditor final

El trabajo lo dirigió un orquestador: un agente cuyo único rol es descomponer el objetivo en fases y repartir tareas. No escribe código de producto; decide qué se hace, en qué orden y con qué restricciones. Cada fase se dividió en tareas independientes —tokens y tema del design system, identidad visual, contenido, SEO— y cada tarea se asignó a un agente ejecutor distinto.

La clave para que varios agentes trabajen en paralelo sin pisarse es simple y poco glamorosa: archivos asignados de forma disjunta. Cada agente recibe una lista explícita de los archivos que puede tocar, y solo esos. El agente de tema trabaja sobre los tokens, el de contenido sobre los textos, el de SEO sobre metadatos y sitemap. Como los conjuntos no se intersectan, no hay conflictos de fusión ni decisiones contradictorias sobre el mismo código. Es la misma disciplina que aplicaría un buen equipo humano distribuido, formalizada al nivel de que una máquina la pueda cumplir sin ambigüedad.

Al final de cada fase entra un agente verificador. Su trabajo no es construir sino auditar: corre el typecheck, el build y el lint completos, arregla las costuras de integración que aparecen cuando piezas construidas por separado se encuentran, y recorre un checklist de marca ítem por ítem. ¿Los acentos usan la escala correcta? ¿Hay un solo glow por vista? ¿Alguien introdujo un color que no existe en los tokens? El verificador no confía en que los ejecutores lo hicieron bien; lo comprueba.

Los detalles que hacen que esto funcione

El design system vive en tokens. Colores, tipografías, sombras y radios están definidos en un solo lugar del tema (Chakra v3), y los componentes consumen esos tokens en vez de valores sueltos. La consecuencia práctica: cuando decidimos cambiar la identidad visual completa de la web, el re-theme fue una sesión de trabajo, no una migración. Se cambió la fuente de verdad y todo lo demás siguió.

El logo es un componente vivo, no una imagen. El gato de AIVAR parpadea con intervalos aleatorios de entre 6 y 12 segundos, respira sutilmente y despierta cuando pasas el cursor por encima. Es un detalle pequeño, pero ilustra algo importante del método: un agente puede implementar comportamiento con esa precisión porque la especificación estaba escrita con esa precisión. 'Que se vea vivo' es una instrucción para un humano con criterio; 'parpadeo con intervalo aleatorio de 6 a 12 segundos' es una instrucción que un agente ejecuta sin inventar.

Las reglas de marca están escritas en markdown, en el repositorio, junto al código. Qué colores existen y para qué sirve cada uno, cuándo se usa la fuente serif de acento, qué está explícitamente prohibido. Cualquier agente que entra a trabajar lee primero esos documentos, y por eso el resultado es coherente aunque lo hayan producido procesos distintos en momentos distintos. El estilo no vive en la cabeza de nadie: vive en un archivo versionado.

La tesis: humanos deciden, agentes ejecutan y auditan, los documentos son el contrato

Este método reparte el trabajo según lo que cada parte hace mejor. Los humanos definimos la dirección —qué queremos construir, cómo debe sentirse, qué criterios de calidad son innegociables— y las escribimos donde una máquina las pueda leer. Los agentes ejecutan dentro de ese marco, en paralelo, con límites explícitos. Y otros agentes auditan el resultado contra los mismos documentos, porque la ejecución rápida sin revisión no es velocidad, es deuda.

Lo que se gana no es solo tiempo. Es trazabilidad: cada decisión de diseño tiene un documento que la respalda, cada archivo tiene un responsable claro por tarea, y cada fase termina con una verificación que deja constancia de qué se revisó. Cuando algo sale mal —y algo siempre sale mal—, se sabe dónde mirar. La velocidad es la consecuencia de ese orden, no un atajo que lo sacrifica.

También hay una lección sobre los límites: los agentes son tan buenos como el contrato que reciben. Las partes del proyecto que salieron a la primera fueron las que tenían reglas escritas y verificables. Las que necesitaron iteración fueron las que dependían de criterio implícito. Cada vez que eso pasó, la corrección no fue 'explicarle mejor al agente', sino mejorar el documento para que la ambigüedad no volviera a existir.

Esto no es un experimento de laboratorio

El mismo método con el que construimos esta web lo aplicamos a productos en producción: sistemas que operan hoy, con usuarios reales y consecuencias reales, incluyendo un piloto con un operador logístico real en Lima. Ahí las verificaciones son más estrictas y los contratos más largos, pero la estructura es la misma: dirección humana, ejecución con agentes, auditoría antes de que nada llegue a producción.

Si te interesa ver qué estamos construyendo con este enfoque y hacia dónde lo estamos llevando, el AI Lab es el mejor punto de entrada: /lab.

Si este tema es prioritario para tu empresa, conversemos.

Podemos ayudarte a aterrizar este reto en una solución concreta para tu operación, tu equipo y tus objetivos de crecimiento.