Fase de consolidación
A esta altura, ya no busco solo inventar formas de hablarles a los modelos. Quiero ver qué banca cuando los vuelvo a meter en mis proyectos en curso.
Dos terrenos me sirven de prueba: una aplicación web completa para exponer los problemas de arquitectura, y mi configuración de sistema, que decide qué puede leer, cargar, llamar o modificar un agente.
Las pruebas de orquestación y las barandas siguen en el decorado. Acá el tema es más terrenal: ¿qué sobrevive cuando tengo que trabajar con esas reglas todos los días?
Una aplicación full-stack como banco de pruebas de arquitectura
Esta app web es mi terreno de prueba. Quiero un marco donde una IA pueda intervenir sin romperlo todo.
Empiezo por hacer visibles las fronteras: contratos entre módulos, tests de arquitectura y reglas que la CI puede rechazar (no solo “¿funciona?”, sino “¿respeta la arquitectura?”).
Para ayudar a la IA, limito el contexto: a veces una sola capa (toda la lógica de negocio), a veces una funcionalidad completa de front a back. Eso mantiene el contexto pequeño y evita daños colaterales.
No busco “dejarlo limpio”. Quiero un entorno donde la IA pueda proponer cambios, donde CI y tests filtren, y donde la arquitectura diga rápido si una propuesta se sale de los rieles.
Este proyecto es mi laboratorio de arquitectura. Ahí veo si mis ideas sobre contexto, reglas y calidad aguantan en una codebase real.
Dotfiles y configuración global: de la magia a las reglas
En paralelo al proyecto web y a la orquestación, retomo todo lo que gobierna mis IAs en el día a día: mi configuración de sistema (dotfiles como .bashrc o .gitconfig) y la configuración global de agentes a nivel sistema.
Al principio es una pila de hooks y scripts. Funciona mientras soy el único operador, pero es frágil de mantener. Paso entonces a presets: configuraciones listas para usar que agrupan herramientas, permisos y contexto según la tarea (MCP, sandbox, permisos, etc.). Eso me permite lanzar un agente con el nivel de acceso correcto sin reconfigurar todo a mano en cada sesión.
Estas pruebas también mostraron los límites de los MCP. Para medirlo de forma objetiva, programé un plugin casero que mide el coste en tokens al abrir una nueva sesión (o un subagente). Resultado: el 15-20% del presupuesto se iba de entrada, y no era el prompt del sistema. El peso venía sobre todo del apilamiento de MCP, alrededor de 36.000 tokens sobre 200.000.
Pasé entonces a carga bajo demanda: en lugar de abrir cada sesión con todo el menú de herramientas, arranco con lo mínimo útil. Para una tarea simple, ningún MCP. Para investigación, solo herramientas de documentación o búsqueda. Para una pasada front-end, las herramientas front-end, y Playwright solo cuando realmente necesito ver la página. La idea no es tener una matriz prolija de perfiles: es no pagar contexto por herramientas que no van a usarse.
En concreto, mis lanzadores seleccionan perfiles medidos al inicio: Base, 0 MCP (~0 tokens);
Minimal, Context7 (~1.300 tokens); Investigación, Context7 + Exa (~3.000 tokens); Front-end 1,
ShadCN (~5.500 tokens); Front-end 2, Context7 + ShadCN + Playwright (~14.000 tokens); y otros
perfiles, back-end, testing o exploración (Firecrawl, etc.), cargados bajo demanda. Estas cifras
no son benchmarks universales. Me sirven para comparar mis propios lanzadores y ver cuándo un
perfil carga demasiado antes de que el agente empiece.
Mantengo los menús avanzados como opcionales y corrijo algunos detalles de UX para quitar fricción.
También fijo una regla común para todos los agentes a nivel sistema. Es mi base global, la que aplica en todas partes.
Atención: esta limpieza no reemplaza los archivos de contexto de proyecto (
AI.md). Los complementa a nivel sistema. Es la base sobre la que se apoyan los proyectos.
La dirección sigue igual: evitar apilar lógica difícil de mantener y hacer las fronteras lo bastante visibles como para que un agente no las invente en el camino.
También formalizo algunas reglas de colaboración: consultar documentación antes de inventar una API, no adivinar cuando falta información, evitar estimaciones “mágicas”, mantenerse enfocado y marcar el resto con TODO/FIXME en lugar de arreglar todo de paso.
No son solo preferencias de estilo. Son barandas contra alucinaciones demasiado seguras, scope creep (la IA intentando arreglar todo a la vez) y ruido (comentarios o métricas que crean una ilusión de control).