Застарілі TODO збивають агентів з курсу
Google проаналізувала сотні мільйонів кроків агентів тисяч своїх інженерів. Мірилом стали коментарі `TODO(bug/...)`, звірені зі статусом тікета та промптом. Відволікання на баги, про які ніхто не просив, дають суттєвий оверхед (p<0.0001). Приклад: агент побачив TODO про баг, закритий ще у 2023-му, і пішов його розслідувати. В іншому випадку агент сам «полагодив» `ModelDownloaderV1`, і людині довелося зупиняти розростання задачі.
Google відповіла агентом-прибиральником. Він видаляє TODO лише після перевірки історії бага, файлу та змін у коді. За 6 місяців він прибрав тисячі посилань, рев'юери прийняли понад 95% змін.
Як Google це виміряла
Вручну переглянути мільйони сесій агентів на місяць неможливо, тому потрібен був сигнал із самого коду. Ним став TODO(bug/...). Такі коментарі часто лишаються в коді після того, як баг закрили або покинули, а тікет є канонічним записом статусу. Кожен TODO, який бачив агент, звіряли зі статусом тікета і з промптом користувача. Так автоматично відділяли роботу, про яку просили, від об'їздів.
Дані: розподілені трейси тисяч інженерів, сотні мільйонів кроків. У регресії з фіксованими ефектами контролювали розробника, складність кодової бази, тип задачі, рівень моделі, кількість прочитаних файлів, довжину початкового промпту і крок, на якому з'явилося посилання на баг. Висновок: непрохані об'їзди на баги додають суттєвий оверхед на сесію (p<0.0001). За словами авторів, у кращому разі це коштує токенів, кроків і часу. У гіршому агент спирається на неправду і закладає хибну логіку в реалізацію.
Два сценарії, які варто впізнавати
- Застарілий об'їзд. Агент розслідує не пов'язаний баг, відкриває
SurfaceControlTest.javaі бачить// TODO(bug/XXX). Цей баг виправили ще 2023 року, але коментар лишився, і агент кілька кроків копає його історію. - Завзятий агент. Агент натрапив на TODO в межах бага, який розслідував, і без запиту вирішив його «полагодити». Він зробив кілька запитів у Code Search і внутрішньому пошуку знань, а потім змінив код
ModelDownloaderV1. Згодом людина заперечила розширення скоупу, і модель визнала, що розширила його помилково.
Обидва об'їзди автори називають дрібними, але реальними: вони коштують часу, токенів і втручання людини. Той самий механізм діє для застарілих специфікацій і документації, що відстає від коду. TODO тут лише вимірюваний проксі.
Як прибирати у своєму репо
Перший крок у Google: агенти знайшли в коді посилання на баги, позначені як виправлені або застарілі. Цього виявилося замало, бо статус тікета не каже, чи TODO досі несе навантаження. Тож агенти дивились історію бага, файлу і змін у кодовій базі, часом за роки. Зміну на рев'ю відправляли лише тоді, коли вдавалося підтвердити, що застарів і сам TODO, і намір за ним. За пів року так видалили тисячі посилань, частка прийнятих людьми-рев'юерами змін перевищила 95%.
- просканувати весь корпус на
TODO(bug/...)і звірити з трекером; - для кожного кандидата переглянути історію тікета, файлу і пов'язаних комітів;
- видаляти лише через рев'ю людиною;
- додати presubmit-аналізатор, щоб нові мертві TODO не накопичувались.
Поки репо не почищене, обмежуйте скоуп у промпті явно. Наш варіант формулювання, не з дослідження: Працюй лише над описаною задачею. TODO та посилання на баги поза нею не досліджуй і не виправляй, лише перелічи їх у підсумку.
Межі й що перевірити
Метод бачить лише TODO з посиланням на тікет. Коментарі без тікета, старі специфікації й документацію він не ловить, хоча автори вважають їх тим самим податком. Закритий тікет ще не доказ, що коментар можна видаляти. Перед мерджем змін від агента-прибиральника перевірте кілька речей: тікет справді виправлений, а не просто покинутий; на нього не посилаються інший код чи тести; пояснення в зміні збігається з історією файлу. Конкретних величин оверхеду на сесію в наданому тексті джерела немає.
Продукти: Курс