# Vibe Coding под прицелом: Claude Opus 4.5 против китайского GLM-4.7 в бою за транскрибацию GigaAM

Ссылка на мой итоговый проект: https://github.com/yaruslove/DialogScribe Ссылка на модель транскрибации GigaAM https://github.com/salute-developers/GigaAM?ysclid=mkykba7jfr389110914

В нашей компании каждую неделю проходят десятки внутришних синхров и встреч с заказчиками под NDA. По согласованию сторон мы записываем эти созвоны, извлекаем аудиодорожки и прогоняем через LLM, чтобы автоматически получать чек-листы задач и протоколы. Проблема в одном: внешние сервисы транскрибации - это потенциальная утечка чувствительных данных. Когда на столе переговоры о контрактах на миллионы или внутренние roadmap'ы, отправлять записи в облако стороннему вендору даже под видом "безопасной обработки" - перебор.

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

Спойлер: с нуля до рабочего прототипа с двумя реализациями ушел один рабочий вечер.

Сейчас на рынке AI-инструментов для разработки настоящий зоопарк. Cursor, Claude Code, open-code, Windsurf, GitHub Copilot, Cline, Kilo, RooCode... каждый день появляется новый "убийца" с фичей, которая обещает кодить за тебя. Под капотом у них крутятся десятки моделей: GPT-5.2-codex, Claude 4.5 Opus, GLM-4.7, Kimi K2.5 и десяток других.

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

Промт как техническое задание. Оба проекта стартовали с одного и того же детального описания, которое я выстраивал итеративно: изучил open-source решения для транскрибации, сравнил точность моделей на русском языке и остановился на GigaAM. Прописал четкие ограничения: строгий запрет по типу - на генерацию фич вне описанного скоупа, детализировал входные форматы, ожидаемые артефакты на выходе и схематично описал архитектуру с указанием паттернов. После получения базового кода работа не закончилась. Я продолжал в режиме vibe coding: итеративно натравливал агента на найденные баги, уточнял граничные случаи и добивался, чтобы каждый проект выдавал валидный файл транскрибации без критических ошибок.

Задача была амбициозной: создать систему автоматической транскрибации аудио и видео на базе российской модели GigaAM с опциональной диаризацией спикеров через pyannote. Промпт был детализированным, с ограничениями по архитектуре, требованиями к CLI и обработке ошибок. По сути, заказ на production-ready библиотеку.

Прежде чем перейти к сравнению, нужно поговорить об слоне в комнате. Claude Opus 4.5 на момент написания статьи - это топовая модель Anthropic для сложных задач программирования и архитектурного проектирования. Но есть нюансы.

Цена вопроса. На OpenRouter токены Opus 4.5 стоят совершенно космических денег. Это самый дорогой вариант среди всех доступных моделей для кодирования.

Лимиты. Если покупать подписку напрямую на anthropic.com, получаешь смехотворные лимиты. Тариф Pro дает настолько скудные объемы, что при активной разработке хватает буквально на 6-7 больших промптов или 2 часа непрерывной работы в чате. После этого начинается танец с ручным обновлением страницей и ожиданием сброса квоты. Многие разработчики жалуются в сетях: привыкаешь к качеству кода, но невозможно работать в потоке, постоянно приходится считать токены, делать оптимизации, открывать новые чаты чтоб не съедать контекст.

Я решил сравнить этот "премиум" с китайским аналогом, который предлагает GLM-4.7 через офицальный сайт https://z.ai/subscribe предлагается Coding Plan.

Claude Code + GLM-4.7 - консольный агент от Anthropic, но с подменой мозгов на китайскую модель GLM-4.7 (подписка Coding Plan). Стоит в 7 раз дешевле, при этом дает в 3 раза больше лимитов на использование. Хитрая комбинация!

Cursor + Claude Opus 4.5 - IDE с нативной интеграцией, топовая подписка с флагманской моделью.

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

Плюсы есть: четкое разделение ответственности, статические методы в AudioProcessor для простоты, базовый паттерн Facade. Но проблемы серьезные. Нет контекстного менеджера в основном классе, тяжелые модели грузятся прямо в конструкторе без lazy loading, неверное именование FileNotFoundErrorCustom (конфликт со встроенным исключением). Фабричных функций для удобного создания объектов нет.

