Что именно сработало в этом трюке
Я зацепился за очень приземлённую идею: перед каждой строкой кода добавлять короткий префикс, что-то вроде номера и мини-хеша. Не абстрактный prompt engineering, а почти канцелярская нумерация файла:
1:a3| function hello() {
2:f1| return "world";
3:0e| }
Смысл у этого простой: модель перестаёт гадать, где именно находится нужная строка. Вместо размытого «измени return в функции выше» она получает якоря, за которые можно цепляться при анализе и при выдаче патча.
Первоисточник тут не paper и не документация вендора, а свежий пользовательский эксперимент в 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 до полноценной автоматизации с помощью ИИ — напишите мне, и мы вместе прикинем, как это приземлить в ваш продукт без лишней магии.