Один из разработчиков поделился размышлениями о том, что на самом деле значит быть software engineer в эпоху агентных инструментов кодирования. Вокруг темы «агентной разработки» слишком много шума и слишком мало сигнала, а суть профессии, по его мнению, — это внимательный, вдумчивый выбор всех тех решений, которые приходится принимать при разработке программных систем.
За пределами хайпа и маркетингового энтузиазма «крупных провайдеров моделей» обнаружился по-настоящему интересный инструмент — сочетание агентного «харнесса» и моделей. Наблюдение за тем, как эти инструменты используют друзья-разработчики, дало немало пищи для размышлений. Как обычно, люди, добивающиеся действительно впечатляющих результатов, не кричат об этом на каждом углу и не постят в соцсетях манифесты о конце профессии. Они находят «большую палку», исследуют точки опоры и, как древний Архимед, используют рычаг, чтобы сдвинуть мир.
За последний год агентные харнессы пересекли рубеж «это вообще возможно сделать». Не хотелось бы, чтобы знания всего человечества присваивались без разрешения и оглядки на последствия, а безумцы занимались экономическим самообслуживанием, которое размазывает тонким слоем масла и без того проседающую экономику США. Экономические модели крупных языковых моделей, судя по всем доступным отчётам, нежизнеспособны, но сама возможность никуда не денется. Более того, она стремительно сжимается: модели с открытыми весами делают вполне мощные персональные компьютеры способными на то же самое. Не так эффективно, но разрыв в скорости и возможностях невелик.
«Можно ли это сделать» — лишь начало, и оно даже близко не составляет большую часть профессии software или system engineer. Это похоже на то, как в двадцать с небольшим лет пришлось учиться сварке — быстро научился создавать вещи, которые потом невозможно было ни поднять, ни вынести за дверь мастерской (спасибо ацетиленовым горелкам за спасение). Урок тогда был усвоен тот же самый, просто на другом материале: то, как именно собрана вещь — вот что определяет всё.
Если использовать агентные харнессы для разработки с некоторой долей предусмотрительности, можно получить не только «работает», но и «тестируемо» (в промптах здесь помогает установка «разрабатывай по red/green TDD»). Но выше этого уровня всё становится куда менее устойчивым. Швы — то, как устроен код, его «API», и как он стыкуется с остальным программным обеспечением — это в той же мере искусство, что и наука. Это набор субъективных оценок, зависящих от точки зрения, опыта и догадок — как о задаче, которую решаешь сейчас, так и о том, как потом долго жить с этим кодом.
Сделать программу отлаживаемой, поддерживаемой, слоистой и композируемой — это по-прежнему тот ещё фокус. Значительная часть этой работы требует обширных, вдумчивых рассуждений. И именно здесь современные LLM, даже на переднем крае возможностей флагманских моделей, дают сбой.
Полезно помнить, что LLM не «рассуждают». Они предсказывают, а сами модели по сути представляют собой сжатые записанные человеческие знания. Поэтому если человеческое рассуждение было зафиксировано в этих знаниях, модель способна воспроизвести его эхо. Для агентов, ориентированных на разработку ПО, именно такие следы рассуждений — ценнейшие данные для обучения моделей. Есть весьма доступное для понимания исследование о том, насколько плохо LLM справляются с рассуждениями — The Illusion of Thinking. Ведутся и другие исследования, включающие предсказание результатов действий, но это не то, чем располагают сегодняшние кодирующие агенты. Это совсем другая — и увлекательная — область исследований. Тем, кто хочет углубиться в тему, стоит покопаться в том, как работают «JEPA-модели», в LeWorld Model и в недавних выступлениях Яна Лекуна.
При этом работая с LLM, всё ещё есть масса способов повысить их эффективность, и, судя по всему, потенциал для улучшений едва начали осваивать. Большинство побед сегодня связаны с тем, чтобы вовремя предоставлять модели качественные, лаконичные данные и снабжать её детерминированными инструментами валидации с обратной связью на естественном языке, которую LLM может использовать для самокоррекции. По-настоящему удивляет не способность модели предсказывать, что писать, а её эффективность в вызове инструментов и следовании инструкциям.
Ещё один недостаток такого следования инструкциям — то, что Саймон Уиллисон назвал «смертельной триадой» (lethal trifecta). По сути, модели LLM не способны отличить хороший совет от плохого. Они фундаментально не могут всегда и последовательно предотвращать атаки через prompt injection. «Работа над alignment», защитные механизмы безопасности и песочницы — всё это помогает выстроить барьеры против худших сценариев, но фундаментальные пробелы остаются. И, честно говоря, нечто, неутомимо следующее инструкциям без полноценного рассуждения, — для меня материал для ночных кошмаров.
Хочется надеяться на скорые подвижки в том, как модели обучаются — чтобы после базового обучения (RLHF) появился эквивалент следов рассуждений. В идеальном будущем такие следы включали бы больше понимания того, что значит создавать ПО с чистыми интерфейсами, отлаживаемое и поддерживаемое — как ключевую часть подкреплённых оценок. Внимательный анализ, планирование и починка швов программного обеспечения (и систем) — один из критических навыков, которым нужно и можно пользоваться при разработке ПО, с агентными помощниками или без них. И на фоне волны реплик вроде «О, это же легко реализовать...» и людей, тянущихся к «клэнкерам», чтобы просто сделать дело, этот навык кажется важнее, чем когда-либо.
Сейчас отличное время следить за теми, кто пишет, говорит и делится мыслями о ремесле разработки программного обеспечения и о том, как становиться лучшими мастерами своего дела. Здесь, надеюсь, очевидно: единой панацеи не существует. Всегда есть компромиссы, и выбор того, что имеет смысл для конкретной задачи. Благодаря множеству ярких умов, делившихся своими мыслями — и сейчас, и десятилетиями раньше, — в распоряжении разработчиков богатый набор инструментов для этой работы. Суть в том, чтобы выбирать — или пересматривать в пользу лучшего варианта — правильные абстракции. В основе этого лежит управление когнитивной нагрузкой, понимание того, какие части должны быть стабильными, а где работа должна гнуться и адаптироваться (и как именно).
И да, эти чёртовы тире я расставил сам. Слишком люблю рекурсивные вставки в скобках в своих текстах, и мне нравится изредка отдыхать от запятых и скобок.