Как перестроить разработку
в AI-Native режим или

Рассмотрим на реальном кейсе, как выглядит ИИ-трансформация разработки международной финтех-компании, где есть три продукта (платежная система, банк и крипта), миллионы пользователей, легаси, тяжелый переезд на новое банковское ядро, десятки платежных адаптеров, регуляторика, старые процессы, 500 инженеров, саботаж и вполне рациональный страх: если начать резко менять все везде и сразу, то компания может развалиться.

Основные задачи: ускорить миграцию банковского ядра, параллельно сократив время разработки платежных адаптеров. Моя роль — CAIO (Chief AI Officer). Формально задача звучала как внедрение ИИ в разработку, но по сути — перестройка всей производственной системы, потому что просто раздать людям Cursor или доступ к LLM в такой компании означает не ускорить разработку, а ускорить хаос.

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

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

Аудит и спецификация: с чего начинается AI-Native

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

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

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

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

Продукт как объект управления

Продукт в этой модели рассматривается как объект управления. Его нельзя держать только в головах продактов, аналитиков, архитекторов и разработчиков. Он должен быть описан на нескольких уровнях. Сначала фиксируется продуктовый слой: что это за продукт, какую задачу пользователя он решает, какие фичи существуют, какие пользовательские сценарии поддерживаются, какие продуктовые метрики важны и какие изменения планируются. Это нужно для того, чтобы разработка начиналась не с вопроса “какой код написать?”, а с вопроса “какое поведение продукта мы хотим получить?”.

Следующий слой — бизнес-требования. Здесь мы описываем сценарии использования по каждой фиче в формате Gherkin, через Given — When — Then. Это не дань моде, а способ сделать поведение системы проверяемым. Вместо абстрактной фразы “пользователь должен иметь возможность оплатить услугу картой” мы описываем конкретный сценарий: в каком состоянии находится пользователь, какое действие он совершает, что должна сделать система, какие проверки выполнить, какие статусы вернуть, что показать на интерфейсе и какие исключения обработать. Такой подход называется BDD — Behavior-driven development. Его смысл в том, чтобы бизнес, аналитик, инженер, тестировщик и агент работали с одним и тем же описанием поведения, а не каждый интерпретировал задачу по-своему.

На основе бизнес-сценариев формируются функциональные и нефункциональные требования. Функциональные требования описывают, что система должна делать. Нефункциональные фиксируют, как хорошо она должна это делать: производительность, надежность, безопасность, доступность, масштабируемость, наблюдаемость, устойчивость к сбоям, качество данных, соответствие регуляторным требованиям и качество ИИ-сервисов, если они встроены в продукт. Каждое требование получает ID. Без ID невозможно связать требование с тестом, задачей, кодом, релизом и метрикой. А без такой связки AI-Native разработка быстро превращается в набор несвязанных артефактов.

Дальше описывается технический слой: кодовая база, сервисы, API, UI, инфраструктура, схемы данных, потоки данных, интеграции, архитектурные ограничения, безопасность, CI/CD, ИИ-сервисы, RAG, промпты, модели, агентные цепочки и критерии качества ИИ. Очень важно, что ИИ-сервисы должны быть частью архитектуры. Промпт — это часть системы, контекст — часть системы. Версионирование промптов — тоже часть системы. И оценка качества ответа — также часть системы. Если это не описано, этим невозможно управлять.

Любое изменение в такой модели оформляется как Change Request. CR фиксирует, что именно меняется, зачем это нужно, какие элементы системы затрагиваются, какое текущее состояние AS-IS, какое целевое состояние TO-BE, какие требования меняются, какие тесты нужны, какие риски возникают и какие метрики должны улучшиться. Разница между AS-IS и TO-BE превращается в план разработки. Здесь подключается агент в роли Project Manager: он декомпозирует изменение в роадмап, фичи, задачи и подзадачи, а для каждой задачи формирует критерии приемки. Это критически важно, потому что если команда не может формально описать, что значит “готово”, агент тоже не сможет стабильно довести задачу до результата. Плохо поставленная задача с ИИ просто быстрее превращается в плохой результат.

От спецификации к тестам и коду

После спецификации и Change Request подключается агент-инженер по тестированию. Его задача — не просто написать тесты, а построить стратегию проверки по слоям архитектуры. Он формирует юнит-тесты, интеграционные тесты, end-to-end сценарии, проверки API, данных, инфраструктуры, клиентской части и ИИ-сервисов. Каждое требование должно быть покрыто тестами, а ID требования должен связываться с ID теста. Так появляется цепочка: требование — тест — задача — код — релиз — метрика. Именно эта цепочка превращает разработку из набора ручных действий в управляемую производственную систему. Без тестов AI-Native подход остается вайбкодингом.

