Заметки про coding agents

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

Формально, coding agents — это подмножество ИИ агентов, но для простоты в этом тексте они будут использоваться как синонимы.

Как я использовал агентов:

• Рефакторил и немного писал код на Rust в экспериментальном движке для игровой логики.
• Использовал их для стандартных задач разработки при работе над Feeds Fun (Python).
• Как трушный хакер решил: чтобы разобраться с чем-то, надо что-нибудь для этого накодить, поэтому за месяц навайбкодил Donna — планировщик для агентов (Python).

Поскольку агенты — штука новая, то:

• Никто не знает как их использовать — мы в процессе нарабатывания опыта, собирания сценариев использования.
• Ни у кого нет разностороннего опыта их использования — либо ты выбираешь один-два подхода и работаешь свою работу ими, либо ты бесконечно экспериментируешь без нанесения пользы.

Поэтому этот пост будет в форме субъективных заметок-тезисов.

Что такое агенты

Для начала, чем агенты не являются:

• Это не «просто LLM», которая всё делает сама каким-то магическим образом.
• Это не сильный/слабый ИИ, который действует как человек.

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

Это хорошо заметно даже по фокусу функциональности агентов, changelog-ам — их разработчики решают вопросы безопасного запуска инструментов, коммуникации между ними, оркестрации, взаимодействия с пользователем, etc. Вопросам, связанным непосредственно с ИИ/LLM, уделяется не так уж много времени.

Концептуально, агент может даже не содержать ИИ-компонентов:

• Linter с автоматическими исправлениями, например isort, вполне может считаться узкоспециализированным агентом.
• GitHub Actions — это вот прямо агенты-агенты, они ещё и реактивные — реагируют на события в репозитории и автоматически что-то делают.
• С помощью Make стопудово можно создать простого агента, где обращение к LLM будет одним из этапов выполнения задачи.

Никто не называл эти штуки агентами по одной причине — «можно, а зачем?» (с).

Появление LLM вдохнуло новую жизнь в концепцию.

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

Во-вторых, LLM могут «понимать» код на приемлемом уровне, что позволяет не только связывать ими инструменты, но и вносить изменения в код, делать минимальное планирование.

Эти две вещи сделали агентную архитектуру более употребимой и актуальной.

Мой контекст использования агентов

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

Более того, сейчас, когда я встречаю что-то новое, связанное с агентами, обычно происходит следующая цепочка событий:

1. «о, интересно»;
2. читаю документацию;
3. не понимаю, как оно может улучшить мою жизнь;
4. откладываю в сторону и двигаюсь дальше.

Поэтому у меня сейчас довольно аскетичный сетап плюс небольшая табличка в Notion со списком инструментов/софта, которые я бы хотел попробовать когда-нибудь в будущем.

Мой сетап:

• Codex CLI как, собственно, агент.
• Donna — CLI для высокоуровневого планирования.
• ast-grep — CLI для навигации по коду и его трансформации.
• Специфичные для проекта большие спецификации (частично в формате Donna) вместо skills.

Это не значит, что я не смотрю на новые вещи и не пробую их — это значит, что они не прописываются в моём рабочем процессе.

Моё текущее взаимодействие с агентами происходит по двум сценариям:

1. Прошу править какую-то очень конкретную штуку с очень чётким описанием изменений.
2. Прошу сделать большое изменение по примерной спеке. После ревью:
   • либо откатываю изменение полностью, правлю спеку и прошу заново;
   • либо начинаю итеративно править код мелкими запросами;
   • либо доделываю работу руками.

Теперь, наконец, давайте перейдём к самим заметкам.

Положительное от агентной архитектуры, отрицательное — от LLM

Это, пожалуй, главный инсайт после обработки заметок:

• Штуки, которые автоматически работают над вашими задачами — хорошо.
• Штуки, которые пытаются делать то, на что (пока?) не способны — плохо.

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

Теперь, когда у нас есть LLM-клей, мы можем наслаждаться работой агентов, но только до тех пор, пока LLM используется именно как клей или как конкретный инструмент. Как только мы ставим LLM в центр, то получаем пафосные, но печальные результаты, вроде крипового игрушечного компилятора за 20000$

Все агенты ошибаются

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

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

Утверждение про ошибки также справедливо для агентов. Оно ещё и более заметно, так как LLM имеют вероятностную природу и ошибаются значительно чаще.

