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 показує, що окремі користувачі описують і труднощі, і корисні способи роботи з локальними моделями. Разом ці матеріали дають змогу порушити питання про те, як організувати перевірку делегованого коду, але не дають відповіді щодо чистої продуктивності.
З них не можна зробити висновок, що розробники загалом уже переключилися з написання коду на нагляд, що агенти незмінно створюють додаткову роботу або що вони підвищують продуктивність галузі. Для таких висновків потрібні порівнювані вимірювання часу й якості на різних завданнях і в різних командах.
Практичне запитання для команди конкретніше: які зміни агент може підготувати самостійно, що потрібно перевірити до злиття та хто відповідає за те, щоб результат розв’язував початкове завдання? Делегування не скасовує цієї інженерної роботи — воно змінює те, де вона починається і на чому зосереджується.