kthulu-go: que el agente trabaje sobre estructura

El problema

Pedirle a un agente que «añada pagos» a un proyecto vacío o desordenado produce código que funciona hoy y no encaja mañana. El agente trabaja sobre texto suelto: no sabe dónde va cada cosa, qué convenciones hay ni qué módulos dependen de cuáles. El resultado depende de la suerte del prompt.

Quería darle al agente lo mismo que a una persona nueva en el equipo: un plano, una estructura predecible y herramientas que respetan esa estructura.

Decisiones

Arquitectura como código. kthulu plan produce un blueprint YAML del sistema (módulos, campos, features) y kthulu create lo convierte en un proyecto. El punto de partida es un plan revisable, no una carpeta vacía.

Monolito modular por features. El código se organiza en slices verticales por funcionalidad, no por capa técnica, con Go, Templ y HTMX. Cada módulo es cohesivo y un agente puede trabajar dentro de uno sin tocar los demás.

El CLI entero como servidor MCP. Cualquier agente compatible (Claude, Cursor y otros) puede usar Kthulu para generar y modificar software con las mismas órdenes que una persona. Además, Kthulu genera servidores MCP: la plantilla mcp crea uno sin dependencias, con interfaz MCP Apps y tests de protocolo.

Declarar en lugar de repetir. Las reglas de validación se escriben en el blueprint y generan el método Validate(), su aplicación en el servicio y respuestas 422 con errores por campo.

Qué hay construido

• Planificación y scaffolding desde blueprint, con plantillas y features combinables (pagos, carrito, colas, correo, almacenamiento).
• Colas de trabajos sobre la base de datos con reintentos, dead letters y tareas periódicas, sin infraestructura extra.
• Migraciones que comparan las entidades con la base de datos real y generan solo cambios aditivos; los destructivos se informan pero nunca se aplican.
• Consola interactiva, BDD con Gherkin y un agente de terminal (kthulu coder).
• Landing y documentación en kthulu-go.vercel.app.

Lo que aprendí

El mejor prompt para un agente es una buena estructura de proyecto. Cuando el plano, las convenciones y las herramientas son explícitos, el agente deja de adivinar y el código generado se parece al que escribiría el equipo.