Как ИИ сократил время разработки на 30–40% на видеостриминговой платформе из 1 млн+ строк: кейс 2026

Почему Фора Софт написала этот кейс

Большая часть материалов про «ИИ в разработке» — это либо вендорский маркетинг, либо тред в Twitter про сайд-проект на 200 строк. Ни то, ни другое не выживает при встрече с реальной боевой системой. Компания Фора Софт уже 21 год выпускает продукты для видео в реальном времени и AI-решения, выпустила более 625 продуктов и последние два с половиной года использует ИИ внутри постоянно работающих инженерных команд — на системах с регуляторами, платящими клиентами и SLA.

Это та статья, которой нам не хватало в 2023 году, когда каждое заявление вида «ИИ ускоряет разработку в два раза» шло без описания системы и без базовой точки отсчёта. Мы берём одну платформу — VALT, продукт для видеонаблюдения, развёрнутый более чем на 770 объектах в США — описываем её масштаб, инженерную культуру вокруг неё, изменённые рабочие процессы и реальные замеры. Цифры (ускорение на 30–40% в среднем и 70% на отдельных задачах, привязанных к контексту) получены при сравнении работы команды со включённым и выключенным ИИ-ассистентом на сопоставимых спринтах.

Если вы руководите сложным зрелым продуктом и решаете, стоит ли вкладываться в инженерию с ИИ, это честная версия ответа. Мы расскажем, где это работает, где нет и какие предусловия должны быть в кодовой базе, чтобы ИИ окупил место для Cursor или Claude Code.

Система: 12 лет в продакшене

VALT — это браузерная платформа для видеонаблюдения и записи, которой пользуются учебные лаборатории, университеты, программы по психическому здоровью, симуляционные центры и правоохранительные структуры. Операторы ведут сессии живого наблюдения с подключением до 50 HD-IP-камер на объект, разбирают записи с аннотациями, делятся ими с заинтересованными сторонами и управляют сроками хранения и правами доступа — всё в одной браузерной сессии. Сегодня систему используют более 50 000 активных пользователей на 770+ инсталляциях в США.

Кодовая база выросла примерно до 200 000 строк собственного кода внутри репозитория объёмом 1 млн+ строк (с учётом вендорских SDK, сторонних библиотек и сгенерированного кода). Стек: TypeScript и Vue.js на фронтенде, PHP с Symfony на бэкенде, Wowza Streaming Engine (Java) для видеопайплайна. RabbitMQ для событий, PostgreSQL для прикладных данных, S3-совместимое хранилище для записей.

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

Этот культурный фундамент — предусловие для эффекта, который мы описываем дальше. ИИ не починил VALT. Команда уже сделала это сама. ИИ сжал время, нужное на то, чтобы делать чистую инженерию в сложной системе.

Куда на самом деле уходило время разработки

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

Обратите внимание на распределение. Чистое написание кода — самая маленькая «ремесленная» доля. Всё, что выше, — когнитивная работа: загрузить систему в голову, найти нужный шов, предсказать побочные эффекты. Именно здесь ИИ-инженерия и даёт рычаг: когнитивные слои сжимаются, а слой набора кода остаётся примерно постоянным.

Как ИИ встроили в рабочий процесс

ИИ не был разовым пилотом. Он стал ежедневным инструментом — через агентов в редакторе (Cursor и Claude Code) и через ботов-ревьюеров в CI. Базовый набор привычек, который мы зафиксировали:

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

2. Реализация по чётко описанным тикетам. «Добавить тип устройства X с правами Y, зарегистрировать его в модуле Z, вывести в админ-интерфейс». ИИ набрасывает изменения по нескольким файлам и попутно подсвечивает возможности рефакторинга. Работа инженера превращается в ревью и подрезание — а не в поиск и ориентирование.

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

4. Документация по запросу. Сгенерировать или обновить докстринги модулей, разделы README и онбординг-материалы по актуальному коду. Команда относится к этому как к непрерывной активности, а не к ежеквартальной обязанности.

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

Конкретный пример: баг с правами на Quick Clip

