ИИ в разработке продукта: что это меняет для бизнеса

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

4 мин

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

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

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

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

Почему термин AI-PDLC вообще появился. Чтобы отличить перестройку всего процесса создания продукта от простой замены инструмента внутри старого процесса. PDLC — это весь путь от задачи клиента до эксплуатации, шире чем разработка.

Три уровня зрелости и чем они отличаются

5 мин

Между «у нас есть ИИ» и «у нас перестроен процесс» лежат три разных состояния. Их полезно различать, потому что подрядчики и вендоры называют словом «ИИ» любое из них, а стоят и дают они совершенно разное.

Уровень первый: ассистент. Разработчик пишет код, модель подсказывает. Процесс не меняется, роли не меняются, документы не меняются. Эффект локальный и измеряется в скорости набора.

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

Уровень третий: агент ведёт единицу работы. Модель готовит план, человек его утверждает, агент исполняет, проверки идут автоматически. Здесь появляются понятия, которых в старом процессе не было: права агента, след его действий, комплект доказательств готовности. Именно этот уровень описывает методология AI-DLC, опубликованная AWS в 2025 году с тремя фазами — замысел, построение, эксплуатация.

Как понять, где вы или ваш подрядчик. По одному вопросу: что произойдёт, если изменить требование? Если правят код — первый уровень. Если правят спецификацию и перегенерируют — второй. Если при этом ещё и проверки прогоняются сами и блокируют выпуск — третий.

Что показывают данные, а не обещания

7 мин

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

Ощущения расходятся с измерениями. В июле 2025 года METR опубликовала результат контролируемого эксперимента: опытные разработчики, работавшие в знакомых им проектах, с ИИ-инструментами выполняли задачи примерно на девятнадцать процентов медленнее. При этом сами они после эксперимента оценивали, что стали на двадцать процентов быстрее. Разрыв в сорок процентных пунктов между ощущением и фактом — главное, что стоит запомнить.

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

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

Как этим пользоваться в переговорах. Не как аргументом «ИИ не работает». А как основанием для вопроса: что у вас устроено так, чтобы ускорение не превратилось в нестабильность. Ответ на этот вопрос отличает зрелого подрядчика от продавца хайпа.

Куда на самом деле уходят деньги

5 мин

Самая частая ошибка бюджета — заложить только подписки. В реальности расходы делятся на три части, и заметная в счёте оказывается наименьшей.

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

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

Время людей на переучивание. Первая команда, которая переходит, какое-то время работает медленнее обычного. Это не признак провала, это цена входа.

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

Контроль: права, след, откат

6 мин

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

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

След действий должен быть пригоден для разбора. Не «логи есть», а: видно, что было предложено, кто утвердил, на каком шаге проверка не сработала. Без этого разбор инцидента превращается в спор.

Откат должен быть проверен на живой системе. Не описан в документе, а испытан. Это то место, где спецификация не помогает: возможность вернуться назад — свойство того, как устроена выкатка.

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

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

Данные, безопасность и требования регулятора

5 мин

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

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

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

Локальные требования к хранению. В нашем регионе часть данных обязана оставаться внутри страны, и это ограничение проектируют до выбора инструмента, а не после. Формулировка «данные обрабатываются в облаке поставщика» в предложении — повод для отдельного разговора, а не мелкий пункт.

Требования безопасности как исполняемые проверки. Правило, записанное в документе, при коротком цикле не соблюдается. Работает только то, что встроено в конвейер и останавливает выпуск.

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

Что происходит с людьми и ролями

6 мин

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

Что уходит. Написание типового кода, первичная документация, черновики тестов, разбор незнакомого кода. Всё, что было механическим наполнением уже принятого решения.

Что появляется. Вычитка требований, проектирование проверок, оценка предложенных планов, разбор поведения агентов в работе. Это работа более высокой квалификации, а не более низкой.

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

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

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

Как считать эффект и не обмануть себя

5 мин

Главная опасность в измерениях — показать одну красивую цифру. Скорость без стабильности всегда выглядит как успех, ровно до первого разбора инцидента.

Держите показатели парами. Скорость выпуска — вместе с долей неудачных изменений. Число закрытых задач — вместе с объёмом переделок. Сокращение времени разработки — вместе с временем восстановления после сбоя. Любая одиночная цифра в этой теме вводит в заблуждение.

Четыре базовых показателя доставки. Частота выпусков, время от готового изменения до работы у клиента, доля изменений, приведших к сбою, и время восстановления. Это отраслевой стандарт, он понятен обеим сторонам и его трудно подделать.

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

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

Первый измеримый результат — не ускорение. Через месяц у вас будет две вещи: список контролей, которые не сработали, и цена прохода задачи. Ускорение на уровне сроков выхода появляется позже, потому что упирается в согласования и релизные окна, которых никто не трогал.

Что делать: заказчику, подрядчику, руководителю

6 мин

Три разные позиции — три разных первых шага. Общее одно: начинать с одной настоящей задачи, а не с презентации и не с перерисовки оргструктуры.

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

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

Если вы руководите командой. Одна команда, добровольно, одна задача из обычного плана. Заранее согласитесь, что эта задача пойдёт медленнее обычного — это плата за то, чтобы найти дыры на одной задаче, а не на всём портфеле.

Что должно получиться через квартал. Не ускорение, а два документа: перечень контролей, которые не сработали, и измеренная стоимость прохода задачи. С ними можно идти к руководству. Без них разговор неизбежно сведётся к спору о том, хайп это или нет.

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