Я год экспериментировал с on-premise Copilot — прямо над нашими разработчиками, — чтобы проверить: а правда ли эта штука разгоняет разработку на десятки процентов? Делюсь реальными метриками скорости и точности, разбираю, как оно работает на примере нашей инсталляции, и показываю результаты. По пути расскажу про все подводные камни: где ИИ стал турбоускорителем, а где подставил подножку и превратился в скрытую ловушку.
Привет, Хабр! На связи Игорь Анохин, руководитель платформенной разработки К2 Облака. Эта статья на основе моего доклада с PyCon о том, как мы уже год живём с Copilot в большой enterprise-компании.
Дисклеймер: я — разработчик веб-сервисов в облаке. Эта статья — для таких же разработчиков, которые слабо знакомы с Copilot, и хотят разобраться в основах. Покажу, как всё работает под капотом на уровне кода: немного про Python, много архитектуры, наш опыт и проблемы.
Как пришла идея использовать Copilot
Мы в K2 Cloud с 2009 года разрабатываем собственное облако — и это нам здорово помогло с Copilot, который требует кучу ресурсов на большие языковые модели. Когда под рукой целое облако, можно просто перекинуть несколько видеокарт из прода в свой маленький проект.
И вот в 2024 году мы увидели заголовки вроде «Visma пишет новый код на 50% быстрее с GitHub Copilot и Azure DevOps». Мы сложили два плюс два и получили: 50% времени на код + 50% ускорения = примерно 25% роста общей производительности разработчиков. У нас в K2 Tech (K2 Cloud — его часть) больше 600 разработчиков. Если хотя бы половина их рабочего времени уходит на код, то это около 100 часов в месяц.
С этими расчётами мы пошли к менеджерам. Конечно же, нам не смогли отказать, ведь цена вопроса — 10 баксов в месяц. Какой ещё способ за такие деньги заставит разработчиков писать на 25% эффективнее? Менеджеры были в восторге — и это наш первый ключевой инсайт.
Инсайт №1. Внедрить Copilot хотят менеджеры, а не разработчики
Менеджеры мыслят категориями эффективности и бюджета, поэтому не устояли перед обещанием +25% к производительности всего за $10 в месяц. Разработчики оказались консервативнее: «Copilot нам не нужен — он тупой и только замедлит нас».
Open Source решения против SaaS, или история про инфобез
Мы стали рассматривать разные SaaS-инструменты после того, как менеджеры одобрили нашу идею. Copilot быстро подхватывает топовые фичи конкурентов, так что показался надёжным выбором. Мы, конечно, присмотрелись к Cursor — среде разработки, которая была пионером в агентах. Помимо этого, среди SaaS-решений наше внимание привлёк JetBrains AI: удобный и свежий инструмент. Если SaaS — ваш вариант, то присмотритесь к вышеперечисленным опциям.
Но когда мы пришли с этим к кибербезопасности, нам резонно сказали: К2 Tech — это интегратор, который работает с чужим исходным кодом. У нас нет легальной возможности передавать этот исходный код третьим лицам, а инсталляцию мы хотим сделать одну на всех. Поэтому пришлось создавать on-premise решение.
Поэтому ещё одна цель этой статьи — проверить, может ли on-premise open source решение во внутреннем контуре генерить качественный код для реальной работы. Посмотрим топовые open source варианты, развернём инсталляцию, разберём принципы работы и пользовательский опыт.
Итак, любой Copilot состоит из двух частей:
IDE-плагина, который встраивается в среду разработки и работает с файлами проекта,
Сервера с LLM, который принимает запросы от плагина и выдаёт код.
Мы проанализировали рынок и выбрали три лучших решения с расширениями, которые сочетают плагин и сервер или содержат только плагин.
Первым зацепил TabbyML — свежак на Rust (разработчики оценили), плюс шикарная админка а-ля GitHub. С ходу даёт Acceptance Rate — метрику принятых подсказок, — даже из коробки после установки.
Второе — RefactAI. Оно покорило поддержкой не только JetBrains и PyCharm, но и VS Code. Для нас это было ощутимым плюсом, потому что у нас есть разработчики, которые пишут на C#, используют Windows и эту IDE для него.
Преимущество RefactAI — файн-тюнинг из коробки: кидаешь ссылку на свой код в админку, и модель самообучается на нём. Это очень приятно и заставляет вас не задумываться о том, как всё работает внутри. Можно просто брать и пользоваться.
Третье — Continue.Dev. В отличие от предыдущих, здесь только плагин без сервера.
Популярность этого инструмента зашкаливает: почти 2 млн скачиваний, а гайды по сборке собственного Copilot ведут на Continue.Dev.
С учётом того, как быстро появляются и исчезают проекты с Copilot, это значимый критерий. Для сравнения, SaaS-гиганты тянут 30-67 млн (в 20 раз больше), но выбора не было — безопасность на первом месте. Так что Continue попал в топ.
Что внутри у Continue.Dev
На самом деле, у Continue.Dev внутри всё тоже самое, что и у модных SaaS-решений. Речь про три столпа Copilot:
Inline дополнение. Вы пишете код, он подсказывает следующую строку,
Чат, который должен знать вашу кодовую базу и отвечать, основываясь на её контексте,
Агенты, которым можно отдать полноценное решение задачи.
Мы решили сосредоточиться именно на Inline дополнении. Для меня это был один из самых важных аспектов Copilot, потому что сеньоры — достаточно консервативные ребята, которые не хотят менять свой подход к разработке. Inline можно безболезненно и без сильного сопротивления внедрить в работу. Сеньор пишет код, как привык, время от времени появляются какие-то подсказки, которые он, может быть, даже примет. А если примет, то может быть, даже порадуется Copilot и скажет, что это не так бесполезно, как он думал.
Как мы развернули инсталляцию
Continue.Dev интегрируется в среду разработки одним конфигом и начинает мониторить проект. Инструмент совместим с любым провайдером LLM, но для self-hosted решений выбирают Ollama — удобный вариант, который ставится одной командой на сервер и поддерживает большинство моделей. Нас не интересуют SaaS-решения, поэтому всё нужно поднимать самостоятельно.
Берём из облака Tesla Т-4 на 16 ГБ памяти, в качестве модели используем Qwen 2.5-Coder и получаем базовую рабочую инсталляцию. Чтобы разобраться, как всё работает изнутри, при этом не заглядывая в код, пишем свой небольшой прокси-плагин Ollama-X и ставим его перед Ollama. Первым добавляем Langfuse — сервис по аналитике, который позволяет логировать входы/выходы модели и собирать дата-сет для дообучения.
Но есть нюанс: Langfuse фиксирует запросы на сервере, а Ollama генерирует ответы и передаёт их в IDE. Принимает ли разработчик сгенерированный код — неизвестно. А это очень важно, потому что эта метрика (доля принятого кода) — ключевая для оценки полезности Copilot.
Поэтому мы всё-таки немного приоткрываем Continue.Dev и обнаруживаем встроенный PostHog, после чего ставим его себе на сервер. К сожалению, PostHog у Continue.Dev не настраивается, он захардкожен в самом расширении. Приходится клонировать репозиторий, переписывать его, билдить и ставить самостоятельно. Это помогает в случаях, когда PyCharm блокирует скачивание плагинов из России — у нас всё уже своё.
Инсайт №2: даже open source решения крадут код
После всех доработок мы увидели аналитику. Выяснили неприятный нюанс: Continue.Dev обещает собирать только анонимную статистику использования, но на деле лукавит. Типичная запись в PostHog выглядит примерно так.
Если вы приняли код (accepted = true), то Continue.Dev логирует минимум: модель,IDE, ОС. Но стоит вам оклонить этот код, как Continue.Dev начинает слать всю информацию о вашем проекте, которую только может собрать.
Это префикс и постфикс запроса к LLM — фактически, весь файл уходит на сервера Continue.Dev просто потому, что им надо понять, а почему же вы не приняли этот код. Но префиксов и суффиксов недостаточно — нужно забрать путь к вашему файлу и репозиторий, в котором вы всё это делаете. Это называется «достаточно анонимной» статистикой, которая не ворует ваш код. При этом такая статистика, справедливости ради, собирается только для VSCode, потому что плагин для PyCharm недоделан, и ваш код пока не воруют.
Langfuse и любой другой Copilot использует специальный шабон, который называется fim_themiddle (fill-in-the-middle). Плагин IDE собирает ваш код и посылает LLM как есть — с тремя важными метками:
fim_begin — начало контекста,
fim_hole — место под курсором для генерации,
fim_end — конец контекста.
Output — это тот самый код, который показывает LLM, и который вы увидите в своей среде разработки. LLM получает весь файл и сама находит, что дополнить. Задача плагина минимальна — подать контекст модели.
Пользовательский опыт
Итак, менеджеры сказали: «Давайте попробуем это в работе». А тут ещё и свои энтузиасты подтянулись — те самые, что вздыхали по Copilot'у, но томились в «enterprise-оковах». В итоге из скромной десятки разработчиков мы за пару недель выросли до 70 экспериментаторов.
Посмотрим на запросы того времени за месяц. Видно, что мы обработали 185 000 запросов на генерацию кода. Чатом пользовались не очень активно: запросов было всего 251, то есть порядка восьми в день.
В статистике справа — распределение по датам, где видно, как Copilot достаточно хорошо изображает Большого брата. Спады, которые уходят в ноль, — это выходные. Таким образом, мы получили достаточно полезный инструмент, который в режиме реального времени позволяет оценить, пишет разработчик код или нет. А если пишет, то когда и сколько. Даже на «нулевых» графиках мелькали одинокие пиксели — видимо, трудоголики не дремали.
Боли производительности
Но разработчики почему-то были недовольны. Говорили, что всё работает медленно и сервер падает. На самом деле, он не падал, а долго отвечал, latency модели росла. Выглядело это так:
Посмотрим на статистику скорости ответа. В идеале, — 90-й перцентиль, но если смотреть на 50-й, то Copilot отвечает половине пользователей примерно за семь секунд, а второй половине — дольше. Как только скорость ответа превышает 10 секунд, разработчики начинают говорить, что Copilot не работает и перестаёт давать подсказки.
На самом деле, это правильная оценка. Инсайт №3: Copilot должен отвечать быстро, иначе может вообще не отвечать. Он живёт подсказками за 2-3 секунды. Больше — и вы сами допишете строку. Замерли на 10 секунд? Значит, реально думаете, а Copilot с таким уже не справится.
Масштаб и расчёт
Мы выяснили, что примерно 15 разработчикам хватает одной Tesla в 16 гигабайт. Если вы решите арендовать такую же в каком-то облаке, это обойдётся порядка 800-1 000 ₽ в месяц на разработчика с поддержкой от инженеров, которые будут содержать эту инсталляцию. У нас со своим облаком вышло вдвое дешевле для 80 разработчиков. Поблагодарили тестеров, щёлкнули пальцами и оставили 15.
Фидбэк: где всё сломалось
Среди оставшихся 15 разработчиков отзывы сильно отличались в зависимости от IDE и были не очень положительными. RAG-поиск в чате (тот самый «знающий вашу кодовую базу») быстро ломался и отвечал общими словами. Из-за этого им пользовались нечасто или вообще переставали. Он мог начать индексировать кодовую базу или сдаться, просто повиснуть без пояснения, что идёт не так. Так мы получили on-premise LLM, слепую к своему же коду.
С функцией edit была аналогичная история. Чтобы агент работал и мог эффективно редактировать, нужен RAG-поиск, а кодовая база должна проиндексироваться. Если всё ломается на первом же этапе, то и агентом не будут активно пользоваться.
Подсказки для кода работали, но отзывы разнились в зависимости от IDE. То, что хвалили и считали «в целом норм» для VSCode, оказывалось плохим для PyCharm. Подсказки появлялись только для тривиального кода — сложные конструкции модель игнорировала.
Но главной проблемой стали внезапные фризы IDE. Расширение просто «замораживало» среду разработки: то она работает, а потом раз — и перестаёт. Пришлось всё-таки лезть в плагин с фонариком и тюнить.
Может, проблема в расширении?
Залез в код и выяснил, что к Copilot уходит трёхэтапный контекст:
Сначала — текущий файл (префикс, суффикс и всё, что влезло в контекст).
На втором этапе к контексту подмешиваются соседние и недавно редактируемые файлы.
На третьем этапе добавляется ещё больше данных: определения переменных с типами, классами, интерфейсами.
Казалось бы, это должно давать подсказки уровня SaaS-разрешения. Но есть нюанс: качество работы плагина сильно зависит от среды разработки. Когда мы начинали, Copilot гораздо больше нравился тем, кто работал с VS Code, чем тем, кто писал в PyCharm.
Дело в том, что в PyCharm реализован только первый шаг. Два других реализованы только в VS Code, потому что для них нужно использовать Language Server Protocol (LSP), который PyCharm держит на коротком поводке. Инсайт №4: в VS Code сторонние плагины летают, а в PyCharm — мучаются из-за разницы в открытости платформ.
Получив такие данные, я подумал, что возможно дело не совсем в Copilot, и SaaS-решения такие же плохие. У меня немного искаженное представление, потому что я часто использую Copilot, и уже привык программировать под него. Даже когда ставил on-premise решения, у меня принималось порядка 10-15% кода, что немало. Я решил дать новичкам попробовать SaaS Copilot и посмотреть, соберёт ли он такой же негативный фидбек.
Сказано — сделано. Нашли open source проект, где можно использовать SaaS, и получили совсем другие отзывы. Те же самые разработчики, которые были не очень довольны Continue.Dev и не имели большого опыта работы с Copilot, меняли своё мнение после GitHub Copilot. И подсказки хорошие, и есть ощущение, что Copilot, оказывается, умный. При рефакторинге убирает рутинные задачи, которые лениво и долго делать. Это чат, в который хочется возвращаться. Действительно позволяет лучше понять проект и отвечает предметно, несмотря на то, что не схватывает всё на лету.
Когда я увидел такое отличие, задумался: почему в SaaS решениях всё так хорошо и у них только положительный фидбэк? 100% ребят, которые пользовались GitHub Copilot, сказали, что хотят продолжать, а с on-premise решением всё не так хорошо.
Почему on-premise хуже SaaS
Всё упирается в open source природу проекта. Авторы проекта не доводят ничего до идеала — оставляют «полуфабрикаты»:
Inline-дополнение работает только для VS Code и не работает в PyCharm, это не меняют.
Чат тоже есть, но индексация проекта просто падает с ошибкой или не завершается.
Агенты тоже «в наличии», но без той полировки, которую наводят ради инвесторов.
GitHub Copilot выигрывает за счёт глубины: больше токенов на генерацию, три варианта промпта с ранжированием, плюс дообучение на принятом коде за последний год. Это даёт и качество, и количество принятия кода.
Выводы: стоит ли пробовать Copilot
Пробовать стоит. Если у вас строгие критерии ИБ, то я бы предложил начать с TabbyML: ставится в IDE буквально парой команд или поднимается сервером. Минимальные требования: MacBook с 8-16 ГБ RAM или ноутбук с GPU от 4 ГБ (модель займёт 2-3 ГБ).
Сейчас обычные Copilot, дополняющие код, уходят на второй план. Всё чаще люди используют агентские решения, которые хорошо подросли за последние полгода — например, Claude Code и Cursor, внутри котрого работает Codex.
Ну а мы пока едим кактус и набираемся опыта. K2 Cloud — это интегратор, и когда open source решения достигнут приемлемого уровня и будут работать из коробки, их получится внедрять для клиентов. И в этот момент мы будем готовы.
Если хотите больше материала про IT, можете заходить в соцсети компании и мой личный блог.
