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

Контекст обычно был примерно такой. Есть устоявшаяся команда, есть зрелый продукт, но, по мнению менеджмента, разработка идет слишком медленно. ИИ-инструменты и кодинговые агенты внутри команды либо почти не используются, либо используются точечно, каждым по-своему, без общего подхода. Иногда их уже пробовали, но результат оказался слабее ожиданий. А на рынке в это время появляются истории о том, как CEO или CPO за ночь собирают прототипы с помощью Codex или Claude Code.

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

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

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

Первая команда

У первой команды процессы более-менее выстроены. Люди умеют фиксировать мысли в текстовом и визуальном виде и передавать контекст друг другу. Типичная цепочка выглядит так:

идея → бизнес-требования и макеты → системные требования → архитектура → задачи на разработку

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

Обычно такие команды неплохо умеют работать асинхронно. Люди пишут документы, оставляют после себя след в виде решений, описаний и ревью-комментариев. Это помогает не только людям, но и ИИ.

Вторая команда

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

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

В какой команде ИИ взлетит быстрее

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

Допустим, разработчику выдали доступ к ChatGPT, Claude Code или другому ассистенту. Внутри такого инструмента — большая языковая модель. Она генерирует ответ, опираясь на тот контекст, который ей передали.

И вот здесь возникает ключевой вопрос: какая из двух команд быстрее получит реальную пользу от ИИ?

Очевидно, первая.

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

Пример запроса может выглядеть так:

Ты — опытный backend-разработчик. В приложенном документе описаны бизнес- и системные требования для фичи обработки банковских выписок. В RFC-123 зафиксирована текущая архитектура. Предложи вариант реализации нового метода API GET /bank-statements/. Также учти наши стандарты разработки: стиль кода, подход к REST API и требования к автотестам. Сначала предложи план реализации, затем список изменений по слоям системы и набор тест-кейсов.

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

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

Вывод

Из этого следует простой вывод: внедрение ИИ зависит не только от интереса к технологии, но и от зрелости производственных процессов.

Context is king — и в общении с людьми, и в работе с ИИ.

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

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

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