Поисковый интерес к ChatGPT в IT-нише остаётся одним из самых высоких среди запросов про инструменты разработки. За формулировкой «как пользоваться GPT» почти всегда стоит практический вопрос: где модель ускоряет работу инженера, а где она уже часть продукта для заказчика. В OtherCode мы разделяем эти два контура явно — иначе секреты, галлюцинации и «красивый, но неверный» код попадают в production быстрее, чем команда успевает их поймать.
Ниже — как мы встраиваем генеративный ИИ в повседневный процесс студии и в продукты вроде Content Factory и URAP, какие политики действуют без исключений и что делаем, когда доступ к OpenAI или Google ограничен.
Почему ChatGPT стал «поиском №1» у разработчиков
Для инженера LLM закрывает три привычных сценария:
- Быстрый справочник — синтаксис API, сравнение подходов, черновик SQL или regex.
- Редактура мысли — превратить черновик ТЗ, ADR или письма заказчику в связный текст.
- Черновик артефакта — тест-план, чеклист ревью, описание эндпоинта по уже существующему коду.
Это не замена разработке с AI как инженерной дисциплине. Это ускорение первого черновика. Ценность появляется, когда вокруг модели есть процесс: кто проверяет, куда нельзя слать данные, какой критерий «готово».
| Сценарий | Что даёт LLM | Что обязательно делает человек | |----------|--------------|--------------------------------| | Черновик PR-описания | Структура, список изменений | Факты по диффу, риски, ссылки на тикеты | | Спецификация API | Таблицы полей, примеры JSON | Инварианты домена, коды ошибок, ACL | | Тест-кейсы | Покрытие happy-path и edge | Реальные фикстуры, негативные сценарии | | Контент для сайта | Черновик секции, FAQ | Факты о продукте, тон бренда, SEO-проверка | | Разбор стека ошибок | Гипотезы причин | Воспроизведение, логи, фикс в репо |
Как OtherCode использует GPT во внутреннем процессе
Черновики code review
Ревьюер вставляет в промпт обезличенный дифф (без URL staging, без токенов, без имён внутренних хостов) и просит модель:
- перечислить потенциальные баги по категориям (null, race, ACL, N+1);
- отметить места без тестов;
- предложить вопросы автору, а не готовый вердикт «approve».
Ответ модели — вход для человека. Финальный комментарий в GitLab всегда пишет инженер. Мы сознательно не подключаем авто-approve по LLM: модель хорошо находит «запахи», плохо оценивает доменные инварианты промышленных и финансовых контуров.
Спецификации и онбординг
Для новых модулей (например, очередной пайплайн в Synapse Stream или экран в Diom на Flutter) LLM помогает собрать черновик:
- список пользовательских сценариев;
- таблицу состояний UI;
- черновик OpenAPI по уже существующим хендлерам.
Дальше документ проходит через техлида. Если модель «додумала» поле, которого нет в БД, это видно на ревью спецификации — дешевле, чем на ревью кода.
Контент и документация
Студийный блог, релизы, внутренние runbook’и: LLM ускоряет структуру и формулировки. Фактическую часть (стек проекта, метрики, имена продуктов) держим в коротком brief, который готовит человек. Content Factory как продукт как раз автоматизирует похожий цикл для заказчиков: генерация → проверка → публикация по правилам, а не «один промпт = готовая статья в прод».
Где LLM уже в продуктах, а не только в чате
Content Factory
Контур генерации контента опирается на API моделей: шаблоны промптов, роли (черновик / редактор / модератор), очередь задач, журнал версий. Человек или правило заказчика утверждает публикацию. Без human-in-the-loop модель легко уходит в тон, который бренд не готов защищать публично.
URAP AI (OCR / NLP)
В URAP генеративные модели не «угадывают документ целиком». Типичный путь:
- Классический OCR / детекция зон.
- Структурирование полей правилами и классификаторами.
- LLM — для нормализации формулировок, сопоставления синонимов, черновика ответа оператору.
- Валидация JSON-схемой и ручная правка на спорных полях.
Так мы снижаем галлюцинации: модель работает в узком окне ответственности, а не как единственный источник истины по юридически значимому документу. Подробнее про контур распознавания — в материале про Python OCR и распознавание документов.
Что намеренно не отдаём LLM
| Контур | Почему без генеративной модели «на кнопке» | |--------|---------------------------------------------| | Команды SCADA / Galvatec / Typhoon (STM32) | Цена ошибки — оборудование и безопасность | | Платёжные списания | Идемпотентность и аудит важнее скорости | | Автопубликация без модерации | Репутационный и правовой риск | | Прямой SQL на prod по тексту пользователя | Инъекции и утечки данных |
Для промышленных проектов (Galvatec, Typhoon) генеративка может помочь инженеру написать черновик драйвера или тест, но прошивка и команды на устройство проходят через ревью, стенд и регламент заказчика.
Политики: без них ChatGPT в компании — дыра
1. Секреты не в промптах
Запрещено: API-ключи, строки подключения, дампы prod, персональные данные клиентов, внутренние IP и hostname’ы self-hosted инфраструктуры. Для разбора инцидента — синтетические логи или маскирование. Pre-commit и обучение команды важнее любого «удобного» плагина.
2. Human review на всём, что уходит наружу
Код в merge request, текст заказчику, конфиг CI, Dockerfile — всё проходит глаза инженера. Модель ускоряет черновик; ответственность остаётся у автора MR. Это согласуется с нашей практикой скорости разработки с AI: ускорение измеряем до зелёного CI и принятого ревью, а не до первого сгенерированного файла.
3. Корпоративные endpoint’ы и настройки retention
Где доступен корпоративный контракт с отключённым обучением на данных — используем его. Для критичных контуров заказчика предпочитаем self-hosted или on-prem модели (см. также выбор провайдеров в смежных статьях блога).
4. Версионирование промптов в продуктах
В Content Factory и URAP промпты — артефакты репозитория: diff, review, откат. «Поправили в админке на лету» без аудита — путь к регрессии качества, которую невозможно воспроизвести.
Когда Google / OpenAI недоступны: российский и нейтральный контур
Ограничения доступа к зарубежным сервисам — рабочая реальность. Для студии и заказчиков это означает:
- дублирование маршрута на YandexGPT / GigaChat / локальные open-weight модели для внутренних задач;
- не строить критичный CI только на облаке одного зарубежного провайдера;
- документировать fallback в runbook: что делать, если API недоступен сутки.
Практику альтернатив инфраструктурным сервисам мы разбирали отдельно: Google-сервисы в России и альтернативы. Для LLM логика та же: абстракция провайдера, кэш ответов где уместно, возможность сменить модель без переписывания продукта.
Наши Next.js-сайты и GitLab CI живут на self-hosted инфраструктуре студии именно затем, чтобы зависимость от внешнего SaaS не останавливала релизы, даже если завтра снова «отвалится» конкретный AI-endpoint.
Как выглядит рабочий день с LLM в OtherCode
Утром инженер открывает тикет и, если задача хорошо описана, просит модель набросать план изменений по уже существующим файлам в репозитории — без доступа к prod. План сверяется с техлидом на сложных модулях (Synapse Stream, прошивочный контур). Дальше код пишется вручную или с автодополнением; модель помогает закрыть boilerplate.
Перед обедом типичны два сценария: (1) черновик описания MR и списка рисков по диффу; (2) генерация негативных тест-кейсов по OpenAPI. После обеда — ревью чужого MR: модель даёт список вопросов, человек отбирает релевантные и пишет комментарии в GitLab. В конце дня Content Factory или маркетинговый Next.js-сайт может получить черновик секции, который редактор правит по брендбуку.
Отдельно от «дневного чата» живут ночные и фоновые джобы: пакетная нормализация полей в URAP, очереди генерации в Content Factory. Там нет интерактивного ChatGPT — только API, схемы, ретраи и алерт при росте доли ручных правок.
Бюджет токенов и экономика
Без учёта стоимости команда быстро упирается в сюрприз в счёте провайдера. Мы разделяем:
| Бюджет | Назначение | Контроль | |--------|------------|----------| | Dev seats | Cursor / чат инженеров | Лимит на человека, запрет bulk-дампов | | Product API | URAP, Content Factory | Квота на проект, кэш, max tokens | | Spike / R&D | Пилоты новых моделей | Временный ключ, отдельный billing tag |
Для продуктов считаем не «токены ради токенов», а стоимость на успешный документ / статью с учётом ручных правок. Если правка занимает столько же, сколько ручная работа с нуля — сценарий выключаем или сужаем роль модели.
Synapse Stream, Diom и промышленный контур: разные роли GPT
В Synapse Stream генеративка помогает поддержке и документации: разобрать паттерн в логах, набросать раздел runbook, предложить формулировку алерта. Обработка потока данных остаётся детерминированной — предсказуемый latency важнее «умного» разбора на каждом сообщении. Подробнее о платформе — в материале про Synapse Stream.
В Diom (Flutter) модель ускоряет вёрстку экранов на компонентах дизайн-системы и черновики локализации. Сетевой слой и доменные правила пишет человек; ключи LLM на устройстве не хранятся — запросы идут через backend студии.
В Galvatec / Typhoon (STM32) допустим только off-path сценарий: помощь в написании unit-тестов прошивки на стенде, объяснение даташита, черновик таблицы регистров. Любая команда на оборудование — вне компетенции модели. Это же правило распространяется на любые SCADA-подобные интеграции.
Практический чеклист внедрения ChatGPT в команду
- Разделить «чат для инженера» и «API в продукте» — разные политики и бюджеты.
- Запретить секреты и PII в промптах; проверить плагины IDE.
- Ввести обязательный human review для кода и клиентского контента.
- Для продуктов — схема ответа, валидация, audit log, метрика ручных правок.
- Подготовить второго провайдера или локальную модель для критичных сценариев.
- Учить команду писать brief: контекст, ограничения, формат выхода — иначе модель галлюцинирует уверенно.
- Завести шаблон промпта для code review и шаблон brief для контента — меньше хаоса в чатах.
- Раз в квартал пересматривать: какие сценарии реально экономят время, какие дают только шум.
Типичные ошибки, которые мы уже видели у заказчиков
«Скормили весь монорепозиторий агенту». Контекст размывается, растёт риск утечки, качество падает. Лучше узкий @file и явная цель.
«Модель написала миграцию — сразу на prod». Без review и бэкапа. LLM не знает вашу историю данных.
«Заменили поиск по регламентам одним чатом без RAG». Ответы звучат уверенно и ссылаются на несуществующие пункты. Нужны retrieval и цитаты.
«Одинаковый промпт для OCR-полей и маркетинга». Разные temperature, схемы и пороги эскалации к человеку.
«Отключили CI, потому что агент локально зелёный». Локальный успех не равен пайплайну на чистом runner. GitLab CI остаётся контрактом.
«Даём заказчику доступ к тому же workspace, что и команде». Смешиваются секреты проектов; лучше изолированные контуры и отдельные ключи.
Как измерять пользу без самообмана
Полезный минимум метрик на 4–6 недель пилота:
- время от «задача взята» до первого осмысленного MR (не до первого файла от GPT);
- доля MR, вернувшихся с ревью на доработку из-за галлюцинаций / лишней абстракции;
- для URAP — % документов без ручной правки критичных полей;
- для Content Factory — время редактора на доведение черновика до публикации;
- инциденты, связанные с утечкой через промпт (цель — ноль).
Если метрики не двигаются, проблема обычно не в «плохой модели», а в плохом brief, отсутствии схемы ответа или в том, что задачу вообще не стоило автоматизировать. Тогда честнее вернуть процесс человеку и оставить LLM на соседнем сценарии.
Что забрать с собой
ChatGPT и другие генеративные модели в 2026 году — стандартный слой ускорения черновиков и узкий слой в продуктах с контролем качества. В OtherCode мы используем их в ревью, спецификациях, Content Factory и URAP, помогаем себе на Next.js и Flutter-задачах, но не отдаём моделям команды на оборудование, платежи и публикацию без человека. Политика «нет секретов в промптах + human review + запасной провайдер + учёт стоимости» дешевле любого инцидента с утечкой или «умной» ошибкой в проде.
Если нужно спроектировать AI-контур под ваш продукт или встроить генеративку в существующий процесс разработки без потери контроля, оставьте заявку — разберём сценарий и границы ответственности на коротком созвоне.
