Разработка в разы быстрее: новая экономика IT-бизнеса
Интервью о платформе управляемой AI-разработки
Кучулин Сергей, Генеральный директор АйТи-Баланс: «Рынок насытился агентами, которые помогают быстрее генерировать код. Настоящий дефицит – в управляемости: чтобы у каждого изменения были требование, тест и документация. Мы собрали это в нативной платформе управляемой AI-разработки. На референс-проекте в компании с оборотом 207 млрд рублей мы получили минус 70% трудозатрат на документацию и разработку, а в общем реализовали продукт втрое быстрее плана. Но главное – не магия AI, а правильный инженерный процесс: человек принимает решения, агенты делают рутину. Поэтому предлагаем не верить на слово, а измерить эффект на одной команде за 4–6 недель».
1. Тренды: рынок перестал покупать «магию»
– Сергей, если смотреть на рынок AI-разработки за последние два года, что изменилось по-настоящему, а что оказалось иллюзией?
– Иллюзия – это идея, что достаточно дать разработчикам доступ к модели, и производительность вырастет сама. Первые полгода все покупали «автодополнение кода» и ждали чуда. Чудо не случилось: агенты действительно существенно ускоряют генерацию кода, но это 15–25% от цикла, а не 2–3 раза.
Настоящее изменение глубже. AI перестает быть инструментом отдельного разработчика и становится участником процесса. В мировой практике это оформилось в spec-driven development: сначала спецификация, из неё – код, тесты и документация, и всё это связано между собой. Kiro от AWS, GitHub Spec Kit, Devin и аналогичные решения – это уже не автокомплит, а попытка перестроить сам цикл разработки. Направление стало мейнстримом. Вопрос только в том, кто и как реализует его в российском контуре.
– Почему агенты не дали обещанного роста? Ведь код пишется быстрее.
– Потому что узкое место не там. Посмотрите на реальный цикл: согласовать требования, описать их, спроектировать, написать код, покрыть тестами, собрать документацию, сдать. Код – далеко не самая длинная часть. Дольше всего команда ждёт решения, переписывает требования и догоняет документацию перед приёмкой.
Представьте, что вы ускорили конвейер на одном участке, а перед ним стоит приёмщик, который проверяет каждую деталь вручную. Вы получите не больше готовой продукции, а больше деталей в очереди. Именно это и произошло со многими внедрениями: код появляется быстрее, а узкое место – требования, тесты и документы – осталось прежним.
– И что, по-вашему, должно измениться?
– Ответственность и прослеживаемость. У каждого изменения в коде должно быть требование, из которого оно родилось, тест, который его проверяет, и документ, который его описывает. Не потому, что этого хочет аудит, а потому, что иначе AI-разработка превращается в фабрику непроверенных изменений.
Когда эта связка есть, AI можно пускать дальше, чем в набор кода: в анализ требований, проектирование, генерацию тест-кейсов, подготовку документации. И вот тогда экономика команды меняется по-настоящему.
– То есть команды не исчезнут?
– Роли не исчезают – меняется то, на что уходит время. Аналитик перестаёт быть машинистом по написанию ТЗ и становится человеком, который формулирует требование и проверяет черновик. Разработчик меньше занимается обвязкой и больше – архитектурой и сложными задачами. Тестировщик проектирует покрытие и разбирает нестандартные сценарии. Технический писатель владеет стандартом и верифицирует подготовленное агентом.
Компании, которые попробовали просто «сократить всех, кого заменит AI», обычно через полгода нанимают людей обратно. А компании, которые перестроили процесс, обнаруживают, что та же команда закрывает больше задач. Это и есть настоящий эффект.
2. АйТи-Баланс: от методологии к продукту
– Почему АйТи-Баланс вообще занялась этой темой? Вы ведь известны как разработчик высоконагруженных систем.
– Именно поэтому. Больше десяти лет мы делаем системы, где цена ошибки и цена простоя высокая. И все эти годы мы боролись с одной и той же проблемой: документация отстаёт от кода, требования теряются, приёмка превращается в археологию. AI-ассистенты эту проблему не решали – они ускоряли только ту часть, которая и так была не самой медленной.
Мы начали не с продукта, а с методологии. Собрали процесс от требования до эксплуатации, разложили его на этапы, для каждого определили, что делает агент, что проверяет человек и какой документ должен появиться на выходе. Сначала обкатали это на себе, потом на реальном проекте с внешним заказчиком. И только после того, как получили измеримый результат, упаковали в платформу.
– В чём отличие от «мы сами соберём такое на open-source»?
– Собрать можно. Вопрос – сколько это стоит и что вы получите в итоге. Обычно на это уходит от шести до двенадцати месяцев, выделенная команда и несколько итераций, после которых остаётся пилот одного энтузиаста, который не масштабируется на организацию.
Мы продаём не промпты и не сборку. Мы продаём готовый процесс, проверенный на практике, и доводим до первой цифры за 4–6 недель. Плюс есть вещи, которые в самостоятельном подходе всплывают поздно: связь требований с кодом и тестами, шаблоны под ГОСТ или внутренние регламенты, разграничение доступа, работа с моделью внутри контура. Это не самая интересная часть, но именно она определяет, доживёт ли инициатива до тиража.
– Вы называете решение «нативной платформой управляемой AI-разработки». Что это значит на практике?
– «Нативная» – значит, AI встроен в каждый этап, а не приделан сбоку к трекеру. «Управляемая» – значит, человек остаётся в контуре на каждом решении: агент готовит черновик, инженер проверяет и утверждает. Платформа не выпускает изменения в продакшен сама.
И ещё одна часть, без которой всё рассыпается, – документация. Она формируется вместе с работой, а не пишется после сдачи. К приёмке у вас уже есть комплект документации на систему, соответствующий вашему регламенту: требования и критерии, проектные решения, тест-кейсы, руководство пользователя и т.д. Это не отчёт «для галочки», а приятный бонус (продукт) нормально выстроенного процесса.
3. Кейс: цифры, которые считали вместе с заказчиком
– Расскажите про референс. Что это была за компания и что именно вы делали?
– Крупный игрок в дистрибуции и логистике: оборот 207 млрд рублей, более 10 тысяч сотрудников, ИТ-отдел – 260 человек. Мы работали на проекте по созданию CMS-системы, команда – четыре разработчика, аналитик и тестировщик. Замеряли два месяца: сначала как есть (план), потом – как стало (факт).
Это не лабораторный эксперимент. Это живой проект с живыми сроками, где мы сравнивали плановую оценку трудозатрат с фактом и считали результат совместно с заказчиком.
– Какие цифры получились?
– Трудозатраты на документацию – минус 70%. Время на анализ и детализацию требований – минус 50%. Продукт вывели примерно втрое быстрее относительно плана. И команде для этого понадобилось в полтора раза меньше людей, чем предполагалось изначально.
Сразу оговорюсь: это первый замер, а не отраслевая статистика. Одна компания, одна команда, один проект. Мы специально не округляем это до «все получат 300%». Но даже если у вас эффект будет вдвое скромнее, экономика уже меняется.
– −70% на документации звучит как маркетинг. Как вы это посчитали?
– Считали не «объём текста», а часы. Сколько времени аналитик, разработчик и тестировщик тратят на подготовку и переписывание документов до и после внедрения. План против факта, по одним и тем же работам. Замер делали вместе с заказчиком, чтобы цифра не была нашей внутренней оценкой.
И это, кстати, самый частый вопрос на встречах. Поэтому мы предлагаем не верить нам на слово, а провести пилот на вашей команде и зафиксировать критерии успеха до старта. Если эффект есть – вы это увидите в цифрах, а не в наших слайдах.
– Что оказалось самым сложным? Не сопротивление ли людей?
– Самое сложное – не технология. Технология как раз работает. Сложно менять привычку: «все сделаю сам, напишу код, потом как нибудь опишу….». Мы переворачиваем порядок: сначала требование и критерий приёмки, потом код с помощью агента, а специалист проводит ревью и формирует правила, по которым работает агент. Для опытного разработчика это поначалу выглядит как бюрократия.
Поэтому внедрение – это всегда работа с людьми: показать на их же задачах, что новый порядок экономит им время, а не отнимает. Когда разработчик видит, что получает управляемый результат, документация собралась сама, а на приёмке не нужно ничего досочинять, сопротивление исчезает за пару недель.
– «В полтора раза меньше команды» – это же про сокращения?
– Это про то, что ту же работу закрывает меньший состав. Заказчик не увольнял людей – он не нанимал дополнительных под тот же объём. Для бизнеса это разница между «нанять ещё трёх человек на год» и «вывести продукт текущей командой».
Рынок труда в ИТ не станет сильно дешевле. Поэтому единственный устойчивый способ масштабировать разработку – поднимать выработку существующей команды, а не только докупать людей.
4. Платформа: что покупает заказчик и с чего начать
– Итак, ваша платформа управляемой AI-разработки, что конкретно получает компания?
– Платформу, которая ставится в ваш контур, набор AI-агентов на каждый этап, шаблоны документов под ваш стандарт/ГОСТ, регламенты процесса и внедрение с обучением. Плюс интеграции с тем, что у вас уже есть: Jira или YouTrack, Git, документооборот. Мы не заставляем переезжать в наш ландшафт – мы встраиваемся в ваш.
Дальше команда работает как обычно, только на каждом шаге у неё есть агент, который готовит черновик, и человек, который принимает решение. Документы появляются по ходу, а не в конце.
– Насколько это безопасно? Наши данные не уйдут наружу?
– Продуктивные данные вообще не участвуют в процессе – они остаются в вашем внутреннем контуре при любом варианте. Выбор касается только кода. Есть три формата: облако – быстрый старт, приватное облако на площадках Sber, Selectel или Т1 с юридической гарантией поставщика, и локальное развёртывание, когда модель работает на вашем оборудовании и код его не покидает.
Для регулируемых отраслей и строгих требований ИБ имеет смысл локальный вариант. Для пилота и средней команды – облако или приватное облако. Архитектуру работы с данными мы фиксируем в security-паспорте до старта, а не после.
– С чего начать и как не купить «кота в мешке»?
– Начинать мы рекомендуем с пилотного внедрения нашей платформы на одной команде и одном проекте. Оптимальный вариант – отдельный проект, который в обычных условиях планировался бы к реализации за 3–4 месяца командой из 5–7 специалистов. Уже на старте фиксируются критерии успеха: например, сокращение трудозатрат на подготовку документации и разработку не менее чем на 40%. Это консервативный ориентир, основанный на нашем практическом опыте.
После завершения пилота мы повторно измеряем ключевые показатели и готовим отчёт об экономическом эффекте и ROI. Такой подход позволяет проверить результат на реальном проекте и собственной команде, оценить окупаемость решения и принять обоснованное решение о масштабировании.
Таким образом, вместо того чтобы покупать «кота в мешке», компания получает возможность проверить эффективность AI-разработки на практике, с понятными критериями успеха и контролируемыми первоначальными вложениями.
– И последний вопрос: что будет через год? AI-разработка станет нормой или останется экспериментом?
– Нормой станет не «использование AI», а управляемая разработка с AI внутри. Разница принципиальная. Эксперименты заканчиваются, когда заканчивается бюджет на энтузиазм. А норма закрепляется, когда у процесса есть владелец, метрики и предсказуемая экономика.
Через год я ожидаю, что в большинстве крупных компаний появится обязательный контур разработки, где требования, код, тесты и документация связаны, а AI-агенты работают на каждом этапе под контролем инженера. Кто-то придёт к этому сам за год-полтора, кто-то – с готовой платформой за несколько недель. Мы предлагаем второй путь: измерить эффект на одной команде, получить цифру и уже потом решать, тиражировать или остановиться.
– Спасибо. Где читателям узнать подробности?
– На сайте, там же калькулятор ROI: можно подставить размер команды и зарплаты и увидеть окупаемость на своих цифрах. Если хотите не расчёт, а замер на реальном проекте – напишите на sales@intec-balance.ru, обсудим пилот за 30 минут.
