Як зменшити оверінжиніринг ШІ-асистента під час роботи з кодом
ИИ-ассистенты для кодапромпт-инжинирингуправление контекстом
Коротка роль, чистий контекст і своєчасне скидання
Я б не лікував оверінжиніринг черговим величезним промптом, а застосував би три прості обмежувачі: вузьку роль, невеликий активний контекст і скидання зіпсованої сесії. Первинним джерелом тут є не анонс компанії та не картка моделі, а надане листування розробників. Дати в ньому немає, тому це практичний розбір спостережень, а не свіжа новина про реліз.
Перший прийом звучить майже надто просто: призначити асистенту роль суворого мінімаліста. В обговоренні використали формулювання, де мету прямо обмежено мінімальною кількістю змінених файлів і рядків. Це корисніше за розмите прохання не ускладнювати: модель отримує перевірюваний критерій для оцінки запропонованого патчу. Одне завдання, найпростіше коректне рішення й жодних супутніх перебудов без запиту.
Другий прийом стосується довгих сесій. Один з учасників зауважує, що дивна поведінка зазвичай починається після накопичення великого контексту, навіть якщо правила записані в промпті та AGENTS.md. Його робоча схема: запустити сесію на невеликому типовому завданні, переконатися, що обрано правильний стиль, а потім використовувати вдалий стан для схожих подальших завдань і форків.
Третій прийом жорсткіший, зате зрозуміліший: якщо з'являються неадекватні правки, стерти зміни й почати завдання заново. До нової сесії переносяться лише роль, саме завдання та ключові правила. Спроба словами змусити модель забути минуле може бути частиною такого перезапуску, але з інженерного погляду надійніше не тягнути за нею стару історію. Інакше шум залишається шумом, лише з новою інструкцією зверху.
Що це змінює у щоденній роботі з кодом
Головний висновок такий: надійність визначається не лише вибором моделі, а й життєвим циклом сесії. Короткий промпт задає межі, малий контекст зменшує кількість випадкових припущень, а скидання не дає хибному напряму закріпитися в наступних відповідях.
Під час очищення коду це особливо помітно. Мета зазвичай локальна, тому несподівана архітектурна перебудова робить рев'ю дорожчим і маскує вихідне завдання. Я б насамперед перевіряв розмір diff, кількість зачеплених файлів і наявність змін, яких запит узагалі не вимагав. Якщо межі знову порушено, продовження діалогу часто менш корисне, ніж чистий старт.
Водночас роль мінімаліста не дає гарантії: у тому самому листуванні є скарга, що асистент ігнорує і промпт, і AGENTS.md. Отже, промпт лишається м'яким обмеженням, а відкат, форк і нова сесія стають частиною контролю якості. Надійність починається не з ідеального формулювання, а з готовності відкинути зіпсований контекст.