Алекс Гусев, автор методологии ADSM (Agent Driven Software Management), опубликовал на Хабре эксперимент, который ставит под сомнение расхожий тезис о непригодности LLM-агентов для реальной разработки из-за недетерминированности вывода. Отправной точкой стала бытовая задача: сформировать плейлист на 4–5 часов в Spotify для семейного мероприятия. ChatGPT предложил список из 100 композиций, оставалось автоматизировать их загрузку в сервис.
Гусев работает по подходу Spec-Driven Development (SDD) — разработке, управляемой спецификацией. Суть в том, что основная часть работы делается не в редакторе кода, а в документах: архитектурных решениях, описаниях поведения, правилах платформы. Эти документы складываются в каталог контекста (./ctx/), который агент читает перед генерацией. На создание спецификаций для своего стиля разработки у автора ушли месяцы, зато они переиспользуются между проектами. Описание конкретного продукта заняло пару часов, а генерация тестов и кода каждой из версий — около 10 минут.
Первая версия приложения (v1.0.0) была создана агентом Codex на базе GPT-5.4 с уровнем reasoning high. Затем Гусев удалил каталоги ./src/ и ./test/ и попросил агента сгенерировать код заново — сначала с уровнем medium (v2.0.0), затем с low (v3.0.0). Контекст при этом не менялся. Результат: три версии с разным числом файлов и строк кода (от 3665 строк в v3 до 5469 в v1), но с одинаковым функционалом. Все три версии успешно создавали плейлисты в Spotify.
Один и тот же контекст (спецификация) трижды использовался для генерации кода с уровнями reasoning high, medium и low — код каждый раз получался разным, функционал — одинаковым.
Однако эксперимент выявил и детерминированность ошибок. Все три версии использовали устаревший Spotify API при добавлении треков в плейлист — несмотря на то что контекст был одинаковым, агент каждый раз прочитывал его с одним и тем же слепым пятном. Гусев намеренно не вносил исправление в спецификацию, чтобы не нарушить чистоту эксперимента. Версия с low reasoning дополнительно не справилась с управлением жизненным циклом веб-сервера: сервер стартовал, но приложение тут же его останавливало, не дождавшись токена OAuth от Spotify. Версии high и medium этой проблемы не имели.
Отдельного внимания заслуживает архитектурный контекст. Гусев использует собственную платформу TeqFW с поздним связыванием зависимостей через конструктор — это означает, что в файлах ./src/ нет ни одного статического импорта. Такой подход нетипичен для JavaScript-экосистемы, и агенты плохо с ним справляются без явных инструкций. Для верификации соответствия кода требованиям платформы используется специальный инструмент teq-esm-validator, встроенный в рабочий процесс агента. Это пример так называемых «скиллов» — дополнительных инструментов, которые агент вызывает в процессе работы.
Эксперимент косвенно отвечает на один из частых аргументов против использования LLM в разработке: мол, нельзя получить воспроизводимый результат. Гусев разграничивает два понятия — детерминированность кода и детерминированность функционала. Код трёх версий не идентичен, но все три решают одну задачу. По аналогии с живописью: десять реализаций одного технического задания разными программистами дадут десять разных кодовых баз с одним и тем же поведением. Вопрос не в том, совпадут ли строки кода, а в том, работает ли результат.
