Michael JohnsonАгенту можно поручить задачу, дождаться изменений в репозитории и получить черновик pull request на проверку. Но вместе с кодом возникает вопрос: соответствует ли результат задаче и не пропустили ли тесты важную проблему?
4 февраля 2026 года GitHub объявил публичное превью Claude и Codex как кодинг-агентов. Компания сообщила, что агентам можно назначать задачи из issues и pull requests, а затем проверять подготовленный ими черновик PR. Это подтверждает, что такой сценарий появился в интерфейсе разработки, но не доказывает ни экономии времени, ни повышения качества кода.
Вопрос поэтому не только в том, способен ли агент написать код. Важно, какую работу человеку приходится выполнять вокруг делегированной задачи: задавать ограничения, следить за ходом работы и оценивать результат.
Надзор — не только финальный просмотр
В препринте, опубликованном на arXiv 21 сентября 2026 года, исследователи предлагают рассматривать надзор за кодинг-агентом как последовательный процесс. Работа The Work Behind Delegation опирается на наблюдения и схемы рабочих процессов 19 опытных разработчиков. Авторы описывают семь этапов надзора и применяют эту рамку к публичным обсуждениям разработчиков на Reddit.
Среди описанных авторами подходов — уделять больше внимания планированию, передавать часть надзорных задач другим агентам и превращать повторяющиеся указания в материалы для повторного использования. Это аналитическая рамка, а не измерение затрат времени: работа не устанавливает, сколько разработчики тратят на контроль и быстрее ли такой процесс ручной работы. На странице arXiv препринт отмечен как находящийся на рецензировании, поэтому его выводы следует считать предварительными.
Для практики полезно различать три действия. Постановка задачи задаёт цель и ограничения. Наблюдение помогает заметить, не отклонился ли агент от намерения. Проверка позволяет оценить, можно ли принять результат с учётом требований, кода и тестов. Успех на одном этапе не гарантирует успеха на следующем: патч может выглядеть правдоподобно, но решать не ту задачу или требовать существенной переделки.
Опыт сообщества — не статистика
В обсуждении на r/LocalLLaMA один участник написал, что его опыт с локальными моделями и агентами оказался разочаровывающим: по его словам, приходилось исправлять результат и напоминать агентам об инструкциях. Другие участники того же треда описали более полезный для себя процесс: ограничивать задачи, работать поэтапно и внимательно проверять код. Это отдельные пользовательские наблюдения, а не сопоставимый тест моделей или измерение производительности команд.
Такие разные отзывы показывают, что опыт может зависеть от задачи, модели, окружения и способа работы. Но по одному обсуждению нельзя определить, какие практики эффективнее в среднем и как часто возникают проблемы. Тред посвящён локальным моделям, поэтому его наблюдения не следует автоматически переносить на все агентные инструменты.
Участие человека само по себе не означает, что делегирование бесполезно. Разработчик может разбить задачу на части, проверять изменения и уточнять требования — оставаясь ответственным за итог. Но без учёта времени на постановку задачи, исправления и ревью нельзя сказать, сократился ли общий объём работы.
Черновик PR — ещё не принятый PR
В описанном GitHub сценарии агенту можно назначить issue и получить черновик pull request. Между его созданием и принятием остаются отдельные вопросы: соответствует ли изменение требованиям, учтены ли крайние случаи, достаточно ли тестов и подходит ли решение архитектуре проекта.
Эти критерии нельзя свести к одной метрике. Число созданных изменений не равно числу пригодных, а успешное прохождение тестов не обязательно подтверждает все важные свойства патча. Даже качественный на вид результат сам по себе не показывает, сколько работы потребовалось на его подготовку и проверку.
Чтобы оценить общий эффект, нужно учитывать весь цикл: постановку задачи, ожидание результата, ревью, исправления и последующее обслуживание кода. Рассмотренные источники не дают такого общего сравнения.
Что можно заключить
Препринт предлагает рамку для разговора о надзоре, а GitHub сообщил о сценарии, в котором агенту назначают задачу и проверяют подготовленный PR. Обсуждение на Reddit показывает, что отдельные пользователи описывают как трудности, так и полезные способы работы с локальными моделями. Вместе эти материалы позволяют поставить вопрос о том, как организовать проверку делегированного кода, но не дают ответа о чистой продуктивности.
Из них нельзя заключить, что разработчики в целом уже переключились с написания кода на надзор, что агенты неизменно создают дополнительную работу или что они повышают производительность отрасли. Для таких выводов нужны сопоставимые измерения времени и качества на разных задачах и в разных командах.
Практический вопрос для команды конкретнее: какие изменения агент может подготовить самостоятельно, что нужно проверить до слияния и кто отвечает за то, чтобы результат решал исходную задачу? Делегирование не отменяет эту инженерную работу — оно меняет то, где она начинается и на чём сосредоточена.