По понятным причинам, большинство компаний сейчас хотят себе AI-native SDLC (мне больше нравится термин AI-driven SDLC, но он пока проигрывает по популярности использования). И тут их поджидает неприятный сюрприз - текущая архитектура, процессы и команды зачастую просто не готовы к таким изменениям. Они строились под совершенно другие реалии, в основе которых лежали два фундаментальных ограничения: «писать код руками долго и сложно» и «люди могут освоить и поддерживать узкий спектр знаний».

Если хочется быстрее - нужно делать параллельно. Чтобы делать параллельно, нужно больше людей. Люди обладают узкими техническими навыками, поэтому нужны разные специализации разработчиков. Так как они работают над одной фичей, то нужно объединить их в команды. У бизнеса нет времени и желания готовить качественные артефакты для разработки - введем дополнительные роли как бизнес-аналитик или проектный менеджер. Вдобавок к узкой специализации, разработчики не могут объективно проверять свою работу. Добавим в команду QA инженеров. Вот у нас и получилась современная команда разработки из FE, BE, QA и дополнительных ролей.

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

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

Очень сомневаюсь. А практика показывает, что результаты получаются далекими от ожиданий. Разработчики начинают генерировать в разы больше кода и создают огромную нагрузку на этап тестирования, который в большинстве компаний остался ручным или полуручным с фокусом на end-to-end тестирование. И тут появляется целый пучок новых проблем от масштабирования окружений до экстренной минимизации ручного тестирования. Если бизнес по-прежнему не вовлекается в процесс разработки, то возникает еще более забавный эффект «слопогенерации». Раньше, во время долгой разработки, у команды возникали дополнительные вопросы к бизнесу и ответы находились до завершения работы. Сейчас же LLM способны закрыть все пробелы догадками или предположениями, из которых потом генерируется решение. И чем таких пробелов больше, тем дальше решение будет от ожиданий бизнеса. Это всего лишь пара примеров ожидаемых эффектов.

Каким же компаниям AI-native SDLC «из коробки»поможет выйти на новый уровень производительности? Тем, у кого уже есть такие практики как сервисная архитектура с разделением по доменному принципу, Continuous Delivery, QA стратегия с прицелом на максимальную автоматизацию, маленькие доменные команды с вовлеченным PO, легко масштабируемая инфраструктура и т.д. То есть, AI снова делает сильных кратно сильнее, а слабых не особо усиливает.

Поэтому внедрение AI-native SDLC - это не про AI инструменты и модели, а про внутреннюю трансформацию организации. А она на порядок сложнее чем внедрение новых инструментов.

Напоминаю, что через 2 недели, 26 октября стартует мой тренинг Effective development with Claude Code. Данной теме там будет уделено достаточно много внимания в последних нескольких модулях. Присоединяйтесь, еще осталось 5 мест!