1823 коммита с LLM за 4 месяца: опыт разработки приложения

Четыре месяца, 1823 коммита и около 200 000 строк кода — так выглядит мобильное приложение для изучения английского, почти целиком написанное через LLM-агента. Автор проекта формулировал задачи, ревьюил и принимал архитектурные решения, но код руками набирал редко. Это не история о том, как здорово,

Первый подводный камень — энтропия. Локально агент пишет аккуратный код, но через двести коммитов в проекте три способа поднять модалку и четыре файла с константами анимаций. Второй — физическая реальность и невысказанные инварианты: 109 коммитов ушло на одно движение шторки над клавиатурой, а на то, чтобы «забудь» в памяти питомца работало честно, понадобилась отдельная спецификация.

Как был организован процесс разработки

Автор использовал LLM-агента как основного исполнителя: он ставил задачи, описывая их на естественном языке, а агент генерировал код. При этом все архитектурные решения оставались за человеком. Такой подход позволил за четыре месяца написать 200 000 строк кода — объём, который в одиночку традиционными методами занял бы значительно больше времени.

Ключевым инструментом стала «конституция проекта» в файле CLAUDE.md. В этом документе были зафиксированы правила, которым агент должен следовать при генерации кода: стандарты оформления, паттерны, запреты. Это помогло снизить хаос, но не устранило его полностью. Через несколько сотен коммитов энтропия взяла своё: появились дублирующиеся решения и расхождения в стилях.

Предыстория и контекст

Использование LLM в разработке — уже не эксперимент, а рабочий инструмент. По данным GitHub, в 2024 году значительная часть нового кода в репозиториях создаётся с помощью ИИ-ассистентов. Однако большинство примеров — это небольшие скрипты или отдельные функции. Проект, целиком написанный через LLM, — всё ещё редкость, особенно когда речь идёт о мобильном приложении с нетривиальной логикой.

Автор пошёл дальше типового использования: он не просто просил агента написать функцию, а делегировал целые модули. Это потребовало выстроить процессы, которые обычно не нужны при традиционной разработке: детальные спецификации, жёсткие правила в CLAUDE.md и храповики, не позволяющие обойти контроль.

Опыт автора вписывается в более широкий тренд: компании всё чаще внедряют ИИ в цикл разработки, но сталкиваются с проблемами качества и поддерживаемости кода. Исследование GitClear за 2024 год показало, что рост использования ИИ коррелирует с увеличением количества дублированного кода и снижением его читаемости. Проект автора — яркая иллюстрация этого феномена.

Почему энтропия кода стала главной проблемой?

Энтропия — это постепенная деградация структуры кода. Локально агент писал аккуратные решения, но без глобального видения он не замечал, что уже есть три способа поднять модалку или четыре файла с константами анимаций. Каждый новый коммит добавлял ещё один вариант, и через двести коммитов проект превратился в «зоопарк» решений.

Чтобы бороться с этим, автор ввёл четыре слоя храповиков. Во-первых, конституция в CLAUDE.md, которая задавала общие правила. Во-вторых, обёртка над git, которая не давала обойти хуки — например, нельзя было закоммитить без прогона тестов. В-третьих, автоматические проверки на дублирование и стиль. В-четвёртых, регулярный рефакторинг, который автор выполнял вручную или с помощью дополнительных задач для агента.

Технические подробности: анимации и память на pgvector

Отдельная боль — анимации. 109 коммитов ушло на одно движение шторки над клавиатурой. Почему так много? Потому что физическая реальность Android-устройств полна невысказанных инвариантов: разная высота клавиатуры, разная частота кадров, особенности рендеринга на конкретных моделях. Агент не знал об этих нюансах и генерировал код, который работал на эмуляторе, но рвался на реальном устройстве.

Автор выделяет пять причин, почему анимация рвалась на реальном Android: игнорирование системных окон, неправильная обработка касаний, отсутствие синхронизации с vsync, гонки при изменении состояния и неучёт плотности пикселей. Каждая из этих причин потребовала отдельной итерации с агентом и уточнения в спецификации.

Память питомца — ещё один вызов. Чтобы «забудь» работало честно, автору пришлось написать отдельную спецификацию. В итоге они использовали слоистую память на pgvector с локальными эмбеддингами. Это позволило хранить и извлекать информацию о взаимодействиях пользователя, но потребовало тщательной настройки.

Кого затронет этот опыт и как

Для разработчиков этот опыт — предупреждение и руководство. Если вы планируете использовать LLM для написания кода, будьте готовы к энтропии. Вам придётся вкладываться в документацию, автоматические проверки и регулярный рефакторинг. Без этого проект быстро станет неуправляемым.

Для бизнеса вывод очевиден: LLM может ускорить разработку, но не заменяет архитектора. Кто-то должен держать в голове общую картину и принимать решения. В противном случае вы получите код, который работает, но который невозможно поддерживать.

В России и СНГ этот опыт особенно актуален: многие компании ищут способы сократить издержки на разработку, и LLM-агенты выглядят привлекательно. Однако, как показывает практика, экономия на архитектуре оборачивается потерями на поддержке.

Что будет дальше

Автор продолжает развивать проект и, вероятно, опубликует ещё материалы с деталями. Можно ожидать, что он поделится спецификациями для агента и более подробным разбором храповиков. Индустрия в целом движется к более зрелому использованию LLM: появляются инструменты для автоматического ревью и контроля качества.

В ближайшие годы мы увидим, как компании адаптируют процессы под ИИ-разработку. Возможно, появятся стандарты для «конституций» проектов и обязательные проверки на энтропию. Пока же опыт автора — один из немногих подробных кейсов, на который можно опираться.

Итог

Опыт с 1823 коммитами показывает: LLM-агенты способны писать огромные объёмы кода, но без жёсткого контроля и человеческого участия проект разваливается. Энтропия и физическая реальность — два врага, с которыми придётся столкнуться каждому, кто решит пойти этим путём. Если вы готовы вкладываться в процессы — результат может впечатлить. Если нет — лучше оставаться на традиционных методах.