Как перестроить разработку и сократить 250 айтишников

Написал новую статью про один из моих последних кейсов. Название звучит провокационно, но статья не про сокращения ради сокращений.

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

В общем, как я в роли CAIO (Chief AI Officer) в международной финтех-компании перестраивал разработку продуктов. Как бы сделать это так, чтобы ничего не сломать?

Главный принцип: AI-Native разработка начинается с правильно оформленной спецификации.

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

И конечно, строить с нуля намного легче, чем трансформировать что-то существующее.

В статье я разбираю, как устроена AI-Native разработка:

• агент-археолог восстанавливает текущее состояние продукта;

• агент-аналитик превращает спецификацию в центр управления: от фичей и пользовательских историй до описания поведения системы в виде сценариев использования и требований;

• Change Request связывает AS-IS и TO-BE, а агент-менеджер составляет план разработки;

• требования получают ID и мэтчатся с тестами, задачами, релизами и метриками;

• тесты становятся обязательными на всех уровнях архитектуры: так мы переходим к TDD (Test-driven Development);

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

В итоге за 3 месяца удалось добиться ускорения релиза новых фичей минимум на 20%, в среднем — на 40%, а в некоторых кейсах — от двух до четырех раз.

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

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

В новой AI-Native модели человек управляет продуктом целиком: ставит задачи агентам, управляет контекстом, принимает архитектурные решения, проверяет результат и несет ответственность за весь продукт.

Так появляется новая роль — AI Product Engineer. Поэтому главный вопрос не в сокращениях, а в том, какая команда нужна компании, если больше не надо вручную писать код? Мы же не пишем двоичный код, а пользуемся высокоуровневыми языками программирования – а сегодня используем естественный язык.

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

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

Но будущее не в том, чтобы быстрее делать старую работу, а в том, чтобы строить новую систему. И именно этому теперь надо учить людей — чтобы они быстрее адаптировались к новой реальности.

Ну а я двигаюсь дальше: следующая задача — внедрить AI-Native подход в производство гуманоидных роботов. Следите за обновлениями.

👉 Полная статья

#кейсы