Стартап оставил Claude и Codex, а работу с документами перенёс в локальный ИИ

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

В препринте от 5 ноября 2026 года Grayhat Developers, компания по разработке ПО с численностью менее 40 человек, рассказала, что произошло после разделения этих задач. Инженеры попробовали собственный хостинг моделей для разработки и обнаружили, что с заменой коммерческих агентов часть работы с репозиторием стала медленнее или сложнее. Они оставили этих агентов для сложных изменений, а часть поиска документов, подготовки контекста и синхронизации задач перенесли в локальный сервис.

Для другой небольшой команды интересно, какую часть переносить первой. Опыт Grayhat даёт конкретную точку отсчёта, оценку, которую стоит разобрать, и пример ошибки внедрения, способной сорвать пилот прежде, чем команда успеет оценить модели.

Прежде чем менять код, нужно собрать контекст

Grayhat использовала Outline для документации, Plane для учёта задач и ERPNext для сведений об организации. Эти сервисы уже размещались на офисном компьютере, а Authentik обеспечивал управление учётными записями. Там же работали коннекторы Model Context Protocol, или MCP. Второй компьютер выполнял инференс моделей. У разделения была практическая цель. Документы и задачи оставались доступны через обычные интерфейсы, пока модели расходовали вычислительные ресурсы на другой машине.

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

Этапы передачи работы в процессе Grayhat. Иллюстрация Telli.sh на основе исследования от 5 ноября.

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

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

Команда оплатила мощности и оценила, какую часть работы можно перенести

По данным авторов, исходные коммерческие расходы составляли около 325 долларов в месяц. Примерно 175 долларов приходилось на семь мест Claude, 140 — на семь подписок Codex и 10 — на кредиты. Также авторы сообщают о более чем 25,93 млрд учтённых токенов по этим сервисам. В статье не установлено, что эти токены относятся к тому же расчётному периоду, что и 325 долларов. Эти показатели описывают разные вещи. Деление одного на другое не определяет цену токена.

По оценке команды, передача контекста, документация и координация проектов составляли 30–40% работы с коммерческим ИИ. Авторы предположили, что локальная система возьмёт на себя примерно 90% этого объёма. После умножения получаются 27–36% всей коммерческой нагрузки. Такая доля от 325 долларов равна примерно 88–117 долларам в месяц. Это оценки нагрузки и её денежного эквивалента из исследования от 5 ноября. Авторы не проводили контролируемого эксперимента со счетами до и после.

От доли работы к её денежному эквиваленту по расчёту Grayhat. Иллюстрация Telli.sh.

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

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

Второй интерфейс изменил то, кто отвечает за настройку

При первом внедрении использовали LobeHub. Инженеры получили инструкции по подключению собственных интерфейсов к внутренним инструментам. По словам авторов, перспективные демонстрации не привели к регулярному использованию. Людям нужно было знать, какой коннектор выбрать, где он находится и как пройти аутентификацию. Каждый дополнительный выбор отдалял первый полезный ответ.

Во втором интерфейсе Grayhat рабочие инструменты настроены централизованно. Рисунок 2 из работы “Create Your Own Work Stack”, Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz и Abdullah Aamir, CC BY 4.0.

Команда перешла на централизованно настроенный LibreChat. Пользователи видели доступные инструменты и могли войти при обращении к ним. Авторы насчитали восемь замечаний о настройке и освоении в 11 структурированных интервью по первой версии. Для второй версии в неструктурированных отзывах Discord было три таких замечания. Цифры получены разными способами. Они помогают обнаружить проблему освоения, но не показывают, насколько выросло использование или у скольких сотрудников исчезла эта трудность.

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

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

Поручайте локальной системе задачи, за результат которых кто-то отвечает

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

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

Со сложным программированием иначе. Миграция базы данных может потребовать изучить исторические контракты данных, изменить несколько сервисов и проверить откат. В Grayhat локальная система испытывала трудности на больших задачах с репозиториями, особенно когда требовались широкий контекст и своевременный инференс. Исследование описывает оборудование, модели и опыт конкретной команды. Оно даёт основания сначала проверить локальную систему на своей нагрузке, а затем расширять круг задач.

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

Короткий пилот помогает отделить полезную работу от обслуживания инфраструктуры

1. Задайте три результата. Выберите сводку со ссылками на задачи, редактуру документации и черновик новой задачи. Одним предложением на каждый результат укажите, кто его принимает и какие подтверждения нужны. Храните пример провала рядом с удачным, включая ошибки, которые легко пропустить.
2. Измерьте текущий процесс. В течение обычной рабочей недели считайте завершённые примеры, существенные исправления и время на поиск контекста. Где возможно, соотнесите использование коммерческих инструментов с процессами. Отметьте, повлияет ли снятие задач на оплачиваемые места или превышение лимита. Отдельно учтите работу, за которую команда вовсе не взялась.
3. Подключите один внутренний инструмент. Начните с доступа на чтение и конкретного проекта. Убедитесь, что уполномоченный сотрудник может получить известную задачу, а человек вне проекта — нет. Ограничьте пилот людьми, которые уже выполняют выбранную работу. Дайте им понятный способ закончить вручную при сбое инструмента.
4. Сравните черновики, прежде чем разрешать запись. Попросите одного проверяющего оценить результаты по одним критериям. Записывайте ссылки на чужие задачи, устаревшие факты и выводы без подтверждения. Прежде чем разрешить ассистенту обновлять настоящий трекер, добавьте предварительный просмотр, согласование и сохраняемый журнал.
5. Посмотрите, какая работа переехала. Сравните принятые результаты, время проверки, активное использование и реальные счета. Добавьте обслуживание машин, простои и обновления коннекторов. Учтите личную помощь с настройкой. Если приложение начинает работать после десяти минут инструктажа каждого пользователя, у внедрения всё равно есть стоимость.

Если у вас уже есть локальная модель для разработчиков, проведите тест на фоне обычной нагрузки. Очередь растёт, когда несколько человек начинают работать одновременно. Сервис, быстро отвечающий на один запрос, всё равно может заставить троих ждать. Для срочных задач предусмотрите видимый статус и возможность вернуться к обычному ручному процессу. Так пилотом можно пользоваться, пока команда выясняет, где проходит граница подходящей нагрузки.

Приложение к работе Grayhat даёт масштаб для сравнения. На компьютере с инструментами было 16 ГБ оперативной памяти, а отдельная машина для инференса получила 32 ГБ и RTX 4080 с 16 ГБ видеопамяти. По мере прояснения операционных требований команда добавила мониторинг сети, планирование и источник бесперебойного питания. Эти сведения полезны для бюджета пилота. Они показывают, чего требует сервис, от которого зависят коллеги, помимо получения ответа от модели.

Решите, где провести следующий час работы с ИИ

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

Источники

• Препринт Grayhat Developers от 5 ноября 2026 года
• Полный текст, включая оценки нагрузки, инфраструктуру и рисунок 2
• Исходное изображение рисунка 2
• Лицензия CC BY 4.0 на рисунок из статьи

---

Чтобы сохранять обсуждения, на которых основана передача работы, и находить их через поиск, создайте аккаунт в Telli.sh.