У епоху AI-кодування хороші звички програмування залишаються важливими

Нещодавно я займався створенням бенчмарку для агентів і виявив, що не можна просто з точки зору розробника оцінювати складність програмного завдання для AI.
Наприклад, завдання рефакторингу: розбити великий файл у кілька тисяч рядків на понад десять малих модулів за функціоналом.
Це завдання для розробника насправді не є складним, основна робота — переміщення коду, організація імпортів, перевірка збірки, і новачки з цим справляються.
Тому я подумав використати просте завдання для бенчмарку, але результат виявився несподіваним.
Claude Code вважає це завдання досить великим, спробував розділити частину, зробив PR і додав Future work для поетапного виконання.
Мій власний агент — “жорсткий” підхід, я просувався у напрямку повного розбиття, але ціна була очевидною: споживання токенів у десятки разів більше, ніж у Claude, і більша частина часу йшла на повторне читання файлів, виправлення помилок компіляції, знову читання файлів і повторне виправлення.
Це змусило мене усвідомити, що завдання, яке здається простим людині, не обов’язково є простим для агента.
Для людини багато рефакторингів — просто “перемістити цей фрагмент”. Але для агента потрібно спочатку по частинах читати великий файл, запам’ятати, які функції і тести пов’язані, потім генерувати купу змін між файлами, і в кінці — по кроках виправляти помилки компіляції.
Здається механічною роботою, але насправді це завдання з високим споживанням токенів і високими витратами на управління станом.
Недавно хтось казав, що в епоху AI-кодування принципи розбиття на модулі вже не так важливі, бо люди все одно не дивляться на код. Тепер я з цим не зовсім погоджуюся.
Чіткі межі модулів, відповідний розмір файлів, прості залежності — це не лише зручність для людини, а й допомога агенту зменшити складність завдання.
З іншого боку, зараз інструменти для читання і редагування файлів у агентів для такого рефакторингу не дуже зручні.
Редагування файлів агентом здебільшого зводиться до текстових замін. Наприклад, Claude Code зазвичай використовує схему old_string / new_string: спочатку дає старий текст, потім замінює його на новий.
Codex часто застосовує apply_patch: генерує патч, схожий на git diff, що замінює старий вміст на новий. Обидва підходи підходять для невеликих змін, але якщо потрібно видалити великий блок коду або перемістити функції в інший файл, модель зазвичай спочатку читає оригінальний вміст у контекст, а потім генерує великий блок замін або diff.
Тому я дав агенту підказку: щоб він спочатку за допомогою скриптів, sed, perl та подібних інструментів розбив великий файл на частини, безпосередньо видалив старий вміст і записав новий у файл, а потім поетапно виправляв. Це значно підвищило його ефективність.
За замовчуванням агент цього не робить, оскільки системні підказки суворо вимагають використовувати вбудовані інструменти для редагування файлів, а не командний рядок.
Ще один крок уперед — агенту можливо потрібні більш просунуті інструменти редагування. Не просто інтерфейс “заміни текст”, а створення структури коду за допомогою парсерів, LSP або компілятора, щоб агент міг робити рефакторинг, як IDE: переміщати функції, видаляти блоки impl, організовувати імпорти.
Не знаю, чи є серед читачів ті, хто вже експериментував у цьому напрямку.
Загалом, навіть у епоху AI-кодування хороші звички програмування мають цінність.
Раннє впровадження через інженерію тестових середовищ дозволяє зробити ці звички стандартною поведінкою агента, що значно зменшує витрати на подальший рефакторинг.