Claude Code Helped Build a Production Elixir App in Four Months Without Hand-Written Code

The author describes a four-month experiment in which he built a production Elixir/Phoenix application with Claude Code and wrote no code by hand. Over that period, the project reached 1,702 commits, 3,880 tests, and 94.83% coverage. Along the way, it also went through two serious production incidents.

Project scale

This was not a demo or a pet project. EasyStocksAI is a service that rates more than 1,000 stocks across 15 metrics. The app calculates scores across four categories, manages portfolios with trade history, benchmarks results against reference strategies, and renders interactive charts. The author also built a blog with a custom Markdown parser that turns tickers and commands into links and embedded charts. The stack is production-grade as well: Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind, and Lightweight Charts.

By the numbers, the project looks more like a full product than an experiment. The codebase contains 422,000 lines of Elixir, more than 73,000 lines of tests, over 300 modules, 34 Oban workers, and 80 database migrations. Data comes from five APIs with cascading fallback: if one source doesn't respond, the system automatically moves to the next. The infrastructure is modest: a VPS on Vultr and PostgreSQL on AWS RDS, with CI/CD running on GitHub Actions.

How quality was maintained

The main control mechanism was a CLAUDE.md file, which Claude Code reads at the start of every session. The author calls it the project's constitution: it lists mandatory commands, prohibitions, and architectural rules. Without these constraints, the AI writes code that works but is hard to manage; with them, it keeps a consistent style and sticks to the process. Every new mistake became a new rule, so the document grew alongside the product.

• mix format and mix credo --strict are mandatory after every change
• No line of production code without a failing test
• Floats are banned for financial data; only Decimal is allowed
• Oban workers must not query the database inside loops
• The database, not process state, is the source of truth

On top of that, the author split the AI's work into roles. In Director mode, the model handles architecture, ADRs, and the change plan. In Implementor mode, it writes code strictly according to that plan and only through TDD. The workflow has three separate phases: brainstorming, a detailed plan, and execution in small 2–5 minute steps. This approach prevents architectural drift: each new AI session reads the ADRs, plans, and memory files, so it picks up from documented context instead of starting from scratch.

Where the AI broke production

The most useful part of the story isn't the numbers but the breakdown of two production incidents. In the first, Oban workers and web requests shared a single pool of 15 PostgreSQL connections. When a backfill of 923 jobs kicked off, the interface effectively went down. The fix was a dedicated ObanRepo with its own pool for internal queue operations. Afterward, the rules gained a mandatory query budget for every worker and concurrency limits for queues.

The second failure was even more revealing. The AI added a ConnectionWatchdog to monitor pool health and avoid a repeat of the first outage. But the monitoring itself caused the next crash: under load, queries with aggressive timeouts started killing connections, and within seconds the watchdog took down the entire Oban pool. In the end, the component was simply removed, and the lesson went into the project's memory.

"Never use pooled connections with aggressive timeouts for monitoring"

The author also built an MCP Debug Server into the app so Claude Code could connect to production as a tool: read logs, inspect Oban queues, run SQL queries, check metrics, and restart workers without SSH or manual debugging. Even here there are limits: access is restricted to a whitelist of actions so debugging doesn't become a security hole. The author's main takeaway is simple: AI can support a real production system, provided it has rules, memory, postmortems, and clear access boundaries.

What it means

This story shows that AI-driven development can already reach production quality, but not on its own. The key factor isn't the model but the discipline around it: TDD, architectural decisions, memory files, postmortems, and strict guardrails. If a human stays on as the architect and editor of the process, AI really does speed up delivery without necessarily sacrificing quality.