Как продолжить получать удовольствие от программирования в эпоху LLM

Души в Великой Машине

Существует один замечательный фантастический роман с таким названием, который захватывал в юности. С одной стороны, он описывает нечто противоположное нашему времени: большой компьютер, где отдельные компоненты — люди, работающие вместе как единое вычислительное устройство. С другой, LLM сами бегут на настоящих компьютерах и выдают себя за (супер)людей. На второй взгляд история и реальность не так уж далеки: наша роль в процессе создания ПО медленно деградирует — из действующих лиц мы превращаемся в шестерёнки машины. Кошмарный сценарий — когда разработчики получают лишь техническое задание, скармливают его LLM, а потом плачут, когда заканчиваются токены, потому что какой-то технофеодальный лорд решил их выдать меньше.

Как программист Haskell, я получаю удовольствие от написания кода на Haskell. Да, мне нравится продукт, над которым мы работаем, мне нравится, что можно делать с моими open source библиотеками, но главное — мне нравится сам процесс выражения своих мыслей на этом языке. Предполагаю, это верно для большинства из вас. И объясняет, почему энтузиасты разных языков программирования по-разному смотрят на будущее с LLM.

Когда я генерирую код, это удовольствие оказывается под угрозой. Поэтому, может быть, не стоит это делать. Хочу продолжать писать (хотя бы наиболее интересные части) программ на Haskell и не читать кучи сгенерированного кода. Одновременно хочу извлечь пользу из токенов, которая не будет медленно сжигать мой мозг.

Хочу показать вам способ оставаться программистом, получающим удовольствие от работы, и при этом стать умеренно более продуктивным с LLM вместо того, чтобы казаться гораздо более продуктивным и потерять всю радость.

Если вы хотите полностью отказаться от LLM — отлично, вы уже знаете, что делать. Но могут быть причины, по которым этого не хочется: нужны реальные прибавки к продуктивности, или вы не хотите отставать, пока вся команда, компания, индустрия переходит на активное использование LLM.

Продолжайте писать код

Если хотите сохранять контроль над кодовой базой, нужно писать код. Если оставить всё генерировать, проект превратится в пустошь, где могут процветать только AI-агенты. Иначе в конце концов вы потеряете кодовую базу.

Другая причина — оставаться хорошим программистом. Навыки теряются без практики. Здесь риск особенно высок: очень легко сдаться и отдать работу агенту. Через несколько недель без собственного кодирования вы заметите, что вам трудно вернуться к написанию кода самому.

LLM гораздо хуже создают качественный, читаемый людьми код, чем принято считать. Они сносно пишут код, который потом обрабатывают только они сами. Но вы наверняка испытывали отчаяние, глядя на полностью сгенерированный файл с ошибкой где-то внутри, и чувствуя собственное бессилие найти её, потому что ландшафт кода совершенно чужой.

Как же получить прибавку в продуктивности, если не позволять агентам писать код? Поручить им почти всё остальное. Особенно скучную, утомительную работу. В идеале задачи, которые легко проверить и сложно испортить.

Планирование

С самых ранних дней компьютеров их использовали как бухгалтерские инструменты. Используйте LLM именно так. Конвертируйте большие письменные беседы экспертов в конкретные дела. Проведите тест, запишите результаты, попросите LLM организовать их в план исправления дефектов.

Применяйте инструменты типа todo-листов или markdown-файлов с frontmatter, чтобы отслеживать планы нормально. LLM может держать большой контекст, но если он переполнен, информация может потеряться без видимых признаков.

Но не позволяйте ей принимать критические решения. Заставляйте её вас спрашивать. Если вы не понимаете вопрос — это вина LLM, она не дала вам нужный контекст (или вы просто устали и вам нужен перерыв). Если одни и те же проблемы возникают снова и снова — отойдите от экрана, подумайте сами, вернитесь с чётким пониманием, что вы хотите.

Исследование

Когда поручаете агенту задачу на исследование, соблазнительно смотреть, как она запрашивает и "думает", запустить другого агента в другом проекте или сварить кофе. Из этих трёх кофе — лучший выбор. Но ещё лучше: исследуйте параллельно сами, используя обычную поисковую систему. Хотя бы приблизительно знайте всё, что будет знать агент.

