Construyendo Kaze: Una App de Producción en 27 Días con Agentes de IA

Construí una aplicación Rails de producción en 27 días, y escribí el 1.7% del código. Los agentes de IA se encargaron del resto: 545 commits, 2.236 tests con 97%+ de cobertura, autenticación, panel de admin, preparación de compliance, soporte bilingüe. Lo que me sorprendió fue cuánto cambió el trabajo cuando dejé de tipear código y empecé a dirigir agentes.

Qué es Kaze

Kaze es un asistente de chat IA seguro para niños de 5 a 18 años. Pensá en ChatGPT, pero diseñado para niños con supervisión parental y una arquitectura de seguridad de 4 capas: filtrado de entrada, reglas de chat integradas, moderación de salida y revisión parental. Los padres crean cuentas vía magic links, agregan hasta 5 perfiles de niños, y cada niño conecta con un código de 8 caracteres. Sin publicidad, sin venta de datos, alineado con COPPA. Los requisitos de seguridad moldearon cada decisión arquitectónica, desde la construcción de prompts hasta el almacenamiento de conversaciones.

El codebase incluye 34 modelos, 60 controladores, 157 vistas, ~23.000 líneas de código de aplicación, y soporte bilingüe completo inglés/español desde el día 2. No es una demo. Construida enteramente a través de agentes de IA operando bajo un proceso de ingeniería estructurado (OpenUP).

El triunfo de la tecnología aburrida

Elegí Rails 8.1 con PostgreSQL porque la IA escribe mejor Rails que cualquier otra cosa que probé. Rails está extremadamente bien representado en los datos de entrenamiento, así que la IA produce código idiomático y conoce las convenciones del ecosistema. El Solid Stack (SolidQueue, SolidCache, SolidCable) eliminó Redis por completo, y RubyLLM me dio integración LLM agnóstica de proveedor con OpenAI, Anthropic y Ollama.

Experimenté brevemente con un setup de frontend más moderno al principio. Perdí medio día antes de volver atrás. La fortaleza de la IA es producir código correcto en ecosistemas bien establecidos. La tecnología aburrida es una ventaja.

Los Números

545 commits totales en 27 días calendario. Co-autoría IA: 429 (78.7%). Commits de merge: 98 (18.0%). Dependabot: 9 (1.7%). Commits solo humanos: 9 (1.7%). Esos 9 commits humanos fueron todos cambios rápidos de configuración, cosas más rápidas de tipear directamente que de describir a un agente. Ningún código de funcionalidad fue escrito por mí.

Tres modelos de Claude se repartieron el trabajo: Opus 4.6 manejó 215 commits (39.4%) para tareas complejas de arquitectura y compliance, Sonnet 4.6 tomó 197 commits (36.1%) para funcionalidades estándar, y Haiku 4.5 cubrió 17 commits (3.1%) para arreglos rápidos. Elegí el modelo para cada tarea de la misma forma que un tech lead asigna personas, según la dificultad del problema.

Qué Hice Realmente

La mayor parte de mi tiempo fue en tres roles: product owner, revisor de PRs y diseñador de procesos. A veces los tres en la misma hora.

Product owner. Cada funcionalidad empezó como mi decisión sobre qué construir y por qué. La IA nunca decidió qué construir a continuación. Las decisiones más impactantes en Kaze fueron decisiones de producto: qué funcionalidades incluir, cuándo pausar para trabajo de calidad, cuándo abordar seguridad a mitad de construcción en lugar de al final.

Revisor de PRs. 98 pull requests mergeados en 27 días, 3.6 por día. El código generado por IA rara vez tiene bugs obvios, lo que hace que los sutiles sean más difíciles de detectar. Una vez me quemé con un PR que se veía limpio pero no resolvía el problema real. Después de eso empecé a revisar el plan antes que el código.

El rol que más me importa es diseñador de procesos. Adapté OpenUP para agentes de IA, construí 26 skills personalizados de Claude Code, definí 5 roles de equipo de agentes, y diseñé la estructura de documentación que sirve como memoria institucional de la IA. Un buen proceso mejora todo lo demás. Pero tiene que mantenerse transparente, corriendo en segundo plano como un supervisor, observando y tomando notas para actuar en la próxima iteración. Si tu proceso es sólido, no importa mucho qué modelo ejecuta la tarea.

Y después está la tranquilidad de un buen control de calidad. La trayectoria de tests cuenta la historia: 0 tests el día 1, 69 para el día 2, 371 para el día 3, 1.067 para el día 5 con 91.1% de cobertura. Después, durante un sprint de alta velocidad (panel de admin, compliance, monetización), la cobertura cayó a 85.5% para el día 16 aunque el número absoluto de tests seguía creciendo. Dediqué un rato solo a recuperar la cobertura: día 17, de vuelta a 97.9%. Número final: 2.236 tests con 97%+. La IA no te va a avisar que la cobertura está cayendo. Tenés que mirar los números vos mismo.

Qué Viene Después

Este artículo es el resumen general. El resto de la serie cubre el proceso estructurado, los skills personalizados y roles de agente, documentación como memoria de IA, un desglose completo de métricas, y qué salió mal en el camino.

Lo que todavía estoy procesando

Durante 30 años fui ingeniero de software. En este proyecto, escribí 9 commits de 545. Cada decisión arquitectónica, cada estándar de calidad, cada prioridad de funcionalidad, cada restricción de seguridad vino de mí. Pero todavía no tengo del todo claro cómo sentirme con que mi mes más productivo haya involucrado casi nada de programación.

A mí me resultó estimulante. El testing principal hasta ahora es mi hijo de 11 años y yo usando el software todos los días. Lo construí para nosotros. A nosotros nos funciona. Si les funciona a otras familias es algo que solo puedo averiguar poniéndolo frente a ellas. Si querés probarlo, usá este código de invitación y experimenta en primera persona.