Суть та же, необходимые практики те же, но, возможно, явление более очевидно.

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

Проблемы с качеством из-за несовершенства LLM

Вероятностная природа LLM приводит к проблемам, которые значительно реже встречаются у людей, по крайней мере у профессионалов.

Здесь я укажу наиболее заметные из них, чтобы не повторяться в описании следующих призм и не переусложнять их.

Слабое абстрактное/критическое мышление

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

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

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

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

Мимикрия ответов под корректные решения

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

Более того, есть теория, что рассуждающие LLM не рассуждают, а генерируют цепочку рассуждений (которая выглядит достоверной) под их же выводы (которые выглядят достоверными).

Из-за этого определить ошибку агента бывает значительно сложнее, чем ошибку человека.

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

Я уже несколько раз попал на подобное поведение LLM и это очень неприятно.

Неконсистентность ответов

LLM не держат стиль кода/архитектуры, особенно неформальный.

С кодом ещё куда ни шло — стиль наследуется от контекста (когда тот есть), контролируется линтерами и настраивается автоматическим форматированием.

А вот с архитектурой сложнее — не всю архитектуру можно формализовать простым способом. Об этом я ещё скажу пару слов.

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

LLM не придерживаются уровня детализации/качества — иногда переусложняют, иногда переупрощают.

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

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

Отсутствие чувства направления

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

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

Такое отклонение легко пропустить в зародыше, а когда оно прорастёт и станет заметен нелинейный рост сложности, может быть уже поздно (дорого) что-то откатывать.

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

Ограничения контекста

Текущий «стандартный» контекст в 1 миллион токенов недостаточен, чтобы вместить в себя все знания о проекте (не говоря уже о всех знаниях разработчика), а методы формирования контекста не позволяют надёжно собирать и компоновать выборку необходимой информации. Это логичным образом приводит к искажению данных на входе LLM и, как следствие, к ошибкам в выводе.

Скорость кодинга vs скорость разработки

Важно различать эти две вещи:

• Скорость кодинга — как быстро вы создаёте рабочий код для полностью разобранной задачи.
• Скорость разработки — как быстро вы доводите фичи от идеи до релиза (до пользователей).

Многие, особенно не программисты, путают эти вещи. Частично в этом есть и наша вина, так как опытный программист часто, например, проектирует и кодит напроектированное одновременно — так значительно быстрее. Часто в это же время мы ещё GUI проектируем, тестируем, анализируем и дополняем бизнес-требования, etc.

Агенты значительно увеличивают скорость кодинга, но далеко не всегда увеличивают скорость разработки, так как большую часть разработки они взять на себя (пока что?) не могут, а если пытаются, то создают больше проблем, чем решают.

Нюанс в том, что скорость кодинга не является проблемой уже лет двадцать.

Благодаря современным IDE (даже до Copilot) задержка при трансляции модели софта из головы программиста в код минимальна.

Скорость кодинга увеличилась

В ситуациях, когда точно известно что надо написать и осталось только выстроить слова в правильном порядке, скорость кодинга увеличилась на порядок.

Как выглядят подобные ситуации:

• У вас есть новая функциональность, есть автоматические тесты старой функциональности и вам надо добавить тесты новой функциональности.
• Вы накидали черновик кода, но в нём есть ряд случайных расхождений: ошибки и/или пропуски типов, нестыковки между возвращаемыми значениями, нестыковки между кодом и тестами, etc. — и вам надо это всё исправить.
• У вас есть один падающий тест и вам надо исправить ошибку в коде, который вы плохо помните.
• Вы точно знаете (и можете описать) что конкретно надо сделать, но не хотите прокидывать изменения по всем зависимостям.

То есть агенты очень полезны, когда контекст полностью определяет, что должно быть сделано. Это немного похоже на коллапс волновой функции при измерении или, что то же самое, на процедурную генерацию через коллапс волновой функции.

Скорость разработки увеличилась в некоторых случаях

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

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

Во-вторых, текущие агенты плохи в планировании и сложном анализе. Отчасти из-за вероятностной природы LLM отчасти из-за молодости технологии. Все «эксперименты с долгосрочным планированием», которые я видел, в итоге либо проваливались (спасибо организаторам за честность), либо превращались в торжество победившего маркетинга, за которым скрывался провал.

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

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

В то же время, агенты позволяют (или смогут позволить) ускорять некоторые аспекты разработки:

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

В чём агенты хороши, так это в прототипировании:

• как в создании отдельных прототипов;
• так и в прототипировании изменений в существующем коде, что позволяет уточнять требования и итерационно доводить изменения до нужного уровня качества.

То есть разработка в целом тоже ускоряется, но пока непонятно насколько и в каких местах именно.

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

Assistant driven development vs agent driven development

Любопытно сравнить влияние на разработку умного автодополнения/inline редактирования кода (например, Copilot) и разработку через агентов.

На моём опыте:

• Copilot позволяет достичь той же скорости кодинга, что и агенты. А на малых задачах даже большей.
• Copilot не вырывает программиста из потока.

За счёт фокуса на локальности изменений Copilot часто предлагает более корректный с точки зрения контекста код.

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

Похожие отзывы я получаю и от коллег — никто из моих знакомых не перешёл на разработку только агентами.

Изменение нагрузки на разработчика

Сложно сказать стало лучше или хуже.

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

Также в работе программиста есть этап, когда ты подгружаешь в мозг информацию о задаче и её контексте (архитектуру, требования, код, доки). Это тяжёлый и долгий процесс. Именно он является основной причиной нелюбви программистов к прерыванию работы, так как его приходится проходить заново. Если работа происходит только через агентов, то этот этап значительно сокращается и упрощается. Но только в случае, если не приходится детально разбираться с правками от агентов.

Оба этих изменения довольно приятны.

С другой стороны, увеличивается поток высокоуровневой информации через человека. Больше информации в единицу времени — больше нагрузка.

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

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

Знания организации и контекст агентов

За весь период существования человечества было осуществлено бесчисленное количество попыток формализовать знания организации так, чтобы они были отделены от сотрудников. Особенно много подобных попыток было за последние лет 30, что понятным образом связано с развитием информационных технологий.

Все эти попытки закончились крахом.

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

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

Соответственно.

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

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

Следовательно:

1. Ответственность за работу остаётся на человеке.
2. Роль документации возрастает, но не любой, см. далее.

Спецификации

Становится важна документация, которая превращает задачи на разработку в задачи на кодинг, а роль LLM сводит к решению локальных вопросов. Примеры:

• стандартный способ обработки ошибок в коде;
• стандартный способ организации кода на файловой системе;
• стандартный способ оформления тестов;
• библиотека цветов, разрешённых для использования в UI с правилами их использования;
• библиотека стандартных компонентов интерфейса;
• алгоритмы разрешения стандартных ситуаций, вопросов, etc.

Создание подобных спецификаций помогает не только агентам, но и людям, так как запускает мышление письмом.

К сожалению, появляется риск превращения спецификаций в код, что создаёт лишнюю работу: сначала мы разрабатываем спецификацию-как-код, потом переносим её один в одни в код.

Отчасти поэтому программисты часто проектируют и кодят одновременно — часто разница между детальной спецификацией и кодом отсутствует.

На тему спецификаций-как-кода как раз на днях появилось интересное эссе A sufficiently detailed spec is code, вот отличная цитата из него:

Specification work is supposed to be harder than coding. Typically the reason we write specification documents before doing the work is to encourage viewing the project through a contemplative and critical lens, because once coding begins we switch gears and become driven with a bias to action.

То есть создание спецификации-как-кода может замедлять разработку.

Пример подобной спецификации есть в статье по ссылке. По сути, это может быть любая спека фичи, проработанная до мельчайших деталей (модель данных, алгоритмы).

Workflows и linters как идеальные спецификации

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

• «Утилита» для исправления имён переменных, согласно стандартам.
• «Утилита» для исправления иерархии ошибок и кода их обработки.
• «Утилита» для написания пропущенных тестов.

То есть агент превращается в машину состояний, и это сейчас стандартный способ описания специализированных агентов. Об этом же и мой пет-проект Donna.

Этот подход может привести к появлению отдельного реактивного слоя, схожего с CI, но находящегося ближе к разработчику.

Изменения в мышлении

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

Во-первых, первым делом надо думать «как это сделать агентом», а не сразу делать руками.

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

В частности, LLM очень чувствительны к точности формулировок — там, где человек «сам догадается», агент гарантированно поймёт задачу неправильно.

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

Это радикально меняет динамику разработки, изменяет что вы можете сделать руками, а что не можете.

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

