Claude Code helped build a production Elixir application without hand-written code in four months

The author described a four-month experiment: a production Elixir/Phoenix application was built through Claude Code without manual code writing. During this time, the project reached 1,702 commits, 3,880 tests, and 94.83% coverage, but experienced two serious production incidents along the way.

Project Scale

This wasn't about a demo or pet project, but about EasyStocksAI, a service for evaluating over 1,000 stocks across 15 metrics. The application calculates scores across four blocks, maintains portfolios with transaction history, compares results against benchmark strategies, and displays interactive charts. The author also built a blog with a custom Markdown parser that can transform tickers and commands into links and embedded charts.

The stack itself is thoroughly production-ready: Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind, and Lightweight Charts.

By the numbers, the project turned out to be closer to a full product than an experiment. The codebase contains 422 thousand lines of Elixir code, over 73 thousand lines of tests, more than 300 modules, 34 Oban workers, and 80 database migrations. Data is pulled from five APIs at once with cascading fallback: if one source doesn't respond, the system automatically switches to the next. Everything ran on modest infrastructure: a Vultr VPS and PostgreSQL in AWS RDS, while CI/CD was built through GitHub Actions.

How Quality Was Maintained

The key control mechanism was a CLAUDE.md file that Claude Code reads in each session. The author describes it as the project's constitution: it contains mandatory commands, prohibitions, and architectural rules. Without such constraints, AI writes functional but poorly manageable code; with them, it maintains consistent style and doesn't forget the process. Each new error became a new rule, so the document grew alongside the product.

• After any change, mix format and mix credo --strict are mandatory
• Not a single line of production code without a failing test
• For financial data, float is forbidden; only Decimal is allowed
• Oban workers cannot make database requests inside loops
• The database is considered the source of truth, not process state

On top of this, the author separated roles within AI development itself. In Director mode, the model handles architecture, ADRs, and change plans; in Implementor mode, it writes code strictly according to the plan and only through TDD. The work cycle is split into three distinct phases: brainstorming, detailed planning, and execution in small 2–5 minute steps. This approach eliminates architectural drift: each new AI session reads the ADRs, plans, and memory files and continues the project from established context, not from scratch.

Where AI Broke Production

The most valuable part of the story isn't the numbers, but the breakdown of two production incidents.

In the first case, Oban workers and web requests shared a single pool of 15 connections to PostgreSQL. When a backfill of 923 tasks was launched, the interface effectively went down. The problem was solved with a dedicated ObanRepo with a separate pool for internal queue operations. After this, mandatory query budgets for each worker and queue concurrency limits were added to the rules.

The second failure was even more instructive. AI added a ConnectionWatchdog to monitor pool health and avoid repeating the first incident. But the monitoring itself became the cause of the next failure: under load, requests with aggressive timeouts started killing connections, and the watchdog took down the entire Oban pool in seconds. In the end, the component was simply removed, and the lesson was recorded in the project's memory.

"Never use pooled connections with aggressive timeouts for monitoring"

Separately, the author built an MCP Debug Server into the application so Claude Code could connect to production as a tool: read logs, check Oban queues, execute SQL queries, check metrics, and restart workers without SSH and manual debugging. But even here there are boundaries: access is restricted to a whitelist of actions so debugging doesn't become a security hole.

The author's main conclusion is straightforward: AI can perfectly well maintain real production, given rules, memory, postmortems, and clear access boundaries.

What This Means

This story shows that AI development can already reach production level, but not by itself. The key role isn't played by the model, but by discipline around it: TDD, architectural decisions, memory files, postmortems, and hard guardrails. If a human remains the architect and editor of the process, AI truly accelerates delivery without necessarily sacrificing quality.