Искусственный интеллект ускоряет разработку, но вместе со скоростью растёт цена неверно поставленной задачи. Чем быстрее команда превращает требования в код, тем важнее заранее проверить бизнес-логику, ограничения и критерии результата.
Код действительно становится дешевле — но не весь проект
Мы уже видим, что ИИ снижает трудоёмкость части разработки. Разработчик тратит меньше времени на разбор существующего кода, типовые фрагменты реализации, подготовку тестов и черновой документации. Часть задач удаётся выполнять быстрее и меньшим составом.
Когда мы говорим, что код становится дешевле, речь именно об этом: на его производство и связанные с ним рутинные операции требуется меньше человеко-часов. Но это не значит, что вместе с кодом так же заметно дешевеет весь проект.
Архитектуру всё равно нужно продумать, интеграции — спроектировать и проверить, права доступа — определить, данные — перенести без потерь. В сложных корпоративных системах остаётся большой объём работы, который нельзя свести к генерации кода.
У коллег по отрасли есть более заметные примеры: задачи, для которых раньше требовалась команда примерно из десяти человек и несколько месяцев работы, сейчас в отдельных случаях выполняют втроём и примерно вдвое быстрее. У нас динамика та же: ИИ снимает часть рутинной нагрузки, но не заменяет решения, от которых зависит устройство системы.
Узкое место смещается к постановке задачи и проектированию
На наших проектах это уже хорошо заметно. Код можно получить быстрее, а вот понять, какой именно код нужен быстрее получается далеко не всегда. До реализации всё равно приходится разобраться в бизнес-процессе, снять противоречия и принять решения, которые модель не может принять за заказчика.
Допустим, компания хочет автоматизировать согласование заявки. Собрать форму и базовый сценарий сегодня несложно. Но сначала нужно определить, откуда система берёт исходные данные, кто имеет право их менять, что происходит при сбое внешней системы, какие действия нужно сохранять для аудита и где проходит граница ответственности между несколькими системами.
ИИ может предложить вполне разумный вариант. Разработчик тоже может сделать логичное предположение. Но ни то ни другое не гарантирует, что предположение соответствует реальному процессу компании. Если такой вопрос не прояснить, неверная логика довольно быстро попадёт не только в код, но и в тесты, интеграции и документацию.
ИИ может быстро оформить требования, но не может сформировать их за бизнес
Меняются и границы ролей внутри команды. Разработчик с помощью ИИ может сам быстрее разобрать исходные материалы, подготовить прототип, черновик требований, описание API или документацию. Меньше времени уходит на рутину и на пересказ одной и той же задачи от одного специалиста другому.
Но между оформить требования и сформировать их есть принципиальная разница. Инструменты искусственного интеллекта хорошо структурируют уже имеющуюся информацию. Они могут превратить заметки встречи в список требований, пользовательские сценарии или критерии приёмки. Они же способны заметить противоречия и предложить варианты решения. Но выбрать вариант за бизнес они не могут.
Если два подразделения по-разному понимают один процесс, сначала нужно договориться между собой. Если одни и те же данные хранятся в нескольких системах, кто-то должен решить, какая из них считается основной. Если не определено, кто вправе отменить операцию после проведения платежа, более подробная спецификация сама по себе проблему не устранит.
Поэтому ИИ снижает трудоёмкость оформления требований, но не снижает автоматически трудоёмкость понимания задачи. На фоне ускорившейся реализации эта разница становится особенно заметной.
Почему быстрый прототип иногда вводит в заблуждение
Заказчики тоже начинают активно использовать ИИ и самостоятельно собирать прототипы: формы, личные кабинеты, небольшие внутренние сервисы. Для проверки гипотез это полезно — рабочий сценарий можно получить быстро и без больших затрат.
Но вместе с этим меняется и восприятие самой разработки. Если представитель компании за вечер собрал работающий прототип, у него закономерно возникает вопрос: почему подрядчику на полноценную систему нужны месяцы работы и совсем другой бюджет?
Коллеги по рынку уже сталкиваются с такими ситуациями. Топ-менеджер крупной компании самостоятельно собирает прототип личного кабинета, а затем использует этот опыт в переговорах с подрядчиком: если первый результат появился за вечер, что именно занимает столько времени в промышленной разработке? Иногда это становится и аргументом для снижения цены.
Проблема в том, что сравниваются разные объёмы работы. В прототипе достаточно показать основной сценарий. В промышленной системе нужно ещё решить, как хранить данные, разграничивать доступ, переживать сбои интеграций, работать под реальной нагрузкой и сопровождать решение после запуска.
Поэтому быстрый прототип — не доказательство того, что весь проект прост. Это способ дёшево проверить гипотезу до того, как команда начнёт строить вокруг неё полноценную систему.
Когда ошибка в требованиях действительно становится дороже
Сама по себе высокая скорость разработки не делает ошибку дороже. Иногда всё происходит наоборот: прототип помогает быстро понять, что гипотеза неверна, и отказаться от неё до серьёзных затрат. Риск появляется тогда, когда непроверенное предположение принимают за подтверждённое требование и используют как основу для следующих этапов.
Представим, что при автоматизации расчёта неверно определили одно бизнес-правило. На его основе подготовили спецификацию и написали код. Если тесты тоже строятся на той же спецификации, они могут успешно проходить: реализация делает именно то, что в них заложено. Затем та же логика попадает в интеграцию и документацию.
При сверке с реальным бизнес-процессом может выясниться, что само исходное правило было неверным. И тогда исправлять приходится уже не одну формулировку в ТЗ, а связанные сценарии, код, тесты, интеграции, а иногда и данные.
В этом и заключается новый риск: ИИ способен быстро масштабировать не только правильное решение, но и ошибочное исходное предположение. Цена такой ошибки зависит от того, когда её обнаружили и сколько частей системы уже построено вокруг неверной логики.
Что нужно выяснить до того, как ускорять реализацию
Не всю неопределённость нужно устранять заранее. Расположение элементов интерфейса, тексты, навигацию или отдельные UX-гипотезы часто выгоднее проверить на прототипе.
Но есть вопросы, которые не стоит оставлять модели или разработчику на усмотрение. Перед реализацией мы бы рекомендовали проверили пять вещей.
1. Что должно измениться после запуска?
Не просто «нужен личный кабинет», а конкретный результат: например, клиент сможет самостоятельно выполнить операцию, ради которой сейчас обращается к менеджеру.
2. Какие бизнес-правила нельзя трактовать по-разному?
Особенно это касается расчётов, денег, обязательств, прав доступа, согласований и исключений из основного сценария. Команда должна понимать, где она может принять рабочее решение сама, а где любое предположение нужно согласовать.
3. Откуда берутся данные, и кто за них отвечает?
Если одна и та же информация находится в нескольких системах, нужно заранее решить, какая из них считается основной и откуда должны приходить изменения.
4. Где проходят границы системы и какие ограничения влияют на архитектуру?
Важно понимать, что делает новый компонент, а что остаётся на стороне CRM, ERP или других сервисов. Здесь же нужно зафиксировать критичные требования к нагрузке, безопасности, доступности, восстановлению и аудиту.
5. Как будет проверяться результат?
Нужны два уровня проверки. Первый — критерии приёмки: система делает именно то, о чём договорились. Второй — эффект для бизнеса: например, сократилось время операции, исчезла ручная работа или снизилось количество ошибок.
Если ответы на эти вопросы остаются неопределёнными, ИИ не устраняет проблему. Он просто помогает быстрее зафиксировать непроверенные предположения в реализации.
Чем быстрее появляется код, тем важнее решения до него
Ускорение разработки меняет не только работу программиста, но и требования к управлению проектом. Чем меньше времени занимает производство очередной версии решения, тем важнее понимать, какие вопросы можно проверить экспериментом, а какие нельзя отдавать в реализацию без однозначного ответа.
Для сложной корпоративной системы ценность всё меньше определяется количеством написанного кода. Гораздо важнее вовремя найти противоречие, определить источник данных, договориться о бизнес-правиле или увидеть архитектурное ограничение до того, как вокруг ошибочного решения появятся код, тесты и интеграции.
Поэтому главный вопрос для заказчика теперь звучит не только так: как быстро команда сможет реализовать задачу? Не менее важно другое: достаточно ли хорошо мы понимаем задачу, чтобы действительно выигрывать от этой скорости?