Здесь картина другая. Полноценный Facade с lazy loading через @property. Рабочий контекстный менеджер (__enter__/__exit__) с корректным cleanup GPU памяти. Есть фабричная функция create_transcriber(). Graceful degradation при отсутствии HF_TOKEN. Глобальные синглтоны для процессоров (get_audio_processor()). Минус только в том, что синглтоны усложнят юнит-тестирование, и есть небольшая избыточность в методах-алиасах.

Есть иерархия исключений с базовым TranscriberError, но всё базово. Исключения без контекста (нет пути к файлу, нет причины ошибки). Сообщения на английском, что менее информативно для русскоязычной аудитории. Критично: сохранение имени FileNotFoundErrorCustom, которое конфликтует со встроенным Python-исключением.

Совсем другой уровень. Богатый контекст в исключениях:

Есть специфичные исключения (HFTokenMissingError, FFmpegNotFoundError), инструкции по исправлению прямо в сообщении, обработка пустого аудио (EmptyAudioError). Единственный минус - все еще переопределение built-in FileNotFoundError в одном месте.

Хорошие docstrings в Google-стиле, консистентность. Но есть критический баг:

Плюс неиспользуемые импорты result и дублирование кода форматирования между models.py и formatters.py.

Чистый код, отличные type hints (включая Path | str), логические секции разделены комментариями. Критических багов не обнаружено. Минус: некоторые методы можно было бы разбить, и есть дублирование метода _resolve_device() в нескольких классах.

Базовая транскрипция audio/video, pyannote диаризация, hybrid диаризация, форматы txt/json/srt/vtt, batch обработка, CLI на click. Нет потоковой транскрипции, нет расширенных форматов вывода.

Все то же, плюс: потоковая транскрипция (transcribe_stream), дополнительные форматы (markdown, screenplay, table), фильтрация по спикеру, preload моделей для ускорения, get_model_info() для интроспекции, batch с progress callback, CLI с баннером и прогресс-баром.

Функциональный CLI с подкомандами (transcribe, batch, check), unicode-нормализация путей. Но вывод минималистичный, нет визуального прогресса, нет цвета.

Красивый баннер, emoji-статусов нет (используется текстовая индикация), цветной вывод, прогресс-бар, тихий режим (--quiet), информативная статистика. Кстати если проект или статья написанны LLM то это легко палиться если в ней есть много emoji или длинные тире «-» берите на заметку. Минус: DummyProgressBar - можно было использовать contextlib.nullcontext.

Lazy imports для torch/numpy, проверка зависимостей в check_dependencies(). Но жесткая зависимость от конкретной версии pyannote API, нет fallback при ошибках загрузки.

Попытка загрузки нескольких версий моделей pyannote, поддержка старого и нового API (token vs use_auth_token), детальные инструкции при ошибках доступа к gated models, fallback методы (_get_duration_fallback).

Жесткие зависимости усложняют мокирование, статические методы сложнее тестировать, нет dependency injection.

Dependency injection через конструктор, lazy loading позволяет тестировать без загрузки моделей, get_model_info() для проверки состояния. Глобальные синглтоны усложняют изоляцию тестов, нет интерфейсов для мокирования.

Убрать глобальные синглтоны или сделать их thread-safe

Кстати пример транскрибации с разбивкой по спикерам:

Цифры говорят сами за себя: проект на Cursor + Opus 4.5 набрал 88 баллов против 64. Он ближе к production-ready решению: лучшая архитектура с полноценным lazy loading, rich error handling с контекстом, продвинутый UX в терминале, поддержка потоковой обработки и гибкая работа с зависимостями.

Но важен другой контекст. Claude Opus 4.5 стоит в 7 раз дороже при том, что дает в 3 раза меньше лимитов. И это ощутимо: когда ты платишь за каждый токен, каждый промпт превращается в финансовое решение. GLM-4.7 при такой ценовой разнице показывает результат "удовлетворительно" и вполне может стартовать MVP.

Если бюджет не ограничен и нужен production-код с первой итерации - Cursor + Opus 4.5 остается топовым выбором для сложной архитектуры. Если нужно прототипировать быстро и дешево, не боясь потратить дневной лимит на 5 минутах работы - китайские альтернативы подбираются вплотную.

Multi-model pipeline: распределяем роли между LLM Зная ценовую диспропорцию (Opus в 7 раз дороже GLM), здравый смысл требует дифференцировать их использование. Работайте по принципу Principal vs Middle: Opus 4.5 назначьте роль архитектора - principal engineer для системного дизайна и планирования приложения, а рутинную реализацию middle и junior уровня отдавайте GLM.

