Чому ШІ важко підхопити незавершене завдання

Хоча агенти ШІ можуть розв’язувати складні завдання, нове дослідження вказує, що їм важко продовжувати роботу, яку почав хтось інший. Це призводить до дублювання зусиль, повільнішого просування та більших витрат.

Один із найвиснажливіших, але необхідних аспектів роботи з агентами ШІ та їхніми інтерфейсами — потреба вводити ШІ в курс справи на початку майже кожного обміну повідомленнями.

Хоча популярні мовні моделі, як-от ChatGPT, надають певний доступ до постійної персоналізованої пам’яті, ця функція працює з перемінним успіхом. Зрештою зазвичай безпечніше докласти зусиль і пояснити ШІ контекст завдання*, хоча б щоб модель не вгадувала хибний контекст на основі свого сформованого під час навчання латентного простору.

Як доводиться підхоплювати чужу роботу на практиці

Звісно, ця проблема виникла раніше за ШІ. Чимало компаній уже вимагають від працівників вести документацію щодо процесів, які ті розробляють або вдосконалюють. Частково це потрібно для легшого введення нових співробітників у курс справи, але можна припустити, що й для запобігання посиленню переговорної позиції працівників.

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

Бездоганна документація, безперечно, заощадила б дні, тижні чи навіть місяці роботи, якби тільки її підготовка була економічно виправданою.

Однак коли роботу виконують агенти ШІ, можливостей розв’язати цю проблему може бути більше.

Передача завдання

Нова дослідницька робота зі США кількісно оцінює цей тягар відсутності документації та називає проблему боргом передачі.

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

Нова робота^† — спільна праця незалежних дослідників і дослідників, пов’язаних із Georgia State University, — розглядає борг передачі стосовно агентів-програмістів, які мають продовжити роботу в кодовій базі з місця, де зупинився інший сеанс, людина чи інша сутність.

Одна з цілей — з’ясувати, скільки документації потрібно для зменшення боргу передачі та які процедури й протоколи можна рекомендувати як майбутню стандартну практику, щоб мінімізувати проблему.

Бюджетні обмеження

В ідеальному випадку можна було б увімкнути докладне журналювання в режимі verbose і просто передати новому агенту, який підхоплює завдання, журнали незавершеної роботи.

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

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

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

Автори нової роботи, озаглавленої Handoff Debt: The Rediscovery Cost When Coding Agents Take Over Interrupted Tasks, розглянули всі ці сценарії й пристосували наявні моделі завдань до нових способів кількісного оцінювання боргу передачі та роботи з ним. Хоча дослідження присвячене саме агентам-програмістам, воно може вказати корисні напрями й для ширшого застосування ШІ та організації політики документування.

Автори заявляють:

«Борг передачі виникає, коли агент досягає видимого прогресу, але залишає стан, з якого наступникові важко продовжити роботу: непояснені зміни, тимчасові робочі файли, приховані припущення або відсутність свідчень перевірки.

«Метрика, що ґрунтується лише на остаточному розв’язанні завдання, не дозволяє відрізнити дороге повторне з’ясування від ефективного продовження роботи.

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

Метод

Автори визначають попередника як попереднього агента, що почав роботу або виконував її останнім, і наступника як нинішнього агента, якому доручено підхопити роботу.

Для побудови бенчмарка, який вимірює вартість передачі незавершених завдань програмної інженерії між агентами, 75 завдань із SWE-bench Verified були перетворені на 181 сценарій передачі, кожен із яких відповідає моменту, коли роботу перервали й передали наступникові. Потім три різні моделі наступників випробували у 2 172 спробах підхопити завдання.

У випробуваннях передачі використовували різні поєднання таких сімейств моделей: Qwen, Gemma та Devstral.

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

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

Для експериментів визначили три моменти початку передачі та три стани передачі :

Дані та тести

Щоб створити реалістичні сценарії передачі, автори взяли 75 завдань програмної інженерії зі SWE-bench Verified, зосередившись на проблемах, розв’язання яких зазвичай триває від 15 хвилин до 4 годин.

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

Побудова бенчмарка підхоплення завдань. Із 75 завдань SWE-bench Verified отримали 181 точку передачі, що охоплює три етапи роботи. Їх позначили за станом репозиторію на момент підхоплення й оцінили за чотирьох умов обміну інформацією, отримавши загалом 2 172 запуски, у яких наступник підхоплює завдання. Джерело

Оскільки кожне завдання могло дати кілька точок передачі, а кожну точку випробовували з чотирма формами переданої інформації, бенчмарк швидко зріс. Підсумкові дані містили 181 окреме завдання передачі та 724 оцінки підхоплення для кожної моделі наступника: загалом 2 172 запуски в трьох випробуваних системах ШІ.

Для тестів використовували середовище агентів-програмістів у стилі OpenHands, із діями в терміналі, фіксацією стану репозиторію в точках передачі, редагуванням файлів та офіційною перевіркою SWE-bench.

В основному дослідженні всі точки передачі отримували із запусків, у яких попередником був Qwen, щоб забезпечити незмінну відправну точку для порівняння різних поєднань агентів і сценаріїв.

Випробували пари Qwen → Qwen, Qwen → Gemma та Qwen → Devstral.

Необроблений журнал дав найбільше скорочення зусиль наступника: кількість подій агента зменшилася на 57–59%, тоді як підсумкові нотатки та структуровані нотатки скоротили кількість подій на 20–46%. Використання вхідних токенів також зменшилося за всіх трьох підходів, на 42–63%:

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

Щоб перевірити, чи переваги реальні, кожну передачу з повнішим контекстом зіставили з передачею тільки репозиторію, що починалася з тієї самої точки. У всіх парах моделей повніший контекст послідовно скорочував обсяг роботи наступників.

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

Щоб підтвердити, що ефект не пояснюється кількома незвичними випадками, дослідники порівняли кожну передачу з передачею тільки репозиторію, що починалася з тієї самої точки. Скорочення витрат було стійким у всіх парах моделей, що свідчить про значущу закономірність, а не кілька виняткових прикладів.

Головна думка…

Коротко кажучи^†, автори виявили, що коли один агент ШІ передає завдання іншому, навіть прості нотатки допомагають другому ефективніше продовжувати роботу.

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

Висновок

Хоча стаття призначена виключно для колег-дослідників і мало приваблює звичайного читача, нова робота торкається однієї з найцікавіших і найнагальніших проблем сучасних інтерфейсів та протоколів взаємодії людини із ШІ.

Хочеться сподіватися, що розроблені підходи й здобуті висновки згодом можна буде поширити на ширші сфери використання ШІ, а не лише на програмування агентами.

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

* Особисто я для сеансів ChatGPT, які сповільнюються через затримки та надмірний контекст, останнім часом почав експортувати, хоча й із певними труднощами, чистий PDF розмови та використовувати його як відправну точку нового сеансу, що стає «частиною 2».

^† На жаль, це не найдоступніша для розуміння стаття, яку я прочитав цього року. Тому я не можу порадити читачеві звернутися до оригінальної роботи, хоча її результати в зрозумілішому викладі залишаються цікавими.

Уперше опубліковано в середу, 3 червня 2026 року