Запрос «посоветуйте модель для кода» неразрешим в том виде, в каком его задают. Под ним прячутся две задачи, у которых требования не просто разные — они противоположные.
Первая: вы печатаете в редакторе, и модель дописывает следующие строки, пока вы не убрали пальцы с клавиатуры. Вторая: вы бросаете в чат три файла и спрашиваете, почему после рефакторинга поехали тесты. Первой нужна скорость и короткий ответ. Второй — размер и длинный контекст. Модель, выигрывающая в одной, в другой оказывается либо мучительно медленной, либо бесполезно поверхностной.
Ниже — разбор обеих задач по существу: какие свойства модели за что отвечают, где проходит граница, и почему при малом размере растёт частота выдуманных методов библиотек. Дата написания — 25 августа 2026 года; названия семейств приводятся как ориентир, их текущее состояние требует проверки на карточках моделей.
#Почему эти две задачи вообще ставят рядом
Ставят их рядом потому, что обе называются словом «код» и обе решаются языковой моделью. На этом сходство заканчивается.
Дополнение в редакторе — это интерактивный цикл с человеком в контуре: вы видите подсказку, принимаете её или продолжаете печатать. Цена ошибки почти нулевая, цена задержки огромная. Разговор о коде — это разовый запрос с обдумыванием: вы ждёте ответ и читаете его целиком. Цена задержки терпимая, цена ошибки высокая, потому что неверный совет об архитектуре стоит дня работы.
Сравнимы задачи в одном: обе упираются в один и тот же бюджет видеопамяти. Держать одновременно две модели — компактную для дополнения и крупную для диалога — получается не на всяком железе, и выбор часто сводится к тому, какой из двух задач вы жертвуете. Общая арифметика бюджета памяти разобрана в материале о том, какую модель выбрать под задачу и железо.
#Дополнение в редакторе: три жёстких требования
Низкая задержка. Подсказка полезна, пока она обгоняет вашу мысль. Ориентир — доли секунды от паузы в наборе до появления текста; когда задержка уходит за секунду, вы успеваете дописать строку сами, и подсказка превращается в помеху, которую нужно отклонять. Это требование само по себе вычёркивает большие модели: даже если такая модель влезла в память, она не успевает.
Короткий ответ. Задача — одна-две строки или тело небольшой функции, а не развёрнутое объяснение. Модель, натренированная на диалог, норовит добавить комментарий, пояснение и предложение улучшить архитектуру, и всё это лезет прямо в файл.
Режим вставки в середину файла. Это ключевое техническое различие, и оно скрыто от глаз. Обычная генерация продолжает текст слева направо. В редакторе же курсор стоит в середине: слева есть начало файла, справа — уже написанный остаток, и модель обязана учитывать оба. Такой режим называется fill-in-the-middle и требует, чтобы модель была специально обучена работать со служебными метками «префикс», «суффикс», «середина».
Здесь легко ошибиться: чат-версии моделей часто не поддерживают этот режим, тогда как базовые версии того же семейства — поддерживают. Модель без поддержки вставки в середину всё равно что-то выдаст, но она будет игнорировать код справа от курсора и предлагать то, что ниже уже написано.
#Разговор о коде: размер и удержанный контекст
Здесь требования разворачиваются на 180 градусов.
Размер. Объяснить, почему падают тесты, увязать три файла и предложить исправление — это цепочка рассуждений. Компактные модели её не тянут: они отвечают правдоподобно и мимо. Практическая нижняя граница для осмысленного разговора о чужом коде начинается около класса 7–8 миллиардов параметров, и даже там ответы требуют перепроверки; разбор кандидатов этого класса — в обзоре моделей на 7–8 миллиардов параметров.
Длинный контекст — реально удерживаемый, а не заявленный. В диалоге о коде вы подаёте несколько файлов сразу, и это десятки тысяч токенов. Число в карточке модели говорит, при каком объёме она технически не падает, а не при каком продолжает помнить, что было в начале. Разрыв между этими величинами бывает кратным, и проверяется он отдельно — методика в статье о том, чем реальный контекст модели отличается от заявленного.
Терпимость к задержке. Ответ через двадцать секунд здесь нормален. Это и есть то, что позволяет взять модель на порядок крупнее, чем для дополнения.
#Что смотреть в таблице требований
Ниже сведены свойства обеих задач. Читать её нужно по столбцам: каждый столбец — это отдельный набор требований, и попытка удовлетворить оба одной моделью проваливается в той строке, где значения расходятся сильнее всего.
| Свойство | Дополнение в редакторе | Диалог о коде |
|---|---|---|
| Размер модели | компактный класс, 1–7 млрд | от 7–8 млрд, лучше 14–32 млрд |
| Приемлемая задержка | доли секунды | до десятков секунд |
| Длина ответа | 1–20 строк | развёрнутый текст |
| Fill-in-the-middle | обязателен | не нужен |
| Тип версии | базовая версия семейства | чат-версия семейства |
Расхождение видно в каждой строке, кроме последней, где оно ещё и переворачивается: дополнению нужна базовая версия, диалогу — чат-версия. Это разные файлы моделей, а не разные настройки одной.
Отдельно стоит посчитать контекст, потому что именно он чаще всего ломает конфигурацию диалоговой модели. Ориентиры для планирования:
| Что подаёте | Порядок объёма | Замечание |
|---|---|---|
| Один файл на 300 строк | тысячи токенов | помещается почти везде |
| Три-четыре связанных файла | десятки тысяч токенов | нужен запас по KV-кэшу |
| Модуль целиком | сотни тысяч токенов | реальное удержание требует проверки |
Вывод из второй таблицы: длину контекста нужно задавать явно и с запасом под ответ, а не полагаться на значения по умолчанию — они часто заметно меньше заявленного максимума.
#Что мешает: модель уверенно придумывает методы
Это главная честная претензия к моделям для кода, и она не лечится настройками.
Модель порождает правдоподобное продолжение текста. Правдоподобное имя метода библиотеки — то, которое выглядело бы уместно в этом API. Существует ли оно на самом деле, модель не проверяет: у неё нет доступа к установленной у вас версии библиотеки, и она не различает «я это видела в обучающих данных» и «это логично здесь смотрится».
Три закономерности, которые стоит держать в голове:
- Чем меньше модель, тем чаще выдумка. Компактные модели заполняют пробелы в знаниях догадками агрессивнее крупных. Именно поэтому дополнение в редакторе безопаснее диалога: вы видите подсказку в контексте своего файла и отклоняете неверную за долю секунды, а выдуманный метод в развёрнутом ответе выглядит убедительно.
- Редкие и молодые библиотеки страдают сильнее. По популярному фреймворку модель видела миллионы строк, по нишевому пакету — десятки.
- Версии смешиваются. Модель уверенно предлагает синтаксис, который был верен две мажорные версии назад, потому что в обучающих данных его больше.
Практическое следствие: всё, что модель говорит об именах внешнего API, проверяется в документации, а не в чате. Ответ «такого метода нет, я его выдумала» модель не даст сама — уверенность в тоне никак не связана с верностью факта.
Вторая помеха мельче, но раздражает больше: диалоговая модель, поставленная на дополнение, дописывает объяснения и советы прямо в файл. Это лечится сменой версии модели на базовую, а не промптом.
#Где модель для дополнения объективно лучше крупной
Соблазн поставить одну большую модель на всё понятен, и он ошибочен по трём причинам.
Она успевает. Компактная модель на дополнении даёт подсказку раньше, чем вы сформулировали следующую мысль. Крупная не успевает — и весь смысл дополнения теряется, каким бы качественным ни был текст.
Она не занимает память постоянно. Дополнение работает весь день, диалог вызывается десяток раз. Держать в видеопамяти большую модель ради того, что случается редко, — плохой размен, особенно если та же память нужна редактору и браузеру.
Она умеет вставку в середину, а крупная чат-версия — обычно нет. Это не вопрос качества, а вопрос того, чему модель обучена. Крупная модель без поддержки такого режима на дополнении объективно хуже маленькой с поддержкой.
Обратное утверждение столь же верно: на вопросе «почему после рефакторинга упали три теста» компактная модель ответит быстро и неправильно, и это хуже, чем медленно и правильно.
#Кому что подойдёт
Бюджет памяти до 8 ГБ, пишете каждый день. Берите компактную базовую модель с fill-in-the-middle на дополнение, а разговор о сложном отдавайте туда, где есть большая модель. Пытаться уместить обе задачи локально при таком бюджете — размен не в вашу пользу.
12–24 ГБ. Реально держать компактную модель на дополнении постоянно и поднимать крупную чат-версию под задачу. Это рабочая конфигурация, при которой обе задачи закрыты честно.
Диалог важнее дополнения. Не тратьте память на дополнение вовсе: возьмите одну модель максимального размера, который влезает целиком, и задайте ей длинный контекст. Как это встраивается в остальной рабочий контур, разобрано в материале про персонального ИИ для разработчика.
Какой бы вариант вы ни выбрали, проверять кандидатов нужно на своём коде, а не на чужих примерах: своя кодовая база, свои библиотеки, свой стиль. Процедура слепого сравнения описана в гайде о том, как тестировать модель на своих задачах.
#Частые вопросы
#Можно ли использовать одну модель и для дополнения, и для диалога?
Можно, но одна из двух задач при этом пострадает. Дополнению нужна базовая версия с поддержкой вставки в середину файла и задержкой в доли секунды, диалогу — чат-версия покрупнее с длинным контекстом. Компромисс обычно означает медленное дополнение либо поверхностные ответы.
#Что такое fill-in-the-middle и почему это важно?
Это режим, в котором модель дописывает текст, видя одновременно код слева от курсора и код справа. Обычная генерация продолжает текст только вперёд и остаток файла игнорирует. Без такого режима подсказки в середине файла будут дублировать то, что ниже уже написано.
#Почему модель придумывает несуществующие методы библиотек?
Она порождает правдоподобное продолжение, а не проверенный факт: у неё нет доступа к установленной у вас версии библиотеки. Чем компактнее модель и чем реже библиотека, тем чаще выдумка. Имена внешних API нужно сверять с документацией.
#Какого размера модель нужна для осмысленного разговора о коде?
Практическая нижняя граница начинается около класса 7–8 миллиардов параметров, и ответы всё равно требуют перепроверки. Заметно устойчивее модели на 14–32 миллиарда, но они требуют соответствующего объёма видеопамяти и терпимости к задержке.
#Сколько контекста нужно, чтобы обсуждать несколько файлов?
Три-четыре связанных файла — это десятки тысяч токенов, и длину контекста придётся задавать явно: значения по умолчанию обычно заметно меньше заявленного максимума. Заявленный максимум при этом не равен длине, на которой модель действительно помнит начало.
#Помогает ли модель для кода в незнакомом языке программирования?
Помогает разобраться в чужом коде и подсказать типовые конструкции. Но проверить её утверждения в незнакомом языке вам будет нечем, а именно там частота выдуманных вызовов выше всего. Это худший сценарий для доверия ответу без проверки.
#Вывод
«Модель для кода» — не один выбор, а два. Дополнению нужны компактность, вставка в середину файла и задержка в доли секунды. Диалогу — размер, чат-версия и реально удерживаемый длинный контекст.
Если памяти мало и вы пишете каждый день — ставьте компактную модель на дополнение, диалог решайте иначе. Если памяти хватает на обе — держите их одновременно, это разные файлы и разные роли. Если выбирать приходится одну — берите ту, что закрывает вашу более частую задачу, и не ждите, что она справится со второй.
И независимо от выбора: имена методов внешних библиотек проверяйте в документации. Уверенный тон модели не является свидетельством того, что вызов существует.