Не просто позволяйте ей исследовать что-то, примите результаты как факты и планируйте дальше. Это приведёт к печальному техническому долгу.

Суть поручения агенту исследование — не в том, чтобы она презентовала вам все релевантные знания или приняла лучшее решение, чем вы. Суть в том, чтобы вам не пришлось тыкать ей "Let Me Google That For You". Вы должны понимать домен, который моделируете, по крайней мере так же хорошо, как агент, в идеале лучше.

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

Вы — программист

Это принципиально меняет игру.

Типичные инструменты для работы с кодом соблазняют на "сначала спланируй, потом дай писать агенту". Отказывайте. Планируйте вместе, но потом пишите вы. Попросите LLM исследовать вашу кодовую базу, выложить список дел, показать все места, которые нужно отредактировать, упомянуть потенциальные подводные камни, напомнить про релевантное прошлое исследование.

Я работаю с таким подходом — это очень весело. Получаю удовольствие от работы. Иногда даже больше, чем до LLM. Всегда есть чёткое дело, не беспокоюсь об общем плане, могу сосредоточиться, быстро справляюсь с делом, потому что оно хорошо спланировано. Как agile, но без всех раздражающих процессов.

Заставьте агентов адаптироваться к вашему способу работы, а не наоборот. Может быть, вы опытный программист, который уже знает, как работает лучше всего. Позвольте агентам делать всю побочную работу вокруг вас, которую вы любите меньше.

У этого подхода несколько преимуществ:

1. Вы продолжаете делать то, что вам нравится. Если вам нравится программирование, занимайтесь им.
2. Вы всегда знаете, в каком состоянии ваша кодовая база. Случайно встретили странный сгенерированный код из своих же сессий? Пришлось переписывать LLM-помойку? Потеряли, где вы находитесь? Этого больше не будет.
3. Плохой план обнаружите рано. Агент-кодер может бесконечно продолжать с чем-то, что вы быстро поймёте как плохую идею.
4. Вы продолжаете совершенствовать навыки. Очевидно. Останетесь хорошим программистом или будете улучшаться дальше.

Редкие случаи, когда агент-кодер полезен

В идеале для чистки кода, маленьких задач, рутины, низкорисковых рефакторингов. Оставили FIXME в коде (может быть, специально, чтобы сэкономить время и силы)? Написали 3 интересных кейса и оставили 7 похожих скучных? Хотите переорганизовать модули и бенчмарки? Нужно заменить неподдерживаемую библиотеку на лучшую? Это валидные кейсы. Проектирование чего-то сложного с нуля — вероятно, нет.

Иногда времени не хватает, но хочется закончить, и остальные дела в плане — очевидные низкорисковые задачи. Нормально сказать "я в отпуске, закончи это" своему агенту, с удачей вернётесь утром к готовой фиче. Но важно делать основную работу самому.

Есть несколько подводных камней:

• Вы написали 3 интересных кейса и говорите агенту закончить оставшиеся 7, потому что это просто адаптация ваших. Скорее всего, нужно рефакторить. Может быть, вы применяете линзу или другой оптик? Может быть, это инстанс популярного type class вроде `Traversable`? LLM прославлены тем, что не видят этого и копируют горы кода. Вы же, как человек, стремитесь к более читаемому коду.
• То же касается "упомяни потенциальные подводные камни". Да, LLM могут быть хороши в прохождении всей цепочки вызовов и убеждении, что все места, которые нужно трогать, в списке. Но вместо того, чтобы полагаться на это для исследования кода, подумайте, может быть, ваша кодовая база плохо организована, если вам нужен LLM для такого исследования.

Цикл рецензирования

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