Реальный тикет из VALT: «Маркеры длительности показывают кнопку Quick Clip пользователям без права Clip Right. Ожидается: пользователь не видит кнопку. По факту: пользователь её видит и при клике получает 403 unauthorized». В системе с несколькими слоями прав (роль, лицензия, фича-флаг, ACL для конкретной записи) такой баг исторически отнял бы час с лишним только на прослеживание. Классический сценарий: открыть нужный Vue-компонент, пройти по цепочке пропсов, заглянуть в резолвер прав, найти отсутствующее условие, написать исправление.

С ИИ-агентом внутри IDE цикл выглядит иначе: текст тикета плюс запрос «найди, где принимается решение о видимости Quick Clip, и скажи, какой проверки прав не хватает» дал короткий список из трёх файлов меньше чем за 60 секунд. Реально не хватало одного условия в предикате видимости, на два файла вглубь. Сквозное время фиксации, включая ручную проверку и регрессионный тест, — меньше 25 минут.

Это и есть неэффектная версия продуктивности на ИИ. Это не модель, которая пишет тысячи строк. Это модель, которая сжимает фазу «куда вообще смотреть» с 30–40 минут до 1 минуты. Повторите это на каждом баг-тикете квартала — и накопленный эффект как раз и даёт ту самую цифру в заголовке.

Измеренные улучшения по типам активностей

Мы замерили скорость по активностям на двух сопоставимых кварталах — тот же состав команды, похожий микс тикетов, отличается только наличие ИИ-инструментов. Картина устойчиво воспроизводилась у разных инженеров и на разных категориях задач.

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

Что не изменилось

Короткий, но важный раздел. ИИ не снял с инженеров VALT ответственность, и считать иначе — самый быстрый способ выкатить регресс на 50 000 пользователей.

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

Безопасность и авторизация. Потоки прав в VALT затрагивают сразу несколько слоёв: роль, лицензию, фича-флаг и ACL конкретной записи. ИИ полезен, чтобы найти существующие проверки, и опасен, когда его просят придумать новые. Каждый дифф, который касается авторизации, читается человеком построчно.

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

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

Легаси: ИИ как дешёвый онбординг

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

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

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

Стек инструментов 2026 года, на котором мы остановились

Универсальной волшебной палочки нет. Мы используем небольшой устоявшийся стек и каждый квартал переоцениваем его. Снимок того, что реально стоит на инженерных рабочих местах VALT и соседних проектов:

1. Кодовые агенты в редакторе. Cursor и Claude Code — в зависимости от предпочтений разработчика. Оба работают с проектными rules-файлами, описывающими соглашения, нейминг, запретные модули и ожидания от ревью. Этот rules-файл — самый недооценённый артефакт: он фиксирует вкус команды и за неделю экономит десятки посредственных предложений.

2. Бот-ревьюер на стороне CI. Делает первый проход по диффу: подсвечивает крайние случаи, отсутствующие тесты и отступления от стиля до того, как код увидит человек. Настроен молчать на придирки по стилю и громко сообщать о потенциальных регрессиях.

3. Длинный контекст для разовых вопросов. Когда старшему инженеру нужно понять «как X взаимодействует с Y по всей кодовой базе», мы запускаем модель с большим контекстным окном и подгружаем нужные директории. Это не постоянный режим — такой инструмент достаём один-два раза в неделю на инженера.

4. Граница приватности. Все ИИ-инструменты, работающие с продакшен-кодом, идут через корпоративные планы без удержания данных и с понятными соглашениями об их обработке. Для клиентских проектов добавляются ограничения по BAA и NDA, что ещё сужает список допустимых вендоров. Клиентский код в бесплатные тарифы моделей не попадает.

Новые виды отказов, которые приносит ИИ

Ускорение приходит со своими рисками. На командах с ИИ появилось три новых режима отказа, которых раньше не было. Каждый из них чинится — но об этом нужно знать заранее.

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

2. Эрозия знаний у джунов. Если джуны опираются на ИИ, чтобы пропустить фазу ориентирования, они быстрее набирают темп, но строят более поверхностные ментальные модели. Через двенадцать месяцев они упираются в задачу, которую ИИ не решает, и обнаруживают, что фундамент не усвоен. Совмещайте работу с ИИ с целенаправленными разборами «объясни это без ИИ».

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

