Estabilización y terreno de prueba

Fase de consolidación (verano-finales de 2025)

Entre los frentes que llevaba en ese momento, estos tres muestran cómo aplico el marco (contexto, reglas, herramientas) en el trabajo diario:

• una app web personal (tipo SaaS) que se convirtió en un verdadero terreno de prueba para IA;
• un proyecto de orquestación que usé como crash test de sobreingeniería;
• mi configuración de sistema (dotfiles) y mi configuración global de IA, desplegadas en mis máquinas y servidores.

Este periodo fijó mi postura: encuadrar, delegar, verificar. Empecé a sentirme como una especie de director de orquesta.

Una aplicación full-stack como banco de pruebas de arquitectura

Esta app web fue mi terreno de prueba. Quería un marco donde una IA pudiera intervenir sin romperlo todo.

Me enfoqué en tres cosas simples: hacer explícita la arquitectura, definir contratos entre módulos y reforzar las pruebas (no solo “¿funciona?”, sino “¿respeta la arquitectura?”).

Para ayudar a la IA, limité el contexto. A veces le doy una sola capa (toda la lógica de negocio), otras veces una funcionalidad completa de front a back. Eso mantiene el contexto pequeño y evita daños colaterales.

No buscaba “dejarlo limpio” por perfeccionismo. Quería 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 se volvió mi laboratorio de arquitectura. Ahí comprobé 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, revisé 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 era una pila de hooks y scripts. Funcionaba mientras yo era el único operador, pero era frágil de mantener. Pasé 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: solo los MCP útiles para la tarea. Mis lanzadores seleccionan perfiles predefinidos según necesidad:

• Base (0 MCP): ningún MCP cargado (~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);
• Otros perfiles: back-end, testing, exploración (Firecrawl, etc.), cargados bajo demanda.

Mantuve los menús avanzados como opcionales y corregí algunos detalles de UX para quitar fricción.

También fijé 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 se mantuvo igual: evitar apilar lógica difícil de mantener y preferir reglas simples, visibles y documentadas, que dejen claro qué está fuera de límites.

También formalicé 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 barandillas 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).