Barandillas
Tests, reglas y restricciones para mantener el control.
Introducción: de la arquitectura al método
En los capítulos anteriores (La odisea del contexto), probé varias formas de cargar y pasar contexto a los agentes. Al final volví a algo más pragmático cuando vi el impacto directo en el código.
Tenía una constitución clara y archivos de instrucciones bien mantenidos. Sobre el papel, todo estaba ordenado. En el código era otra historia: la IA genera, y a veces se equivoca. Necesitaba barandillas, no promesas.
Seguía la pregunta del día a día: ¿cómo trabajar con agentes sin volver a una fábrica de gas? Este capítulo cuenta cómo puse rieles de calidad para que cada iteración devolviera feedback inmediato.
Estado de situación
En esta etapa, ya vivo con estas herramientas todos los días. Mi setup incluye:
- prompts reutilizables (comandos, skills);
- una constitución de proyecto única (reglas y marco compartido);
- un orquestador capaz de lanzar agentes y cerrar el bucle con subagentes;
- una CI robusta que solo deja pasar PRs con tests y build en verde;
- scripts y mapeos simbólicos para generar archivos de contexto para varias herramientas.
Voy alternando entre arquitectura, dirección técnica y tooling. Sigo programando, pero sobre todo para reforzar el ecosistema de automatización.
El problema real ya no era acumular más consignas, sino volver la calidad verificable.
Hacia herramientas de aseguramiento de calidad y orquestación
A partir de ahí, busqué una señal simple: la IA propone, el sistema responde. Si algo se rompe, quiero feedback claro y cómo corregirlo en seguida. El objetivo no es educar al modelo a base de prompts más largos, sino poner los límites en el código.
Se habla mucho de DX (Developer Experience) para humanos. Yo hablo de AIX: la misma idea, pero para sistemas de IA. Cuando configuro un linter, un mensaje de error o un script, lo hago para que una IA entienda y se corrija sola. Si el feedback es claro, avanza. Si es vago, patina y repite errores.
El bucle operativo (del prompt a las barandillas).
- Defino la tarea (normalmente en términos simples).
- La IA planifica y explora la codebase, detecta patrones existentes y propone una implementación.
- Edita el código y ejecuta tests locales (scripts instrumentados).
- Guarda y hace commit con Git.
- Mis hooks y pipelines se disparan automáticamente: linters, checks de tipos, reglas de arquitectura y tests unitarios/integración.
- El feedback vuelve a la IA (logs, errores, diffs), que corrige y vuelve a intentar hasta validar.
- La CI repite la misma batería de controles (y algunos más pesados) antes de autorizar PR/merge.
En concreto, esto es lo que puse en marcha:
- Linting y formateo automatizados en local y en CI;
- Type checking estricto (TypeScript en modo estricto);
- Reglas de arquitectura automatizadas (Dependency Cruiser);
- Tests unitarios y de integración pensados para flujos con agentes;
- Git hooks que notifican a los agentes y disparan análisis y sugerencias;
- Pipelines de CI que ejecutan verificaciones avanzadas y suben tickets/acciones.
Nota (hoy): mis workflows siguieron evolucionando. Ahora tengo hooks que se lanzan en cuanto se escribe o modifica un archivo en Claude Code (lint/typecheck). El feedback llega más rápido, pero es menos completo que los controles al commit y en CI.
Depuré y publiqué el validador de arquitectura como open source: hex-validator. Está hecho para mis decisiones de arquitectura, pero sus reglas y patrones pueden servir de inspiración.
La idea es simple: dejar que la IA proponga, pero forzarla a pasar por un sistema que valida, bloquea o devuelve feedback accionable.
La continuación llega en una fase de estabilización más larga, donde estas barandillas se ponen a prueba en proyectos reales.