Кодовые агенты: что меняется в инженерной работе

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

Такой признак есть, и он один. Сравните, сколько стоит сделать задачу и сколько стоит проверить, что она сделана правильно.

Почему именно приёмка

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

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

Где ускорение реальное

Обвязка. Конфиги, скрипты сборки, миграции, тесты по существующему образцу. Проверка — запустить.

Разведка. «Найди, где обрабатывается вот это» на незнакомой кодовой базе. Здесь агент выигрывает даже когда ошибается: он приносит пять мест, из которых нужное обычно есть, а проверить каждое стоит секунды.

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

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

Где ускорение мнимое

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

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

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

Что меняется в самой работе

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

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

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

Управление контекстом. Агент хорош ровно настолько, насколько хорошо описан проект: соглашения, запреты, примеры «как надо». Файл с правилами проекта в репозитории окупается на второй неделе и продолжает окупаться.

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

Про длину контекста — не то, что обычно обсуждают

Разговор про контекст обычно сводится к его размеру: сколько токенов влезает. На практике важнее другое — что именно туда попадает и в каком порядке.

Три вещи, которые я наблюдаю стабильно.

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

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

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

Практический минимум

1. Правила проекта — в репозитории, а не в голове и не в чате.
2. Требовать план до изменений. План проверяется за минуту, код — за час, и большинство неверных решений видно уже в плане.
3. Не отдавать задачи, где нет теста и нет способа быстро увидеть ошибку. Сначала сделать способ, потом отдавать.
4. Ограничивать размер изменения. Диффы, которые невозможно прочитать целиком, не проверяются — они одобряются.

Чего я не делаю

Не прошу агента «отрефакторить» без указания, что именно не нравится. Формулировка без критерия даёт изменение без критерия, и проверять его приходится целиком.

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

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

Что осталось непонятным

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

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