Не принимайте и даже не читайте артефакт, созданный LLM, без цикла автоматического рецензирования. Это прямо относится к коду (когда вы ещё позволяете генерировать), но особенно к планам. Когда агент пишет код, работа не закончена, когда она отдаёт результат — работа закончена (пригодна для человеческого глаза), когда агент-рецензент не находит замечаний. То же касается планов. Утомительно искать логические дыры в плане (рефакторинг функции в деле 2, которое запланировано на дело 7), так добавьте рецензента, который это найдёт.

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

Граница

Вы полностью недоиспользуете возможности фронтир-моделей.

Какой-то программист в интернете

Да. Это логическое следствие моей позиции.

Но есть несколько причин, почему полагаться на фронтир-модели — плохая идея.

1. Экологическая стоимость. (Хотя эта статья не должна касаться этого.) Фронтир-модели используют огромное количество энергии. Хотя это в какой-то степени предположение, потому что компании LLM не очень прозрачны в работе.
2. Трудно доверять чему-то, что выдаёт себя за намного умнее вас. В конце концов, вы несёте ответственность за код, который производите. Не ваша машина. Винить кого-то в своём коде — то, что делают плохие менеджеры и коллеги со своими сотрудниками, смешно делать с машиной. Используйте LLM так, чтобы можно было нести ответственность за результаты. Это работает, только если вы — неотъемлемая часть процесса.
3. Самые продвинутые модели используют больше всего токенов, так что нет гарантии, что вы сможете доделать задачу с ними в одной сессии. Всё, что можно сделать с меньшей моделью — безопаснее.
4. Когда ваш процесс не нуждается в фронтир-моделях, есть шанс когда-нибудь заменить их на open weight или open source модели, и не зависеть от технофеодальных лордов.

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

Нет токенов?

Может быть, вы испытывали, как работа остановилась из-за нехватки токенов. Раздражает. Рабочий процесс построен на инструменте, доступ к которому вы внезапно потеряли. В экстремальном случае вы не можете продолжать вообще. Возьмите этот XKCD и представьте "нет токенов" вместо "compilation" для здорового способа обработки ситуации.

Если это случается несколько раз, вы можете почувствовать предательство. И правильно. Вас предали. Сколько токенов у вас в сессии на конкретный план — произвольное число, по воле какого-то технофеодального лорда. Это не как товар, который вы купили на справедливом рынке и потом используете предсказуемо.

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

Конечно, экономить токены нужно. Переоцените настройки агентов, использование, размер контекста, навыки и так далее, чтобы сэкономить. Но даже если вы всё это сделали и купили больший тариф, может не хватить.

И вместо того, чтобы видеть это как "ваша вина" когда вы исчерпали токены после всех попыток экономить, рассматривайте это как технический сбой, к которому нужно быть готовым. Если вы когда-нибудь работали много в поезде или самолёте, знаете, что нужно быть готовым к тому, что интернета не будет. Скачивайте большие ассеты заранее. Всегда имейте работу, которую можно делать офлайн.

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

LLM-галиматья

Текст, созданный LLM, не похож на текст человека. Особенно плохо, когда LLM на самом деле не знает, о чём говорит. Рассматривайте LLM-галиматью как потенциально вредную для вашего психического здоровья. Не потребляйте её слишком много. Общайтесь с людьми о вашем коде, особенно о больших видениях и интересных моментах. Читайте артефакты LLM только после того, как агенты-рецензенты сняли острые углы.

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

Ваши близкие люди

Программирование в основном — социальное занятие. Например, в компании или open source проекте мы отправляем друг другу pull request'ы, пишем issues и commit messages. Это форма коммуникации. Даже если вы один на проекте, ваше прошлое я пишет issues и commit messages для будущего я. Коммуникация между людьми — фундамент разработки ПО.

Убедитесь, что вы всегда встречаете людей сначала как людей. Не отправляйте полностью сгенерированный PR кому-то. Я сделал это случайно, другой конец был справедливо раздражен. Стараюсь больше не повторять эту ошибку.

Агенты охотно предложат вам написать полное тело PR в грамматически правильном языке, со всеми деталями. Это не коммуникация. Это выход инструмента. Рассматривайте такие тексты так же, как бенчмарк-цифры или дебаг-трассировки: добавляйте к своему написанному рукой телу PR, возможно, в `