Меня зовут Влад, я фуллстек-разработчик в Selectel. Есть распространенное мнение, что для серьезной агентской разработки хорошо подходят только коммерческие модели вроде Claude и ChatGPT, а open-source модели всегда остаются на вторых ролях. В реальном корпоративном проекте выбор устроен сложнее: в первую очередь думаешь, что можно модели передать, а уже потом — какую модель использовать.

В моих сценариях внешние модели я использую для ресерча и AI-ассиста на данных, за которые можно не переживать, а задачи с закрытым кодом или внутренней документацией выполняются с self-hosted GLM внутри управляемого контура. В статье расскажу, как harness делает такой внутренний контур практически применимым и как оптимизировать итоговый процесс в гибридном режиме.

Что именно проверялось

Публичные бенчмарки отражают общий уровень моделей (не всегда честно) и при этом далеко не всегда говорят о качестве в повседневных задачах. Входные данные подготовлены заранее, содержат полный и достаточный контекст. Нередко тесты бенчмарков слиты в сеть, и на решениях этих тестов обучают новые модели, что значительно уменьшает полезность публичных бенчмарков. Минусов достаточно, и достоверного бенчмарка, который бы меня устроил, я пока не нашел.

На практике я попытаюсь ответить на вопрос: может ли self-hosted-модель выполнять ограниченные задачи разработчика с закрытым контекстом на проектах разного уровня сложности и доводить результат до инженерного ревью? По факту все, что ниже, — мой опыт за последний год, бенчмарков с циферками не будет.

Какие конфигурации использовались

Характеристики и API-цены, приведенные ниже, зафиксированы на июль 2026 года. Цены указаны за миллион входных и выходных токенов. Они нужны только как ориентир: подписка, API с оплатой по фактическому использованию и self-hosted-инфраструктура — разные модели оплаты.

GLM-5.1 и GLM-5.2 — открытые текстовые модели с архитектурой Mixture of Experts (MoE, «смесь экспертов»). Для семейства GLM-5 разработчики указывают 744 млрд общих и 40 млрд активных параметров. Конфигурации, которые упоминаются дальше:

* Базовая цена за миллион токенов на дату проверки. Для GLM приведен тариф ИИ-роутера, как ориентир: он не является себестоимостью self-hosted-стенда.

Для Claude и GPT значения относятся к API, а не к месячным подпискам. У GPT-5.5 запросы с входом свыше 272K токенов тарифицируются для всей сессии по ставкам 2× за вход и 1,5× за выход. xhigh — уровень глубины рассуждения, а не отдельная модель.

Источники характеристик: технический отчет GLM-5, GLM-5.1, GLM-5.2, модели Claude, GPT-5.3-Codex, GPT-5.5. Цены взяты со страницы ИИ-роутера Selectel на июль 2026.

Условия сравнения

В первом кейсе сравниваю реальные рабочие условия: self-hosted-конфигурация имела прямой доступ к внутренним репозиториям, а для внешней модели контекст приходилось собирать вручную. Во втором — четырем конфигурациям были доступны одинаковая постановка и один исходный код.

Кратко о self-hosted-стенде

GLM работает на инфраструктуре с несколькими GPU в двух независимых репликах. Модель запускалась в FP8-квантизации. Когда реплику использует один активный клиент, скорость генерации держится около 400–500 токенов в секунду. С ростом числа параллельных сессий скорость отдельного пользователя снижается, зато суммарная пропускная способность реплики растет.

ИИ‑роутер — доступ к 300+ моделям из одной панели

Подключите OpenAI‑совместимый шлюз по единому API‑ключу. Настраивайте сквозную аналитику, отслеживайте лимиты и квотируйте ресурсы.

Запустить ИИ‑роутер →

Где заканчивается вайбкодинг и начинается инженерная работа

Вайбкодинг подходит для задач, когда итоговый результат должен подтвердить какую-то гипотезу или не планируется использовать в чем-либо серьезном. С другой стороны, мы понимаем: даже если код в какой-то момент написан ИИ, его необходимо отревьюить. Ведь ответственность в конечном итоге за инженером, который этот код принес. 

И тут уже вступает в работу инженерная дисциплина. В некоторых местах она сложнее, чем просто написание кода: требуются сотни строк инструкций и огромное количество обвязок из скриптов. В особенности я бы выделил настройку безопасного окружения, в котором агент, даже если что-то и сломает, то это будет совершенно не страшно.

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

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

• закрытые данные передаются только инструментам разрешенного контура;

