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

El autor describe un experimento de cuatro meses. Construyó una aplicación en producción con Elixir/Phoenix mediante Claude Code y no escribió código a mano. En ese tiempo, el proyecto alcanzó 1 702 commits, 3 880 tests y un 94,83% de cobertura. Por el camino también sufrió dos incidentes graves en producción.

Escala del proyecto

No se trataba de una demo ni de un proyecto personal. Era EasyStocksAI, un servicio que evalúa más de 1 000 acciones según 15 métricas. La aplicación calcula una puntuación en cuatro bloques y gestiona carteras con historial de operaciones. También compara los resultados con estrategias de benchmark y muestra gráficos interactivos. Además, el autor creó un blog con un parser de Markdown propio que convierte tickers y comandos en enlaces y gráficos integrados. El stack también es de producción: Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind y Lightweight Charts.

Por sus cifras, el proyecto se parece más a un producto completo que a un experimento. La base de código suma 422 mil líneas de Elixir, más de 73 mil líneas de tests, más de 300 módulos, 34 workers de Oban y 80 migraciones de base de datos. Los datos llegan de cinco API con un fallback en cascada. Si una fuente no responde, el sistema pasa automáticamente a la siguiente. Todo funcionaba sobre una infraestructura modesta: un VPS en Vultr y PostgreSQL en AWS RDS. El CI/CD se montó con GitHub Actions.

Cómo se mantuvo la calidad

El principal mecanismo de control fue el archivo CLAUDE.md, que Claude Code lee en cada sesión. El autor lo describe como la constitución del proyecto. Recoge los comandos obligatorios, las prohibiciones y las reglas de arquitectura. Sin estas restricciones, la IA escribe código que funciona pero que resulta difícil de controlar. Con ellas, mantiene un estilo uniforme y no olvida el proceso. Cada error nuevo se convertía en una regla nueva, así que el documento creció junto con el producto.

• Después de cualquier cambio son obligatorios mix format y mix credo --strict
• Ni una sola línea de código de producción sin un test que falle
• Para datos financieros se prohíbe float; solo Decimal
• En los workers de Oban no se pueden hacer consultas a la base de datos dentro de bucles
• La base de datos es la principal fuente de verdad, no el estado de los procesos

Además, el autor separó roles dentro del propio desarrollo con IA. En el modo Director, el modelo se ocupa de la arquitectura, los ADR y el plan de cambios. En el modo Implementor, escribe código siguiendo estrictamente ese plan y solo mediante TDD. El ciclo de trabajo se divide en tres fases: brainstorming, un plan detallado y ejecución en pasos pequeños de 2–5 minutos. Este enfoque elimina la deriva arquitectónica. Cada nueva sesión de la IA lee los ADR, los planes y los archivos de memoria. Así retoma el proyecto desde un contexto ya fijado y no desde cero.

Dónde la IA rompió producción

Lo más útil de la historia no son las cifras, sino el análisis de dos incidentes en producción.

En el primero, los workers de Oban y las peticiones web compartían un mismo pool de 15 conexiones a PostgreSQL. Cuando se lanzó un backfill de 923 tareas, la interfaz prácticamente se cayó. El problema se resolvió con un ObanRepo dedicado, con un pool propio para las operaciones internas de la cola. Después se añadieron a las reglas un query budget obligatorio para cada worker y límites de concurrencia para las colas.

El segundo fallo fue todavía más revelador. La IA añadió un ConnectionWatchdog para vigilar la salud del pool y evitar que se repitiera el primer incidente. Pero la propia monitorización provocó la siguiente caída. Bajo carga, las consultas con un timeout agresivo empezaron a matar conexiones, y en cuestión de segundos el watchdog tumbó todo el pool de Oban. Al final, el componente se eliminó sin más y la lección quedó registrada en la memoria del proyecto.

«Nunca uses pooled connections con timeouts agresivos para monitorización»

Además, el autor integró en la aplicación un MCP Debug Server para que Claude Code pudiera conectarse a producción como herramienta. Desde ahí puede leer logs, revisar las colas de Oban, ejecutar consultas SQL, comprobar métricas y reiniciar workers sin SSH ni depuración manual. Aun así, hay límites. El acceso se restringe a una lista blanca de acciones para que la depuración no se convierta en un agujero de seguridad.

La conclusión del autor es sencilla. La IA puede mantener un entorno de producción real si cuenta con reglas, memoria, postmortems y límites de acceso claros.

Qué significa

Esta historia muestra que el desarrollo con IA ya puede alcanzar el nivel de producción, pero no por sí solo. El papel clave no lo juega el modelo, sino la disciplina que lo rodea: TDD, decisiones de arquitectura, archivos de memoria, postmortems y guardrails estrictos. Si una persona sigue siendo la arquitecta y la editora del proceso, la IA acelera de verdad las entregas sin que la calidad tenga que resentirse.