В обсуждении Goodbye Coding Plans на r/LocalLLaMA от 10 октября 2026 года прозвучал прогноз: примерно через год локальной модели вместе с хорошим harness хватит, чтобы писать 90% кода. Ни бенчмарков, ни замеров, ни описания методики в посте нет. Это мнение участника дискуссии, и разбирать его стоит именно так.
Что стоит за тезисом о «90% кода» на локальной модели
Формулировка автора звучит дословно так:
I’d say we’re a year-ish away from local + good harness being enough to write 90% of code.
Там же отдельное обращение к семейству моделей: «Looking at you, Qwen». То есть ставка делается на локальный запуск плюс обвязку, а Qwen назван перспективным кандидатом для такого сценария.
Показательна реакция комментаторов. Часть пользователей возразила, что Qwen3.8 Next Flash, по их мнению, уже близок к заявленному уровню. Автор ответил на это: «damn, sounds like you all think Qwen3.8 Next Flash is there already… going to have to give it a spin…», то есть собрался проверить модель сам. Ни замеров, ни подтверждённых данных о возможностях Qwen3.8 Next Flash в материале нет: только мнения и намерение протестировать.
Цифра 90% превращается в лозунг, пока не задана рамка. Что считается кодом: написание с нуля, рефакторинг, отладка, тесты, ревью. На какой кодовой базе: пет-проект на несколько тысяч строк или рабочий монорепозиторий. С каким harness и на каком железе. По какой метрике успех: код проходит тесты, принимается ревью без правок или требует нескольких итераций. В исходном посте нет ни одного из этих уточнений. Чтобы понять, насколько реалистичен прогноз, нужно сначала разобраться, что такое harness и какие компоненты входят в локальный цикл написания кода.
Что такое harness и из чего состоит локальный цикл написания кода
«Локальная модель + harness» - это связка из двух частей, и вторая часть названа не случайно. Harness (обвязка) управляет моделью: собирает контекст, вызывает инструменты, читает и правит файлы, запускает команды, разбирает вывод и решает, что делать дальше. Сама модель только генерирует токены. В исходной дискуссии понятие harness детально не раскрывается, и это пробел, который стоит закрыть.
Модель, инференс-движок и агентная обвязка: кто за что отвечает
- Модель принимает текст и возвращает следующий токен. От неё зависят качество кода, следование инструкциям и способность удерживать длинную задачу.
- Инференс-движок запускает веса на вашем железе, делит память между весами и KV-кэшем, обслуживает запросы. Сюда попадают универсальные решения вроде llama.cpp, Ollama и vLLM, а также узкие сборки под конкретное железо и формат квантизации.
- Harness держит историю сессии, обрезает и переупаковывает контекст, вызывает инструменты, следит за лимитами и повторяет цикл до результата.
- Агентная логика задаёт последовательность шагов: где искать код, какие файлы читать, какой патч предложить, какие тесты прогнать.
Рабочий цикл выглядит так: задача формулируется в harness, harness собирает релевантный контекст из репозитория, модель предлагает изменение, harness применяет патч, запускает тесты или линтер, возвращает вывод модели и повторяет шаг, пока ошибки не исчезнут или не закончится бюджет по токенам. Всё это происходит на одной машине, без обращения к внешним API.
Почему harness может быть важнее самой модели
Сильная модель без доступа к репозиторию и возможности запускать команды упирается в копипаст между чатом и редактором. Слабый harness на сильной модели выдаёт правдоподобные патчи, которые не собираются. Обратная ситуация встречается чаще, чем кажется: средняя модель в аккуратной обвязке с обратной связью по тестам доводит задачу до рабочего состояния, потому что видит ошибку и может её исправить на следующем шаге.
Аналогия простая: модель - двигатель, harness - трансмиссия, шасси и тормоза. Мощный двигатель без коробки передач никуда не поедет. Поэтому тезис и звучит как «local + good harness», где акцент на второй части.
Практическая сторона вопроса - расход контекста, tool calling и поведение обвязки на слабом железе - разобрана в статье little-coder или Pi для локального кодинга на малых моделях.
Локальный запуск против облачных coding-планов: честное сравнение
Облачный coding-план, то есть подписка на ассистента с доступом к крупной модели, и локальная связка решают одну задачу разными средствами. Сравнение по одной оси ничего не даёт, разница проявляется в комплексе.
| Ось сравнения | Локальный запуск | Облачный coding-план |
|---|---|---|
| Код и данные | Не покидают вашу машину | Уходят на серверы провайдера |
| Старт | Нужна настройка движка и harness | Оплата и установка клиента |
| Железо | Ваша GPU и объём VRAM | Чужое, за стоимость подписки |
| Потолок качества | Ограничен моделью, которая влезает в память | Доступ к самым крупным моделям |
| Скорость | Зависит от железа и квантизации | Обычно выше и стабильнее |
| Лимиты | Только ваши токены в секунду | Квоты и правила тарифа |
Приватность, стоимость и контроль: что реально получает пользователь
Главный аргумент локального запуска - код не уходит наружу. Для проектов под NDA, внутренних репозиториев и задач с персональными данными это часто решает вопрос выбора без обсуждения качества. Второй момент - предсказуемость: нет квот, нет изменения условий тарифа, нет зависимости от доступности чужого API. Третий - возможность дообучения под свой стек и свои соглашения о коде.
Облачный план выигрывает в другом. Время до первого результата минимально, качество на сложных задачах выше, покупать железо не нужно. Для команды из нескольких человек подписка часто обходится дешевле, чем рабочие станции с достаточным объёмом VRAM каждому. Разговор о деньгах упирается в масштаб: одна машина против нескольких подписок. Считать это нужно под конкретную команду, а не по общим соображениям.
Где локальный запуск проигрывает облачным планам
- Контекстное окно. Даже при большом заявленном окне реальный рабочий контекст ограничен памятью: KV-кэш растёт вместе с длиной диалога и съедает VRAM, которую вы уже отдали весам.
- Скорость генерации. Агентный цикл делает десятки вызовов модели на одну задачу. Если каждый вызов идёт медленно, разница в комфорте заметна сильнее, чем на одиночном запросе.
- Качество на сложных задачах. Многофайловый рефакторинг, миграции, разбор чужого кода с неявными зависимостями: здесь локальные модели, которые влезают в потребительскую память, пока уступают топовым облачным.
- Стоимость владения. Железо, электричество, время на настройку harness и на отладку его поведения. Это не разовый платёж, а постоянные вложения.
- Сопровождение. Обвязку нужно обновлять, следить за форматами квантизации и совместимостью движков с новыми моделями.
Ограничения стоит читать как текущее состояние, а не как приговор: и модели, и harness меняются быстро. Планировать переход через год на основе чужого прогноза без собственных замеров не стоит.
Какие локальные модели и harness рассматривать сегодня
Qwen упомянут в обсуждении как перспективный кандидат для связки с harness, а в комментариях Qwen3.8 Next Flash называют близкой к нужному уровню. Подтверждённых бенчмарков этих заявлений в материале нет, поэтому воспринимайте их как повод присмотреться к семейству, а не как готовый вывод о пригодности. Как читать сравнения моделей, когда данные противоречат друг другу, разобрано в статье DeepSeek отстал в гонке открытых LLM или это только так выглядит.
На что смотреть в модели: контекст, квантизация, поддержка кода
- Контекстное окно. Оно определяет, сколько кода модель видит за один проход. Для агентного цикла важнее не максимум из спецификации, а то, сколько окна остаётся после системного промпта, описания инструментов и истории шагов.
- Квантизация. Форматы вроде GGUF, AWQ, GPTQ или NVFP4 уменьшают вес модели, но влияют на качество и на требования к VRAM. На слабом железе это компромисс, который приходится принимать.
- Специализация на коде. Модель, обученная на коде, часто обходит более крупную общую модель на задачах программирования. Число параметров не единственный критерий.
- Следование инструкциям. Для агентного цикла критично, насколько модель слушает правила проекта и не выдумывает несуществующие файлы и функции.
Harness: какие функции критичны для написания кода
- управление контекстом и историей: что попадает в промпт, что обрезается, что суммируется;
- доступ к файловой системе с ограничением области видимости: чтение, поиск, точечные правки;
- запуск команд, тестов и линтеров с возвратом вывода обратно модели;
- обработка ошибок и повторов: что делать, если патч не применяется или тест падает;
- интеграция с редактором и контролем версий, чтобы изменения было видно и легко откатить.
Без этих функций локальная модель остаётся чат-ботом в терминале. С ними она становится coding-агентом, и именно этот слой определяет, сколько задач закрывается автоматически, без ручного копирования кода.
Требования к железу: что нужно для локального coding-агента
Ориентир по памяти для весов: при 4-битной квантизации модель занимает примерно 0,5-0,6 ГБ на каждый миллиард параметров. Считайте это оценкой порядка, а не точной цифрой: реальный расход зависит от формата квантизации, длины контекста и конкретного движка. К весам добавляется KV-кэш, который растёт вместе с контекстом, и служебные буферы.
- Модели уровня 7-14B в 4-битной квантизации обычно укладываются в потребительские GPU. Это рабочий вариант для автодополнения и небольших правок.
- Модели уровня 20-32B требуют заметно больше памяти, и на домашней машине они чаще живут в квантизованном виде с урезанным контекстом.
- Крупные MoE-модели можно поднять на рабочей станции с большим объёмом VRAM, но скорость и бюджет контекста придётся подбирать под конкретную обвязку.
Скорость генерации влияет на комфорт нелинейно. Человек читает ответ и успевает подумать, а агент делает десятки вызовов и ждёт каждый. Поэтому для coding-агента ориентируйтесь на скорость в агентном цикле, а не на одиночный чат. Ресурсы расходует и сам harness: индексация репозитория, поиск по файлам, хранение истории сессий.
Отдельная переменная - движок. Универсальные решения вроде llama.cpp и vLLM покрывают широкий круг моделей, тогда как сборки под конкретную архитектуру и железо дают другой баланс скорости и совместимости. Какие компромиссы это несёт, разобрано в материале про узкоспециализированные inference-движки для локальных LLM.
Как оценивать заявления о «90% кода»: критерии и осторожность
Чтобы проверить тезис, нужны четыре уточнения. Какие задачи считаются кодом: написание с нуля, рефакторинг, отладка, тесты, ревью чужого патча. На какой кодовой базе: пет-проект на пять тысяч строк и рабочий монорепозиторий дают разные результаты. С каким harness и на каком железе. По какой метрике: проходит ли код тесты, принимает ли его ревьюер без правок, сколько итераций нужно до рабочего результата.
Без этих уточнений 90% остаётся лозунгом, а не измерением. Автодополнение строк и закрытие задачи по написанию кода отличаются на порядок по сложности, и складывать их в одну цифру нельзя. В исходном обсуждении критериев нет, поэтому тезис и остаётся мнением.
Почему бенчмарки не равны реальной работе
Бенчмарки измеряют узкие задачи в контролируемых условиях: изолированная функция, известный вход, автоматическая проверка. Реальная работа включает контекст проекта, неявные зависимости, стиль кода команды и требования ревью. Модель с высоким баллом может проваливаться в конкретном репозитории, а средняя модель в хорошей обвязке закрывает рутину.
Полезны не только классические тесты, но и живые замеры на реальных задачах. Пример такого подхода - locallm.top, открытый бенчмарк локальных LLM с агентными тестами: результаты собирают по доменам с оценкой экспертов. Любые таблицы стоит читать с поправкой на условия запуска, версию модели и квантизацию.
Когда локальный запуск реально заменит облачные coding-планы
Замена не произойдёт одномоментно. Она растёт из трёх процессов: качество локальных моделей, зрелость harness и доступность памяти на потребительском железе. Обсуждение называет срок около года, и эту цифру стоит воспринимать как мнение участника дискуссии, а не как прогноз с обоснованием. Первоисточник прогноза - пост Goodbye Coding Plans.
Часть сценариев закрывается локально уже сейчас: приватные проекты, типовые правки, автодополнение, генерация тестов, объяснение незнакомого кода. Для сложных многофайловых рефакторингов и задач, где нужен широкий взгляд на архитектуру, локальные модели пока проигрывают. Насколько велик разрыв на одной задаче, показывает разбор сравнения локальных Qwen с облачной моделью в 3D-моделировании на RTX 5090: мощности видеокарты самой по себе не хватает.
Практический вывод такой. Возьмите десяток задач из своего рабочего репозитория, прогоните их через локальную связку с тем harness, который планируете использовать, и посчитайте, сколько задач доходит до принятого патча и сколько итераций это заняло. Такой замер полезнее любого прогноза со стороны. Если результат устраивает на приватных задачах, локальную модель можно включать в работу сегодня, а облачный план оставить под то, что она не тянет.