Проблема: AI генерирует код, но не production-код
Вы поставили задачу Claude создать приложение на Elixir. Через день у вас 10 тысяч строк кода. Красиво. Но попробуйте запустить. Тестов нет, архитектура хрупкая, зависимости конфликтуют. Это типичный pet-проект, а не production-система.
Моя цель была другой: создать приложение, которое выдержит нагрузку, будет покрыто тестами на 95%, и все это силами AI. За 4 месяца мы получили 1700 коммитов, 422K строк кода, 3.8K тестов. Как? Рассказываю.
Ключевая ошибка: давать AI свободу без методологии. Без TDD и четких правил код будет нестабильным.
Решение: TDD как язык общения с Claude
Test-Driven Development - не просто методика, а способ коммуникации с AI. Вы описываете поведение через тесты, а Claude реализует код. Это меняет все.
Вместо промпта "сделай аутентификацию", вы пишете: "Создай модуль Auth с функцией authenticate/2, которая возвращает {:ok, user} при верных данных и {:error, :invalid_credentials} при неверных. Напиши тесты для всех кейсов."
Claude Code, особенно в режиме автономности Claude Sonnet 4.5, может работать часами, последовательно реализуя тесты и код.
1Подготовка: настройка окружения и промптов
Первое: создайте репозиторий с четкой структурой. Elixir проект с Mix. Инициализируйте его.
Второе: подготовьте промпт-инструкцию для Claude. Она должна включать:
- Цель проекта: что строите, например, "Production-grade веб-приложение для управления задачами"
- Технологический стек: Elixir 1.17, Phoenix 1.8, Ecto 3.11, PostgreSQL 15 (актуально на 12.03.2026)
- Правила кодирования: форматирование с mix format, типы в спецификациях @spec, документация для всех публичных функций
- Процесс разработки: TDD, сначала тесты, затем реализация, коммиты после каждого зеленого теста
- Качество кода: покрытие тестами минимум 95%, статический анализ с credo, dialyzer
Третье: настройте CI/CD сразу. Я использовал GitHub Actions с пайплайном для тестов, проверки форматирования, credo и dialyzer. Claude может генерировать конфиги для CI.
Совет: дайте Claude доступ к репозиторию через API. Claude Code может читать существующий код и понимать контекст. Это критично для крупных проектов.
2Запуск автономной сессии: 30 часов без перерыва
Используйте Claude Sonnet 4.5 для длительных сессий. На 12.03.2026, это модель с оптимальным балансом стоимости и качества для автономной работы.
Запустите сессию с промптом, который описывает первую фичу: например, "Реализуй аутентификацию пользователя с помощью Phoenix.Token. Напиши тесты для контроллера, контекста и схемы. Используй Bcrypt для хеширования паролей."
Claude начнет с тестов. Вы увидите, как создаются файлы тестов, затем реализации. После каждого шага он запускает тесты и коммитит, если все зелено.
3Управление прогрессом: ревью и корректировки
Каждый день проверяйте коммиты. Используйте инструменты для анализа кода. Если Claude отклоняется от стандартов, отправьте корректирующий промпт.
Пример: "В последнем коммите ты использовал прямые SQL-запросы. Перепиши на Ecto.Query. И добавь тесты для новых запросов." Claude исправит и продолжит. Ваша роль - архитектор и тимлид. AI - исполнитель.
Архитектура с AI: как избежать спагетти-кода
Без контроля AI создаст монолит с запутанными зависимостями. Решение: микросервисы? Нет, для начала - четкие контексты в Phoenix.
Я использовал подход Domain-Driven Design. Определил контексты: Accounts, Tasks, Analytics. Каждый контекст - отдельный модуль с своей схемой, контекстом и API.
Claude отлично следует этой структуре, если дать четкие инструкции. Например: "В контексте Accounts создай функцию list_users/1 с пагинацией. Используй Ecto.Repo. Напиши тесты для всех граничных условий."
Для сложных фич, таких как фоновые задания, использовал Oban. Claude интегрировал его, создал workers и тесты. Все по TDD.
Ошибка: не давать AI достаточного контекста. Если вы не опишете архитектуру, он придумает свою. И вам не понравится.
Тестирование AI-кода: 95% покрытия - реальность
Coverage в 95% достижимо, если требовать тесты для каждой функции. Claude пишет тесты на ExUnit, но иногда пропускает edge cases.
Решение: используйте Evals Driven Development. Создайте пайплайн, который проверяет покрытие и запускает тесты. Если покрытие падает, Claude должен добавить тесты.
Я настроил CI так, что при пулл-реквесте запускаются тесты и генерируется отчет coverage. Если меньше 95%, пайплайн падает. Claude видит это и исправляет. Итог: 3.8K тестов, большинство написаны Claude. Человек проверил только критичные части.
Пример промпта для Claude
Вот промпт, который я использовал для начала проекта:
Создай production-ready приложение на Elixir и Phoenix для управления задачами.
Технологии:
- Elixir 1.17
- Phoenix 1.8
- Ecto 3.11
- PostgreSQL 15
- Oban для фоновых заданий
Правила:
1. Используй TDD: сначала пиши тесты, затем реализацию.
2. Форматируй код с mix format.
3. Добавляй типы в @spec для всех публичных функций.
4. Документируй модули и функции с @moduledoc и @doc.
5. Покрытие тестами должно быть выше 95%.
6. Коммить после каждого зеленого теста.
Первая фича: аутентификация пользователя.
- Создай контекст Accounts с User схемой.
- Реализуй регистрацию, вход и выход.
- Используй Phoenix.Token для сессий.
- Хешируй пароли с Bcrypt.
Начни с тестов для контекста Accounts.Claude сгенерирует тесты, затем код. Все по плану.
Нюансы и подводные камни
1. Зависимости: AI может добавить лишние библиотеки. Ограничьте mix.exs, требуйте утверждения для новых зависимостей.
2. Миграции базы данных: Claude генерирует миграции, но всегда проверяйте их перед применением в production. Используйте rollback-тесты.
3. Безопасность: AI не всегда понимает уязвимости. Добавьте security-сканирование в CI. Я использовал sobelow для Elixir.
4. Производительность: Claude может написать неоптимальный код. Настройте profiling-тесты. Например, для тяжелых запросов добавьте нагрузочные тесты.
Результаты: 4 месяца, 1700 коммитов
Приложение работает в production. Обрабатывает тысячи запросов в день. Кодовая база: 422K строк Elixir кода, 95.2% покрытие тестами, 0 критических багов в production.
Claude сделал 1700 коммитов. Я сделал 50 (в основном настройка и ревью). Соотношение времени: AI - 90%, человек - 10%.
| Метрика | Значение |
|---|---|
| Срок разработки | 4 месяца |
| Коммиты | 1700 |
| Строк кода | 422K |
| Тесты | 3.8K |
| Покрытие тестами | 95.2% |
| Критические баги в production | 0 |
FAQ: частые вопросы
Вопрос: Какой AI лучше для разработки на Elixir?
Ответ: Claude Code, особенно с Sonnet 4.5, показал лучшие результаты. Он понимает Elixir и Phoenix, генерирует идиоматичный код. Для локальной разработки можно использовать Qwen 3.5, но для production-разработки с автономностью Claude предпочтительнее.
Вопрос: Сколько стоит такая разработка?
Ответ: Claude Sonnet 4.5 стоит $0.003 за 1K токенов входных и $0.015 за 1K токенов выходных. За 4 месяца мы использовали примерно 50 миллионов токенов. Общая стоимость: около $900. Дешевле, чем разработчик.
Вопрос: Как управлять множеством AI-агентов?
Ответ: В этом проекте я использовал одного Claude. Но для больших систем можно запустить несколько агентов, как в эксперименте Anthropic с 16 агентами. Ключ - четкое разделение обязанностей и коммуникация через API.
Вопрос: Что делать, если AI застрял?
Ответ: Отправьте промпт с диагностикой: "Тест test_user_creation падает с ошибкой X. Проверь реализацию функции create_user/1. Возможно, проблема с валидацией." Claude обычно находит и исправляет.
Что дальше?
AI-разработка на Elixir только начинается. Следующий шаг - автономный QA-агент, как в концепции автономного QA-агента, который будет писать интеграционные тесты и проводить нагрузочное тестирование.
Но уже сейчас можно создавать production-системы силами AI. Главное - методология, контроль и понимание, что AI не замена инженеру, а инструмент. Инструмент, который пишет 1700 коммитов за 4 месяца.
