Дисклеймер

Материал описывает небольшой эксперимент с вайб‑кодингом. Это не история промышленной разработки и не попытка предложить новый стандарт. Материал скорее описывает попытку реализации идеи и размышления о результатах. 

КДПВ
КДПВ

Идея

На идею создания этого микропроекта меня подтолкнул пересмотр тарифов на использование GitHub Copilot. Раньше за месяц активного использования (не промышленной, но регулярной хобби‑разработки по вечерам) я не тратил и половины лимита премиум‑запросов. А теперь запас таких запросов стал просто таять на глазах. 

При этом современные открытые LLM довольно неплохо продвинулись и на моей не супер‑топовой видеокарте RTX 4080 стало возможно запускать модели, вполне подходящие для рутинных задач. Да, между локальными и облачными моделями всё ещё огромная пропасть. Да, с 16 Gb VRAM о комфортном вайб‑кодинге с длительным агентным циклом, огромным контекстом и десятком инструментов говорить не приходится. Но всё же, имея чёткое ТЗ, например deepseek‑r1:14b стабильно выдаёт вполне себе рабочий код. 

Ну и последним кусочком этого пазла стала одна из статей на хабре, где обсуждается, на что дорогие облачные модели тратят изрядную часть своих токенов. Если кратко — на рутину. Да, да, в том числе на ту самую рутину, которая вполне по силам локальным моделям.

И тут возникло несколько вопросов: 

  • Можно ли вообще заставить облачную модель думать только над сложными задачами (планирование, анализ, архитектура), а генерацию кода делегировать локальной?

  • Позволит ли это уменьшить расход облачных токенов?

  • Не существует ли уже готового решения, которое делает ровно то же самое?

Прототип

Как и положено любому современному проекту про LLM, сначала я спросил у нескольких LLM, как лучше реализовать мою идею. Все они с энтузиазмом начали предлагать архитектуру, обсуждать детали реализации и даже спорить о мелочах. Я решил, что интерфейс между Copilot и локальной моделью проще сделать через MCP, который обращается к ollama. В результате первый рабочий прототип появился буквально за один вечер.

После нескольких итераций настройки VS Code агент уже работал так, как задумывалось. Он продолжал анализировать задачу, строить план решения и пользоваться всеми привычными инструментами. Но когда доходило до написания кода, вместо самостоятельной генерации он вызывал мой MCP‑сервер, который перенаправлял задачу локальной модели.

Вопрос без ответа

Кажется, проект задышал — облако планирует, локальная модель послушно исполняет. Но мне не давал покоя вопрос: а экономит ли вообще такая система платные токены? С одной стороны, облачная модель действительно перестала писать код самостоятельно. С другой — она ведь сначала должна подробно сформулировать техническое задание для локальной модели. Затем получить ответ. Затем внимательно его прочитать. Возможно, исправить. Возможно, переписать. Возникает закономерный вопрос: а не получается ли так, что вместо одной генерации мы получили две? Интуитивно кажется, что предварительное планирование даже без прямой экономии токенов должно положительно влиять на качество кода. Но вот что делать с перечитыванием и переписыванием ответов — я пока не решил. Тут, конечно, можно придумать несколько вариантов. Но для аргументированного выбора нужны метрики. Количество токенов, потраченных локальной моделью, измерить довольно просто. А вот понять, сколько токенов при этом израсходовал GitHub Copilot, мне пока не удалось.

Всё было зря. Или нет?

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

Я действительно нашёл такое решение. И это была не нонейм поделка такого же хобби‑вайб‑кодера как я. Оказалось, что современные версии VS Code умеют работать с локальными моделями практически «из коробки». Более того, Ollama можно подключить непосредственно к GitHub Copilot. Я уже почти смирился с тем, что изобрёл велосипед. 

Что ж, надо осваивать инструмент, созданный профессионалами. Но попробовав разобраться, как же эту тривиальную задачу решили в Microsoft, я не нашёл как настроить роутинг между моделями. Можно выбрать Ollama вручную (кстати, почему‑то не все доступные модели можно включить в Copilot), можно оставить авто‑выбор, но как заставить рассуждать и планировать облачную модель, а черную работу свалить на локальную? Может быть, я плохо искал, или может эта фишка стала доступна пока я писал эту статью, кто знает. Но на момент написания статьи именно MCP‑сервер для меня оказался самым простым способом реализовать подобный роутинг. 

P. S. Что дальше

Идей, что можно усовершенствовать много. Но думаю, главное — получить достоверные метрики, на которых можно будет строить выводы и проверять гипотезы. Надеюсь кто‑нибудь в комментариях подскажет, как это можно сделать. А может наоборот — накидает советов в панамку.
Репозиторий проекта github.com/username-111/JunPilot