• код проходит одинаковые проверки независимо от способа создания;

• промпты, агенты и скиллы поддерживаются как инженерная инфраструктура;

• критическую часть процесса инженер должен понимать и уметь выполнить вручную.

Почему доступ к контексту меняет выбор модели

В продуктовой разработке самый важный критерий выбора агента и LLM, как по мне, — это ответ на вопрос: «Можно или нельзя передать контекст для текущей задачи?». Если для внутренней модели мы можем передать спецификации и контракты внутренних систем, то для внешних — точно нет. 

В итоге для решения такой задачи с помощью ИИ необходимо собрать данные, обезличить, пересказать сведения, передать абстрактные куски кода. Это порой может занимать часы. В этом плане self-hosted-контур раскрывается на полную: доступ к документации, деталям и связанным тикетам, прямой доступ к репозиторию и смежным проектам — все это огромное количество ценного контекста. 

В обоих случаях инженеру нужно настроить доставку полезного контекста. Во внешнем контуре большую часть приходится пропускать через инженера, а во внутреннем — процесс удается автоматизировать. Это отдельная большая задача. Дальше — пара примеров решения задач с помощью обоих контуров.

Кейс с разным доступным контекстом

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

В self-hosted-контуре я подключил GLM-5.1 через OpenCode ко всем связанным репозиториям. После настройки агент сам собрал технический контекст и задал только пару общих архитектурных вопросов, которых не хватало. Рабочий proof of concept (PoC) с тестами и самоверификацией был готов примерно за 1–2 часа работы модели; отдельного ручного сбора контекста не потребовалось. Результат с первого промпта — получил готовый компонент, который можно было полировать, полностью рабочий и без багов, как выяснилось в итоге. Для меня это был «вау-эффект».

Для внешнего контура я использовал Claude Opus 4.7 для режима планирования и Claude Sonnet 4.6 для реализации. Из-за отсутствия прямого доступа к внутренним репозиториям я потратил больше двух часов на сбор, абстракцию и передачу разрешенных контрактов без самих исходников. Местами были swagger схемы, местами — куски документации или вырезки из кода. 

Работа Claude заняла еще около трех часов: в процессе у модели были вопросы, на которые я быстро не мог ответить по тем или иным причинам. Я бы еще добавил, что такие вопросы в процессе дергают инженера, и если в первом случае я мог заниматься другой задачей, тут мне приходилось находиться рядом. После этих уточнений Claude также довел задачу до PoC.

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

Кейс с одинаковым доступным снимком проекта

Другая задача более синтетическая, выполненная с помощью GLM-5.1, Claude Opus 4.7, Claude Sonnet 4.6 и GPT-5.5 xhigh. Работа велась в монорепозитории с фронтендом, бэкендом, базой данных и парой небольших микросервисов. Изменение затрагивало REST-интеграцию, создание новой страницы и доработку двух существующих страниц. Всем четырем конфигурациям были доступны одинаковая постановка и один исходник.

Все конфигурации прошли одни и те же этапы: планирование, реализацию и quality gates (проверки качества). Каждая получила полный цикл из трех сессий без перезапуска задачи с нуля. После чего модели проверяли результат друг друга.

*Решение задачи разбивалось на 3 новых сессии: Ресерч → Планирование → Реализация.

**Под «неровностями» понимаются небольшие проблемы реализации и качества кода. Это не ошибки или баги.

В итоге все модели полностью справились с задачами — к 2026 году в этом уже не приходится сомневаться.

Агент — это инструмент, только с качественным Harness

Для self-hosted-конфигурации я выбрал OpenCode: это open-source-клиент с интерфейсом командной строки (CLI), его можно подключить к большинству ИИ-сервисов, запускать в терминале или headless как скрипт и дополнять скиллами, субагентами и MCP. 

Выбор клиента здесь важен не как рейтинг интерфейсов, а как способ сохранить один проверяемый процесс при смене модели и контура.

Мой ИИ-воркфлоу (примеры выше были сделаны по нему) выглядит так:

1. проводим интервью, чтобы зафиксировать задачу в inbox.md;

2. ищем связанный код и ограничения, кладем в research.md;

3. на основе ресерча и интервью составляем plan.md, задавая инженеру уточняющие вопросы по архитектуре и не только;

4. разбиваем план на атомарные задачи в prd.json. Что-то похожее на таски с доски;

