Как на самом деле работает жизненный цикл разработки ПО с ИИ?

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

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

Это различие важно, потому что объем кода почти ничего не говорит о прогрессе. В исследовании DORA ИИ назван усилителем той организации, в которой он работает. Я вижу то же самое на практике: четкие интерфейсы, быстрые тесты и дисциплинированный выпуск ускоряются, а расплывчатые требования, общие базы данных и медленное ревью начинают обходиться дорого со скоростью машины.

Оценивать нужно неопределенность, а не усилия

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

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

Для каждой задачи оценивайте окно доставки по простой модели:

delivery window = queue + clarification + implementation + review + verification + rollout + observation

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

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

При планировании мощности учитывайте людей, которые проверяют работу. Посчитайте часы ревьюеров по областям, доступность QA-окружений, окна миграций и число одновременных выпусков, за которыми способна следить дежурная команда. Если мощность реализации удвоилась, а эти пределы не изменились, плановый объем не должен удваиваться. Направьте свободное время агентов на устранение ограничения: создайте недостающие фикстуры, сократите тестовый набор, опишите интерфейс или автоматизируйте доказательства релиза. Так расплывчатое обещание продуктивности превращается в решение об очереди, которое CTO может проверить. Сообщайте диапазон вместе с его предположениями. Дата без предположений превращается в обещание, даже если исходная оценка явно зависела от условий.

Разумное обязательство в плане звучит так: «Мы ожидаем ограниченное изменение API на этой неделе. По переработке авторизации пока остается диапазон: в четверг решение по политике и нагрузочный тест прояснят два открытых риска». Такой ответ выглядит менее аккуратно, чем сумма сторипойнтов, зато он намного честнее.

Спецификации становятся главной инженерной поверхностью

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

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

Для многих ограниченных изменений достаточно такого компактного файла:

change: reject-expired-invitations
owner: identity-team
scope:
  allowed: [services/invitations, tests/invitations]
  forbidden: [services/billing, db/migrations]
invariants:
  - accepted invitations keep their current session behavior
  - expired tokens never create a user
acceptance:
  - unit tests cover expiry boundary in UTC
  - integration test returns 410 for an expired token
rollout:
  flag: invitation_expiry_v2
  first_stage: internal_accounts
stop_when:
  - schema change is required
  - session behavior differs from the invariant
evidence:
  - test commands and results
  - changed files
  - rollback command

Он предотвращает типичный сбой. Получив задачу «обработать просроченные приглашения», агент может добавить nullable-столбец, изменить разбор токена и обновить посторонний вспомогательный код сессий, потому что так проходят его локальные тесты. Контракт заставляет остановиться у границы схемы и вернуть конфликт человеку.

Храните такие контракты в системе контроля версий рядом с кодом. Они дают долговечное объяснение того, зачем существует изменение и какие компромиссы команда выбрала осознанно. NIST SP 800-218 рекомендует отслеживать требования безопасности, риски и проектные решения на протяжении разработки. С агентами этот совет становится еще полезнее: одна только история промптов плохо подходит для аудита, потому что в ней много шума, она привязана к конкретному инструменту и часто оторвана от ушедшего в релиз коммита.

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

Ревью смещается от авторства к доказательствам

Ревьюер должен сначала оценить заявленный результат, риск и доказательства, а уже потом читать каждую измененную строку. Традиционный пул-реквест исходит из высокой стоимости написания кода, поэтому по диффу ревьюер приблизительно восстанавливает ход мысли автора. Агент способен создать аккуратный и внутренне согласованный дифф, не понимая нарушенного бизнес-правила. Беглость текста повышает цену поверхностного ревью.

Требуйте, чтобы каждый пул-реквест отвечал на пять вопросов:

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

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

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

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

В записи об одобрении должны быть имя ответственного человека, класс изменения, выполненные проверки и срок действия каждого исключения. Фраза «проверено ИИ» ничего не говорит об ответственности. Агент может подготовить сводку и найти слабые места, но он не дежурит с пейджером, не объясняет риск клиенту и не решает, допустимо ли бизнес-исключение.

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

QA начинается до первой сгенерированной строки

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

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

Используйте четыре тестовых слоя с разными задачами. Быстрые модульные тесты и тесты свойств исследуют локальное поведение. Контрактные тесты защищают интерфейсы между сервисами и внешними потребителями. Небольшой набор сквозных тестов проверяет бизнес-пути в окружении, похожем на продакшен. Проверки во время работы подтверждают предположения, которые можно испытать только на продакшен-трафике. Дополнительные браузерные сценарии не заменят отсутствующий контрактный тест, а высокий процент покрытия не скажет, можно ли оформить возврат дважды.

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

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

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

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

