Как перестроить разработку и сократить 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 подход в производство гуманоидных роботов. Следите за обновлениями.
👉 Полная статья
#кейсы
Написал новую статью про один из моих последних кейсов. Название звучит провокационно, но статья не про сокращения ради сокращений.
Она про то, что в старой модели компания может держать 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 подход в производство гуманоидных роботов. Следите за обновлениями.
👉 Полная статья
#кейсы