Обирайте роботу для агентів за тим, наскільки чітко її можна перевірити

Форма завдання — корисний сигнал-попередження

У статті на ESEM у жовтні 2026 року дослідники Ebtesam Al-Haque і Brittany Johnson вивчили траєкторії агентів для кодування на 51 000 завдань із вирішення програмних issues. Вони повідомляють, що структурні ознаки, особливо фрагментація патча й масштаб репозиторію, передбачають складність завдання в їхньому наборі даних. Цей висновок — не універсальне правило відбору: він вимірює залежності в колекції бенчмарків, а не гарантований успіх на приватному беклозі команди.

Окремий бенчмарк жовтня 2026 року, AgentSWE, перевіряє, як агенти будують, редагують і оптимізують інших агентів. Автори повідомляють про повторювані розриви між випадками розробки та відкладеними випадками, а також про результати, що виглядали завершеними, але не працювали під час виконання. Це спеціалізований бенчмарк, тож він не встановлює частоти збоїв для звичайної роботи над фічами. Проте він підкріплює практичну думку: охайний на вигляд патч або впевнене повідомлення про завершення — слабкий доказ, якщо жодна перевірка не перевіряє саму вимогу.

Шлях верифікації має входити в оцінку

Коли завдання перетинає модулі, залежить від неявних правил або має лише жменю простих прикладів, рев’ю ускладнюється. Агент може створити більше коду в більшій кількості файлів, як підказують цифри GitHub, а інженеру все одно доводиться відновлювати намір і проєктувати перевірки. Це проблема розподілу роботи: очевидний виграш часу на кодування може з’їсти уточнення, дизайн тестів і простежування поведінки по репозиторію.

Це підказує межу делегування. Починайте з роботи, чию очікувану поведінку можна сформулювати, перевірити й оглянути без опори на недокументоване судження: відтворюваний дефект, обмежену міграцію з перевірками сумісності або тести для узгодженої поведінки. Завдання з неоднозначними продуктовими рішеннями, широкими архітектурними компромісами чи високою ціною помилки тримайте під пильним керівництвом людей, доки команда не зможе їх специфікувати й верифікувати. Це стартові категорії, а не гарантії.

Користуйтеся перевіркою делегування, що починається з верифікації

Перш ніж доручати агентові завдання цього місяця, попросіть інженера-власника записати чотири речі: поведінку, яку треба змінити; випадки, що мають і далі працювати; ділянки репозиторію, які, імовірно, зачепить зміна; і докази, які вважатимуться «готово». Потім неформально класифікуйте завдання. Чітка вимога плюс сильні виконувані перевірки — гарний пілот. Фрагментована зміна у великій або погано зрозумілій кодовій базі потребує кроку декомпозиції людиною. Якщо ніхто не може сказати, що спростувало б результат, залишайте роботу дослідницькою й вимагайте, щоб рішення ухвалював інженер.

Для малого пілота порівняйте схожі завдання з допомогою агента й без неї. Фіксуйте час інженера на уточнення, підготовку контексту, перевірку поведінки, доопрацювання патча та його підтримку після злиття. Розбирайте збої як свідчення про визначення завдання чи межі тестів, а не лише про модель. Не вважайте завдання завершеним лише тому, що агент відкрив pull request або повідомив про успіх; вважайте його завершеним, коли проходять звичайні приймальні перевірки команди й відповідальний рев’юер погоджується, що зміна відповідає вимозі.

Джерела

• GitHub Blog — Octoverse: Commits, pushes reach new highs in 2026 as developers build with agents (28 жовтня 2026)
• Al-Haque and Johnson — What Makes Software Issue Resolution Tasks Difficult for Agents? (ESEM 2026; 18 серпня 2026)
• Wang et al. — AgentSWE: Can Coding Agents Build the Agent You Actually Want? (9 жовтня 2026)