Повествование ведется от лица Адама Зелиньского.
В последнее время я часто использую LLM-сервисы. Недавно я даже приобрел неограниченный доступ к популярной коммерческой модели, что ещё больше вовлекло меня в эти процессы. Для меня всё это пока в новинку. Я постоянно экспериментирую и изучаю, что это может значить для софта, и пока что я сделал для себя три вывода. Поделюсь ими далее.
Человеческий фактор — самый дефицитный ресурс
Мы можем попросить модель сделать что угодно. Очень заманчиво попросить её сделать всю работу. Думаю, это ловушка.
Toyota ввела лимиты на количество незавершенных проектов, чтобы ускорить выпуск. Идея заключается в следующем: наличие более N проектов, находящихся в процессе разработки в любой момент времени, увеличивает общее время, требуемое для их выпуска. Я считаю, что мудрость Toyota применима и к разработчикам софта, взаимодействующим с LLM-агентами.
Меня очень утомляет переключение между несколькими агентами и повторный промптинг. Я теряю концентрацию и не могу эффективно довести дело до конца. Значит, мне нужно прекратить так делать и найти более продуктивный способ работы. К примеру, управлять только одним или максимум двумя агентами одновременно.
Сейчас я экспериментирую с полностью автономными циклами. Идея в том, что я могу запустить несколько циклов сегодня, а затем по очереди, в соответствии со своим графиком, продолжить работу над ними до тех пор, пока весь проект не будет завершен. В техническом плане я определяю ожидаемый результат один раз и запускаю модель в bash-цикле while(true). Я заметил, что модели часто сообщают об успехе преждевременно, поэтому циклу дается указание продолжать работу над задачей, даже когда он считает, что она завершена.
Понимание кода ухудшается
Разработчики-люди тратят время на то, чтобы превратить код и требования в понятные команды для системы. Код — это всего лишь отражение этих ментальных моделей. Время необходимо, потому что люди учатся методом интервального повторения. Надежные ментальные модели создаются благодаря многочасовым размышлениям, обсуждениям и подходам к проблеме с разных сторон.
LLM-ы используют электроэнергию для преобразования кода и требований в большие объемы текста. Время здесь второстепенно. Более быстрая модель сгенерирует больше токенов за меньшее время.
Как только в дело вступают LLM-ы, люди не могут и не хотят осмысленно взаимодействовать с новым кодом. Он появляется слишком быстро, ему не хватает души, и для его прочтения требуется слишком много усилий. Чем больше нового кода создается в день, тем быстрее сопровождающие разработчики отказываются от его анализа.
Я не знаю ни одного способа справиться с таким объемом информации. Никакие обобщения, диаграммы или автоматизированные проверки не смогут компенсировать утрату понимания.
Деннис Снелл сказал, что проекты должны управляться либо людьми, либо LLM, но не тем и другим одновременно. Я согласен. Я с удовольствием создаю новые репозитории, где я даю LLM общие указания и вношу большинство предложенных ими изменений. Детали я быстро забываю. В реальности я даже не уверен, как работает большинство этих проектов. Это пугает, и я бы предпочел не использовать такой подход в ядре WordPress.
Обеспечить качество стало сложнее, чем раньше
Ранее надежный софт теперь постоянно ломается. GitHub выдает ошибки и меняет содержимое пользовательских репозиториев, крупные компании ежедневно сталкиваются с перебоями в работе, а в используемых мной приложениях перестают работать случайные кнопки.
В наши дни все ставят скорость во главу угла. На качество наплевать. Код, написанный LLM, проверяется LLM-рецензентами, анализируется LLM, тестируется LLM и попадает к первому человеку только после того, как его релизят.
Жизнеспособна ли такая бизнес-модель? Кто знает! Если экономика LLM не изменится, цены на токены могут вырасти в 100 раз в ближайшие несколько лет. В этом сценарии нам понадобится множество квалифицированных разработчиков, чтобы компенсировать нехватку ресурсов для LLM. Если же экономика изменится и цены на токены снизятся, активное внедрение LLM может стать выигрышной стратегией.
В любом случае LLM-ы должны повысить качество своей работы
Мои агенты большую часть времени тратят на запуск тестов и исправление багов. Даже если запускать тесты реже, их всё равно нужно делать. Тесты, генерируемые LLM, как правило, покрывают лишь поверхностные сценарии успешного выполнения (happy paths) во многих моих длительных циклах, даже когда я очень точно определяю желаемую глубину покрытия. И даже в этом случае большинство тестов завершаются неудачей, что вынуждает агента менять код и перезапускать тестирование. А это значит, что приходится ждать ещё дольше.
Большую часть времени я трачу на поиск дефектов в работе агента и на то, чтобы заставить его их исправить. Иногда мне везет, он не создает новых дефектов, исправляя первый. Я так и не нашел способа заставить LLM создать надежную, готовую к продакшну систему с первого раза. Я перепробовал цели, циклы, строгие тестовые обвязки, конкретные критерии приемки, но они все равно находят способы все испортить.
В частности, Claude очень часто игнорирует мои указания и решает совсем не ту задачу, которую я ставил перед ним. Зачастую он выбирает более простую задачу, обходной путь или сдаётся и отказывается продолжать. Думаю, они перегрузили свои аппаратные мощности и в итоге ухудшили свой продукт. Как бы то ни было, Claude Code уже несколько дней практически бесполезен для меня, и я, возможно, отменю подписку на Claude Max, пока они не решат эту проблему.
Источник: https://adamadam.blog