Кроме того, вы также не учитесь! До агентов, разработчик был вынужден изучать каждую новую штуку, которую он использовал — это органичным образом расширяло его знания и понимание области. Если написание кода полностью переходит к агентам, этот важный аспект развития программиста пропадает.

Третий пункт я считаю источником большого риска и проблем, которые пока непонятно, как решать.

Возможно ли надёжно делегировать агентам долгосрочное управление кодом — это открытый вопрос.

Изменения в стратегии разработки

Агенты меняют скорость, но не качество

Кто делал плохую работу, тот сейчас делает её в разы быстрее (и больше), а может и в худшем качестве.

Соответственно, значительно возрастает роль процессов принятия решений и процессов контроля качества.

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

Возрастает роль автоматизации

Или нет, зависит от того как конкретная команда на эту штуку смотрела.

В моей картине мира автоматизация — это основной способ контроля качества, поэтому у меня мало что меняется. Но для многих это всё ещё скорее способ ускорения доставки фич в прод (CI/CD) и только вспомогательный способ контроля качества. В последнем случае переход на разработку через агентов потребует пересмотреть взгляды на мир.

«Достаточное качество» как новый стандарт

Стремление добиваться максимально возможного качества (в ущерб экономической целесообразности) — это довольно распространённая проблема в разработке. Она особенно заметна у программистов, так как формальная природа и математичность кода провоцируют стремление к его (субъективной) идеальности.

При разработке через агентов добиваться идеального кода скорее невозможно из-за вероятностной природы LLM. По крайней мере на текущем этапе развития технологии. Поэтому «достаточное качество» становится единственным возможным уровнем качества, к которому можно стремиться.

Это наверняка будет приносить много боли разработчикам, по крайней мере поначалу. Но, в целом, скорее благо.

Инкрементальная разработка становится более важной практикой

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

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

Поскольку у агентов сложности с консистентным внесением крупных изменений, это естественным образом вынуждает производить их поэтапно — то есть разрабатывать инкрементально.

Причина внедрения практики выглядит не очень позитивно, но сама практика однозначно пойдёт на пользу.

Формальная верификация становится проще и полезнее

До появления агентов было, ммм… два множества инструментов для формальной верификации:

• простые инструменты, которые реально использовались: контроль типов, отслеживание типичных ошибок с помощью линтеров, etc.
• сложные инструменты, которые практически нереально использовать из-за сложности и требуемого времени.

К последним можно отнести, например, контроль выполнимости кода, формальные спецификации, контроль связанности модулей, etc.

Агенты позволяют убрать большую часть проблем от использования сложных инструментов, так как забирают на себя большую часть работы по интерпретации ошибок и их исправлению.

Одновременно эти инструменты особенно нужны для агентов, чтобы ограничивать их полёт фантазии. Например, контроль доменных зон через контроль импортов (какие модули может использовать каждая часть проекта) должен значительно сокращать случаи помещения кода не в то место.

Плюс, благодаря современным инструментам интроспекции разработчики должны быть в состоянии писать собственные тесты на специфические для их проекта правила и стандарты.

Поэтому я ожидаю рост популярности сложных инструментов формальной верификации кода.

Harness Engineer — новая роль

В последние месяцы родился такой термин, как harness — программная обвязка вокруг агентов, которая обеспечивает их нужными инструментами, данными, контекстом и, в том числе, проверяет их работу с помощью линтеров и прочих формальных проверок.

Агенты без хорошего Harness — это как проект без CI/CD — ничего хорошего из этого не выйдет.

Учитывая возрастающую роль автоматизации и формальных проверок, я рискну предположить, что появится как минимум отдельная роль — Harness Engineer, который будет отвечать за разработку и поддержку harness для агентов.

Соответственно, на уровне компаний это должно породить дисциплину HarnessOps по аналогии с DevOps.

Разделение полномочий между агентами и людьми

Появляется деление задач на те, которые «правильно» делать агентами, и те, которые «правильно» делать людьми.

Само собой, никто сейчас не знает где эта граница проходит и, учитывая природу людей, ещё долго будут споры и холивары на эту тему.

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

Это надо просто принять и жить с этим. В идеале — обсудить в команде и выработать пару эвристик, чтобы избежать конфликтов.

Ускорение обмена информацией

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

Ещё больше возрастает (куда уж больше-то) важность самостоятельности сотрудников, владения проектом, здоровой коммуникации.

