GoVueKit usa tests para que los agentes no dupliquen código en tu boilerplate
El proyecto introduce un archivo de mapeo verificado por CI que guía a los LLM sobre qué módulos ya existen, evitando que reescriban funcionalidades.
GoVueKit ha lanzado una solución para un problema creciente en el desarrollo asistido por IA: los agentes de código tienden a recrear funcionalidades existentes si no saben que ya están implementadas. Al pedirle a un LLM que añada planes premium, este puede generar un segundo cliente de Stripe o tablas duplicadas solo porque no tiene conciencia del archivo internal/billing. El resultado es código que compila pero que duplica el trabajo y rompe la coherencia del sistema.
El mapa como parte del código
El enfoque de GoVueKit no es mejorar los prompts, ya que las instrucciones en el chat son volátiles. En su lugar, el proyecto incluye un archivo AGENTS.md en la raíz del repositorio. Este archivo es leído nativamente por herramientas como Codex y Cursor, e importado por Claude Code. No es documentación genérica, sino una tabla concreta que mapea capacidades al código: internal/billing para pagos, internal/email para correos, internal/jobs para tareas en segundo plano, etc.
La clave técnica está en cómo se mantiene este mapa actualizado. GoVueKit ha implementado un test específico, cmd/server/agents_test.go, que hace que la compilación falle (CI roja) si ocurre alguna de estas cosas:
- Existe un paquete en
internal/que no está documentado enAGENTS.md. - El archivo de agentes hace referencia a un camino que ya no existe.
- Una interfaz o "seam" documentada cambia de nombre.
Esto garantiza que si make test pasa, la información que el agente lee es cierta. Es una forma de prevención de deriva documental: el mapa no puede desincronizarse del código sin romper la integración continua.
Limitaciones y contexto
El kit incluye 186 tests en Go ejecutados sobre PostgreSQL y SQLite, así como 48 tests de frontend y 14 escenarios de Playwright que ejecutan el binario de producción real. Esto verifica que los cambios del agente respeten las reglas de multi-tenancy (por ejemplo, que una solicitud de otro tenant devuelva un 404) y la paridad de traducciones.
No obstante, el equipo reconoce las limitaciones. El enfoque funciona bien porque GoVueKit es un boilerplate pequeño (19 paquetes Go, una sola migración de esquema). En un framework extenso, este mapa sería un libro demasiado grande para la ventana de contexto de un LLM. Además, el mapa evita duplicar código base, pero no garantiza que la lógica de negocio que pide el usuario sea buena ni que el código generado sea elegante. La revisión humana sigue siendo necesaria.
Para quienes trabajan con boiletplates de Go y Vue 3, esta es una señal de que la gestión de la documentación para agentes está dejando de ser un afterthought para convertirse en una parte verificable de la arquitectura del proyecto. Si evalúas herramientas similares, la pregunta clave es cuánto del proyecto cabe en el contexto del modelo y cómo sabes que la documentación no miente.
