ساعد Claude Code على بناء تطبيق Elixir للإنتاج من دون كتابة كود يدويًا خلال أربعة أشهر

Автор описал четырехмесячный эксперимент: production-приложение на Elixir/Phoenix собиралось через Claude Code без ручного написания кода. За это время проект дошел до 1 702 коммитов, 3 880 тестов и 94,83% покрытия, но по пути успел пережить два серьезных инцидента в проде.

Масштаб проекта

Речь шла не о демо или пет-проекте, а о сервисе EasyStocksAI для оценки более 1 000 акций по 15 метрикам. Приложение считает скоринг по четырем блокам, ведет портфели с историей сделок, сравнивает результаты с benchmark-стратегиями и показывает интерактивные графики. Отдельно автор сделал блог с кастомным Markdown-парсером, который умеет превращать тикеры и команды в ссылки и встроенные графики.

Стек тоже вполне production: Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind и Lightweight Charts. По цифрам проект оказался ближе к полноценному продукту, чем к эксперименту. В кодовой базе — 422 тысячи строк Elixir-кода, свыше 73 тысяч строк тестов, более 300 модулей, 34 Oban-воркера и 80 миграций базы.

Данные тянутся сразу из пяти API с каскадным fallback: если один источник не отвечает, система автоматически уходит к следующему. Запускалось все на скромной инфраструктуре: VPS на Vultr и PostgreSQL в AWS RDS, а CI/CD был собран через GitHub Actions.

Как держали качество

Главным механизмом контроля стал файл CLAUDE.md, который Claude Code читает в каждой сессии. Автор описывает его как конституцию проекта: там зафиксированы обязательные команды, запреты и архитектурные правила. Без таких ограничений AI пишет рабочий, но плохо управляемый код; с ними — держит единый стиль и не забывает процесс. Каждая новая ошибка превращалась в новое правило, поэтому документ рос вместе с продуктом.

• После любого изменения обязательны mix format и mix credo --strict Ни одной строки production-кода без падающего теста Для финансовых данных запрещены float, только Decimal В Oban-воркерах нельзя делать запросы к базе внутри циклов База данных считается главным источником истины, а не состояние процессов Поверх этого автор развел роли внутри самой AI-разработки. В режиме Director модель занимается архитектурой, ADR и планом изменений, а в режиме Implementor пишет код строго по этому плану и только через TDD. Рабочий цикл разбит на три отдельные фазы: brainstorming, детальный план и исполнение маленькими шагами по 2–5 минут. Такой подход убирает архитектурный дрейф: новая сессия AI читает ADR, планы и memory-файлы и продолжает проект не с нуля, а из уже зафиксированного контекста.

Где AI ломал прод Самая полезная часть истории — не цифры, а разбор двух production-инцидентов.

В первом случае Oban-воркеры и веб-запросы делили один пул из 15 соединений к PostgreSQL. Когда запустили бэкфилл на 923 задачи, интерфейс фактически лег. Проблему решили выделенным ObanRepo с отдельным пулом для внутренних операций очереди. После этого в правила добавили обязательный query budget для каждого воркера и ограничения по конкурентности очередей. Второй сбой оказался еще показательнее. AI добавил ConnectionWatchdog, чтобы следить за здоровьем пула и не повторить первую аварию. Но мониторинг сам стал причиной следующего падения: под нагрузкой запросы с агрессивным таймаутом начали убивать соединения, и watchdog за считаные секунды положил весь Oban-пул. В итоге компонент просто удалили, а урок записали в память проекта.

«Никогда не используй pooled connections с агрессивными таймаутами для мониторинга»

Отдельно автор встроил в приложение MCP Debug Server, чтобы Claude Code мог подключаться к production как к инструменту: читать логи, смотреть очереди Oban, выполнять SQL-запросы, проверять метрики и перезапускать воркеры без SSH и ручного дебага. Но даже здесь есть границы: доступ разрешен только к белому списку действий, чтобы отладка не превратилась в дыру в безопасности. Главный вывод автора простой: AI вполне может поддерживать реальный прод, если у него есть правила, память, постмортемы и понятные границы доступа.

Что это значит

Эта история показывает, что AI-разработка уже может дотягиваться до production-уровня, но не сама по себе. Ключевую роль играет не модель, а дисциплина вокруг нее: TDD, архитектурные решения, memory-файлы, постмортемы и жесткие guardrails. Если человек остается архитектором и редактором процесса, AI действительно ускоряет поставку без обязательного падения качества.