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