Если говориьь про внедрение ИИ в процессы разработки, то тут вектор развития направлен на то, стобы забирать рутинные задачи, которые требуют времени и при этом не имеют сложности, котррая не посильна ИИ. Примеры таких задач: 1. Автоматизация исправления багов. Был доклад, где в команде из трех человек внедрили ИИ так, чтобы он брал тикеты с багами из Jira, проверял может ои он их исправить, вносил правки в код и о правлял на ревью. Задача радработчика была проревьюить код. В итоге исправление багов стало полуавтоматическим и менее рутиным, освободив команде время на разработку новой функциональности. 2. Ревью кода. ИИ может проверить код по базовому чек-листу и найти тривиальные проблемы. Это позволит сэкономить время разработчика на проведение ревью, так как будет базовая проверка и уже дивому разрабу можно смотреть только критичные части в коде. 3. Автоматизация сборки интерфейсов. Мы сожем создать дизайн систему, а ИИ поручить создание структуры интерфейса, то есть что и где должно отображаться с использованием готового ui-kit. В итоге фронтенд разработчик не будет собирать интерфейс из готовых компонентов, а будет проводить ревью и добавлять бизнес-логику, вместо верстки. 4. Автоматизация создания базовых компонентов и сценариев. Например, создание формы можно сделать с помощью ИИ, просто задав ему структуру полей и правила валидации. Для каждого продукта можно выделить свои рутинные точки, которые не имеет смысл делать руками. Тут надо смотреть на команду. Я придерживаюсь принципов: "если в задаче есть повторяющиеся действия, то они должны быть автоматизированы" , "если задачу можно описать понятно, то ее можно сделать с помощью ИИ".

Про метрики и observability история, на мой взгляд, попроще. Начнем с метрик. Есть продуктовые метрики и метрики производительности, например, WebVitals. И есть утверждение, что WebVitals не отражает удовлетворение пользователя от продуктов. WebVitals могут быть отличными, но при этом целевое действие пользователь выполняет с неохотой, потому что долго или неудобно. И вот тут стоит создать свою систему метрик, которые будут достижимыми, на них можно повлиять и они важны для конечного пользователя. Например, открытие карты для выбора ПВЗ на странице оформления заказа выполняется 5 секунд. WebVitals может не среагировать на такое в ряде случаев, и мы не будем знать о проблеме и думать, почему растут отказы. В этом случае можно самим собирать метрику скорости загрузки карты с ПВЗ и следить за ней с помощью observability.

И вот тут, как мне кажется, может быть полезен ИИ. Мы автоматизируем сборку метрик и сохранение данных. Метрики стоит собирать с прода и пре-прод стендов. Дальше в процесс тестирования можно включить этап, когда происходит сверка изменений метрик на стендах, чтобы понимать как релизы на них влияют. И вот тут можно подключать ИИ для анализа этих самых метрик с двух сторон: 1. Прогнозирование изменений метрик в будущем, чтобы выдавать предупреждения о том, что продукт начал деградировать потцелевым показателям. 2. Поиск связей между изменениями метрик и задачи в релизе. То есть ИИ смотрит на метрику и пытается найти задачу, которая могла вызвать негативный эффект, чтобы ускорить реакцию команды на проблему.

С точки зрения перспектив я считаю, что они есть и будущее за эволюционным развитием процессов со вдумчивым подключением ИИ к процессам под дестким контролем и регулярной рефлексией с ответом на вопрос: "помогает ли ИИ оптимизировать процесс или создал новые проблемы?"