Никакие утренние стендапы догнать мир не помогут. Только асинхронная проактивная коммуникация — каждый должен пушить свой прогресс в какой-нибудь Slack и делать это так, чтобы поток событий не превращался в спам. Иначе будут разрабатываться N (по количеству разработчиков) параллельных слабо связанных проектов вместо одного.

Парное документирование

Поскольку кодинг уходит на сторону агентов, от нас уходит и (довольно эффективная) практика парного программирования.

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

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

Время глобальных рефакторингов

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

Они их делают не идеально, но:

• Ревью поверх правок значительно быстрее, удобнее и менее напряжно, чем вдумчивое изменение кода.
• Правильные спеки могут делать некоторые рефакторинги тривиальными.

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

Потеря контроля

Скорее всего это временная проблема и она решится по мере развития интерфейсов.

Однако сейчас довольно сложно встроиться в процесс работы агента, а значит сложно его направлять и замечать проблемы на ранних этапах работы.

Это особенно заметно, если сравнивать с собственным процессом мышления, когда вы в любой момент можете остановиться и осмотреться.

Какие задачи лучше всего решают агенты

Рутинные/монотонные задачи с чётко определёнными границами, критериями успеха и качества:

• Анализ кода.
• Массовый рефакторинг «под спеку» или «под linter».
• Завершение изменений начатых человеком «чтобы код компилировался и тесты проходили».
• Выполнение чётких инструкций по внесению изменений: пойди туда, сделай это, потом это, потом туда, etc.
• Создание прототипов, которые будут выкинуты.
• Экспериментальное прототипирование изменений, чтобы посмотреть что и как будет затронуто.
• Быстрое внесение крупных изменений без чёткой инструкции, чтобы потом их итерационно доводить до ума.
• Редактирование кода, который хорошо покрыт тестами, комментариями и спеками.
• Приведение кода к единому стилю на основе чётких спецификаций.

Во всех остальных случаях я бы сказал, что агенты демонстрируют не очень хорошие результаты.

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

Инструментарий

Что я могу посоветовать использовать с агентами?

Немного, главный совет — экспериментируйте. Но вот пара идей.

Конкретного базового агента порекомендовать не могу — пробуйте разные, выбирайте тот, который вам больше нравится. Я использую Codex CLI, но сугубо потому, что нахожусь в инфраструктуре OpenAI и люблю консоль.

Rust — главный язык программирования для агентов из-за своей параноидальной безопасности и строгой типизации — выполнять эти требования — боль для людей, но не такая сложная задача для агентов. Rust заставляет использовать правильные паттерны, которые сами по себе помогают создавать хороший софт.

Если очень хочется специализированных инструментов, то можно посмотреть в сторону OpenSpec и Ralph, но скорее как концепций, чем конкретного софта — у них много аналогов.

Всё-таки порекомендую посмотреть в сторону базового агента pi.dev — он спроектирован с фокусом на расширяемости сторонними инструментами, что в духе следующего раздела этого поста. Но руками я его пока не успел потрогать.

Будущее инструментария

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

Сейчас мы находимся в фазе сборки комбайнов. Скоро мы начнём разбирать их на составляющие, которые можно будет комбинировать, следуя Unix way — тогда можно будет обсуждать персональные сборки агентов.

Косвенно это мнение подтверждает обилие нишевых agent-related стандартов, которые постепенно появляются в явном и неявном виде.

Навскидку, декомпозиция может быть следующей:

• Оркестратор задач.
• Интерфейс для взаимодействия с пользователем.
• Песочница для выполнения деструктивных операций.
• Инструмент для взаимодействия с LLM.
• Инструмент для навигации по коду и прочим артефактам.
• База данных/знаний для памяти (возможно).

Хайп, хайп, хайп

Минутка ворчания.

Этот GitHub сломался — несите новый

Такого массового нерелевантного роста количества звёзд у проектов не было никогда. Люди вообще не проверяют кого и за что они отмечают — ставят звёзды сугубо по ключевым словам и красивым картинкам.

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

Сейчас разница между 1000, 10000 и 100000 звёзд говорит только о хайпе и маркетинговой стратегии проекта.

Как блокчейн, только громче

Если присмотреться, то у блокчейна и агентов есть общие черты:

• обе технологии хорошо выглядят в полностью цифровом пространстве, но испытывают проблемы при маппинге на реальный мир;
• обе технологии технологически сложны;
• хайп вокруг обеих технологий сильно затрудняет их объективную оценку, понимание их реальных возможностей и ограничений.

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