Що саме спрацювало в цьому трюку
Я зачепився за дуже приземлену ідею: перед кожним рядком коду додавати короткий префікс, щось на зразок номера та міні-хешу. Не абстрактний промпт-інжиніринг, а майже канцелярська нумерація файлу:
1:a3| function hello() {
2:f1| return "world";
3:0e| }
Сенс цього простий: модель перестає вгадувати, де саме знаходиться потрібний рядок. Замість розмитого «зміни return у функції вище» вона отримує якорі, за які можна чіплятися під час аналізу та при видачі патча.
Першоджерело тут не наукова стаття і не документація вендора, а свіжий експеримент користувача в X. Станом на 22 березня 2026 року це не виглядає як усталений стандарт індустрії, а радше як вдала знахідка з польових тестів. Але саме такі речі я люблю найбільше: вони часто потім перетворюються на реальні продуктові прийоми.
Що мене тут не здивувало, то це ефект на слабких моделях. Велика модель ще може витягнути контекст за рахунок загальної сили, а маленька частіше втрачає позицію, плутає схожі блоки й починає патчити «приблизно туди». Префікси знижують цю невизначеність майже безкоштовно.
Чому моделі від цього взагалі стають точнішими
Я б пояснив це так: ми зменшуємо неоднозначність адресації. Код сповнений повторюваних конструкцій — однакові if, return, дужки, сигнатури, майже однакові методи. Для LLM це не AST і не IDE-індекс, а просто послідовність токенів, де легко промахнутися на сусідній фрагмент.
Коли я даю рядкам ідентифікатори, завдання змінюється. Моделі вже не потрібно тримати в голові лише відносне положення шматка коду. У неї з'являється зовнішній маркер, майже як координати в редакторі.
І тут є приємний побічний ефект: відповідь моделі легше валідувати програмно. Якщо агент каже «заміни 18:ab і встав після 19:4f», мій інструмент може перевірити, чи існують ці рядки, чи не застарів контекст, і чи не з'їхав патч після паралельних змін.
Де це реально знадобиться в продуктах
Якщо ви будуєте AI-архітектуру для code assistant, внутрішнього copilot або CI-агента, це прямо проситься в пайплайн. Не як магія, а як дешевий шар розмітки перед викликом моделі. Ціна майже нульова, а виграш може бути дуже практичним: менше зайвих diff, менше повторних ітерацій, менше токенів на уточнення.
Я б особливо дивився на три сценарії:
- редагування довгих файлів, де модель часто губить потрібний блок;
- робота з дешевшими або локальними моделями;
- багатокрокова ШІ-інтеграція, де патч потім застосовує інша система автоматично.
Для бізнесу це звучить прозаїчно, але корисно: можна зробити ШІ-автоматизацію дешевшою без негайного апгрейду на дорожчу модель. Іноді правильне пакування контексту дає більше, ніж перехід на наступний тариф у API-провайдера.
Ми в Nahornyi AI Lab регулярно впираємося саме в такі деталі, коли йде впровадження штучного інтелекту в редактори, сапорт-інструменти чи внутрішні інженерні панелі. У демо майже все працює. У продакшені все ламається на дрібницях на кшталт невірної адресації, конфліктних правок і крихких патчів. Тому я дивлюся на цей трюк не як на цікавий мем з X, а як на хорошу цеглину для розробки ШІ-рішень.
Де підступ і що б я перевірив сам
Я б не продавав це як доведену срібну кулю. Поки це радше сильне спостереження, а не академічно підтверджений метод. Немає нормальних публічних бенчмарків, немає порівняння на різних моделях і немає ясності, які префікси кращі — просто номери, номери з хешем чи щось інше.
Але тестується це швидко. Я б прогнав A/B-тест на своєму редакторі: однакові завдання, однакові моделі, з префіксами й без. Дивився б не тільки на «вийшло чи ні», а й на кількість повторних запитів, точність застосування diff і вартість успішної правки.
Цей розбір зробив я, Вадим Нагорний з Nahornyi AI Lab. Я не колекціоную новини про ШІ, я такі штуки вбудовую в робочі пайплайни, де важливі точність, ціна та передбачуваність. Якщо хочете обговорити ваш кейс — від code assistant до повноцінної автоматизації за допомогою ШІ — напишіть мені, і ми разом прикинемо, як це приземлити у ваш продукт без зайвої магії.