Современные инструменты вроде open-code позволяют реализовать эту стратегию буквально в рамках одного проекта, переключаясь между моделями на лету: один чат-агрегатор маршрутизирует ваши запросы - от стратегического планирования кода в Opus до массовой генерации функций в GLM, сохраняя общий контекст диалога и историю изменений.

Для монструозного legacy на миллионы строк, где стандартные IDE обрезают контекст, используйте shotgun_code - инструмент, который интеллектуально упаковывает локальную кодовую базу и отправляет её напрямую в LLM API, минуя ограничения встроенных ассистентов.

Критически важен размер контекстного окна: Gemini 3 Pro предлагает 1 миллион токенов против 200k у Opus и GLM. Это позволяет выстраивать сложные цепочки: Gemini выполняет one-shot RAG, "проглатывая" огромную кодовую базу для извлечения фактов; Opus на их основе проектирует архитектуру и нарезает задачи; GLM решает их итеративно в цикле обратной связи. Такой конвейер превращает недели анализа легаси в часы работы, сохраняя бюджет на массовой разработке

В конце января 2026 года стало очевидно: индустрия пересекла точку невозрата. Лично я нахожусь в состоянии легкого шока. За один вечер я реализовал транскрибер, на который раньше ушел бы целый месяц. На выходных буквально "промтил" многостраничный фронтенд со сложной логикой, не заглядывая в документацию по TypeScript, который никогда не изучал системно. Ощущение себя киборгом со вторым мозгом, когда скорость разработки умножается на десять, а за спиной словно стоит команда архитекторов и фронтендеров, сложно передать словами.

Помните мемы в ТГ-каналах начала 2025 года про "по промтил и в прод"? Тогда vibe coding казался позорным читерством для тех, кто не умеет в Python. Сейчас, в конце января 2026-го, я как data scientist открыто заявляю: я vibe-кодер. И мне не стыдно!

Это не замена инженерному мышлению, а эволюция инструмента. Как ассемблер уступил место высокоуровневым языкам, так и написание кода строка за строкой уступает место описанию намерений. Но за этой простотой кроется сложность: нужно знать архитектуру контекстных окон, техники инжиниринга промптов, быстрые команды IDE и ограничения каждой модели. Vibe coding - это навык, которому придется учиться всем, кто хочет остаться в профессии.

При этом классические инженеры никуда не исчезнут - в cron-задачах и маркетинговых лендингах может и правда останется один архитектор с LLM, но в системах, где цена ошибки непозволительно высока, человеческий аудит останется критичным. Запуск ракет, медицинские импланты, ядро банковских транзакций - там, где баг стоит жизней или миллиардов, deep expertise и ручное ревью кода сохранятся. Однако общая потребность в «простых кодерах» явно сократится, индустрия трансформируется, и граница между разработчиком и продуктологом размоется окончательно.

А теперь вопрос к корпоративным лидерам: вы уже задумались, как внедрять эти инструменты в production? Какую LLM выбрать - одну универсальную или оркестрацию специализированных? Платить за подписку, покупать токены по API или инвестировать в свои A100? И главное - ограничится ли это ассистированием разработчиков или нужно бустить еще и аналитику, продажи?

Те, кто сейчас отвечает на эти вопросы, завтра зададут темп рынка. Остальные будут догонять, перечитывая старые мемы про "настоящих программистов".

Этот опыт совпадает с метаморфозой, которую описал Андрей Карпати. Еще осенью он скептически относился к агентам, но к концу года совершил разворот на 180 градусов, признав фазовый сдвиг: перешел от "80% ручного кода и 20% агента" к обратному соотношению, где модель пишет код, а человек только корректирует. Карпати пишет, что наблюдать, как агент 30 минут упорно решает задачу, где человек давно бы отложил проблему на потом, это ощущение присутствия AGI. Я разделяю этот восторг и тревогу: мы наблюдаем, как меняется сама природа программирования, и это одновременно вдохновляет и леденит душу.

P.S. На горизонте маячит Kimi 2.5 от Moonshot AI, которая обещает переписать правила игры в плане контекстного окна и стоимости, но в рамках этого эксперимента я ее не тестировал. Возможно, следующая битва будет еще интереснее.