И только теперь мы переходим к написанию кода: после того, как есть спецификация, требования, тесты и критерии приемки. Это называется TDD — Test-driven development. Сначала требование, потом сценарий, потом тест, потом код, потом прогон тестов, потом проверка продукта как пользователь, потом обновление спецификации. В такой системе человек перестает быть писателем тысяч строк кода. Его роль становится выше: постановка задачи, управление контекстом, архитектурные решения, проверка результата и ответственность за продукт.

Изменение операционной модели и культуры

Но технической методологии недостаточно. Тут как раз и терпят неудачи большинство ИИ-трансформаций. Компания может собрать агентов, настроить RAG, описать спецификации, внедрить тесты и провести несколько воркшопов, но через два месяца все вернется к старому процессу, если не поменять операционную модель. AI-Native разработка — это не просто новые инструменты. Это изменение оргструктуры, ролей, культуры, обучения, онбординга, коммуникаций и технической организации работы.

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

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

Лид в AI-Native компании — это человек, который управляет производственной системой команды. Он должен понимать, как ставить задачи агентам, как работать со спецификацией, как поддерживать документацию актуальной, как проверять сгенерированный результат, как строить трассируемость требований, как организовывать тестирование, как строить и читать дашборды, как разбирать ошибки и как перевести команду в новый режим.

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

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

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

Новые сотрудники в такой системе онбордятся уже не через хаотичные созвоны и фразу “поговори с Васей, он точно знает”. Они заходят во внутреннюю академию и видят, как в компании принято работать: как устроена спецификация, как писать требования, как оформлять Change Request, как работать с агентами, как описывать Gherkin-сценарии, как строить тесты, как проверять сгенерированный код и как пользоваться дашбордом. Это резко снижает зависимость от старожилов и ускоряет включение новых людей в работу.

Инфраструктура и дашборды

Методология должна быть встроена и в технический контур разработки. Нужен единый репозиторий спецификаций, единый формат требований, единый формат Change Request, единая логика ID для требований, тестов, задач и релизов, правила работы с RAG, версионирование промптов, пайплайны генерации и проверки кода, CI/CD, регрессионные тесты, ревью безопасности и архитектуры, проверка моделей, а также продуктовый и технический дашборд для мониторинга.

Дашборд должен показывать состояние системы, продукта, ИИ-сервисов, стоимость ИИ-инференса, экономику фич, актуальность спецификаций и узкие места процесса. AI-Native разработка без дашборда — это самолет без приборной панели: вроде летим, но непонятно куда, на какой высоте и сколько осталось топлива.

В такой системе появляется новая роль — AI Product Engineer. Это не классический разработчик, не просто продакт или аналитик. AI Product Engineer — это человек, который понимает продукт, бизнес-требования, архитектуру и умеет управлять разработкой через ИИ-агентов. Он связывает пользовательскую потребность, бизнес-логику, спецификацию, требования, архитектуру, данные, тесты, код и метрики вместе. Раньше для этого требовалась команда из нескольких специалистов, но теперь часть работы можно отдать агентам, а ответственность все равно остается у человека.

Ответственность за продукт

Именно ответственность становится главным человеческим навыком. В старой парадигме человек часто отвечал за выполнение задачи. В новой модели он отвечает за сам продукт.

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

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

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

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

Второе направление — поиск новых людей и ИИ-чемпионов. Чемпионов нужно выявлять на хакатонах, интенсивах и буткемпах. В обычном интервью человек легко расскажет, что “работает с ИИ”, но в реальной задаче сразу видно, кто действительно мыслит через ИИ. Здесь же становится понятно, кто из текущих сотрудников способен перейти в новую роль, а кому комфортнее оставаться в старой.

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

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

Реальные эффекты и сокращения

Теперь вернемся к заголовку. “Как перестроить разработку и сократить 250 айтишников” звучит провокационно, но суть не в сокращении ради сокращения. Суть в том, что в старой модели компания может держать 500 разработчиков и все равно двигаться медленно.

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

В новой модели часть этой работы забирают агенты, спецификации, тесты, RAG, дашборд, внутренняя академия и грамотно организованный процесс. Тогда меньшая команда может делать больше. Не потому что людей “заменили ИИ”, а потому что люди перестали работать в хаосе. ИИ дисциплинирует, а человек остается там, где он действительно нужен: в постановке целей, продуктовом мышлении, архитектурных решениях, управлении рисками, валидации результата, ответственности, работе с неопределенностью и принятии решений, где важны бизнес-контекст, безопасность, этика и здравый смысл.

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

По эффекту результаты были разными в зависимости от типа задач. Минимальное ускорение разработки составило около 20% (да, с учетом сокращения половины команды результаты только улучшились), среднее — примерно 40%, а на отдельных задачах, например в разработке платежных адаптеров, ускорение было от двух до четырех раз. Я считал время от постановки задачи до релиза, покрытие тестами, скорость онбординга и количество дефектов после релиза.

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

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