Привет, Хабр! У нас на носу 2026 год, Илон Маск обещал AGI ещё вчера (раз уж упомянул: это действительно было в одном из его интервью, где он сказал, что ожидает AGI в 25-26 годах), а AI-ассистенты для кода слышны из каждого утюга. Все мы знакомы с Cursor, многие пробовали его коммерческие (Windsurf) и открытые (Cline, Continue.dev) альтернативы. И поначалу — чистый восторг. Кажется, еще чуть-чуть, и можно будет просто говорить машине, что делать.

Но эйфория проходит, как только ты начинаешь использовать эти инструменты на реальном проекте со сложной архитектурой. Ты просишь модель добавить новую фичу, а она генерирует код, который полностью игнорирует твои паттерны, сервисный слой и общие принципы проекта. Вместо того чтобы нажимать Accept, ты часами занимаешься ручными правками, потому что результат, простите, "вырвиглазный".

Знакомая боль? Давайте разберемся, почему так происходит и как с этим бороться.

Корень проблемы (во всяком случае, моё мнение)

Казалось бы, ответ очевиден — дело в контексте. Любому разработчику, чтобы писать консистентный код, нужно сначала "загрузить в голову" кодовую базу. С моделями то же самое. Но ведь все эти модные IDE и плагины как раз и созданы, чтобы давать модели контекст всего проекта! Или нет?

Здесь и кроется дьявол. Подавляющее большинство этих инструментов работают по принципу RAG (Retrieval-Augmented Generation). Если упростить:

1. При запуске инструмент индексирует весь ваш проект, превращая код в векторы (числовые представления смысла).

2. Когда вы даете задачу, система сначала ищет в этой векторной базе самые релевантные куски кода.

3. И только эти найденные фрагменты отправляются в модель вместе с вашим запросом.

Модель сделает вашу задачу. Но не будет знать, что в файле X лежит хитрый базовый класс, который нужно было унаследовать, а в файле Y — конвенция по именованию, и вообще Z содержит код с подобной механикой, которую бы соблюсти и здесь.

Векторный поиск не найдет файлы "заодно, чтобы учесть архитектуру косвенно аналогичного кода". Он найдет только то, что напрямую связано с вашим запросом по смыслу. В итоге модель работает с очень ограниченным, "туннельным" зрением, не видя всей картины.

Почему так сделано? Все просто: экономика и технические ограничения. Контекстные окна моделей не резиновые, а стоимость запроса прямо пропорциональна количеству токенов (почти). Отправлять весь проект при каждом чихе — значит разорить пользователя. Инструменты хотят, чтобы вы ими пользовались, а не ушли, как бабушка из продуктового, со словами "Сколько?!".

Решение "в лоб" (пришёл к нему с опытом, но, не сомневаюсь, можно и лучше)

Проблему мы осознали. А что делать? Если модель не видит всей картины, нужно ей эту картину показать. Мое решение, пусть и не на 100% универсальное, но для меня оказавшееся куда более юзабельным, — это скормить модели весь проект целиком.

Да, именно так. "Грубой силой".

Инструментарий:

1. code2prompt (сайт, GitHub) — простая утилита с прекрасной документацией и, на секундочку, 6.7k звёзд на GitHub, которая собирает весь ваш код (исключая node_modules, venv, .env, etc) в единый markdown-файл с удобной структурой.

2. Google AI Studio и модель Gemini 2.5 Pro. Почему она? Огромное контекстное окно (до 1 млн токенов), которое, на мое удивление, почти не "забывается" даже на 600k токенов. И самое приятное — через веб-интерфейс это бесплатно и безлимитно.

Лайфхак: Если использовать Google-аккаунт/IP-адрес, зарегистрированный в ЕС, ваши данные не будут использоваться для обучения моделей, что немного повышает уровень приватности.

Процесс выглядит так:

1. С помощью code2prompt генерируем один большой текстовый файл с кодом проекта.

2. Открываем Google AI Studio, вставляем весь текст в начало промпта.

3. И начинаем диалог: "Это наша кодовая база. Давай спроектируем новую фичу..."

Модель, имея перед глазами абсолютно все, начинает понимать вашу архитектуру, стиль и зависимости. Результаты становятся на порядок логичнее и согласованнее. После планирования можно попросить ее написать код в формате git diff, который останется только проверить и применить.

Когда это применять?

Конечно, этот "ядерный" подход — не замена Cursor на каждый день. Это инструмент для стратегических задач, например:

• Проектирование новой крупной фичи.

• Проведение масштабного рефакторинга.

• Поиск архитектурных несостыковок.

• Онбординг в новый для вас (и для модели) проект.

Для мелких правок в стиле "поправь мне эту функцию" интегрированные плагины всё еще удобнее и быстрее, безусловно. А порой удобнее и их в этом две свои руки.

Важнейшая оговорка

Прежде чем вы побежите пробовать, давайте о главном.

Этот метод категорически не подходит для коммерческих проектов с закрытым исходным кодом, NDA или любой другой чувствительной информацией. Отправка всей кодовой базы на сторонние серверы — это колоссальный риск безопасности. Используйте его только для личных, учебных или open-source проектов, где раскрытие кода не является проблемой. Я поступаю именно так.

Кроме того, у метода есть и технический предел. Если ваша кодовая база даже после очистки весит больше контекстного окна топовых моделей, решение "в лоб" не сработает. Надеюсь, Торвальдс не встретит эту статью :)

А какой у вас опыт борьбы за качественный контекст? Сталкивались с подобными проблемами? Делитесь в комментариях своими наблюдениями, лайфхаками и решениями — думаю, эта тема актуальна для многих. Благодарю! Надеюсь узнать что-то полезное для себя ;)