Ограничения потока важнее числа агентов

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

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

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

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

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

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

Дежурный отвечает за каждое решение агента в продакшене

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

Рассмотрим предсказуемый сбой. Агент меняет поведение повторных попыток в воркере и добавляет экспоненциальную задержку. Модульные тесты проходят, трафика на стейджинге недостаточно для проявления проблемы, и в пятницу изменение уходит в продакшен. Теперь задачи живут дольше, удерживают подключения к базе данных во время повторов и подводят пул к исчерпанию. Задержка запросов растет в другом сервисе, поэтому первое предупреждение указывает в сторону от воркера.

При слабом жизненном цикле реакция ломается в четыре этапа:

1. Дежурный видит развертывание, но не понимает, какое поведение изменилось, потому что пул-реквест описывает файлы, а не замысел.
2. Сгенерированный ранбук предлагает перезапустить воркеры, что на время усиливает смену подключений.
3. У изменения нет флага, а откат одновременно отменяет постороннюю зависимость схемы из того же большого пакета.
4. Через несколько часов команда находит изменение повторов, сопоставив трассировки подключений со временем развертывания.

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

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

SRE Workbook от Google рассматривает бюджет ошибок как политику баланса между темпом релизов и надежностью. Применяйте тот же регулятор к пропускной способности агентов. Когда сервис расходует бюджет, сокращайте объем изменений, повышайте требования к доказательствам и направляйте агентов на задачи надежности. Бюджет должен менять разрешения в системе доставки, а не только цвет на дашборде.

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

Архитектура должна удешевлять ошибки

Лучшая архитектура для агентов дает явные границы, быструю обратную связь и обратимые релизы. Для этого не обязательно переходить на микросервисы. Модульный монолит с четким владением, типизированными контрактами, изолированными тестами и локальным запуском одной командой часто понятнее агентам и людям, чем распределенная система с расплывчатыми границами сервисов.

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

Сократите полномочия среды программирования. Дайте агенту реализации доступ на чтение репозитория и только нужные для задачи инструменты. Используйте краткоживущие учетные данные, отделяйте разработку от продакшена, записывайте вызовы инструментов и требуйте одобрения для изменений зависимостей, доступа к секретам, миграций и развертывания. Цель не в недоверии к каждому результату. Нужно не дать одному неверному выводу превратиться в широкое действие.

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

Записи архитектурных решений должны излагать ограничения языком, который агент способен применить. Фраза «используй стандартный шаблон» бесполезна, если шаблонов три. Назовите допустимое направление зависимостей, границу транзакции, поведение при ошибке и пример реализации. Если ревьюеры снова и снова исправляют одну и ту же сгенерированную ошибку, поправьте указания в репозитории или ограничитель вместо бесконечного повторения комментария.

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

Роли в команде смещаются к владению решениями

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

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

Младшие инженеры по-прежнему нужны, но обучение должно измениться. Если агент всегда выдает ответ, новичок способен сливать код, не формируя мысленную модель системы. Давайте ему собственные ограниченные сервисы, требуйте объяснять режимы отказа, подключайте к ревью и дежурствам с поддержкой, а оценивайте умение ставить диагноз, а не беглость промптов. Критическое чтение сгенерированного кода требует обучения.

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

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

Меняйте жизненный цикл через измеряемый эксперимент

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

Проведите эксперимент на нескольких циклах доставки и явно задайте рабочие правила:

1. Классифицируйте входящую работу по неопределенности и последствиям, а сначала разрешите агентам реализовывать только ограниченные классы.
2. Требуйте версионируемый контракт изменения и защищайте приемочные тесты от незаметного редактирования агентом.
3. Задайте лимиты на ревью и выпуск, назначив конкретного человека для одобрения чувствительных путей.
4. Привяжите сигналы продакшена и инструкции отката к каждому релизу, затем один раз выполните откат во время эксперимента.
5. Сравните время доставки, время ревью, долю неудачных изменений, время восстановления и нагрузку дежурных с прежней базовой линией того же сервиса.

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

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

Team & AI Audit от oleg.is изучает всю систему доставки: структуру команды, агентские инструменты, ворота ревью, QA и эксплуатацию продакшена, а не считает лицензии или созданные строки. Именно такой охват нужен руководителям, которые решают, сможет ли меньшая команда с ИИ безопасно отвечать за продукт.

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