2 хв читання

Як зменшити оверінжиніринг ШІ-асистента під час роботи з кодом

ИИ-ассистенты для кодапромпт-инжинирингуправление контекстом

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

Коротка роль, чистий контекст і своєчасне скидання

Я б не лікував оверінжиніринг черговим величезним промптом, а застосував би три прості обмежувачі: вузьку роль, невеликий активний контекст і скидання зіпсованої сесії. Первинним джерелом тут є не анонс компанії та не картка моделі, а надане листування розробників. Дати в ньому немає, тому це практичний розбір спостережень, а не свіжа новина про реліз.

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

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

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

Що це змінює у щоденній роботі з кодом

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

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

Водночас роль мінімаліста не дає гарантії: у тому самому листуванні є скарга, що асистент ігнорує і промпт, і AGENTS.md. Отже, промпт лишається м'яким обмеженням, а відкат, форк і нова сесія стають частиною контролю якості. Надійність починається не з ідеального формулювання, а з готовності відкинути зіпсований контекст.

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