5. запускаем Ralph loop — скрипт, который по очереди передает агенту задачи из prd.json. Каждая задача получает отдельный контекст и завершается отдельным коммитом. В процессе сохраняем промежуточные действия в process.md;

6. итоговый код проверяем через quality gates, чтобы не было мусора, дубликатов и прочих расхождений с нашими правилами;

7. инженер проверяет merge request (MR), исправляет ошибки и подтверждает ожидаемое поведение;

8. проводим рефлексию на основе всех этапов. В полуавтоматическом режиме анализируем процесс, чтобы потенциально улучшить или изменить воркфлоу, скрипты и инструкции — то есть наш harness в целом.

Напомню, harness — это инфраструктурная обвязка, которая управляет LLM-моделью и автоматизирует ее работу. Сюда входят системные промпты, скрипты автоматизации, MCP, линтеры, тесты и изолированные окружения для безопасного запуска кода. Модель дает лишь «интеллект», а harness превращает ее в инструмент.

Обвязка решает три группы задач:

• Собирает контекст. Субагенты ищут релевантный код, Atlassian MCP предоставляет разрешенный доступ к Jira и Confluence, а Figma MCP — к макетам;

• Делает атомарные задачи. Когда большая задача разбита на мелкие части — агенту проще их выполнить, контекст не засорен, меньше шанс на reward hack;

• Проверяет результат. Линтеры и тесты валидируют код, Playwright MCP проходит пользовательские сценарии в работающем приложении, а инженер завершает процесс ревью merge request;

• Самоулучшение. При нахождении ошибок в процессе ревью мы их фиксируем, чтобы в следующий раз их не повторять.

Количество доступных скиллов лучше ограничивать и по возможности весь harness держать минимальным. Форматирование и другие детерминированные правила надежнее вынести в линтеры, Git hooks и скрипты, оставив модели только инструкции.

Интервью, ресерч и план

Для больших задач важен каждый из этих шагов. 

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

Ресерч поможет нам зафиксировать все связанные файлы и связи, когда мы будем планировать фичу или реализовывать ее — нам не нужно будет искать все заново, а только читать релевантные источники. 

План — самая важная часть воркфлоу, мы ничего не делаем без плана. Мы фиксируем, что мы делаем, как мы делаем, для чего, какие могут быть проблемы, что нужно протестировать и не забыть. 

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

Для крошечных задач мы скорее хотим использовать два этапа — план + ресерч в одном запросе и сразу приступать к реализации в следующем.

Loops и prd.json, quality gates

Самые большие задачи, которые потенциально будут делаться за несколько млн. токенов — рекомендую также пропускать через agentloop. Главная идея такая — мы создаем json в который кладем массив задач к выполнению. Запускаем скрипт который создает новый контекст на каждую новую задачу, токенов тратится больше, но результат предсказуемей, а агента можно оставить выполнять задачу долгое время.

Отдельно можно вынести, что через такой подход мы можем складывать в массив какие угодно задачи, например:

• проверку безопасности;

• написание тестов;

• рефакторинг;

• переводы.

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

Проверка MR и рефлексия

На выходе после работы ИИ у нас есть готовый MR, прошедший линтеры, преттиры, билды и тесты. Время смотреть инженеру. 

Большое количество кода после ИИ смотреть тяжело — но это необходимая часть, особенно для проектов которые имеют пользователей. Если все предыдущие шаги сделаны правильно — значит у нас код +- нормально качества, по крайней мере это ожидается. Все найденные косяки, баги, кривые подходы и дыры — фиксируются, после чего начинается рефлексия.

Прежде чем начать говорить про рефлексию — поговорим про память. Большое количество провайдеров предлагают свои механизмы долгосрочной памяти LLM: Anthropic, OpenAI, open-source-плагины. Все на бумаге звучит отлично, но как показывает практика, трата на чтение, поиск по памяти и сохранение в нее — очень дорогие по токенам задачи. Отдельно говоря про проблему «Что вообще класть в память?». Потому я предлагаю отказаться от памяти и использовать рефлексию.

Рефлексия в контексте ИИ агента — это осмысление проделанной работы и сохранение результатов на будущее. От памяти отличается тем, что итоги рефлексии мы сохраняем в skills, agents.md и прочих инструкциях. Получаем вот такой flow:

Решаем с помощью ИИ → ревьюим → находим повторяющиеся проблемы и паттерны → пересохраняем в инструкции.