Что это значит для вашего проекта

Когда Фора Софт оценивает проект, базовая планка продуктивности — это уровень с подключённым ИИ, а не уровень 2022 года. Поэтому наши сроки и бюджеты часто оказываются на 20–30% ниже, чем у крупных агентств на сопоставимом объёме. Мы не срезаем углы — мы отражаем в цене реальный объём работы.

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

Если вы выбираете партнёра по разработке в 2026 году, вопрос «вы используете ИИ в инженерии?» — не тот вопрос. Конечно используют. Правильные вопросы такие: покажите прирост скорости на реальной кодовой базе, которую вы поддерживаете, и как у вас устроена дисциплина ревью на сгенерированных диффах? Если вендор не отвечает на оба — уходите.

Пять ловушек, на которые мы наступали раз за разом

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

2. Пропускать тесты, потому что «дифф выглядит правильно». Сгенерированный код визуально создаёт впечатление, что поверхность изменения меньше, чем она есть. Применяйте к нему ту же тестовую дисциплину, что и к человеческому коду; идеально, если ИИ ещё и пишет сам тест.

3. Генерировать документацию, которую никто не проверяет. Сгенерированная документация убедительна и иногда неверна. Мы относимся к ней как к черновикам, которые человек коммитит только после чтения кода. Иначе это технический долг с дополнительными шагами.

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

5. Недооценивать rules-файл. Плохой rules-файл выдаёт складно сформулированную чушь. Хороший — фиксирует нейминг, границы модулей, запретные паттерны и ожидания от ревью. Время, вложенное в этот артефакт, окупается на всю команду.

Решающая рамка: вкладываться ли сейчас

Пять вопросов по порядку. Ответы на них показывают, имеет ли смысл вкладываться в ИИ-инженерию в этом квартале, в следующем или пока нет.

В1. Достаточно ли ваша кодовая база старая, чтобы изучение контекста доминировало? Если новый инженер тратит больше двух недель до своего первого осмысленного изменения — ответ да, и ИИ агрессивно сожмёт эту фазу.

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

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

В4. Понятны ли ваши вендоры и границы обработки данных? Клиентский код, регулируемые данные, NDA-проекты — всё это требует чистых корпоративных контрактов и гарантий отсутствия удержания. Если их нет, ограничьте ИИ внутренними инструментами, пока контракты не появятся.

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

KPI, которые стоит вывести на дашборд

Качество. Доля багов, доехавших до продакшена (баги, найденные в проде / все найденные баги), после внедрения ИИ должна оставаться плоской или улучшаться, но не ухудшаться. Покрытие тестами критичных путей — больше 75%, а сгенерированные диффы должны выходить с покрытием не ниже окружающего модуля.

Бизнес. Цикл по тикету (от «в работе» до «готово»), число тикетов на инженера за спринт и время до первого осмысленного изменения у нового сотрудника. Прирост в 30–40% виден здесь, а не в строках кода в день.

Надёжность. Частота продакшен-инцидентов, среднее время до обнаружения и среднее время до восстановления. Команда с ИИ не должна вносить больше инцидентов на релиз. Если вносит — считайте это проблемой дисциплины ревью и поправьте процесс до того, как наращивать темп.

Когда ИИ-инженерия — не та инвестиция

Короткий контраргумент. Не каждый квартал ИИ-инженерия — правильное вложение.

Если ваша кодовая база молодая (меньше 25 тыс. строк), ваше узкое место — product-market fit и интервью с клиентами, а не инженерная скорость. Вкладывайтесь туда. Если у команды плохое покрытие тестами и слабая дисциплина ревью — ИИ ускорит не то, что нужно; квартал стоит потратить на качество. Если вы работаете под ограничениями по обработке данных, которые не закрываются текущими вендорами, отложите внедрение, пока корпоративные контракты не подтянутся.

И ещё: если вы покупаете «ИИ-инженерию» как лозунг для инвесторов, вы получите лозунг, а не скорость. Цифра в 30–40% получается из ежедневной интеграции в реальные процессы, а не из пресс-релизов.

