Claude Code ayudó a crear una aplicación de producción en Elixir sin escribir código a mano en cuatro meses

El autor describió un experimento de cuatro meses: una aplicación Elixir/Phoenix en producción fue construida a través de Claude Code sin escritura manual de código. Durante este tiempo, el proyecto alcanzó 1.702 commits, 3.880 tests y 94,83% de cobertura, pero experimentó dos incidentes graves en producción en el camino.

Escala del Proyecto

No se trataba de un demo o proyecto personal, sino de un servicio EasyStocksAI para evaluar más de 1.000 acciones en 15 métricas. La aplicación calcula puntuaciones en cuatro bloques, mantiene portafolios con historial de transacciones, compara resultados con estrategias de referencia y muestra gráficos interactivos. El autor también construyó un blog con un parser Markdown personalizado que puede transformar tickers y comandos en enlaces y gráficos incrustados.

El stack también es completamente production-ready: Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind y Lightweight Charts.

Por los números, el proyecto resultó ser más cercano a un producto completo que a un experimento. La base de código contiene 422 mil líneas de código Elixir, más de 73 mil líneas de tests, más de 300 módulos, 34 workers Oban y 80 migraciones de base de datos. Los datos se extraen de cinco APIs simultáneamente con fallback en cascada: si una fuente no responde, el sistema automáticamente cambia a la siguiente. Todo se ejecutaba en infraestructura modesta: un VPS en Vultr y PostgreSQL en AWS RDS, mientras que CI/CD fue construido a través de GitHub Actions.

Cómo se Mantuvo la Calidad

El mecanismo de control principal fue un archivo CLAUDE.md que Claude Code lee en cada sesión. El autor lo describe como la constitución del proyecto: contiene comandos obligatorios, prohibiciones y reglas arquitectónicas. Sin tales restricciones, AI escribe código funcional pero mal gestionable; con ellas, mantiene estilo consistente y no olvida el proceso. Cada nuevo error se convirtió en una nueva regla, por lo que el documento creció junto con el producto.

• Después de cualquier cambio, mix format y mix credo --strict son obligatorios
• Ni una sola línea de código de producción sin un test fallando
• Para datos financieros, float está prohibido; solo se permite Decimal
• Los workers Oban no pueden hacer peticiones a la base de datos dentro de bucles
• La base de datos se considera la fuente de verdad, no el estado de los procesos

Además de esto, el autor separó roles dentro del desarrollo de AI en sí. En modo Director, el modelo se encarga de arquitectura, ADRs y planes de cambios; en modo Implementor, escribe código estrictamente según el plan y solo a través de TDD. El ciclo de trabajo se divide en tres fases distintas: brainstorming, planificación detallada y ejecución en pequeños pasos de 2–5 minutos. Este enfoque elimina la deriva arquitectónica: cada nueva sesión de AI lee los ADRs, planes y archivos de memoria y continúa el proyecto desde el contexto establecido, no desde cero.

Dónde AI Rompió Producción

La parte más valiosa de la historia no son los números, sino el análisis de dos incidentes en producción.

En el primer caso, los workers Oban y las peticiones web compartían un único pool de 15 conexiones a PostgreSQL. Cuando se lanzó un backfill de 923 tareas, la interfaz efectivamente se cayó. El problema se resolvió con un ObanRepo dedicado con un pool separado para operaciones internas de la cola. Después de esto, se agregaron presupuestos de query obligatorios para cada worker y límites de concurrencia de cola a las reglas.

El segundo fallo fue aún más instructivo. AI añadió un ConnectionWatchdog para monitorear la salud del pool y evitar repetir el primer incidente. Pero el monitoreo en sí se convirtió en la causa de la siguiente caída: bajo carga, las peticiones con timeouts agresivos comenzaron a matar conexiones, y el watchdog derribó todo el pool Oban en segundos. Al final, el componente fue simplemente eliminado, y la lección fue registrada en la memoria del proyecto.

"Nunca uses pooled connections con timeouts agresivos para monitoreo"

Por separado, el autor construyó un MCP Debug Server en la aplicación para que Claude Code pudiera conectarse a producción como una herramienta: leer logs, verificar colas Oban, ejecutar queries SQL, verificar métricas y reiniciar workers sin SSH y debugging manual. Pero incluso aquí hay límites: el acceso está restringido a una whitelist de acciones para que el debugging no se convierta en un agujero de seguridad.

La conclusión principal del autor es simple: AI puede mantener perfectamente bien producción real, dados reglas, memoria, postmortems y límites de acceso claros.

Qué Significa Esto

Esta historia muestra que el desarrollo con AI ya puede alcanzar nivel de producción, pero no por sí solo. El papel clave no lo juega el modelo, sino la disciplina a su alrededor: TDD, decisiones arquitectónicas, archivos de memoria, postmortems y guardrails rígidos. Si un humano sigue siendo el arquitecto y editor del proceso, AI verdaderamente acelera la entrega sin necesariamente sacrificar calidad.