Добавлю что если давать бесконтрольно агенту самому себе обновлять инструкции — мы получим раковую опухоль, тысячи и тысячи строк кода инструкций в skills, agents, commands и тд. Это можно решить — написав skill в котором зашить требования к размеру и структуре всех своих инструкций, условно схема, за которую нельзя выходить.

Как процесс переходит между контурами

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

После перехода сохраняется тот же цикл: исследование контекста, план, атомарные задачи, выполнение, автоматические проверки и MR. Качество остается примерно тем же.

Где работа ИИ получается хуже, а где лучше?

На своих задачах я использую ИИ повсеместно, так как понимаю, что это буст по производительности. Без преувеличения, последний год самый продуктивный в моей карьере. ИИ-агента хорошо использовать для ресерча, поверхностного и глубокого анализа кодовой базы, поиска быстрых ответов и написания кода, типовых задач, написания инструментария для разработки. Раньше часто останавливал себя от автоматизации некоторых рутинных задач, потому как понимал, что, потратив сейчас десять часов на разработку решения, я скорее всего не сэкономлю время на саму задачу, — сейчас ситуация кардинально поменялась. Отдельно бы добавил использование агента как второе мнение.

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

Отдельно выделю последние 20% работы над задачей: как пример, агент уже выполнил 80%, и задача работает, как договорено, но опытный инженер сразу видит, где можно еще отполировать, чтобы было лучше, — мелкие шероховатости, неточности, краевые сценарии, оптимизации, оверинжиниринг. Также изменяющийся контекст — часто бывает, что задача меняется в процессе реализации, и агент не всегда готов к такому.

Экономика, данные и эксплуатационные риски

Очень сложно рассчитать цену каждого токена, и даже если это сделать, цена перестанет быть актуальной очень быстро. Полная стоимость владения (total cost of ownership, TCO) включает аренду или амортизацию GPU, развертывание и сопровождение, мониторинг, резервирование, простой и фактическую утилизацию. Я не решусь утверждать, какой вариант дешевле — внутренний контур или внешний; API-цены в справочной таблице нужны только как внешний ориентир.

Данные и безопасность. OpenAI и Anthropic говорят, что не обучают модели на данных своих корпоративных клиентов, но это не отменяет тот факт, что есть внутренние требования к месту обработки, срокам хранения и допустимым поставщикам. В нашем сценарии закрытый код не передается внешнему поставщику модели. Self-hosting позволяет нам контролировать размещение и доступ, но не отменяет управление правами, журналирование, защиту секретов, сетевые ограничения и контроль полномочий инструментов. 

Региональная доступность. Сейчас прямая покупка с территории России недоступна, соответственно и поддержка тоже, в случае проблем — мы вынуждены решать их сами. 

Контекстное окно. Документированное окно GLM-5.1 составляет 200K токенов, у GLM-5.2 — 1M, но в нашем стенде рабочий лимит обеих моделей установлен на 200K. По своему опыту в рабочих задачах 1 млн токенов окно — оверхед, если решение задачи не умещается в 50K–120K, есть вероятность, что подход можно оптимизировать.

Модальность. Claude и GPT принимают на вход текст и изображения, а GLM — нет. При этом сама эта возможность полезна довольно условно и была нужна только в верстке макетов, но даже так — способность работать с изображениями не гарантирует, что верстка будет нормальной, а потому настраивать флоу с этим сценарием не рекомендуется.

Воспроизводимость. Отдельно хочу добавить, что зафиксированная версия не отменяет падение качества модели для внешних источников. Субъективно я замечал, как падает качество моделей от Anthropic перед новой моделью и просто в процессе эксплуатации на тех же сценариях. При работе через внешних провайдеров по типу OpenRouter запросы также могут маршрутизироваться между разными провайдерами, и эти провайдеры могут менять квант без оповещения потребителя. В self-hosted-контуре у нас меняется только скорость модели, качество ответов всегда одинаковое.

Эксплуатация. Полный контроль self-hosted-контура дает как преимущество, так и накладывает дополнительные ограничения и требования к работе с инструментами, разверткой, мониторингом. С другой стороны, это повышает экспертизу.

Матрица выбора контура

Итого

Внешние модели остаются мощными инструментами для ресерча и задач, где разрешено передавать полный контекст, для разработки PoC. Self-hosted LLM можно использовать всегда, но они требуют больше экспертизы в настройке. Я выбираю гибрид — использую на постоянной основе оба варианта, получая преимущества каждого из них.

Self-hosted GLM — хороший конкурент не без недостатков, но показывает, что open-source LLM могут тягаться, а местами и превосходить закрытые модели.

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