Ориентирование против набора кода: откуда берутся 70%

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

Для задачи, привязанной к контексту — например, «добавить тип устройства X с правами Y, зарегистрировать в модуле Z, вывести в админке» — до ИИ мы получали ~30 минут ориентирования и ~20 минут исполнения. С ИИ ориентирование падает до ~3 минут, исполнение — до ~12 минут. Итого: 50 мин → 15 мин, сокращение на 70%. Согнулась именно доля ориентирования.

И наоборот, на чистом наборе нового кода — разворачивании микросервиса на знакомом стеке с нуля — до ИИ это занимало ~4 часа, после — ~3,5 часа. Фаза ориентирования и так была короткой, поэтому выигрыш незначителен. Это объясняет, почему команды на гринфилд-проектах говорят «ИИ нам мало что дал», а команды, поддерживающие зрелые системы, — «ИИ изменил нам квартал». Правы и те, и другие — у них просто разный микс работ.

Что это значит для найма

Инженер, который хорошо выпускал в 2022, и в 2026 хорошо выпускает — но планка сместилась. Дифференциатор — уже не скорость печати и не знание библиотек. Это умение направлять ИИ-агента, критически читать его диффы и отказываться от неправильных предложений.

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

Другой практический эффект: джуны быстрее набирают темп на зрелой кодовой базе, потому что ИИ помогает с ориентированием, на которое раньше уходили недели. Продуктивность джунов выросла. Планка для «сениора» тоже выросла, потому что вещи, которые умеют только сениоры (архитектура, безопасность, производительность, суждение), занимают теперь бо́льшую долю работы — именно той, которую ИИ не делает.

FAQ

Заменяет ли ИИ старших разработчиков?

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

Безопасно ли использовать ИИ в продакшен-системах?

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

Где ИИ помогает сильнее всего?

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

Где ИИ буксует?

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

Улучшает ли ИИ качество кода?

Основной выигрыш — в скорости; выигрыш по качеству косвенный. Помогает более качественная поддержка ревью и более раннее выявление крайних случаев. Контр-эффект: команды, которые перестают читать диффы, потому что «выглядит правильно», получают падение качества. Итоговый эффект целиком зависит от дисциплины ревью.

Сколько нужно времени, чтобы команда реально получила свои 30–40%?

По нашему опыту — 6–10 недель ежедневного использования плюс письменный rules-файл, за который отвечает старший инженер. Команды, которые пробуют ИИ две недели и бросают, обычно бросают до того, как кривая выходит на плато. Команды, которые включают его в ежедневную привычку, видят сдвиг скорости в течение квартала.

Использовать Cursor, Claude Code или оба сразу?

В 2026 году оба заслуживают внимания; различия скорее в форме рабочего процесса, чем в возможностях. Мы даём инженерам выбирать внутри утверждённого набора — на одних и тех же корпоративных контрактах. Стандартизировать единый rules-файл важнее, чем единый редактор.

Применимо ли это к мобильной, встраиваемой или игровой разработке?

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

Что почитать дальше

Готовы получить свои 30–40% на своей платформе?

ИИ не переворачивает разработку за ночь. Он убирает трение. На системе возрастом 12 лет, объёмом 1 млн+ строк кода и с 50 000+ пользователей это трение жило в изучении контекста, расследовании багов и код-ревью — и его исчезновение дало прирост скорости команды на 30–40%. Этот прирост реальный, повторяемый и измеримый; и он же зависит от инженерной культуры, которая у вас либо уже есть, либо её предстоит выстроить.

Если вы поддерживаете или масштабируете сложную платформу — видео, коммуникации, медицину, AI-продукт — вопрос уже не в том, может ли ИИ писать код. Вопрос в том, позволяют ли ваша архитектура, тесты и дисциплина ревью получить это ускорение. Фора Софт два с половиной года оценивает и выпускает проекты от базы с подключённым ИИ. За 30 минут мы обычно можем сказать, даст ли ваша кодовая база тот же выигрыш, какие предусловия требуются и сколько будет стоить внедрение на 12 недель.